GRC for subsidiaries: Central direction, local responsibility

A group policy can apply to several companies. That does not establish implementation everywhere. Different systems, contracts and operational workflows produce different risks and evidence.

GRC for subsidiaries therefore needs two perspectives: a shared basis and a traceable local assessment. Central reporting must show where a requirement applies, where it is implemented and where a decision is still missing.

Separate requirements, services and responsibility

Start with the services actually shared. If the group operates a central identity service, some technical implementation can be central. The companies still need to establish which applications are connected and which local exceptions exist.

This is a working aid, not a statement about which legal duties a particular company can delegate. That assessment depends on its specific scope.

NIST CSF 2.0 connects security governance with organisational objectives, responsibilities and communication across organisational levels. This supports shared terminology, rather than treating every subsidiary as equivalent. NIST CSF 2.0, chapter 5

Shared evidence needs a visible scope

If a central recovery test covers only two platforms, it does not automatically demonstrate recoverability for every subsidiary. Document which systems, periods and services the evidence covers.

Avoid both extremes: requesting the same test again everywhere, or marking central evidence as sufficient everywhere without checking it. Our guide to using one piece of evidence for several audits explains reuse against specific review questions.

Fictional case: Three subsidiaries use the same backup provider. Two run their systems on the tested platform; the third also uses a local application. The central test may be relevant to the first two. Local recovery still needs separate assessment for the third. The group report explicitly shows that gap.

Compare only assessments made using the same method

“80 per cent implemented” means little if each company defines status and scope differently. Agree on shared terms for implementation, effectiveness, pending assessment and justified exceptions.

Alongside an overall figure, show the reference scope: companies included, requirements considered and data cutoff. Missing responses must not silently count as fulfilled. Our ISMS effectiveness metrics help distinguish activities from dependable results.

Exceptions require a decision

A local deviation is not necessarily an error. A different business model or technical transition can justify it. It becomes problematic when nobody knows who assesses it or when it ends.

Record the affected requirement, factual reasoning, residual risk, any compensating measure, authorised decision-maker and next review trigger. Reasoned risk acceptance belongs in the defined decision process, beyond a free-text reporting field.

Turn group reporting into work

Every relevant gap needs a clear owner for the next step. A central procurement decision may be a prerequisite for several local measures. The group then needs one shared decision rather than three independently postponed deadlines.

In Kopexa, you can model internal requirements using your own frameworks. Measures hold evidence and are mapped to controls. During the trial, test specifically how scope, access and responsibilities fit your group structure.

Start with two different subsidiaries and one shared requirement. Extend the approach once the path from a requirement to local implementation and back to a management decision works.