Multi-Entity Compliance: Running SOC 2, ISO 27001, HIPAA and GDPR Across Subsidiaries

Short answer: Multi-entity compliance works best when you define controls once at group level, let each entity inherit them, and add only the controls that local systems or laws require. Scope SOC 2 reports around systems, not legal entities, and draw the ISO 27001 scope around one management system. Then handle GDPR roles, data transfers and HIPAA designations entity by entity.

Related guides:

• Unified compliance framework: one control set for every framework
• Mapping common criteria for SOC 2 and ISO 27001
• Compliance controls explained

Key takeaways

• Choose an operating model first: centralized, federated or separate. The choice follows how integrated the entities' people, systems and customers really are, not the org chart.
• Split controls into three layers: group-wide shared controls, entity-specific controls and local legal requirements. Each entity inherits the first layer and owns the other two.
• A SOC 2 report describes a system. One report can cover services run by several entities, or each entity can have its own.
• An ISO 27001 certificate covers one management system. Several sites or entities can sit under it if a central function runs that system.
• Under GDPR, each legal entity can be its own controller. Intra-group data flows need roles, contracts and transfer safeguards just like external ones.

---

Should you run one compliance program or one per entity?

Run one program when entities share infrastructure, people and customers, and split it only where the business is genuinely separate. Most growing groups land somewhere between the extremes, so treat this as a spectrum.

Model	How it works	When it fits	Watch out for
Centralized	One control library, one risk register, one policy set, one audit calendar. Entities are scope labels.	A US parent with small EU and UK entities that sell the same product on the same cloud account.	Local legal requirements get lost. Entity leaders feel no ownership.
Federated	A group security team owns shared controls. Each entity owns its local controls and evidence.	A group with a few products, or a recent acquisition that still runs its own stack.	Gaps between "shared" and "local" if nobody maps inheritance explicitly.
Separate	Each entity runs its own program, audits and certificates.	A regulated or ring-fenced subsidiary, or a portfolio company you may sell.	Duplicated policies, risk assessments and evidence for the same control.

Two questions usually decide it. First, do the entities use the same identity provider, cloud accounts and engineering team? If yes, centralize those controls, because splitting them creates paperwork without reducing risk. Second, do customers buy from the entities separately and ask each for its own assurance? If yes, you may still need separate reports or certificates, even on top of a shared control base.

Which controls should be shared across entities?

Share every control that is operated by the same people on the same systems, and keep only genuinely local work at entity level. This layered model is what prevents duplication.

1. Group-wide shared controls. Identity and access management, MFA, endpoint management, security awareness training, vendor risk management, incident response, the information security policy set and the risk methodology. A group team owns these and collects evidence once.
2. Entity-specific controls. Anything tied to a system or process only one entity runs: an acquired company's separate cloud account, a clinic software product with its own change management, a local HR onboarding process. The entity owns the control and its evidence.
3. Local legal requirements. Obligations that attach to a legal entity, such as its records of processing, data protection contracts, regulator registrations and HIPAA documentation. These cannot be inherited, because the law binds the entity itself.

Write inheritance down. For each entity, list which shared controls apply, which are excluded (and why), and which local controls supplement them. This mirrors the way complementary user entity controls split responsibility between a provider and its customers, except that here the split is inside your own group.

Evidence ownership follows the same layers. Shared controls get one evidence owner at group level, tagged to every entity that inherits them. Entity controls get a named local owner. When an auditor for one entity asks for MFA evidence, you hand over the group evidence plus the entity's inheritance record, rather than collecting it again.

Do you need a separate SOC 2 report for each entity?

No, not necessarily. A SOC 2 report is about a system, so one report can cover services that several entities deliver together, as long as the system description makes the boundaries clear.

The AICPA SOC 2 description criteria are used to prepare and evaluate the description of the service organization's system. That description, not the legal structure, defines what the auditor tests. In practice you have three options:

• One report, one combined system. Name the entities involved in the system description and explain which entity performs which part of the service. This fits when entities deliver one product together, for example engineering in one country and support in another.
• One report per system. If the group sells two distinct products on different stacks, describe each system separately. The shared controls are still tested once per examination, but each report stays readable for its customers.
• Treat a related entity as a subservice organization. If one entity provides hosting or support to another, the AICPA SOC 2 guide covers how subservice organizations are presented in a report. Agree the approach with your auditor early, since it changes what gets tested.

In our experience, buyers care less about which entity signed the report than whether the report covers the service they are buying. Make sure the system description uses the product names your customers recognize.

Can one ISO 27001 certificate cover several entities?

Yes, if the entities are covered by one information security management system (ISMS). ISO/IEC 27001:2022 requires you to determine the boundaries and applicability of the ISMS in clause 4.3, and that scope statement can name several entities, locations and services.

Certification bodies audit multi-site organizations under IAF MD 1, the International Accreditation Forum's mandatory document for multi-site certification. It applies to an organization "covered by a single management system" with an identified central function that is responsible for and centrally controls that system. Among its conditions:

