Multi-Rooftop Dealership Group Compliance
A dealership group manages compliance across rooftops by running one framework everywhere, scoping access so each store sees only its own data while ownership sees all of it, and deciding deliberately whether the FTC Safeguards Rule information security program is written once for the group or separately per legal entity. Rooftop-by-rooftop tools make group-level reporting impossible.
What makes group compliance different from single-store compliance?
A single store answers one question: are we compliant. A group answers three: is each store compliant, are they compliant in the same way, and can we prove it as a group. The second and third are where most groups struggle, and neither is solved by buying more copies of a single-store tool.
The failure pattern is familiar. Each rooftop adopts something at a different time. One uses a training vendor, another a safety consultant, a third has a binder. Every store can produce something, and ownership cannot produce anything about the group. When a lender or an insurer asks a portfolio-level question, the answer takes three weeks of email.
How should the information security program be structured across entities?
The Safeguards Rule attaches to the financial institution. Where rooftops are separate legal entities, each is a financial institution in its own right, and each owes a program. That does not mean each needs a document written from scratch.
Two structures work in practice:
- One program, store appendices. A group-level program covering shared systems, shared IT administration, and shared policy, with a per-store appendix capturing that store's risk assessment, systems, and physical conditions. Maintained once, accurate everywhere.
- Separate programs per entity. Appropriate where entities genuinely operate independently: different DMS, different network, different IT provider. More maintenance, but honest.
The structure that fails is a single generic document naming the group and describing no store in particular. It satisfies nobody reading it closely, because the risk assessment at 16 CFR 314.4(b) has to reflect actual conditions.
Who can hold the Qualified Individual role?
The Qualified Individual can sit at an affiliate or at a service provider rather than on the dealership's own payroll (16 CFR 314.4(a)). That is what makes one appointment across commonly owned entities workable instead of eight hires.
Two conditions come with using someone outside the dealership. The dealership keeps responsibility for compliance, and it has to name a senior member of its own personnel to direct and oversee whoever holds the role.
Groups get the first condition right and skip the second. The role goes to a vendor, nobody inside the group is named to oversee them, and the file shows a Qualified Individual while no one at the group can say what that person did this year.
Who gets the annual written report?
The Qualified Individual reports in writing at least once a year to the board of directors or equivalent governing body (16 CFR 314.4(i)). Where there is no board, the report goes to a senior officer responsible for the information security program.
Eight entities means eight reports, unless those entities share one governing body, which most dealer groups do. The workable structure is a single report with a section per store, covering what the Rule asks for: the status of the program, compliance with the Rule, and material matters including the risk assessment, risk management and control decisions, service provider arrangements, test results, security events and the response to them, and recommendations for change.
A report that describes the group and names no store fails the way the generic program document fails. Ownership signs something that reads well and proves nothing about the store an examiner asks about.
Which entity owns which obligation?
Group structure decides who holds the paperwork and who signs it. It does not reduce the number of times each obligation is owed.
| Obligation | Who owes it | What proof looks like |
|---|---|---|
| Information security program (16 CFR 314.4) | Each entity that is a financial institution | A written program whose risk assessment describes that store's systems and physical conditions, not the group's in general. |
| Qualified Individual (314.4(a)) | Each entity designates one, and the same person may serve several | A written designation per entity, plus the named senior employee inside the group who directs and oversees that person. |
| Risk assessment (314.4(b)) | Each entity | A written assessment naming that store's DMS, network, service providers and physical conditions. |
| Testing (314.4(d)) | Each entity | Continuous monitoring, or an annual penetration test plus vulnerability assessments at least every six months. |
| Annual written report (314.4(i)) | The Qualified Individual, to each governing body | A report covering program status, compliance and material matters, with the store named. |
| FTC notification (16 CFR 314.4(j)) | The entity that held the data | Notice to the FTC within 30 days of discovering an event involving unencrypted customer information of 500 or more consumers. |
| OSHA 300 log and 300A posting | Each establishment | That site's own log, and the 300A posted at that site for its own employees. |
What should group-level reporting show?
Ownership needs to answer four questions without opening individual store reports:
- Which rooftops are below an acceptable score, and on which pillar.
- Where are remediations overdue, and who owns them.
- Which stores have training gaps, and in which departments.
- Which vendors are unattested, and at which locations.
ARMP produces location grades side by side inside one group view, drawn from the same audit data the individual store sees. The score breaks into audit, cybersecurity, documentation, training, and vendor pillars, and is snapshotted over time, so a group can see whether a store is genuinely improving or was simply audited on a good day.
How does access scoping actually work?
Store scoping and role permissions are separate axes, and a group needs both. Role determines what kind of thing someone can do: an employee takes training, a manager assigns it, a Qualified Individual oversees the program. Store scope determines which rooftops that applies to.
ARMP handles this with a current-store context per user and store-level policies enforced on the data, so a manager assigned to two rooftops sees exactly those two. A consultant or owner-level account spans the group. The practical consequence is that a general manager promoted over an additional store gains that store's data without a new login.
How should a group sequence a rollout?
Attempting every rooftop at once is the common mistake; it produces a large simultaneous remediation load with no one available to close it. A workable sequence:
- Baseline one store first. Pick a mid-sized rooftop, not the best or worst, and run the full assessment. This calibrates what the findings volume actually looks like.
- Fix the group-level items once. Vendor attestations, shared IT controls, MFA, and policy documents usually resolve across the group rather than per store.
- Roll the on-site assessment out in waves. Two or three rooftops at a time, so remediation capacity keeps pace.
- Standardise training assignment by role and department, and let expiry run rather than re-enrolling manually.
- Set the group reporting cadence and hold a standing review, so scores are looked at rather than accumulated.
What changes when the group crosses a state line?
Federal OSHA covers part of the country. Around twenty states run their own OSHA-approved plan, which has to be at least as effective as the federal program and in several states is stricter, with its own reporting timelines and its own inspectors. A group operating on both sides of that line runs two sets of rules for the same task, and one written safety program citing the federal standard will be short in one of them.
Breach notification splits the same way. The Safeguards Rule sets the FTC deadline at 30 days for an event reaching 500 consumers (16 CFR 314.4(j)). Every state also has its own notification law, with its own threshold, its own deadline and its own definition of personal information, and the law that applies is the one where the affected customer lives rather than where the store sits. A group selling across a state line runs more than one clock on the same incident, and the shortest one governs how fast anybody has to move.
What changes when the group acquires a store?
An acquired rooftop is not a blank slate; it is someone else's compliance history. Assess it on the group framework before assuming anything, because self-reported condition at handover is routinely optimistic. Pull its vendor list into the group inventory and re-attest, since the acquired store's vendor agreements were written for a different entity. Migrate training records rather than resetting everyone, or the store will spend a quarter retaking courses that were already valid. And confirm whether the entity structure changed, because that determines whether the store joins an existing information security program or needs its own.
Related guides
Frequently asked questions
Does a dealership group need one Qualified Individual or one per store?
The Safeguards Rule requires a single Qualified Individual per covered financial institution. Whether that is one person for the group or one per rooftop depends on the legal entity structure: separate corporate entities are separate financial institutions. Many groups appoint one Qualified Individual across commonly owned entities with designated site contacts underneath, which is workable provided that individual genuinely has authority at every store rather than nominal oversight.
Can one information security program cover every rooftop?
It can, provided it reflects the actual conditions at each store rather than describing a generic dealership. Where rooftops share systems, a DMS, and IT administration, a single program with store-specific appendices is usually stronger than separate documents, because it is maintained once. Where a store runs a different DMS or a different network, that difference has to appear in the program or the risk assessment is inaccurate for that location.
How should access be scoped across a group?
By store, with role layered on top. A service manager at one rooftop should not see another rooftop's audit findings or employee records. A general manager over three stores should see those three. Ownership and the compliance officer should see everything without switching accounts. Getting this wrong in either direction causes problems: too open exposes employee data across entities, too closed means nobody can produce a group-level answer.
What does a group need that a single store does not?
Comparability and consolidation. Comparability means every rooftop is audited against the same framework, so a score of 82 at one store means the same thing as 82 at another. Consolidation means ownership can see the group in one view, with location grades side by side, rather than opening seven reports. Without both, the group has seven compliance programs rather than one.
How do acquisitions affect group compliance?
An acquired rooftop arrives with its own history: existing audit findings, undocumented vendor relationships, training records in another system, and often no written information security program. The practical sequence is to assess the new store on the group framework first to establish a real baseline, bring its vendor inventory and attestations into the group record, then migrate training history rather than resetting every employee to zero.