They lose the ability to prove who can actually perform regulated actions, which weakens incident response, recovery, and third-party risk governance. A directory can show that an account exists, but it cannot by itself prove whether that identity can move data, change controls, or trigger critical workflows. DORA programmes need entitlement-level visibility, not just account inventory.
Why account inventory alone fails under DORA
Tracking accounts tells you that an identity exists, but not whether it can execute a regulated action. For DORA, that gap matters because operational resilience depends on knowing which users, admins, services, and vendors can actually change controls, move data, approve workflows, or disrupt recovery paths.
An account list is a directory view. effective permissions are the control view. If you cannot answer “who can do what, in which system, under which conditions,” you cannot reliably prove least privilege, segregation of duties, or blast-radius containment when an incident occurs.
That is why entitlement-level visibility is the real requirement, not just account inventory. A permissions view also exposes inherited access, dormant but still powerful roles, cross-environment trust, and privilege pathways that a plain account count will miss.
What breaks in incident response, recovery, and third-party governance
When teams only track identities, they often misclassify risk during an event. An account may appear normal even though it can still trigger production changes, access sensitive records, or invoke vendor-connected workflows. The result is slower triage, weaker containment, and poorer evidence for demonstrating control effectiveness.
For DORA specifically, that can undermine EU Digital Operational Resilience Act (DORA) obligations around ICT risk management, incident handling, and third-party oversight. A team needs to know not only which accounts exist, but which external providers, service identities, and delegated paths can actually affect critical functions.
It also makes recovery harder. During restoration, you need to distinguish safe access from residual privilege, especially where standing access, break-glass paths, or inherited admin rights could reintroduce the failure you were trying to recover from. A directory alone cannot answer that.
How to model access so DORA controls are auditable
The practical fix is to treat permissions as the auditable object and accounts as one of several inputs. That means mapping entitlements, roles, groups, inherited permissions, conditional access, and service-to-service trust into one view that can be reviewed against critical business services.
Effective permissions are easiest to understand when teams inspect the path from granted access to effective permissions, not just the presence of an account. That is where overprivilege, cross-account trust, and hidden escalation paths usually become visible.
For organisations with cloud, platform, or automation-heavy estates, this also supports identity controls mapped to regulatory obligations and helps align access reviews with what regulators and auditors actually care about: whether a control can be exercised, not whether an account exists on paper.
Risk and Threat Considerations
When teams rely on identity inventories instead of effective permissions, they create blind spots in both resilience and attack surface. Excessive access, inherited access, and dormant but still-authorised accounts can all survive unnoticed until an incident, when they become the fastest route to disruption, data movement, or recovery failure.
Failure mechanism: The organisation reviews names in a directory, but not the entitlements, role chains, delegated trust, and conditional paths that determine real authority. That leaves privileged workflows, third-party access, and emergency paths insufficiently governed.
Impact: Incident response becomes slower and less certain, recovery can re-enable unsafe access, and third-party risk decisions become harder to defend because the team cannot prove who could actually perform critical actions.
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 DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | GV.SC — Cybersecurity Supply Chain Risk Management | DORA requires control over third-party and delegated access paths that affect critical services. |
| RC.RP — Recovery Planning | DORA recovery depends on knowing which identities can change systems during restoration. | |
| GV.RM — Risk Management Strategy | Effective permissions are needed to evidence operational resilience and access risk governance under DORA. | |
| Recommendation — Map external and delegated access to critical services and review it as a supply-chain risk. Validate the permissions that can alter recovery steps before declaring restoration complete. Base access governance on effective permissions, not account counts, for resilience reporting. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Effective permissions are the direct object of least-privilege enforcement and review. |
| AC-2 — Account Management | Account records alone are insufficient without managing the permissions attached to them. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit evidence must show who can perform regulated actions, not only who exists in directories. | |
| Recommendation — Review and trim actual entitlements, not just account presence. Link account lifecycle actions to entitlement changes and periodic validation. Collect audit evidence that ties actions back to effective permissions and privileged paths. | ||
Practitioner Guidance
What to verify: Before trusting an access review, verify the effective permission set for each critical identity, including inherited group membership, cross-account trust, and any role that can modify controls or recovery settings.
Decision rule: If an identity can change production state, move sensitive data, or approve a recovery step, treat it as privileged regardless of how ordinary the account appears in the directory. If you cannot trace that path, treat the access review as incomplete.
What good looks like: Recovery teams can answer, from evidence, which identities can perform regulated actions, which third parties depend on those paths, and which permissions are temporary, standing, or exception-based.
Practitioner takeaway: Under DORA, account inventory is only the starting point, because resilience and governance depend on proving actual authority, not just listing identities.
Related resources from NHI Mgmt Group
- What breaks when teams rely only on direct entitlements instead of effective permissions?
- What breaks when Azure teams rely on assigned roles instead of effective permissions?
- How should security teams govern non-human identities alongside human accounts?
- How should security teams govern Active Directory service accounts?