Two European regulatory frameworks that increase pressure on organisations to prove resilient security controls, including authentication, access governance, and operational continuity. They push teams to show that identity controls are enforced consistently, can be audited, and still function under disruption or attack.
Expanded Definition
nis2 and DORA are best understood as a pair of European regulatory pressure points rather than a single standard. NIS2 broadens cybersecurity obligations for covered essential and important entities, while DORA focuses on digital operational resilience in the financial sector and its critical ICT dependencies. Together, they shift the question from “do we have security controls?” to “can we prove those controls operate consistently, survive disruption, and support recovery?”
For identity and access teams, the practical boundary is important: these frameworks do not define authentication theory or access design in the abstract. They require evidence that access governance, privileged control, logging, continuity, and recovery are enforced, testable, and auditable. That is why identity controls matter here even when the regulation is not written as an IAM-only text. The common misunderstanding is to treat compliance as documentation work; in practice, the burden is on operational reliability and demonstrable control performance.
For the official texts, the most direct references are the NIS2 Directive and the Digital Operational Resilience Act.
Examples and Use Cases
In practice, NIS2 and DORA show up wherever organisations must demonstrate that resilience controls are not just designed, but operating under pressure. They affect how security leaders document authority, how IAM teams evidence access decisions, and how operations teams prove recovery capability.
- A financial institution tests whether privileged access can still be controlled during an outage, rather than assuming emergency access will be acceptable without review.
- An organisation maps service ownership so identity recovery, backup authentication, and administrative access remain available during a degraded state.
- A regulated entity logs who approved elevated access, when it was used, and how quickly it was revoked after the change window ended.
- A security team validates that third-party access paths remain bounded and observable, especially when suppliers support systems essential to continuity.
- A board-level reporting process ties access exceptions and resilience failures to remediation evidence, not just policy statements.
The tradeoff is that stronger proof requirements usually increase operational friction. Teams must accept more testing, tighter change discipline, and clearer ownership in exchange for a defensible resilience posture.
Security Implications
When NIS2 and DORA are misunderstood, the failure is usually not a single missing control. It is a chain of weak evidence, inconsistent enforcement, and poor recovery readiness. Organisations may have authenticators, privileged access workflows, and incident procedures, yet still fail because those controls cannot be demonstrated across normal operations and disruption scenarios.
The most common exposure is control drift: access rules exist on paper but differ between platforms, environments, or business units. Under stress, that drift creates gaps in approval, logging, or revocation. Another failure mode is resilience theater, where continuity plans assume identity services, admin access, or recovery paths will be available without testing. In a real outage, that assumption can block remediation, delay containment, and expand business impact.
For IAM and PAM teams, the practical signal is whether the organisation can still prove who had access, who approved it, and how access was constrained when services were degraded. If the answer depends on manual reconstruction after the fact, the control is already too fragile for regulatory scrutiny.
Domain and Governance Relevance
NIS2 and DORA matter because they move identity from an internal control topic into an externally accountable resilience issue. Access governance is no longer just about preventing overprivilege; it becomes part of the evidence that the organisation can sustain operations, contain incidents, and restore trust after disruption.
This is especially relevant where non-human identities, service accounts, or administrator credentials are part of critical business flows. If those identities are not inventoried, bounded, and recoverable, the organisation may lose the ability to operate key services even when the underlying application stack remains intact. That makes machine access governance a resilience concern, not just an IAM hygiene task.
For NHIMG, the key interpretation is simple: in regulated environments, identity control quality is judged by continuity under stress. A control that only works in steady state is not enough if the regulator expects it to function, and be shown to function, during an incident or recovery event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 set the technical controls, while NIS2 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Art. 21 — Cybersecurity risk-management measures | Requires proportionate technical and organisational controls for resilience and access governance. |
| Recommendation — Map access governance and continuity controls to Art. 21 and retain evidence that they operate under disruption. | ||
| DORA | Article 9 — ICT Risk Management | Directly covers operational resilience and control effectiveness for ICT-dependent financial services. |
| Article 10 — Protection and Prevention | Addresses preventative ICT safeguards that include identity, access, and privileged control measures. | |
| Article 11 — Detection | Supports monitoring and logging needed to prove access and resilience control operation. | |
| Recommendation — Use Article 9 to align identity controls with operational resilience testing and recovery readiness. Apply Article 10 to enforce preventive access controls that remain consistent across environments. Implement Article 11 monitoring so access activity and resilience failures are detectable and auditable. | ||
| CIS Controls v8 | 5 — Account Management | Supports controlled lifecycle management of user and non-human access that regulators expect to be governed. |
| 8 — Audit Log Management | Provides the logging evidence needed to demonstrate access decisions and operational control performance. | |
| 17 — Incident Response Management | Helps connect resilience obligations to containment, recovery, and post-incident evidence handling. | |
| Recommendation — Use Control 5 to keep access ownership, approval, and revocation processes consistently enforced. Apply Control 8 to retain trustworthy logs that prove who accessed what and when. Use Control 17 to validate that access and recovery processes still work during incident response. | ||
Related resources from NHI Mgmt Group
- How should financial institutions use identity governance for DORA and NIS2 compliance?
- Who is accountable when cyber resilience controls fail under NIS2 and DORA?
- How should organisations govern certificate lifecycle management for NIS2 and DORA?
- How should AppSec teams align controls across DORA, CRA, and NIS2?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
