NIS2 Identity Audit Without Paralysis

Introduction

Conducting a comprehensive NIS2 identity audit often feels like an impossible trade-off between strict security oversight and the need for business agility.

Identity teams frequently face operational paralysis when they attempt to audit access for every user and application simultaneously. The European Union's Directive (EU) 2022/2555 mandates stringent supply chain security and access controls, yet it does not require an immediate, platform-wide lockout.

By adopting a risk-based filtering approach, security engineers can support the access-control part of NIS2 while maintaining continuous operations. This strategy requires shifting focus from exhaustive manual spreadsheet reviews toward automated, data-driven identity lifecycle verification that targets high-risk zones first.

An identity review will not make an organization NIS2-compliant by itself. It supports the access-control part of NIS2 by producing the evidence and decisions that those measures depend on.

Auditors expect both documented policies and evidence that they operate: an access register, approval and revocation logs, review decisions, approved exceptions and test results (NIS2 Articles 32 and 33; Implementing Regulation (EU) 2024/2690, Annex, point 11).

This guide is for organizations that fall under NIS2 as essential or important entities, and for suppliers that support them. Supporting an in-scope organization does not automatically make a supplier directly regulated. In Poland, NIS2 was implemented through amendments to the Act on the National Cybersecurity System (KSC), effective 3 April 2026. Check the requirements and transition dates that apply to your entity. Treat the thresholds in this guide as examples to adapt to your risk.

NIS2 doesn't prescribe a standalone "identity audit". It requires proportionate cybersecurity risk-management measures, including access control (Article 21). A structured identity review is one practical way to meet that part.

Prerequisites

Successful audits rely on operational readiness rather than just compliance documentation. Start with the best available inventory: the identity provider (IdP), critical SaaS and non-SaaS systems, local and emergency accounts, and machine identities. Record the inventory's gaps and prioritize by service risk. Include applications managed by business units outside of standard IT control.

Before starting, ensure that JML (Joiner-Mover-Leaver) processes are mapped to specific identity attributes within your primary IdP. Furthermore, assign clear entitlement ownership to business managers for non-standard roles.

Without these foundations, auditing efforts lack the necessary context to distinguish between active business usage and residual technical debt.

Step-by-step implementation

Implementing an identity access review requires a phased, verifiable procedure that connects security policy to operational reality. The following steps provide a repeatable framework for identity teams to execute a thorough review while reducing the risk of disruption.

Step 1: Scoping systems critical to services

1. Start with the best available inventory. Include the identity provider (IdP), critical SaaS and non-SaaS systems, local and emergency accounts, and machine identities. Record gaps and prioritize by service risk.
2. Identify systems that process essential service data or host sensitive customer records, not only high-risk SaaS and B2B.
3. Map existing B2B federation endpoints to distinguish external partner access from internal employee access.
4. Segment these systems into tiers based on data sensitivity and organizational impact.
5. Document current MFA requirements and session timeout settings for each scoped system.
6. Collect enough sign-in and audit logs to see normal use. For many systems a few weeks is a reasonable starting example; base the window on how often the system is used and how long your logs are kept.

Step 2: Identifying ghost accounts and stale identities

1. Extract user lists from scoped applications and reconcile them with both IdP data and personnel or partner records. The IdP alone cannot confirm employment or contract status.
2. Flag accounts with no recent sign-in for review. For example, 90 days is a common starting point; use a shorter threshold for privileged and external accounts, and a longer one for seasonal users. A few weeks of logs cannot establish 90 days of inactivity unless reliable last-sign-in history exists; treat missing history as unknown, not inactive.
3. Investigate service accounts and machine identities that lack documented owners or defined expiration policies.
4. Create a temporary report of all accounts that exist in local application databases but are missing from the centralized IdP.
5. Verify if these identities belong to former employees, contractors, or external consultants. Record those findings against Deprovisioning so orphaned accounts are listed for an approved change rather than removed during the inventory.

Step 3: Reviewing roles and privileged access

1. Review existing RBAC models to determine if assigned permissions still align with current job functions.
2. Use named administrators, limit standing privilege, and test a backup or emergency-access path.
3. Evaluate direct access grants that bypass group-based membership, identifying outliers that violate standard provisioning.
4. Document every instance where a user holds conflicting administrative privileges across different business systems.
5. Confirm that entitlement maps are readable by department leads, not just technical administrators, to ensure accountability for access assignments.

Keep the audit separate from the fix. Inventory, reconciliation, owner decisions and evidence collection are read-only and shouldn't disrupt anyone. Revoking grants, disabling accounts or switching a policy to enforce (fail-closed) are production changes. Run them through your normal change process: a named approver, a pilot on a small group, a check of the impact, and a tested rollback. Exceptions are approved by the business owner of the system, recorded with a reason and an end date, and signed off by security.

Step 4: Aligning governance controls with NIST 800-53

