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.

Multi-Rooftop Dealership Group Compliance

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.

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 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.