DORA and NIS2 raise the bar for cyber resilience and reporting

At a glance

What this is: DORA and NIS2 are reshaping EU cyber compliance by making resilience testing, incident reporting and third-party oversight operational obligations rather than policy statements.

Why it matters: For IAM, PAM, NHI and broader security teams, these rules matter because access governance, supplier controls and incident evidence now need to stand up to regulatory scrutiny, not just internal audit.

Context

DORA and NIS2 are regulatory responses to a simple problem: organisations were often too slow to detect, report and recover from cyber disruption. That gap becomes more visible when the affected environment includes finance, essential services and complex supplier chains, where access paths and recovery dependencies are tightly interwoven.

The identity angle is real even though the article is framed as cyber resilience. Third-party access, executive accountability, monitoring coverage and recovery evidence all depend on who can act, what they can reach and how quickly those privileges can be contained when an incident occurs.

Key questions

Q: What are the first compliance gaps teams should fix for DORA and NIS2?

A: Start with incident reporting ownership, supplier access visibility and recovery evidence. If the organisation cannot prove who can detect, validate and escalate an incident, compliance will fail under pressure. The strongest programmes bind access governance, response playbooks and supplier obligations into one auditable workflow rather than treating them as separate workstreams.

Q: Why does NIS2 make third-party access a governance issue?

A: Because NIS2 expects organisations to control risk across their supply chain, not just inside the enterprise boundary. If vendors, MSPs, or cloud partners retain unnecessary access, the organisation still owns the accountability. Third-party lifecycle management, entitlement scope, and revocation discipline become part of compliance.

Q: What breaks when incident response plans are not rehearsed?

A: When plans are not rehearsed, teams lose time deciding who can act, what to isolate, and how to communicate. That delay can let attackers keep access, expand scope, or destroy evidence. A plan that cannot be executed under pressure is not a control, only a document.

Q: Which controls help prove readiness for DORA and NIS2 oversight?

A: Controls that tie privileged access, monitoring, supplier accountability and recovery testing into one evidence chain are the most useful. The goal is not simply to have policies, but to show that access decisions, incident handling and business continuity are joined up well enough to withstand supervisory review.

Technical breakdown

How DORA and NIS2 change resilience from policy to evidence

Both measures push organisations beyond aspirational security language and toward demonstrable operating controls. DORA focuses on financial entities and their service providers, while NIS2 broadens the compliance burden across essential and important sectors. In practice, that means resilience is no longer judged only by plans on paper. Regulators and auditors will expect evidence that incidents are detected, escalated, reported and recovered through tested processes, not improvised during a crisis.

Practical implication: map your control evidence to incident detection, reporting and recovery workflows before a regulator asks for proof.

Why third-party and supplier access is now a compliance issue

The article makes clear that both rules extend beyond the primary organisation. DORA explicitly brings digital service providers into scope, and NIS2 pushes supply chain security as a core obligation. That matters because outsourced access often becomes the weakest governance point: standing vendor accounts, untested offboarding, unclear notification paths and missing contractual duties can all break the chain between detection and accountable reporting.

Practical implication: treat supplier access, offboarding and notification obligations as part of the compliance control set, not an adjacent procurement task.

What reporting deadlines expose about identity and response readiness

Rapid-turnaround reporting only works when organisations know who owns the incident, who can validate impact and who can authorise containment. That creates a hidden identity control problem inside resilience: access to logs, systems, evidence stores and executive escalation channels must be reliable under stress. If those paths are unclear, incident reporting becomes an administrative scramble rather than a controlled regulatory process.

Practical implication: test whether incident responders, approvers and evidence owners can be identified and reached quickly under real disruption.

Threat narrative

Attacker objective: The attacker aims to disrupt operations, extend access into valuable systems and create business or regulatory fallout that the organisation must then explain and report.

1. Entry often begins with compromise of exposed services, third-party access or user pathways that were not governed tightly enough to limit blast radius.
2. Escalation follows when the attacker can move through weak monitoring, standing access or poorly contained supplier connections to reach higher-value systems.
3. Impact is realised through business disruption, data loss or delayed recovery that then becomes a reporting and accountability problem for the organisation.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Regulatory resilience has become an access-governance problem: DORA and NIS2 may read like cyber compliance measures, but the operational test is still identity, privilege and evidence control. If organisations cannot prove who had access, who could approve containment and who owned supplier connectivity, they will struggle to demonstrate resilience under either regime. The practical conclusion is that compliance now depends on access governance as much as on monitoring.

