In a group of companies, cyber risk is managed centrally but legal accountability sits with each subsidiary's own board, and most governance failures happen in the gap between the two. A group CISO can set one standard, run one security operations centre and buy one identity platform, yet a regulator will still ask a named subsidiary director why that entity failed to meet its obligations. This guide covers what is specific to holding company and subsidiary structures: legal entity accountability, local regulators and boards, how group policy cascades into entities, how shared security services are charged and documented, and how to bring acquired companies into the model. It builds on the centralised, federated and hybrid basics in the Security Operating Model and Organisation Design Guide and is written for group CISOs, subsidiary security leads, company secretaries and the risk and legal teams who support them.
Key takeaways
- Accountability does not consolidate. Laws such as NIS2 and DORA place duties on each regulated entity and its management body, even when the group provides every control.
- Group policy needs local adoption. A group standard binds a subsidiary only when its own board adopts it, with local variations recorded where national law requires them.
- Intra-group services are still third-party services. DORA treats an ICT intra-group service provider within the same third-party framework, so shared services need contracts, service levels and exit plans like any supplier.
- Group size changes the penalty exposure. NIS2 maximum fines are calculated on the worldwide turnover of the undertaking the entity belongs to, which brings group finances into subsidiary risk.
- Acquisitions are where the model is tested. Define day-one minimum controls, a convergence timeline and a decision on whether the acquired company keeps its own identity estate.
Why groups are different from single organisations
A single company has one board, one set of legal obligations and one risk appetite. A group has several of each, joined by ownership but not by law. Three facts shape everything that follows.
- Separate legal persons: each subsidiary is its own company with directors who owe duties to that company. A parent can direct, fund and influence, but in most jurisdictions it cannot simply override a subsidiary board's legal duties.
- Several supervisors: a bank, an insurer, an energy supplier and a software subsidiary in the same group may each answer to a different regulator in a different country, with different reporting deadlines.
- Shared technology: in practice the group usually runs identity, email, cloud tenancy, detection and response centrally. The control lives in one entity; the obligation lives in another.
Banking supervisors have long written this down. The European Banking Authority's Guidelines on internal governance (EBA/GL/2021/05) ask parent undertakings and subsidiaries to keep governance arrangements consistent and well integrated on a consolidated or sub-consolidated basis (paragraph 83), and say that a subsidiary's management body should adopt and implement group-wide policies at individual level in a way that complies with EU and national law (paragraph 84). The same logic works for cyber governance in any sector: the group designs, the entity adopts and remains accountable.
Legal entity accountability
Start by building an entity register for security purposes. For each legal entity, record its country, its regulated activities, its supervisors, the laws that apply to it, its directors, its named security lead and the group services it consumes. Without that register, nobody can answer the first question in an incident: which entities must report, to whom and by when.
| Obligation | Who it attaches to | Group angle | Source |
|---|---|---|---|
| NIS2 risk-management measures and management body approval | Each essential or important entity; its management body must approve the measures, oversee them and can be held liable (Art. 20(1)); members must follow training (Art. 20(2)) | One group programme can serve many entities, but each entity's management body must approve it for that entity | Directive (EU) 2022/2555 |
| NIS2 incident reporting | Each entity: early warning within 24 hours, notification within 72 hours, final report within one month of the notification (Art. 23(4)) | A group incident may trigger parallel reports in several Member States | Directive (EU) 2022/2555 |
| NIS2 jurisdiction | Generally the Member State where the entity is established; certain digital providers fall under their main establishment, where cybersecurity risk-management decisions are predominantly taken (Art. 26) | Where group decisions are taken can decide which authority supervises a digital provider | Directive (EU) 2022/2555 |
| NIS2 maximum fines | At least EUR 10 million or 2% (essential) and EUR 7 million or 1.4% (important) of the worldwide annual turnover of the undertaking to which the entity belongs, whichever is higher (Art. 34(4), (5)) | A small subsidiary of a large group carries a group-sized ceiling | Directive (EU) 2022/2555 |
| DORA ICT risk management | The management body of each financial entity defines, approves, oversees and is responsible for the framework (Art. 5(2)) | Verification of compliance may be outsourced to intra-group or external undertakings (Art. 6(10)); responsibility stays with the entity | Regulation (EU) 2022/2554 |
| DORA register of information | Maintained at entity level and at sub-consolidated and consolidated levels (Art. 28(3)) | The group needs one data model that rolls up cleanly | Regulation (EU) 2022/2554 |
| GDPR data protection officer | Each controller or processor that must appoint one | A group of undertakings may appoint a single DPO provided one is easily accessible from each establishment (Art. 37(2)) | Regulation (EU) 2016/679 |
NIS2 also lets Member States consider how independent an entity is from its partner or linked enterprises when applying the size rules (recital 16), which matters when a small subsidiary relies entirely on group systems. National transposition varies, so check each country; the NIS2 Directive Guide and the DORA Guide cover the regimes themselves.
Local regulators and subsidiary boards
Each regulated subsidiary needs a named person who can speak for its security to its supervisor and its board. That person may sit in the group function and wear a subsidiary hat, but the role must be written down.
- Named entity security lead: appointed by the subsidiary board, with a documented reporting line to the group CISO and direct access to the subsidiary board. In regulated entities, align this with any local requirement for a responsible officer.
- Subsidiary board reporting: the board receives an entity view, not the group pack. The UK Cyber Governance Code of Practice asks boards to require formal reporting at least quarterly with agreed metrics and tolerances (action E2) and to exercise the incident plan at least annually (action D2); apply that rhythm at each material entity. See the Board Cyber Risk Reporting Guide.
- Supervisory relationships: keep a contact map of supervisors per entity and an agreed position on who communicates with them. Group messages to one supervisor reach others quickly; inconsistent statements cause more trouble than late ones.
- Director training: NIS2 Art. 20(2) requires management body members of in-scope entities to follow training. A group programme can deliver it, but attendance must be recorded per entity.
- Conflicts of interest: the EBA guidelines ask the consolidating institution to consider each subsidiary's interests, not only the group's (paragraph 86). If a group decision weakens a subsidiary's position, for example moving its data to a shared platform its regulator has not approved, the subsidiary board must be able to say no.
Group policy cascade
A policy written by the group is not binding on a subsidiary until that subsidiary adopts it. The cascade needs to be designed so adoption is routine and variations are visible.
- Group policy set: the group approves a small number of policies and a larger set of standards, as described in the Security Policy Framework Guide. Each states which requirements are mandatory everywhere and which may be varied locally.
- Entity adoption: each subsidiary board, or a committee it delegates to, formally adopts the group set, minuted, with an adoption date and version.
- Local addenda: where national law or a supervisor requires more, the entity adds a local addendum. It may add, never subtract, unless a recorded exception exists.
- Exceptions: a subsidiary that cannot meet a group requirement raises a time-limited exception, approved at the level the group's delegation of authority sets, with a compensating control. Use the same mechanics as the Hardening Exceptions and Compensating Controls Template.
- Attestation: each entity's security lead attests compliance annually, with evidence the group can sample.
| Requirement type | Set by | Local variation | Example |
|---|---|---|---|
| Group mandatory | Group board or risk committee | Only by formal exception | Phishing-resistant MFA for administrators; central log forwarding |
| Group baseline with local parameters | Group CISO | Parameters within a stated range | Log retention (minimum set by group, longer where local law requires) |
| Local requirement | Subsidiary board, often driven by its supervisor | Owned locally, reported to group | Sector-specific incident notification to a national authority |
| Guidance | Group function | Optional | Preferred tooling patterns |
Third-country subsidiaries need one more step. The EBA guidelines say they should be consistent with group-wide policies only where that is not unlawful under local law (paragraph 88). Legal review of each group policy against each non-home jurisdiction belongs in the policy lifecycle, not in an incident.
Shared security services between entities
Most groups run security centrally and provide it to subsidiaries. Supervisors increasingly treat that as outsourcing. DORA defines an ICT intra-group service provider as an undertaking that is part of a financial group and provides predominantly ICT services (Art. 3(20)), and its recitals say intra-group ICT services should not automatically be considered less risky and should be subject to the same framework (recital 31). The EBA guidelines say an institution remains fully responsible for services outsourced within the group (paragraph 92).
- Intra-group agreement: a written agreement between the providing entity and each consuming entity, listing the services (SOC monitoring, identity platform, vulnerability scanning, incident response), service levels, data locations, audit and access rights for the entity and its supervisor, sub-outsourcing and exit.
- Service catalogue per entity: which group services each entity consumes, and which it runs itself. This feeds the DORA register of information at entity and consolidated levels.
- Charging: allocate costs with a documented key (headcount, endpoints, revenue or consumption) that the finance and tax teams agree, because intra-group service charges are also a transfer pricing matter. A transparent key also stops subsidiaries opting out of shared controls to save money.
- Service reporting: each consuming entity receives its own service report so its board can oversee a service it is accountable for but does not run.
- Exit and separation: document how an entity would leave the shared service if it is sold. A disposal without a separation plan leaves the buyer and the seller sharing credentials, tenants and logs for months.
The DORA ICT Third-Party Risk and Register of Information Guide covers the register mechanics for financial groups.
Where identity fits
Identity is where group structures become technical. Shared directories, cross-tenant trust and group-owned service accounts let one entity's compromise spread to others.
- Tenant model: decide per entity whether it shares the group identity tenant or keeps its own with cross-tenant access. Separate tenants support divestment and local regulators; shared tenants simplify control. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide for one platform's mechanics.
- Group administrators: group staff with administrative rights in subsidiary systems are a privileged access path into every entity. Record them per entity and include them in each entity's access review.
- Shared non-human identities: service accounts, API keys and integration credentials used by group platforms across entities need a named owner and an entity map, so a disposal or a breach can be scoped quickly.
Bringing acquired subsidiaries into the model
Due diligence decides what you are buying; the post-close programme decides how fast the acquired company meets group standards. The deal phase is covered in the Cyber Due Diligence in Mergers and Acquisitions Guide. After closing, governance work runs in this order.
- Day one: add the entity to the security entity register, name an interim security lead, agree an incident escalation route to the group, and confirm minimum controls (MFA on remote access and email, administrator inventory, backup check).
- First 30 days: map the entity's regulators and reporting obligations, collect its existing policies and exceptions, and decide its tenant and connectivity model. Keep network and identity trust to the group restricted until the minimum controls are verified.
- First 100 days: the subsidiary board adopts the group policy set with local addenda; group monitoring is connected; open findings from diligence become tracked exceptions with dates.
- Convergence (6 to 24 months): migrate onto shared services where the integration plan says so, sign the intra-group agreement, and close the interim exceptions. Some acquisitions stay federated on purpose, for example where a sale is likely; record that decision.
Decision guidance
- When to keep a subsidiary semi-autonomous: it has its own licence or supervisor, a separate technology estate, a likely disposal, or local law that conflicts with group policy. Give it a stronger local security lead and lighter group integration.
- When to integrate fully: it shares the group's customers, systems and brand, and an incident there would be reported as a group incident anyway.
- Smaller groups: with a handful of entities in one country, one security function, one policy set adopted by each board and simple cost allocation are enough. Avoid building a federated bureaucracy for three companies.
- Large multinational groups: expect a regional layer between group and entity, a formal intra-group agreement per regulated entity, and a group-level register that rolls up from entity registers.
Measuring whether group governance works
| Metric | Definition | Why it matters |
|---|---|---|
| Policy adoption coverage | Entities whose board has adopted the current group policy version, divided by in-scope entities | Shows whether group policy is legally binding where it needs to be |
| Named security lead coverage | Regulated entities with a board-appointed security lead | Gaps here become regulator findings |
| Open entity exceptions past expiry | Count and age of group policy exceptions beyond their end date | Shows whether the exception process is real |
| Intra-group agreement coverage | Consuming entities with a signed, current agreement for each shared security service | Required evidence for supervisors and for disposals |
| Acquisition convergence time | Days from closing to minimum-control verification and to policy adoption | Measures the riskiest period in a group's life |
| Entity incident reporting drill result | Time for an exercise to identify every entity with a reporting duty and its deadline | Tests the entity register under pressure |
Framework mapping
| Group governance activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 |
|---|---|---|---|
| Entity register of laws and supervisors | GV.OC-03 | PM-9 Risk Management Strategy | Clause 4.2; A.5.31 Legal, statutory, regulatory and contractual requirements |
| Named accountability per entity | GV.RR-01, GV.RR-02 | PM-2 Information Security Program Leadership Role | Clause 5.3; A.5.2 Information security roles and responsibilities |
| Policy cascade and local adoption | GV.PO-01, GV.PO-02 | PL-1 Policy and Procedures; PM-1 Information Security Program Plan | Clause 5.2; A.5.1 Policies for information security |
| Intra-group shared services | GV.SC-01 | CA-2 Control Assessments (of the provider) | A.5.19 Information security in supplier relationships |
| Group risk roll-up and oversight | GV.RM-03, GV.OV-01 | PM-9 Risk Management Strategy | Clause 9.3 Management review |
The independent assurance layer is covered in the Three Lines Model for Cyber Risk Guide.
Common failure patterns
- Group policy never adopted locally: the group assumes its standard applies everywhere; a supervisor finds the subsidiary board never approved it, so the entity has no binding security policy.
- One group report, no entity view: subsidiary directors see only consolidated metrics and cannot show they oversaw their own entity's risk.
- Shared services with no agreement: the group SOC monitors a regulated subsidiary with no contract, no audit rights and no exit plan, which fails both outsourcing rules and divestment.
- Reporting map built during the incident: the team spends the first day working out which entities and authorities must be told, while the 24-hour NIS2 early warning clock runs.
- Acquired company left on trust: an acquisition is connected to the group network and identity tenant before its administrator accounts and remote access are checked.
- Disposal without separation: a sold subsidiary keeps group credentials, tenant trust or log access long after the sale.
Practitioner checklist
- Maintain a security entity register with laws, supervisors, directors, security lead and consumed services for every legal entity.
- Have every in-scope subsidiary board formally adopt the current group policy set, with local addenda recorded.
- Appoint and document a security lead for each regulated entity, with direct access to its board.
- Send each material subsidiary board an entity-level report at least quarterly.
- Pre-build the incident reporting map: entity, authority, deadline and who files.
- Put a written intra-group agreement in place for every shared security service, with audit rights and exit terms.
- Agree a cost allocation key for shared security services with finance and tax.
- Run a day-one, 30-day and 100-day governance plan for every acquisition.
- Write a separation plan before any disposal closes.
Standards and references
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- EUR-Lex: Regulation (EU) 2016/679 (GDPR)
- European Banking Authority: Guidelines on internal governance under Directive 2013/36/EU (EBA/GL/2021/05)
- UK Government and NCSC: Cyber Governance Code of Practice
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Security Operating Model and Organisation Design Guide, Cyber Due Diligence in Mergers and Acquisitions Guide, Where Should the CISO Report, Cyber Risk Appetite Statement Template. This guide summarises governance obligations under several laws and is not legal advice.