NIS2 readiness: make access changes and their evidence traceable

01

Start with an access question you can answer

NIS2 Article 21 includes human resources security, access-control policies and asset management among cybersecurity risk-management measures. Applicability and national implementation require their own assessment. The workflow described here is an engineering way to organize access decisions and evidence, rather than a declaration that one tool establishes compliance.

02

Build an inventory that connects people to systems

List the systems in the first scope and identify their business owners. Include ordinary accounts, administrative accounts, shared operational identities and external-provider access. A directory export is a useful input, but it may omit accounts held directly in applications or maintained by a supplier.

For each access relationship, record the person or accountable owner, system, role, reason and approval reference. Service accounts need an operational owner even though they do not correspond to an employee. Temporary supplier access should identify the engagement it supports. This helps reviewers ask whether the permission still serves a current need.

03

Define joiner, mover and leaver events

A new starter needs a documented request and the right approval before access is provisioned. A role change needs review of existing permissions as well as requests for new ones. A departure needs an explicit list of systems and owners responsible for removal.

The event source matters. HR may own employment status, while a purchasing or project owner knows when a contractor's engagement ends. Agree how those signals enter the workflow and who corrects an inaccurate event. Do not let a mistaken source update silently remove critical operational access without the agreed handling procedure.

04

Record execution separately from approval

An approved removal request proves a decision was made. It does not prove that the account was disabled in every destination. Store the outcome from the supported interface or the confirmation from the responsible operator, together with the system and time.

Some destinations may support automation; others may require an authorized manual step. Both can fit one evidence view if their completion criteria are explicit. Keep failed actions visible and assigned. A central checklist should not turn green merely because it sent an email to a system owner.

05

Design for exceptions that carry real responsibility

A departing engineer may own an unattended integration. Disabling the personal account can break the integration while leaving a separate token active. Identify those dependencies and assign a successor before the approved transition. Preserve the reason for any temporary exception and the person who accepted it.

Emergency access needs its own handling. Record why it was granted, who approved it and how its use will be reviewed. An exception without an owner or review point easily becomes a permanent permission. The application should make overdue review visible without assuming that every exception can be removed safely by an automated job.

06

Keep the evidence useful without exposing secrets

The access register should identify permissions and decisions, not store passwords, private keys or recovery codes. Link to controlled systems of record for sensitive configuration. Restrict who can view the full inventory, because it can reveal privileged accounts and operational dependencies.

Personnel data also needs appropriate handling. Record only what is needed to establish responsibility and the event. A security reviewer may need the employment-status change without the confidential reason for departure. Define export access, retention and support procedures with the people responsible for security and data protection.

07

Test the lifecycle through real destinations

Choose a small set of systems and rehearse a starter, a department move, an external engagement ending and a failed removal. Include one system outside the central identity provider. Verify the destination state using the agreed method, not only the task status in the new workflow.

Measure accounts without accountable owners, approved changes lacking execution evidence and access surviving after its agreed removal point. Record which findings require process changes rather than code. Repeating the exercise after remediation should demonstrate whether the identified gaps were actually addressed.

08

Make evidence review a recurring operational task

Assign a person to review unresolved lifecycle events and another appropriate owner for each system. The review should identify stale requests, disconnected integrations and exceptions needing a decision. Provide a direct route from the summary to the underlying evidence.

When an application is added or a supplier changes, update the inventory and test its lifecycle handling. A process that worked for last year's systems can become incomplete without any software failure. Treat coverage as a maintained operational property and make changes in coverage visible to the team.

• Select one departing employee and verify account state in every system in scope, including an application outside the central identity provider.
• Identify any service account or unattended integration they owned and confirm an accountable successor without exposing credentials in the evidence register.
• Inspect an access exception and verify its reason, approving person and review point, together with the latest recorded decision.
• Check that the lifecycle report distinguishes approved removal from executed removal and shows failed destination actions with an owner.

09

Scope the implementation around a known gap

RDC can build an access inventory, HR or engagement-event handoffs, approval tasks and destination evidence collection. A focused proposal starts with the systems where joiner, mover or leaver work is currently hardest to verify.

Bring the existing access procedure, a system list and redacted examples of unresolved changes. We can map supported integrations, manual responsibilities and acceptance tests. Your legal and security advisers determine applicable obligations; our engineering work makes the chosen controls easier to operate, investigate and demonstrate.