Access reviews satisfy NIS2 Article 21(2)(i) and DORA Article 9(4)(c) only when they produce evidence that can withstand supervisory scrutiny. Sign-off alone does not constitute evidence. A manager who approves 200 entitlements in four minutes has completed the review on paper. They have not performed a risk-informed access decision, and the resulting artifact will not survive a competent auditor's examination. The operational question for regulated entities in 2026 is not whether access reviews are conducted but whether they produce audit-grade evidence of deliberate, informed access decisions. This guide covers the practical implementation of evidence-based identity governance: what constitutes defensible access review evidence, how to structure review campaigns for quality rather than completion, how SCIM provisioning eliminates lifecycle gaps, and how to detect and remediate orphaned accounts before auditors find them.
What NIS2 and DORA Specifically Require for Access Control
The regulatory requirements for access control are more specific than many organizations realize. A generic "we do access reviews" statement does not satisfy either framework.
NIS2 Article 21(2)(i) requires measures for "human resources security, access control policies and asset management." The legislative text groups access control with HR security deliberately. The European Commission's implementing guidance and ENISA's NIS2 implementation materials clarify that this requires identity lifecycle management that is synchronized with HR events: onboarding provisions the correct access, role changes trigger access modification, and offboarding revokes all access with verifiable completeness.
The implementing regulation further specifies that access control policies must include the principle of least privilege, separation of duties, and regular review of access rights. "Regular review" is not defined by a specific frequency, but the expectation from national competent authorities conducting supervisory reviews in 2026 is that review frequency should be proportionate to the criticality of the systems involved. Critical systems should be reviewed more frequently than low-risk systems.
DORA Article 9(4)(c) requires financial entities to implement "policies and procedures for the granting and revocation of access rights and their monitoring." The explicit mention of both granting and revocation reflects a regulatory recognition that most organizations are better at granting access than revoking it. The monitoring requirement adds a continuous dimension: it is not sufficient to grant and revoke correctly. The organization must also monitor access rights on an ongoing basis to detect drift.
DORA Article 9(4)(d) requires "strong authentication mechanisms, based on relevant standards." For access reviews, this means the review process itself should require authenticated review decisions. A bulk approval performed without the reviewer authenticating to the review platform does not demonstrate deliberate decision-making.
DORA RTS on ICT risk management (published under Article 15 delegated acts) further specifies that financial entities should maintain a register of user access rights, regularly compare actual access against granted access, and document deviations. The comparison requirement is operationally significant: it demands that organizations verify not just what access was granted but what access is actually in use.
What Constitutes Audit-Grade Access Review Evidence
Audit-grade evidence is evidence that a competent auditor or supervisory authority can use to determine whether the control achieved its intended purpose. For access reviews, the intended purpose is ensuring that every identity holds only the access rights that their current role requires and that excess access is identified and remediated.
An audit-grade access review evidence package must include:
Scope documentation. What identities and entitlements were included in the review? What was excluded and why? If service accounts were excluded, is there a separate review process for them? Scope gaps are the first thing auditors check because they indicate whether the review covered the full access population or only a convenient subset.
Reviewer qualification. Who performed the review, and why were they qualified to assess the entitlements in question? A reviewer should be the functional manager or system owner who understands what access the role requires. Reviews delegated to someone who does not understand the business context (the intern completing them during the manager's vacation) produce evidence of completion, not evidence of informed decision-making.
Review duration and depth metrics. How long did the reviewer spend on each entitlement decision? If a reviewer approved 150 entitlements in eight minutes, the evidence demonstrates rubber-stamping, not review. Auditors increasingly request timestamp data for individual approval decisions to assess whether meaningful evaluation occurred.
Decision justification for non-standard entitlements. For entitlements that fall outside the standard role profile, the reviewer should document why the entitlement is required. "Still needed" is not justification. "Required for ongoing Project Atlas data migration, expected to complete Q2 2026" is justification. The specificity of justification directly correlates with the evidentiary value of the approval.
Remediation tracking for revoked entitlements. When the review identifies entitlements that should be revoked, the revocation must be tracked to completion. An access review that identifies 40 entitlements for revocation but only revokes 30, with the remaining 10 lost in the workflow, has a 25% remediation failure rate. Auditors will calculate this rate, and it directly undermines the control's effectiveness claim.
Exception documentation with expiry. Any decision to retain entitlements that exceed the role profile should be documented as an exception with a defined expiry date and an accountable owner. Exceptions without expiry become permanent entitlements by default, defeating the purpose of the review.
Campaign-Based vs Continuous Review: Choosing the Right Model
Organizations implementing access reviews under NIS2 and DORA face an architectural choice between campaign-based and continuous review models. Each has distinct advantages, and many organizations will use both.
Campaign-based reviews operate on a defined schedule: all entitlements for a defined scope are reviewed during a fixed window. Quarterly campaigns for critical systems, semi-annual campaigns for standard systems, and annual campaigns for low-risk systems are a common cadence.
Campaign advantages: clear deadlines create accountability, compliance reporting is straightforward (campaign completed by X date with Y% completion), and resource planning is predictable. Campaign disadvantages: access drift between campaigns is unmonitored, review fatigue increases as campaign volume grows, and the artificial deadline encourages rushing through reviews to hit completion targets.
Continuous reviews trigger access re-evaluation based on events rather than schedules. An employee role change triggers review of existing entitlements. A new entitlement grant outside the standard provisioning process triggers immediate review. An entitlement that has not been used for 90 days triggers usage-based review. A vendor's security rating downgrade triggers review of their personnel's access.
Continuous advantages: drift detection is near-real-time, review volume is distributed evenly over time rather than concentrated in campaign windows, and reviews are contextually relevant (triggered by a change that might affect access appropriateness). Continuous disadvantages: completeness is harder to measure (there is no "campaign completion rate"), the triggering logic requires integration with HR, provisioning, and usage analytics systems, and resource requirements are less predictable.
The practical recommendation for organizations under NIS2 and DORA: use campaign-based reviews as the baseline to ensure complete coverage at defined intervals, and layer continuous reviews on top for high-risk scenarios (role changes, unusual access patterns, vendor downgrades) that should not wait for the next campaign cycle. The combination provides both the coverage completeness that auditors expect and the operational responsiveness that real identity risk demands.
SCIM Provisioning: Closing the Lifecycle Gap
SCIM (System for Cross-domain Identity Management) is the protocol that transforms identity lifecycle management from a manual, error-prone process into an automated, auditable one. For NIS2 and DORA compliance, SCIM is not a nice-to-have. It is the operational mechanism that closes the gap between HR events and access state.
The lifecycle management problem is straightforward: when an employee joins, changes roles, or leaves, their access across all systems must be updated to reflect their new status. Without automated provisioning, this update depends on manual processes: IT tickets, email requests, individual system administrator actions across every application. Each manual step introduces delay, potential error, and evidence gaps.
Onboarding with SCIM. When HR creates a new employee record, SCIM provisioning automatically creates accounts in all systems that the employee's role requires, with exactly the entitlements defined for that role. The provisioning is logged with timestamps, creating evidence that access was granted according to the defined role profile from day one. No excess access, no ad-hoc grants, no gaps in provisioning evidence.
Role changes with SCIM. When HR records a role change, SCIM automatically adjusts entitlements across all connected systems: new role entitlements are provisioned, and previous role entitlements that do not apply to the new role are revoked. The adjustment is logged, creating evidence that access was modified to match the new role without manual intervention. Without SCIM, role changes are the primary source of privilege accumulation: new access is granted, old access is retained.
Offboarding with SCIM. When HR records a termination, SCIM automatically deprovisions the employee's accounts across all connected systems. The deprovisioning is logged with confirmation from each system, creating evidence that access was revoked completely and promptly. Without SCIM, offboarding completeness depends on manual checklist execution, and verification requires checking each system individually.
SCIM does not solve all lifecycle management problems. Applications that do not support SCIM still require manual provisioning and deprovisioning. Non-human identities (service accounts, API keys) are outside SCIM's scope. But for the applications that support SCIM, the protocol transforms identity lifecycle management from a manual evidence collection problem into an automated, audit-ready process.
DORA's requirement in Article 9(4)(c) for "policies and procedures for the granting and revocation of access rights" is most cleanly satisfied by SCIM-based provisioning, because the granting and revocation are automated, logged, and auditable by design.
Orphaned Account Detection: Finding What the Reviews Miss
Orphaned accounts are accounts that exist in application systems but are no longer associated with an active identity. They emerge from three sources: incomplete offboarding (the corporate directory account was disabled but application-level accounts persist), unmanaged application adoption (an employee created an account in a SaaS application outside IT's provisioning scope), and historical migrations (accounts created during system migrations that were never cleaned up).
Orphaned accounts are high-risk for two reasons. First, they often retain the access rights they held when they were active, including any accumulated excess access. Second, they are not monitored. No one logs in to review their activity because no one knows they exist. An attacker who discovers an orphaned account with elevated privileges has persistent, unmonitored access to the system.
Detecting orphaned accounts requires a comparison between two data sets: the set of all accounts in all application systems and the set of all active identities in the corporate directory. Any account that exists in an application system but does not correspond to an active identity is potentially orphaned.
This comparison is straightforward in concept and difficult in practice because it requires a complete inventory of accounts across all application systems, not just the ones connected to the corporate IdP. Shadow IT applications, legacy systems with local authentication, and partner portals with independently managed accounts all contain potential orphaned accounts that central identity tools cannot see.
Practical orphaned account detection follows a three-step process:
Discovery. Enumerate accounts across all known application systems. For SCIM-connected applications, account data is available through the protocol. For non-SCIM applications, API integrations, log analysis, or manual inventory are required. The discovery scope should explicitly include systems that the corporate IdP does not manage.
Correlation. Match discovered accounts against the active identity directory. Flag accounts that have no matching active identity, accounts where the matching identity has been terminated, and accounts where the matching identity's role does not justify the application access.
Remediation. Disable or delete orphaned accounts according to a defined process. For accounts with potential business data dependencies, disable first and delete after a confirmation period. For accounts with elevated privileges, disable immediately and investigate access logs for unauthorized activity.
NIS2 Article 21(2)(i)'s access control requirement implicitly includes orphaned account management because orphaned accounts represent uncontrolled access that no policy governs. DORA's requirement to monitor access rights on an ongoing basis explicitly requires the kind of continuous account inventory and correlation that orphaned account detection demands.
Segregation of Duties: Evidence That Exceptions Are Managed
Segregation of duties (SoD) conflicts occur when a single identity holds entitlements that, when combined, create a risk that the organization's control framework is designed to prevent. A user who can both create purchase orders and approve payments, for example, holds a classic SoD conflict because they can execute a fraudulent transaction without a second party's involvement.
Under NIS2 and DORA, SoD is not just a financial controls concern. In the cybersecurity context, SoD conflicts include: an identity that can both deploy code to production and approve that deployment, an identity that can both create user accounts and approve access rights, an identity that can both configure security monitoring and suppress alerts.
The evidence challenge with SoD is not detecting conflicts. Most identity governance platforms can define SoD rules and flag violations. The evidence challenge is demonstrating that detected conflicts are managed through a deliberate risk acceptance process rather than ignored.
Audit-grade SoD evidence includes: a documented SoD rule set that reflects the organization's control objectives, automated detection of violations against that rule set, a risk acceptance process for necessary violations (with business justification, compensating controls, executive approval, and defined expiry), and periodic revalidation of accepted exceptions to confirm they remain necessary and that compensating controls remain effective.
Unmanaged SoD exceptions are among the findings most likely to generate supervisory action under both NIS2 and DORA, because they represent a governance process that was defined but not executed.
Building the Evidence-First Identity Governance Program
The transition from ceremony-based to evidence-first identity governance requires changes across process, technology, and organizational accountability.
Process redesign. Replace the annual review checkbox with a tiered review program: quarterly campaigns for critical system access, semi-annual for standard access, and continuous event-triggered reviews for role changes, vendor changes, and usage anomalies. Define evidence quality standards (reviewer qualification, decision timeliness, justification requirements) and measure against them. Treat evidence quality as a KPI alongside review completion.
Technology enablement. Deploy SCIM provisioning for all applications that support it. Implement automated orphaned account detection across the full application inventory. Enable review workflow tools that capture decision-level timestamp and justification data. Integrate identity governance with compliance management to map access controls directly to NIS2 Article 21(2)(i) and DORA Article 9(4)(c) evidence requirements.
Organizational accountability. Assign identity risk ownership to a named executive, not just the IAM team. Report identity risk metrics (privilege drift, review quality scores, offboarding completeness, orphaned account population, SoD exception age) to leadership alongside other enterprise risk metrics. Make identity governance a standing board agenda item, not an annual CISO report footnote.
How FortisEU Operationalizes Evidence-First Access Governance
FortisEU implements identity governance as a core risk domain with evidence quality built into every workflow. Access review campaigns in FortisEU capture decision-level data: who reviewed, when they reviewed, how long they spent, what justification they provided, and what remediation actions resulted. This evidence package is generated automatically by the review workflow, not assembled manually after the fact.
The platform supports both campaign-based and continuous review models, with configurable triggers for event-based reviews on role changes, vendor risk changes, and entitlement usage anomalies. Orphaned account detection runs continuously against the full application inventory, with findings routed to accountable owners through SLA-enforced remediation workflows.
For organizations subject to NIS2 and DORA, FortisEU maps identity governance evidence directly to specific regulatory articles, generating compliance evidence packages that can be presented to supervisory authorities without manual assembly. SoD conflicts are detected against configurable rule sets, with exception management that enforces expiry, compensating controls, and periodic revalidation.
Key Takeaways
- Audit-grade access review evidence requires scope documentation, reviewer qualification, decision timing data, specific justification for non-standard entitlements, remediation tracking, and exception management with expiry. Sign-off alone does not constitute evidence under NIS2 or DORA supervisory scrutiny.
- Use campaign-based reviews for baseline coverage and continuous event-triggered reviews for high-risk scenarios. The combination provides the completeness auditors expect and the responsiveness that operational identity risk demands.
- SCIM provisioning transforms identity lifecycle management from a manual evidence collection problem into an automated, audit-ready process. It is the cleanest path to satisfying DORA Article 9(4)(c) requirements for access granting and revocation procedures.
- Orphaned account detection requires comparing accounts across all application systems against the active identity directory, including applications outside the corporate IdP's management scope. Orphaned accounts with elevated privileges represent high-risk unmonitored access.
- SoD conflict management must demonstrate a deliberate risk acceptance process, not just detection. Unmanaged SoD exceptions are among the highest-likelihood supervisory findings under both NIS2 and DORA.