ISMS for Corporate Groups: Group Policies vs. Local Implementation

TL;DR

There are three fundamental models: a fully centralized ISMS, fully decentralized ISMS instances, or a federation model with a central framework and local implementation.
The federation model is the best solution for most corporate groups because it combines consistency with local adaptability.
Group policies define the what and the why. Local implementations define the how, adapted to the respective entity.
Certification is possible either as a group certificate or as individual certificates per entity. Both approaches have pros and cons.
Cross-entity reporting only works with standardized metrics and assessment scales. Without this standardization, comparisons between entities are worthless.

Why a single ISMS isn't enough

When a company grows, it rarely does so organically and uniformly. Companies are acquired, subsidiaries are established, joint ventures are formed. Each of these entities brings its own processes, systems, and cultures. The holding or parent company then faces the question: How do we organize information security across all entities without either forcing everything into a centralized straitjacket or sinking into a patchwork of individual solutions?

This question isn't theoretical. It has tangible consequences. Regulatory requirements like NIS2 may apply differently depending on the entity. Customers expect a consistent security level across the entire group. A security incident at a subsidiary can affect the entire group. And auditors — whether internal or external — want to understand how security governance works across the group.

This article describes the different models, their pros and cons, and provides you with a roadmap for implementing a group-wide ISMS.

The three fundamental models

Model 1: Fully centralized ISMS

In the centralized model, there is a single ISMS managed by the holding company that applies to all entities. The headquarters defines all policies, conducts the risk assessment, manages the measures, and is responsible for the audit. The local entities implement what headquarters prescribes.

Advantages: Maximum consistency, uniform security level, simple reporting, a single point of contact for auditors and customers, economies of scale for tools and training.

Disadvantages: Local specifics are easily overlooked. A policy that makes sense for the headquarters with 500 employees may be oversized for the subsidiary with 20. Local acceptance drops when requirements come top-down without involving those affected. And headquarters needs deep knowledge of the processes and systems of all entities — which is barely feasible in heterogeneous groups.

Suited for: Small corporate groups with few, similarly structured entities at the same location.

Model 2: Fully decentralized ISMS

In the decentralized model, each entity has its own ISMS with its own policies, risk assessment, and CISO (Information Security Officer). The holding company sets no content-related requirements but merely verifies that each entity has a functioning ISMS.

Advantages: Maximum local adaptability. Each entity can tailor its ISMS precisely to its needs. High local acceptance because those affected are involved in the design.

Disadvantages: No uniform security level across the group. Risks that span entity boundaries (e.g., shared IT infrastructure) fall through the cracks. Reporting isn't comparable. Duplication of effort for similar policies. And if one entity has a poor ISMS, it potentially affects the entire group.

Suited for: Loosely connected groups with highly heterogeneous entities that have few operational dependencies.

Model 3: Federation model (hub-and-spoke)

The federation model combines central governance with local implementation. The holding company defines a binding framework (group policies, minimum standards, assessment scales, reporting requirements), and the local entities implement this framework, adapted to their specific needs.

Advantages: Consistency where needed (uniform minimum standards, comparable reporting) and flexibility where needed (local processes, specific risks). Clear division of responsibilities between headquarters and entities. Good balance between governance and practicality.

Disadvantages: More complex to set up than the other two models. Requires clear delineation of what is centrally prescribed and what can be decided locally. Needs a coordination mechanism between headquarters and entities.

Suited for: Most corporate groups with more than three entities, especially when entities have different industries, sizes, or locations.

The federation model in detail

The architecture

The federation model consists of three levels:

Level 1: Group framework. The holding company defines the overarching framework. This includes the group's information security policy, the binding group policies (minimum baseline), the risk assessment methodology (uniform scales and criteria), the reporting requirements, and the governance structure (roles, committees, escalation paths).

Level 2: Local ISMS. Each entity has its own ISMS within the group framework. It conducts its own risk assessment, creates local policies that concretize the group policies, implements measures, and reports to headquarters.

