User Access Review: Process, Frequency and Template

A user access review is a recorded check, by someone accountable, that each account and permission in a system still matches a current need. When access is no longer needed, the review ends with a removal that has been confirmed in the target system. A review that collects “approved” ticks but leaves unneeded access in place gives an auditor nothing to rely on.

This guide covers the process step by step, the review intervals that regulations and standards actually set, the ways reviews fail in audits, a checklist, and a free spreadsheet template you can use for your next campaign. Every interval below comes from a primary text checked on 21 October 2026, with the source linked beside it. Where a framework sets no number, we say so rather than inventing one.

Short answer on frequency: DORA’s technical standard requires access rights to be updated where changes are necessary and at least every 6 months for ICT systems supporting critical or important functions, and at least once a year for other ICT systems. PCI DSS v4.0.1 sets at least once every six months for user accounts in scope. Slovakia’s NBÚ Decree 227/2025 sets at least once a year for operators of essential services. NIST SP 800-53 and the NIS2 implementing regulation leave the interval to the organisation, and ISO/IEC 27001’s control text is not public, so we quote no number from it. Whatever the interval, a departure should change access when it happens; DORA’s technical standard requires withdrawal of access rights without undue delay when employment ends or access is no longer necessary.

What a user access review is

The review asks one question per line: should this account, held by this person or system, still have this entitlement? An entitlement is a single unit of access, such as a group membership, an application role or a database privilege. The reviewer answers keep, remove or modify, and gives a reason.

Three things make a review useful as evidence. The reviewer must be someone who can actually judge the business need, usually a line manager or the owner of the application or data. The population must be complete, so the list reflects what the system really grants, including access inherited through groups. And every removal decision must be carried out and checked, because a decision recorded in a spreadsheet does not change a single permission.

Review, certification and recertification

The terms overlap. “Access certification” and “recertification” are common names in identity governance products for the same activity, often run as a campaign: a defined scope, a set of reviewers and a deadline. midPoint, the open source platform easyIGA runs on, calls the feature access certification and implements it as certification campaigns with a remediation step. This guide uses “user access review” for the whole process and “campaign” for one run of it. The glossary defines the related terms.

Privileged and non-human accounts need their own population

Administrator rights, emergency (break-glass) accounts and service accounts carry different risks from an ordinary user’s group memberships. Several frameworks treat them separately. The NIS2 implementing regulation has a dedicated review requirement for privileged and system administration accounts, and PCI DSS separates application and system accounts into requirement 7.2.5.1 with a risk-based interval. Review these in their own campaign, with reviewers who understand what the rights allow.

A service account has no manager in the HR sense. It needs a named human owner, a stated purpose and, where available, last-use data. Asking a line manager whether svc_batch_07 is “still needed” rarely produces a reliable answer. Our page on orphaned accounts and non-human identities covers how ownership is established before a review.

Who does what

A review touches several roles. Writing them down before the first campaign means every line has an answer to the question an auditor will ask of it: who was responsible for this decision?

Two reviewers for the same line is a design choice. A manager may know the person’s job but not what a cryptic ERP role permits. An application owner knows the role but not whether the person changed teams last month. For sensitive systems, combining both views, or routing privileged rights to the application owner, gives a better decision.

DORA’s technical standard makes this explicit for financial entities: its account-management procedures must include “assignment of roles and responsibilities for granting, reviewing, and revoking access rights” (Delegated Regulation (EU) 2024/1774, Article 21(e)(i)).

The user access review process, step by step

The seven steps below follow one campaign from scope to stored record. Steps 5 and 6 happen outside the review file, which makes them the easiest to skip.

1. Define the scope

Name the systems in the campaign, the account types (employees, contractors, third-party staff, service accounts, privileged accounts) and the entitlement types (roles, groups, direct permissions). Record why any in-scope system was left out. A review that silently skips a system is hard to defend later.