1. NIST SP 800-53 (for example the AC and IA control families) is a useful mapping for structuring controls, but it is not a NIS2 requirement.
2. Formalize Least Privilege by implementing granular policy updates for accounts exceeding required access levels, through an approved change.
3. Create a change management ticket for each identified privilege reduction to ensure operational transparency.
4. Run owner reviews at planned intervals that match the risk, with privileged and external access reviewed more often than standard access. An annual cycle is only an example. For entities covered by Implementing Regulation (EU) 2024/2690 (for example cloud, data center and managed service providers), access rights must be reviewed at planned intervals; the regulation does not set a fixed annual cadence.
5. Standardize naming conventions for all roles and permissions to improve the traceability of access decisions during future audits.

Step 5: Transitioning to sustainable automation

1. Use identity governance tooling that lets owners review and approve access in one place and keeps a record of each decision.
2. Set up automated alerts for when new administrative accounts are provisioned outside of standard request channels.
3. Deploy self-service access request portals to reduce the burden of manual entitlement management.
4. Schedule recurring reports that compare IdP groups with application entitlement exports to catch drift. Access logs help assess use; they do not show every grant.
5. Conduct a quarterly review of the automation rules themselves to ensure they still capture the intent of your security policies.

Worked example: an inactive partner account

During the inventory, an export from the customer support application shows an account for a contractor at a former partner agency. Its last sign-in was five months ago, and it still has agent-level access to customer records.

1. Check the identity source. Look the account up in the identity provider (IdP). It is a local application account, not federated. A local account alone does not prove it was omitted from the leaver process; the review must establish that.
2. Check with the business owner. The support manager who owns the application confirms that the partner contract ended in the spring and that nobody needs the account.
3. Record the finding. Log it in the access register with the account, the access level, the last sign-in date, the owner's decision ("remove") and the risk (external access to personal data).
4. Approve the change. Raise a standard change to disable the account, approved by the application owner. Plan the rollback: if the former partner's access must be restored, require fresh owner approval.
5. Remove and validate. Disable the account, revoke its active sessions and API tokens, and confirm that a sign-in attempt fails. Delete it per retention policy while preserving the audit record.
6. Fix the cause. Add local and partner accounts in this application to the next owner review, so the next one is caught by the process rather than by an audit.

Finding, decision, change record and test result together make up the evidence.

Validation and testing

Verification techniques prove that your access controls function correctly in a live environment. Testing does not mean breaking existing workflows.

By setting new access policies to report-only or audit mode where the product supports it, identity operators can detect potential service disruptions before they impact end users.

Leave a policy in report-only mode long enough to see real usage, for example one or two business cycles, where the product supports it. Don't wait by default when you already know about a deficiency. NIS2 Article 21(4) expects corrective measures without undue delay, so fix confirmed high-risk gaps (e.g. an active account for someone who has left) straight away, through an approved change.

Define the policy's scope, test representative workflows, and monitor its impact after enforcement.

Common pitfalls

Avoiding common mistakes prevents the audit process from becoming a source of business friction. Many organizations fall into the trap of spreadsheet-driven paralysis, where thousands of rows of data are manually updated without ever reaching a state of reconciliation.

Neglecting external B2B access often leaves a significant security gap, as partners frequently retain access far longer than necessary. Another frequent mistake is failing to define clear entitlement ownership, which results in orphaned permissions that nobody dares to remove.

Avoid these errors by mandating that every application owner must sign off on their specific access list during the audit cycle.

Sources

• Directive (EU) 2022/2555 NIS2
• Implementing Regulation (EU) 2024/2690
• NIST SP 800-53 Rev. 5 Update 1
• Amendments to the Act on the National Cybersecurity System (KSC)

FAQ

How does the NIS2 Directive impact identity management?

The NIS2 Directive requires organizations operating as essential or important entities to implement proportionate cybersecurity risk-management measures, including access control (Article 21). For identity management teams, this means you must provide documented evidence of who has access to what, ensure timely deprovisioning of leavers, and maintain rigorous oversight of privileged access, particularly for third-party B2B connections. Supporting an in-scope organization does not automatically make a supplier directly regulated.

What is the first step in a non-disruptive identity audit?

The first step is scoping systems critical to the organization's services. Rather than attempting to audit every application at once, identity teams should start with the best available inventory — the IdP, critical SaaS and non-SaaS systems, local and emergency accounts, and machine identities — record its gaps, and prioritize by service risk. This focuses initial efforts where disruption would matter most.

How can I identify ghost accounts without manual spreadsheet review?

Reconcile application accounts with both IdP data and personnel or partner records. The IdP alone cannot confirm employment or contract status. Flag accounts with no recent sign-in for review. For example, 90 days is a common starting point; use a shorter threshold for privileged and external accounts, and a longer one for seasonal users. Treat missing last-sign-in history as unknown, not inactive.

Why is entitlement ownership critical for NIS2 compliance?

Entitlement ownership provides accountability. When access is granted, NIS2 requires clear evidence that the access was justified and approved. If an entitlement has no owner, nobody can confirm if that access is still necessary, which creates a compliance gap. Assigning owners ensures that access is reviewed and stripped when the business requirement expires.

When should an organization move from manual audits to automated identity governance?

You should transition to automated governance as soon as you have established a reliable JML process. If your team spends more than 20% of their monthly time manually reconciling user lists or manually removing access for offboarded employees, manual auditing is no longer scalable or secure for your organization.