Level 3: Operational implementation. The actual implementation of security measures in the systems, processes, and behaviors of the individual entity.

Group policies vs. local policies

The delineation between group policies and local policies is the most critical design decision of the federation model. The rule of thumb: The group policy defines the what and the why. The local policy defines the how.

An example: The group policy on access control might specify:

Access rights must be granted according to the least privilege principle
Privileged accounts must be protected by MFA
Access rights must be adjusted within 24 hours when an employee changes roles or leaves
A recertification of all access rights must occur at least annually

These are the minimum requirements that apply to all entities. The local policy of a subsidiary then specifies: Which identity management system is used? Who is the approver for which systems? How exactly is the recertification organized? These details differ from entity to entity and must be determined locally.

What belongs in the group framework?

Not everything needs to be centrally prescribed. Focus on areas with group-wide relevance:

Always central:

Group information security policy
Risk assessment methodology (scales, criteria, acceptance thresholds)
Information classification scheme
Incident response process for group-relevant incidents
Reporting requirements and metrics
Minimum standards for critical areas (access control, encryption, backup)

Usually central:

Supplier assessment for group-wide service providers
Awareness program (at least framework requirements)
Audit planning and coordination
Crisis communication

Always local:

Detailed procedures
Asset inventory
Local risk assessment
Operational measures
Training delivery
Local incident response procedures

Governance structure

Roles in the group structure

Group CISO: Responsible for the group framework, coordination between entities, and consolidated reporting to the group executive management. In smaller groups, this role can also be performed by the CISO of the parent company, provided sufficient capacity exists.

Local CISOs: Responsible for the ISMS of their entity within the group framework. They report functionally to the Group CISO and organizationally to their local management. This dual reporting line is intentional — the local CISO must both implement group requirements and represent local needs.

ISMS Steering Committee: A regular body (quarterly or semi-annually) where the Group CISO and local CISOs convene. Agenda: status of local ISMS, group-wide risks, harmonization needs, experience sharing.

Local risk owners: In each entity, there are risk owners responsible for specific risks. They report to the local CISO.

Communication channels

Define clear communication channels for different scenarios:

Normal operations: Local CISOs report quarterly to the Group CISO. The ISMS Steering Committee meets quarterly.

Security incidents: For local incidents, the local CISO decides on escalation. For group-critical incidents (affecting multiple entities, regulatory relevance, reputational risk), the Group CISO is immediately involved.

New requirements: Regulatory changes affecting the group are centrally assessed and communicated as requirements to the local CISOs.

Risk management across entity boundaries

Local risks vs. group risks

In the federation model, there are two categories of risks that are handled differently:

Local risks affect a single entity and are assessed, treated, and reported there. Example: A local ERP system server fails and only impacts local order processing.

