One GRC Programme, Many Jurisdictions: Structuring for Multi-Entity Groups

Two failure modes

A group with entities in several countries has a structural problem: the parent needs a consolidated view of risk and compliance, while each subsidiary answers to a regulator the others have never heard of.

Most groups resolve this badly, in one of two directions.

Centralise everything. The group mandates a single framework and a single control set for all entities. Reporting is clean. The problem surfaces at the first local inspection, when the subsidiary discovers that group controls do not map to what its supervisor actually asks for, and it quietly starts maintaining a second, real control set in a spreadsheet.

Federate everything. Each entity runs its own programme against its own obligations. Local compliance is genuinely better. But the group has no comparable view: one entity's "high" risk is another's "medium", risk registers are structured differently, and consolidating for the board becomes a quarterly manual exercise that is out of date before it is presented.

The first optimises for the parent and fails the entity. The second optimises for the entity and fails the parent. Neither is a tooling problem; both are modelling problems.

What actually needs to be shared, and what does not

The resolution is recognising that these are separate layers, and only some of them need to be common.

Must be common across the group:

Risk taxonomy. What counts as an operational risk versus a cyber risk, and the categories underneath. Without this, nothing consolidates.
Impact and likelihood scales. Including how financial impact converts across currencies. If "high impact" means a different magnitude in each entity, the group heat map is decoration.
Severity and rating definitions for findings and issues.
The internal control library. One library describing what the group does, from which entities draw.
Evidence standards. What constitutes acceptable evidence, and retention expectations.

Must be entity-specific:

Applicable authorities and frameworks. Which regulators supervise this entity, and which of their frameworks bind it.
Control applicability. Which library controls apply here, and which local-only controls exist that no other entity needs.
Risk appetite thresholds. A group appetite statement is meaningful; the tolerances beneath it are not identical for a licensed bank and a shared-services company.
Assessment calendars. Regulatory cycles do not align across jurisdictions.
Data residency and access scope. Frequently a legal constraint, not a preference.

The single most common mistake is putting applicable frameworks in the common layer. Once "the group is an ISO 27001 organisation" becomes structural rather than per-entity, every entity with additional local obligations has to work around the model.

Modelling the hierarchy

Three distinct hierarchies are usually conflated, and they genuinely differ:

Legal entity structure. Who owns whom. Drives statutory obligation, regulatory scope, and liability. This is the one regulators care about.

Operational structure. Business units, departments, functions. Drives control ownership and who actually performs the work. It routinely crosses legal boundaries: a shared security operations function may serve entities in four countries.

Geographic structure. Locations and sites. Drives physical controls, local law, and data residency.

A risk usually belongs to a legal entity, is owned by someone in the operational structure, and may be constrained by geography. Systems that support only one hierarchy force the other two into free-text fields, and the moment that happens, consolidated reporting stops being trustworthy.

Rolling up without flattening

With the layers separated, consolidation becomes tractable.

Risk rolls up by legal entity, using the common scales. Because impact and likelihood are defined once, a group heat map means something. Entity-level detail stays intact underneath.

Compliance posture does not roll up as a single number, and should not. "The group is 87% compliant" is not a meaningful statement when entities are measured against different frameworks. What does roll up is control health: for each control in the shared library, how many entities where it applies have it operating effectively. That is comparable, because the control is the same object everywhere.

Findings roll up by severity, using common definitions, filtered by entity for local remediation and aggregated for group oversight.

Framework coverage stays entity-scoped, and is reported as a set rather than an average: this entity against its supervisor's framework, that one against its own.

Practical checks

A few questions that expose whether a structure holds:

Can an entity add a control that no other entity has, without a group change request?
Can a control owner sit in a different legal entity from the risk they control?
When a regulator issues a revision, can it be applied to one entity without touching the others?
Can a group risk report be produced without anyone editing a spreadsheet?
Can an entity's data be scoped so users elsewhere in the group cannot see it, while the parent still gets rollups?

If any of these requires a workaround, the model is flattening something it should be keeping distinct, and the workaround is where your next audit finding comes from.

The underlying principle

Groups do not need one programme in the sense of one set of obligations. They need one model, shared vocabulary, shared control library, shared scales, with obligations attached per entity.

Get the shared layer right and local specificity costs you nothing at group level. Get it wrong and no amount of reporting effort will make the consolidated picture true.