Because centralisation only helps if the approval path, log trail, and evidence store are connected in practice. If those parts sit in different systems or teams, organisations may have controls but not demonstrable control continuity. The result is weak audit proof, unclear ownership, and more work to reconstruct decisions after the fact.
Why centralising identity control on paper breaks down in practice
Centralisation only works when the control path is actually integrated. If approval, logging, and evidence collection are split across different tools or teams, the programme may look tidy on a chart while still producing gaps in execution. That creates a false sense of control continuity, especially when auditors or incident responders need to trace a decision end to end.
The practical failure is usually not the policy itself, but the handoffs. One team approves access, another system records the change, and a third group stores the evidence, so no single process can prove what happened without reconstruction.
That is why “centralised” identity control can still behave like a federated process in operation: the control exists, but the control path is fragmented.
What NIS2 programmes lose when the audit trail is fragmented
NIS2 programmes need more than documented governance, they need evidence that controls are operating consistently. When the same identity event is handled differently across business units, the organisation can no longer show a reliable chain from request to approval to implementation to review. This weakens audit proof and makes ownership harder to defend when exceptions appear.
Fragmentation also increases rework. If a reviewer cannot see whether an access decision was approved, executed, and retained in one continuous trail, the team has to rebuild the record after the fact from tickets, logs, emails, and system exports.
For programmes under regulatory pressure, that reconstruction cost is itself a signal that control design and operating design do not match.
Why “single owner” language is not enough for control continuity
A central policy owner is useful, but it does not guarantee control continuity. Continuous control depends on a connected approval path, a durable log trail, and evidence storage that preserves the same object identity across systems. If any one of those layers uses different identifiers, retention rules, or team handoffs, the programme becomes difficult to attest and difficult to improve.
This is especially visible in identity governance because access decisions often need to be explained months later. The more separate the workflow, the more likely that ownership becomes ambiguous, exceptions multiply, and the organisation cannot tell whether a control failed or simply became unprovable.
Centralisation is therefore a design property, not a reporting label: it must be true in workflow, data, and accountability, not only in policy text.
Risk and Threat Considerations
Fragmented identity control creates exposure even when the organisation believes it is compliant, because missing continuity makes it harder to detect excessive access, reconstruct misuse, or prove that privileged changes were authorised. In regulated environments, weak continuity can also turn a routine review into a control exception or audit finding.
Failure mechanism: Approval, execution, and evidence are split across systems or teams, so the organisation cannot reliably trace a decision from request to review. That breaks the control chain, obscures ownership, and leaves gaps that attackers or careless operators can exploit.
Impact: The programme accumulates weak audit proof, slower investigations, higher manual effort, and a greater chance that real access issues remain unresolved because nobody can confidently reconcile the records.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Identity decisions need a coherent audit trail to prove who approved what and when. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Fragmented logging weakens review and reconstruction of identity control evidence. | |
| Recommendation — Define and capture audit events for identity approvals, changes, and reviews. Review identity audit records for gaps, inconsistencies, and unresolved exceptions. | ||
| ISO/IEC 27001:2022 | A.5.28 — Collection of Evidence | The question is about preserving evidence continuity across centralised identity controls. |
| A.5.15 — Access control | Centralised identity control depends on consistent access governance across systems. | |
| Recommendation — Preserve evidence for identity decisions in a traceable, retrievable form. Align access control decisions with one governed approval and review path. | ||
| NIS2 | ICT risk management measures | NIS2 programmes must show effective, end-to-end control operation and evidence. |
| Recommendation — Map identity workflows to demonstrable ICT risk management measures. | ||
Practitioner Guidance
What to verify: Test whether one identity event produces one traceable record across approval, implementation, logging, and retention. If a reviewer needs multiple tools or teams to reconstruct the same decision, the control is functionally fragmented even if policy says it is centralised.
What good looks like: Each access decision should have a consistent identifier, a clear owner, a single timestamped approval trail, and an evidence store that can be retrieved without manual cross-team reconstruction. That is the practical standard for control continuity.
Common mistake: Treating a governance diagram as proof of central control. The real test is whether the operating model preserves the same control object across workflow, logging, and evidence, especially during exceptions and recertification.
Practitioner takeaway: Centralisation only reduces NIS2 risk when the control is continuous end to end, if the workflow is split, the programme may still be governed but it is not yet operationally provable.