Tie the scope to your obligations. A DORA-regulated entity needs to know which ICT systems support critical or important functions, because they have a shorter interval. DORA defines a critical or important function as one whose disruption “would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities”, among other conditions (Regulation (EU) 2022/2554, Article 3(22)). A PCI DSS entity reviews the accounts within its PCI DSS scope.

2. Extract access data you can trust

Pull the current accounts and entitlements from each system as of a fixed date, and keep the extract. Use effective access where possible: the permissions a person can actually exercise, including those inherited through nested groups or roles. A list of direct assignments alone misses access granted through groups and roles.

Correlate each account to a person or an owned service identity. Accounts that match nobody are a finding before the review even starts. Add the context that helps a decision: department, job title, account creation date, who granted the access and when, and last use. If a system cannot supply last use, leave the field empty and say so. A guessed value is worse than a known gap.

3. Assign reviewers and give them context

Route each line to the person who can judge it. Give the reviewer a plain-language description of each entitlement, not only its technical name. “FI_AP_POST” means little to a manager; “Can post supplier invoices in the finance system” is a decision they can make.

Set a deadline and decide in advance what happens when a reviewer does not respond. We recommend escalation to the reviewer’s own manager or to the control owner. Treating silence as approval turns the review into a formality, so if your policy ever allows it, write down why and for which low-risk population.

4. Record decisions with a justification

Each line ends with one of three decisions:

• Keep: the access still matches the person’s current work.
• Remove: the access is no longer needed.
• Modify: the need exists but the level is wrong, for example write access where read access would do.

Ask for a short justification on every keep decision for privileged or sensitive access, and on every exception. Record the reviewer’s identity and the decision date. If the reviewer delegates, record the delegate. An auditor testing the control will sample these fields.

5. Carry out removals and modifications

A remove decision changes nothing until someone acts on it. Raise a ticket or an automated change for each one, linked to the review line. DORA’s technical standard requires “withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary” (Article 21(e)(iii)). In our reading, a reviewer’s remove decision is the point at which the access is known to be no longer necessary, so the withdrawal should start from that date.

Set a target time for completing removals, shorter for privileged rights. Track open removals in the campaign, so the campaign cannot be closed while they are still outstanding without a recorded exception.

6. Verify the result in the target system

Check that each removal actually happened. Re-extract the access from the target system after the change, or use a reconciliation report, and compare it with the decisions. Record who verified it and when. A disabled directory account can still leave a local application account, an API token or an active session behind, so verification has to happen where the access lives. Our employee offboarding guide explains the places access survives a directory change.

Keep four states apart in your records: removal requested, attempted, failed and verified. A failed change counted as complete is a serious error in a review record, because it looks like a working control.

7. Store the record and report the result

Close the campaign with a summary: scope, extract date, number of lines, decisions by type, removals verified, removals still open, exceptions with owners and due dates, and reviewers who did not respond. Store the extract, the decision file and the verification evidence together.

Some rules set the retention period. Slovakia’s NBÚ Decree 227/2025 requires the review record to be kept at least from the end of the last audit to the end of the next audit or self-assessment (Annex 1, item 80). The NIS2 implementing regulation requires entities to “document the results of the review including the necessary changes of access rights” (Annex, point 11.2.3). Where no rule sets a period, keep records at least until the auditor who will test them has finished, and agree the period with your control owner.

How often to review access, according to the primary texts

Answers online often repeat review intervals without a source. The table lists only what each primary text says, as checked on 21 October 2026.

DORA’s technical standard sets six and twelve months, plus event-driven updates

Article 21(e)(iv) of the DORA technical standard requires “update of access rights where changes are necessary and at least once a year for all ICT systems, other than ICT systems supporting critical or important functions and at least every 6 months for ICT systems supporting critical or important functions”. The words “where changes are necessary” matter as much as the intervals. In our reading, a transfer or departure is such a change, so the update follows the event, and the periodic update catches what the event process missed. The standard itself names one event: withdrawal of access rights without undue delay upon termination of employment or when access is no longer necessary (point (e)(iii)).