Group risks affect multiple entities or have implications for the overall group. They typically arise from shared infrastructure (central Active Directory, shared internet connection), dependencies between entities (intra-group supplier relationships), reputational risks (a data breach at a subsidiary damages the group's brand), or regulatory risks (NIS2 could consider the entire group as a connected enterprise).

Group risks are centrally captured, assessed, and managed. The risk assessment is conducted by the Group CISO with input from the affected local CISOs.

Uniform risk assessment

For risks to be comparable across entity boundaries, uniform assessment scales are needed. If Entity A rates likelihood on a scale of 1-3 and Entity B on a scale of 1-5, the results cannot be aggregated.

Define a uniform risk assessment methodology in the group framework:

The assessment scale for likelihood (e.g., 1-5 with defined criteria)
The assessment scale for impact (e.g., 1-5 with defined thresholds in euros)
The risk acceptance threshold (e.g., risks up to risk value 8 are acceptable, above requires treatment)
The assessment methodology (qualitative, semi-quantitative, matrix method)

The thresholds for impact can vary between entities but must relate to each other. A loss of 100,000 euros has a different significance for an entity with 10 million euros in revenue than for one with 200 million euros. Therefore, define the levels as percentages or establish entity-specific absolute values that correspond to the same relative severity.

Certification in the corporate group

Option 1: Group certificate

A single ISO 27001 certificate covering all entities. The scope encompasses the entire group, and the audit examines both the central governance and the local implementation at the entities.

Advantages: One certificate that can be presented to all customers and partners. Lower total audit effort because the auditor doesn't need to examine all entities every time in recurring audits (sampling approach).

Disadvantages: A major nonconformity at a single entity jeopardizes the certificate for the entire group. The initial certification audit is extensive and expensive. And all entities must have a comparable maturity level — which is difficult to achieve in heterogeneous groups.

Option 2: Individual certificates per entity

Each entity is certified separately, with its own scope, audit, and certificate. The group framework is considered as context but not directly audited.

Advantages: A nonconformity at one entity affects only that entity's certificate. Entities can be certified at different paces. Well suited when not all entities need a certificate.

Disadvantages: Higher total audit effort. No unified certificate for the group. And there's a risk that non-certified entities are perceived as weak links.

Option 3: Phased approach

Start with the certification of the parent company or the most important subsidiary. Expand the scope in subsequent years to additional entities. This approach is the most pragmatic for groups that are beginning their ISMS journey.

Reporting across the group

Consolidated metrics

For group management, you need metrics that show the security status of the entire group at a glance. Define a standardized metrics set that all entities collect:

Risk metrics: Number of open risks by risk class, trend of the risk situation (improved/stable/deteriorated), number of accepted risks above the threshold.

Action metrics: Implementation rate of planned measures, number of overdue measures, average implementation time.

Incident metrics: Number of reported security incidents, proportion of incidents handled with a defined process, average response time.

Compliance metrics: Proportion of employees with current awareness training, proportion of controls with evidence, result of the last audit.

Group dashboard

Consolidate the metrics in a group dashboard available to group management and the ISMS Steering Committee. The dashboard should provide both the aggregated group view and the ability to drill down to individual entities.

A traffic light system (green/yellow/red) per entity and metric area gives a quick overview. Important: The traffic light logic must be transparently defined so that all entities are evaluated by the same criteria.

Practical recommendations for implementation

Start with the group framework

Before you build local ISMS instances, define the group framework. This means: create group policies, establish the risk assessment methodology, define reporting requirements, set up the governance structure. This framework doesn't need to be perfect, but it must exist before the local entities start. Otherwise, you'll build local ISMS instances that later need to be painstakingly harmonized.

Pilot with one entity

Implement the federation model in one entity first before rolling it out to all. Choose an entity that is large enough to be representative but small enough to remain manageable. The lessons from the pilot feed into the refinement of the group framework.

Invest in the Steering Committee

The ISMS Steering Committee is the heart of the governance. Take time for the meetings, prepare them well, and ensure that results are documented and followed up. A functioning steering committee saves you dozens of bilateral discussions.

Harmonize tools

It's not mandatory that all entities use the same ISMS tool. But when reporting requirements are standardized, a shared tool is the simplest way to meet them. The alternative — manual data consolidation from different tools — is error-prone and time-consuming. ISMS Lite supports multi-scope scenarios with a central group framework and local implementation in a single instance.

Respect local differences

The group framework must not be so tight that local specifics have no room. A subsidiary in a regulated environment (e.g., healthcare) needs stricter requirements than one in a less regulated sector. A subsidiary with 20 employees needs leaner processes than one with 500. The federation model thrives when headquarters acknowledges the differences and sets minimum standards that are achievable for all — without slowing down the leading entities.

A group-wide ISMS is not a one-time project but an ongoing governance process. It requires investment in coordination, communication, and tools. But the effort pays off: A group with consistent information security is more resilient against attacks, more credible to customers, and better positioned for regulatory requirements than a group where each entity fights on its own.