Third-party oversight is now part of the control plane: The article correctly points to suppliers, digital service providers and contractual supplements because modern resilience failures rarely stay inside one organisation. Third-party accounts, delegated access and notification obligations create an expanded governance boundary that security teams have to manage continuously. Practitioners should treat supplier identity lifecycles as regulated operational dependencies.

Reporting deadlines expose the difference between detection and readiness: Many programmes can detect an incident, but far fewer can assemble accurate impact, ownership and escalation evidence under pressure. That gap is where compliance fails, because the regulator is not asking whether an alert fired. The question is whether the organisation can turn detection into a defensible report inside the required window.

Standards alignment now matters because control evidence must be portable: NIST-CSF, CIS Controls and NIST 800-53 all help structure resilience work, but the regulatory demand is evidence that survives scrutiny across incident response, recovery and supplier management. For identity teams, the useful takeaway is to align access review, privileged access and offboarding evidence with the same reporting chain used for cyber events. That makes the control story auditable, not just internally persuasive.

What this signals

Regulatory readiness now depends on control evidence, not policy language: Teams should expect DORA and NIS2 to force a tighter link between access governance, incident response and business continuity. If privileged access and third-party accounts are not mapped to reporting and recovery duties, the programme will look complete until the first real incident.

Third-party identity lifecycles are now part of resilience planning: Supplier access, termination steps and notification obligations need to be testable alongside the core response plan. That is especially true where service providers can influence logs, recovery paths or evidence collection, because those dependencies shape how quickly a team can explain an incident.

Resilience reporting is a governance test for the whole operating model: Security leaders should prepare for questions about who can authorise actions, who owns the evidence and how the organisation proves it can meet reporting deadlines under degraded conditions. The programmes that win here will be the ones that make identity, access and accountability visible before the crisis arrives.

For practitioners

• Map reporting evidence to named owners Identify who can validate incident scope, authorise containment and submit regulatory updates across finance, critical services and suppliers.
• Review supplier access and offboarding paths Check whether third-party accounts, contractual notification duties and termination steps are documented, tested and tied to resilience obligations.
• Test incident reporting under pressure Run exercises that force teams to gather logs, impact evidence and approval chains while systems are degraded or access is partially unavailable.
• Close executive accountability gaps Confirm that board-level ownership, escalation criteria and decision rights are explicit for both DORA and NIS2 reporting scenarios.
• Align access governance with resilience controls Ensure privileged access, monitoring coverage and offboarding evidence can support both operational recovery and regulatory reporting requirements.

Key takeaways

• DORA and NIS2 move cyber resilience from a best-practice discussion into a regulated obligation for finance and essential services.
• The strongest compliance pressure sits at the intersection of incident reporting, supplier oversight and executive accountability.
• Organisations that cannot evidence access ownership, recovery readiness and third-party control will struggle to satisfy supervisory expectations.

Key terms

• Digital Operational Resilience Act: DORA is an EU regulatory framework that requires financial entities and their critical ICT providers to prove they can withstand, respond to, and recover from disruption. For identity teams, it turns authentication, access, and recovery into evidence-bearing controls rather than background IT functions.
• Third Party Risk: Third party risk is the chance that an outside organization, supplier, contractor, or service provider will create harm for your business. It includes security, privacy, operational, legal, and compliance exposure caused by access to data, systems, or processes. In identity terms, it often arises from shared credentials, integrations, and delegated trust.
• Incident Reporting: The process of detecting, triaging, documenting, and notifying the right stakeholders about a security event. Under DORA and NIS2, reporting becomes a governed capability that depends on accurate logs, clear ownership, and rehearsed decision paths rather than ad hoc communication.
• Operational Accountability: Operational accountability is the ability to assign ownership, prove control enforcement, and show evidence for AI decisions and data use. It requires named responsibilities, auditable actions, and governance processes that make it clear who approved the system, who monitors it, and who responds when it fails.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and IAM practitioners connect identity controls to the resilience and accountability demands reflected in modern regulation.