These intervals apply to entities under Title II of the standard. Entities that qualify for the simplified ICT risk-management framework under Article 16(1) of DORA follow Article 33 instead, which requires periodic review and withdrawal but sets no interval. Confirm which regime applies before you build a calendar on the six-month figure. Our DORA access-control guide covers the surrounding requirements in more depth.

PCI DSS v4.0.1 sets six months for user accounts

Requirement 7.2.4 requires that “All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: At least once every six months”, that inappropriate access is addressed, and that management acknowledges that access remains appropriate. Requirement 7.2.5.1 covers application and system accounts at a frequency set by the entity’s targeted risk analysis. PCI SSC announced in June 2024 that v4.0 would be retired on 31 December 2024 and that v4.0.1 would then be the only active version of the standard.

A note on our source: the PCI DSS document is distributed through the PCI SSC document library after a licence acceptance, which we could not complete with our verification tools, so we did not read the v4.0.1 text itself. The wording above is quoted as reproduced on Microsoft’s PCI DSS requirement 7 page, a secondary source; Microsoft’s guidance series describes itself as based on PCI DSS v4.0, and PCI SSC states that v4.0.1 added no new or deleted requirements. Check the wording against your licensed copy of v4.0.1.

The NIS2 implementing regulation uses planned intervals

Commission Implementing Regulation (EU) 2024/2690 applies to a defined set of digital entities, including DNS service providers, cloud computing, data centre and managed service providers, online marketplaces and trust service providers. Point 11.2.3 of its Annex reads: “The relevant entities shall review access rights at planned intervals and shall modify them based on organisational changes.” Point 11.3.3 applies the same rule to privileged and system administration accounts. Both require the results to be documented.

ENISA’s technical implementation guidance (June 2025, version 1.0) gives this guidance for point 11.2.3: “Perform access control reviews of assets to verify that all privileges are authorised on a recurring schedule at least annually.” For point 11.5.4, which requires entities to regularly review identities and deactivate those no longer needed, the same ENISA document suggests that the review of active identities “can be done on a recurring schedule, as a minimum quarterly, or more frequently”, with annual review for micro-sized entities. Both figures are guidance, not a legal minimum, but they are a reasonable reference point when you set your own plan. For other NIS2 entities, the national transposition decides, as the Slovak example below shows.

NIST SP 800-53 leaves the frequency to you

NIST’s control catalogue leaves the interval as an organisation-defined parameter. AC-2 j. requires the organisation to “Review accounts for compliance with account management requirements [Assignment: organization-defined frequency]”. AC-6(7) requires review, at an organisation-defined frequency, of “the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges”, and reassignment or removal where necessary. In SP 800-53B, AC-6(7) is part of the moderate and high baselines. The catalogue is at Release 5.2.0, issued 27 August 2025. Programmes built on NIST, such as US federal authorisations, may fill in the parameter with a number; check the programme you are assessed against.

ISO/IEC 27001:2022 Annex A 5.18 and your own policy

ISO/IEC 27001:2022 (edition 3, published October 2022) is sold by ISO, and we do not quote its Annex A control text here. The public evidence for where access-rights review sits in Annex A is ENISA’s mapping table (version 1.2), which relates the NIS2 requirement on management of access rights (point 11.2) to ISO/IEC 27001:2022 A.5.3 and A.5.18, and the privileged-account requirement (point 11.3) to A.8.2 and A.8.18, while warning that the mapping “should not be interpreted as a measure of equivalency among different standards or frameworks”.

Our recommendation is to decide the interval in your own risk treatment, write it into your access-control policy with the reasoning, and keep evidence that each campaign followed it. An auditor can then test the campaign against your own documented rule. Read the control and ISO/IEC 27002:2022 guidance in your licensed copy.

SOX reviews follow audit practice, not a statutory interval