• the organization has a single management system and a centralized management review;
• the central function is part of the organization and is not subcontracted to an outside party;
• all sites are covered by the organization's internal audit programme.

IAF MD 1 also says that where a sector standard has its own multi-site rules, those take precedence, and it names ISO/IEC 27006 (the standard for ISMS certification bodies) as an example. So ask your certification body how it applies sampling to your sites before you commit to a scope.

If an acquired company runs its own ISMS, IAF MD 1 does not cover groups running multiple management systems. You can either keep its certificate separate for now or merge its ISMS into yours and extend the scope at a later audit.

How do GDPR and HIPAA treat a group of companies?

Both laws look at legal entities, not the group brand. Under GDPR each entity has its own role, and under HIPAA affiliated entities can choose to act as one.

GDPR. The GDPR defines a "group of undertakings" as a controlling undertaking and its controlled undertakings (Art. 4(19)), but it does not treat the group as one controller. Work through these points for every entity:

• Role. Decide whether each entity is a controller, a processor or a joint controller for each processing activity. Where two or more controllers jointly determine the purposes and means of processing, Art. 26 requires an arrangement that sets out their responsibilities.
• Intra-group contracts. When one entity processes data on another's behalf, Art. 28(3) requires that processing to be governed by a contract or other legal act. Many groups sign one intra-group data processing agreement that all entities accede to.
• Transfers. Transfers to group entities outside the EEA need a safeguard under Art. 46, such as standard data protection clauses adopted by the Commission. Larger groups may use binding corporate rules, which the competent supervisory authority approves through the consistency mechanism under Art. 47. A UK entity follows the UK regime, and the ICO publishes guidance on its own transfer tools.
• Lead authority. For cross-border processing, Art. 56 makes the supervisory authority of the main establishment the lead authority. For a controller, Art. 4(16) defines the main establishment as the place of its central administration in the Union, unless processing decisions are taken at another EU establishment. A US parent whose EU decisions are made in the US should get advice on how this applies.
• DPO. Art. 37(2) lets a group of undertakings appoint a single data protection officer, provided the DPO is easily accessible from each establishment.

HIPAA. Under 45 CFR 164.105(b), legally separate covered entities under common ownership or control may designate themselves as a single affiliated covered entity, and the designation must be documented. This matters for a HealthTech that acquires a clinic software company that is itself a covered entity. If the acquired company is a business associate instead, the designation does not apply and its BAAs stay with that entity.

How do you bring an acquired company into the program?

Start with discovery, keep its existing assurance alive, then merge controls layer by layer. Rushing to rip out an acquired company's controls often breaks the evidence trail its customers rely on.

Onboarding checklist:

• Inventory assurance. Collect existing SOC 2 reports, ISO 27001 certificates, HIPAA risk analyses, BAAs and customer security commitments.
• Map legal roles. Record whether the company is a controller, processor, covered entity or business associate for each service.
• Run a gap assessment against your group control library, not against each framework separately.
• Keep interim coverage. Let existing reports and certificates run until your scope extension is ready, so customers are not left without assurance.
• Connect shared controls first. Move the company onto group identity, endpoint management, training and vendor review, then mark those controls as inherited.
• Assign local owners for the controls that stay entity-specific.
• Sign intra-group agreements for data processing and transfers.
• Update risk registers so the new entity's risks appear in the group register.
• Extend scope in the next SOC 2 system description and ISO 27001 scope statement, after talking to your auditor and certification body.

Treat the timing as an example only. Integration speed depends on how different the two stacks are and on the audit calendar you inherit.

How SecureSlate helps

SecureSlate gives growing groups one control library with multi-framework control mapping across SOC 2, ISO 27001, HIPAA, GDPR and more, so a shared control is written once and mapped everywhere. Custom frameworks and controls let you model entity-specific and local requirements. Agentless read-only cloud integrations and the device agent collect evidence across each entity's accounts and endpoints. Access reviews, vendor risk management, risk management and audit management keep every entity on the same cadence, and a trust center plus security questionnaire automation help each business answer its own customers.

FAQ

Is multi-entity compliance the same as a unified compliance framework?

No. A unified compliance framework maps one control set across several frameworks. Multi-entity compliance applies that control set across several legal entities, deciding which controls each entity inherits and which it owns. Most groups need both.

Can a subsidiary use its parent's SOC 2 report?

Only if the subsidiary's services are inside the system the report describes. A customer of the subsidiary needs to see its service in the system description. Otherwise the subsidiary needs its own report or a scope extension.

Does each EU entity need its own GDPR records?

Each entity acting as a controller or processor carries its own GDPR obligations, so in our experience it is clearer to keep processing records per entity, even if one group team maintains them.

Should an acquired company keep its own ISO 27001 certificate?

Often, at first. IAF MD 1 covers one management system, so an acquired company with its own ISMS is usually kept separate until it is merged into the group ISMS and the scope is extended.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.