Who is accountable for NIS2 access decisions and incident reporting?

Why This Matters for Security Teams

NIS2 turns access control and incident reporting into board-level accountability, but the operational burden sits with identity, security, and data teams. That split matters because regulators do not accept “the system did it” as an answer when access was granted too broadly or an incident report was late. Evidence must show who approved access, who reviewed it, and who escalated the incident. For NHI-heavy environments, that evidence often depends on disciplined secrets governance and audit-ready identity records, as highlighted in the Ultimate Guide to NHIs.

The practical challenge is that most organisations now rely on service accounts, API keys, and automation tokens that do not behave like human users. The attack surface is larger, the review cadence is weaker, and incident scope can expand quickly once a single secret is exposed. Current guidance suggests mapping these controls to the access and incident handling obligations set out in the EU NIS2 Directive, then proving ownership with logs, approvals, and reporting artefacts. In practice, many security teams encounter accountability gaps only after an access review fails or a report deadline is missed, rather than through intentional control design.

How It Works in Practice

Accountability under NIS2 is not just a policy statement. It requires named ownership for access decisions, periodic review outcomes, and incident reporting workflows. Management remains accountable for governance, but operational teams need defined responsibilities for deciding who can access what, under which conditions, and how quickly that access is revoked when risk changes. For NHI and service-account estates, that usually means joining IAM records with secrets inventory, ticketing history, and approval evidence so the organisation can reconstruct a decision chain.

Practitioners usually make this work by separating three layers:

• Access decision ownership: define who approves privilege changes, who validates exceptions, and who can override standard policy.
• Review evidence: retain recertification results, revocation actions, and justification for any retained access.
• Incident reporting custody: assign who detects, classifies, documents, and submits the report, including internal escalation thresholds.

That structure becomes far more defensible when teams can align it to current NHI control guidance such as the OWASP Non-Human Identity Top 10 and to the governance perspective in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The goal is not only faster access decisions, but also a provable trail showing why those decisions were made and how incidents were contained. These controls tend to break down when access is embedded in CI/CD pipelines without ticket linkage because the approval chain becomes invisible after deployment.

Common Variations and Edge Cases

Tighter approval and reporting controls often increase operational overhead, requiring organisations to balance speed against evidentiary strength. That tradeoff is especially visible in automation-heavy environments, where pipeline credentials, break-glass access, and third-party integrations can change too quickly for manual recertification alone.

There is no universal standard for how often NIS2 access reviews must run for every environment, so current guidance suggests risk-based frequency rather than a one-size-fits-all calendar. High-impact systems need shorter review intervals and stronger exception handling. Low-risk internal tooling may tolerate a lighter process, but only if revocation, logging, and reporting still remain auditable.

Two edge cases matter most. First, delegated administration can blur responsibility when platform teams manage access tools but business owners approve the actual privileges. Second, outsourced operations can weaken incident reporting if contracts do not specify who records, escalates, and submits notifications. The NIS2 legal text and the broader research on NHI exposure in the 52 NHI Breaches Analysis both point to the same pattern: accountability fails when ownership is implied instead of documented. In practice, this gap is usually discovered during an audit or a live incident, not during routine governance.

Related resources from NHI Mgmt Group

• Who is accountable when supplier access contributes to a NIS2 incident?
• Who is accountable when a DDoS outage disrupts customer access?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who should be accountable for DNS access reviews?