Section 404 of the Sarbanes-Oxley Act (15 U.S.C. § 7262) requires an issuer’s annual report to contain an internal control report that states management’s responsibility for internal control over financial reporting and that must “contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting”. The statute does not mention access reviews. In SOX programmes, user access reviews for financially significant systems are commonly designed and tested as IT general controls (ITGCs). The PCAOB’s auditing standard AS 2201 lists, among the factors that affect the risk associated with a control, “the degree to which the control relies on the effectiveness of other controls (e.g., the control environment or information technology general controls)” (paragraph .47); it sets no access review interval. The interval is a control-design decision that management makes and the external auditor tests.

Slovakia’s NBÚ Decree 227/2025 requires at least once a year

For Slovak operators of essential services, item 80 of Annex 1 to NBÚ Decree 227/2025, in force since 1 September 2025, requires a review “v pravidelných intervaloch, najmenej raz ročne” (at regular intervals, at least once a year). The review compares approved permissions with the actual state, includes detection and invalidation of unused accounts, and produces a record kept at least from the end of the last audit to the end of the next audit or self-assessment. Our guide to NBÚ Decree 227/2025 explains items 76 to 87 and how to run the annual review.

Germany’s MaRisk no longer sets review intervals

Some guides still cite BaFin’s MaRisk intervals: at least annual review for signing rights on payment accounts and material IT rights, at least every six months for particularly critical IT rights such as administrator access, and at least every three years for all others. Those intervals sat in an explanatory note to AT 4.3.1 in the 2024 version. The current version, Rundschreiben 06/2026 (BA) of 30 June 2026, no longer contains them. BaFin’s cover letter says the deletion of explanatory notes does not mean the supervisor would stop recognising solutions built on them. Do not present the old figures as a current MaRisk requirement. Institutions in DORA’s scope apply the intervals of the DORA technical standard above. For institutions outside DORA’s scope we found no review interval in the current MaRisk text; our recommendation is to set the interval by risk and document the reasoning.

Setting your own interval

Where your framework sets no number, or sets only a maximum, set the interval by risk and write the reasoning down:

The interval column is our recommendation, built from the rules above, not a legal requirement. Any of these populations also needs event-driven review: joiners, movers and leavers should change access when the event happens.

Why reviews fail

Each weakness below leaves a review record unable to answer an auditor’s sample questions. Each has a practical fix you can build into the next campaign.

Rubber-stamping. A reviewer approves every line in seconds because the list is long, the entitlement names are cryptic and nothing happens if they say yes. Signs in the data: 100 percent keep decisions, many lines decided in the same minute, and no justification text. Shorter lists, plain descriptions, highlighting what changed since the last review and requiring a reason for keeping privileged rights all reduce it.

Missing context. The reviewer sees a username and a group name and nothing else. Without the person’s current job, the meaning of the entitlement, who granted it and whether it is used, a careful reviewer has nothing to judge with. Add the context to the list, or the review becomes guesswork.

Incomplete population. The extract misses accounts in a local application, inherited permissions or a second directory. The review then certifies a list that is smaller than reality. Reconcile the extract against the system before sending it out.

No proof of revocation. The campaign records “remove” decisions, but nobody can show the access was removed. In some cases the access was removed and then reappeared because an automated process or a role assignment granted it again. Verification in the target system, and a check in the next campaign that removed access stayed removed, close this gap.

Wrong reviewer. A manager reviews a privileged database role they do not understand, or a departing manager’s team is never reassigned. Route technical and privileged rights to the owner of the system, and reassign reviews when reviewers change.

No record of exceptions. Someone keeps access that conflicts with policy, for a good reason that only exists in an email. Record the exception, its owner and its expiry date in the campaign.

User access review checklist

Use this list before, during and after each campaign.

Before the campaign

• Scope written down: systems, account types, entitlement types, exclusions with reasons
• Interval for each population set and traced to your rule or risk decision
• Access extracted from each system with an extract date, using effective access where possible
• Every account correlated to a person or an owned service identity; unmatched accounts listed as findings
• Entitlements described in plain language
• Reviewers assigned, with privileged rights routed to system owners
• Deadline, escalation route and non-response rule agreed

During the campaign

• Each line has a decision: keep, remove or modify
• Justification recorded for privileged and sensitive keep decisions and for every exception
• Reviewer identity and decision date recorded, including delegates
• Non-responses escalated, not auto-approved

After the campaign

• A ticket or change raised for every remove and modify decision
• Each removal verified in the target system, with who and when
• Failed or pending removals tracked to completion or a recorded exception
• Summary written: counts by decision, removals verified, open items, exceptions
• Extract, decisions and verification evidence stored together for the required retention period
• Next campaign date set; removed access checked again in the next run

The free user access review template

The user access review template (XLSX) is a single workbook with three sheets. It is free to use and does not require a sign-up. It uses standard functions (COUNTA, COUNTIF, COUNTIFS, SUMPRODUCT, IF, AND, MAX, LEN and TRIM) and drop-down data validation, and we tested its formulas in LibreOffice Calc.

• Instructions explains how to fill in the sheets, the meaning of each decision and the verification rule.
• Review has one row per account and entitlement, with drop-down lists for the decision and the verification fields.
• Summary counts decisions and verification status with formulas, so the totals update as reviewers work.

Columns in the Review sheet

What the Summary sheet counts

The Summary sheet counts the lines in the review, each type of decision, lines still without a decision and the share decided. It then counts the removals and modifications that need a change, how many are verified in the target system and how many are marked No. Two quality checks count keep decisions without a justification and decisions without a date. A status cell shows Complete only when every line is decided and every change is verified. In the Review sheet, a remove or modify line that is not yet verified is shaded orange and a keep decision without a reason is shaded yellow.

A spreadsheet works for a first campaign or a small scope. Protect the file, keep the original extract beside it, and store a dated copy when the campaign closes, because a shared spreadsheet keeps no reliable history of who changed a decision.

When a spreadsheet stops being enough

Spreadsheets break down in predictable places: many systems and reviewers, extracts that age while the campaign runs, manual copying of decisions into tickets, and no link between a decision and the change that followed. An identity governance and administration (IGA) system connects to the source systems, generates the review from current data, records decisions with the reviewer’s identity, and can drive or track the removal. That reduces copying. Your team still decides the scope and the reviewers, and still checks that removals reached the target systems.

When you evaluate a tool, test the parts that fail in audits: can it show where each permission came from, does it keep a missing value visibly missing, and does it separate a recorded removal decision from a confirmed change in the target system?

Where easyIGA fits

easyIGA is identity governance software built on midPoint. For access reviews, it brings the person, the permission and the available history together, so the reviewer has a basis for the decision. Last use, grant details and captured approvals appear where the connected sources supply them, and missing information is marked clearly.

easyIGA records the requester and captured approval steps for requests made through the product. Access granted outside easyIGA is identified separately, using the creation details recorded by midPoint. Keeping and removing access are recorded decisions, and a pending or failed change remains separate from a verified removal. Review evidence exports include the available request and approval history. For access requests, the approver sees conflicts from configured midPoint exclusion policies at decision time (separation of duties). Rule authoring and simulation inside easyIGA are planned and not yet available.

You choose review populations and frequency from your risks and obligations, as described above. The access reviews page describes the workflow, and the audit evidence page explains which records support a decision and what they cannot prove on their own.

Frequently asked questions

How often should user access reviews be performed?

It depends on the rule you are under. DORA’s technical standard requires access rights to be updated where changes are necessary and at least every 6 months for ICT systems supporting critical or important functions, and at least once a year for other ICT systems. PCI DSS v4.0.1 requirement 7.2.4 sets at least once every six months for user accounts. NBÚ Decree 227/2025 sets at least once a year for Slovak operators of essential services. NIST SP 800-53 and the NIS2 implementing regulation leave the interval to you. For ISO/IEC 27001, our recommendation is to set and document the interval in your own policy. Our recommendation for privileged access is to review it at least as often as your strictest applicable rule.

Is a quarterly access review required?

None of the primary texts checked for this guide sets a quarterly interval. The closest figure is non-binding: ENISA’s technical implementation guidance for point 11.5.4 of the NIS2 implementing regulation (review of identities) suggests a recurring schedule “as a minimum quarterly, or more frequently”, with annual review for micro-sized entities. An organisation may still choose quarterly reviews for high-risk populations, or agree them with its auditor. Write down why you chose the interval.

What is the difference between a user access review and an access certification?

In practice they describe the same check. “Certification” and “recertification” are terms used in IGA products for a review campaign. midPoint calls the feature access certification.

Who should review user access?

The person who can judge the business need: usually the line manager for job fit, and the application or data owner for what a technical or privileged entitlement allows. The control owner defines the process and signs off the result.

What evidence does an auditor expect from an access review?

Plan to show the scope and extract date, the list reviewed, each decision with reviewer and date, justifications for kept privileged access and exceptions, the tickets for removals, and proof that removals were completed in the target system. Some rules add retention requirements, such as NBÚ item 80.

Does a review replace leaver and mover processes?

No. A review catches what the event processes missed. DORA’s technical standard requires withdrawal of access rights without undue delay when employment ends or access is no longer necessary, and separately requires the periodic update described above; in our reading the two obligations run independently of each other.

Can I use the template for ISO 27001 or SOC 2 evidence?

The template records the fields this guide recommends keeping: reviewer, decision, justification, dates, revocation ticket and verification. Whether it is sufficient depends on your control design and your auditor. It does not establish compliance by itself.

Sources and verification record

All sources, URLs and the image licence were checked on 21 October 2026, and the legal and standards claims were re-checked against the primary texts in a separate review pass on the same date. EUR-Lex, iso.org, pcaobus.org and unsplash.com block plain automated status checks; their pages were read through a page-fetching tool on that date.

1. European Commission, Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 (DORA RTS on ICT risk management), Official Journal of 25 June 2024, Articles 21 and 33
2. European Parliament and Council, Regulation (EU) 2022/2554 (DORA), Article 3(22)
3. European Commission, Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Annex points 11.2.3 and 11.3.3
4. ENISA, Technical implementation guidance on Implementing Regulation (EU) 2024/2690, version 1.0, published 26 June 2025 (guidance under points 11.2.3 and 11.5.4), and mapping table version 1.2, 21 August 2025
5. PCI Security Standards Council, Document Library (PCI DSS v4.0.1, licence acceptance required; text not read for this article), and Just Published: PCI DSS v4.0.1, 11 June 2024
6. Microsoft, Microsoft Entra ID and PCI-DSS Requirement 7, updated 23 August 2024 (secondary source of the quoted requirement wording; Microsoft’s series states it is based on PCI DSS v4.0)
7. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0, 27 August 2025, controls AC-2 and AC-6(7)
8. ISO, ISO/IEC 27001:2022, edition 3, October 2022
9. Legal Information Institute, 15 U.S. Code § 7262, Management assessment of internal controls
10. PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting
11. National Security Authority of the Slovak Republic (NBÚ), Decree No. 227/2025 Coll. on security measures, Slov-Lex, effective 1 September 2025, and Annex 1 (PDF)
12. BaFin, Rundschreiben 06/2026 (BA), MaRisk, 30 June 2026, its cover letter and the comparison version
13. Evolveum, midPoint access certification (configuration reference for midPoint 4.10; the unversioned address docs.evolveum.com/midpoint/reference/roles-policies/certification/ redirects here)
14. Photo by Jakub Żerdzicki, Unsplash, free to use under the Unsplash License

This article is practical guidance and a reading of the cited texts. It is not legal advice. Confirm which rules apply to your organisation, and the intervals your supervisor or auditor expects, with qualified legal and compliance advisers.