The most expensive recurring compliance ritual at regulated organisations, after SOX testing itself, is the quarterly access review. A 1,000-person organisation with two hundred cloud platform applications spends roughly 149 person-days per cycle reconstructing entitlement state, distributing spreadsheets to managers, chasing approvals, opening service-desk tickets, and assembling the audit binder. The work happens on a calendar deadline, the artefacts come out late, and the deepest finding from every audit cycle is the same one: a row in the spreadsheet that says "approve" without evidence the reviewer actually looked at it.

This is the operational ritual every major framework now mandates. SOC 2 CC6.3 expects four quarterly cycles inside a Type II window. ISO 27001 A.5.18 requires access rights reviewed at planned intervals. PCI DSS 4.0.1 Requirement 7.2.4 mandates a six-monthly review at minimum and Requirement 8.6 (mandatory since 31 March 2025) extends the same governance to service accounts. NIST 800-53 AC-2 requires accounts reviewed at organisation-defined frequency. HIPAA's December 2024 NPRM explicitly requires annual workforce-access review and removes the addressable carve-out. NIS2's Implementing Regulation 2024/2690 mandates documented review cadence on the identity-and-access management annexes. SOX ITGC examinations under the tightened PCAOB AS 1105 expect independent corroboration of the review, not just the manager's signed PDF. FINMA Circular 2023/1, ADHICS V2's quarterly self-assessment, and SAMA's Domain 3.3.5 all add the same expectation in their own vocabulary.

The frameworks have converged. The pain has not gone away. This article walks through why quarterly access reviews are universally painful (the pain is architectural, not procedural), what each major framework actually requires by cadence, the stale-entitlement failure modes that drove the largest 2024 breaches, and what an architecture that treats access events as first-class evidence does differently.

Why quarterly access reviews are universally painful

The workflow at a tier-1 bank or a hospital network looks roughly identical across organisations. The governance, risk, and compliance team announces the quarter's review window thirty days out. The IAM operations team pulls user lists from each in-scope system: ERP, HRIS, EHR, core banking, ServiceNow, Active Directory groups, AWS IAM, Azure RBAC, the data warehouse, payment gateways, the dozen cloud platforms with admin access. Each extract is a different format. Someone normalises the extracts into spreadsheets keyed by role owner. The spreadsheets go out to a few hundred to a few thousand line managers and application owners. Reminders, escalations, and executive chasers follow. Typical completion rate at the deadline is between sixty and seventy-five percent.

When the spreadsheets come back, most managers have ticked "approve all" because reviewing a forty-seven-row list of cryptic Active Directory group names would take ninety minutes per reviewer they do not have. The exceptions get logged in another spreadsheet. The revocations get raised as service-desk tickets. The tickets take five to fifteen business days to action. The GRC team stitches everything into a quarterly review pack for the audit binder.

The pain is not the volume. The pain is that none of the underlying work produces operational value. Reviewers attest to a state that nobody knows is current. The auditor reads the PDF and asks why the user count in the cover page differs from the user count in the system-of-record extract by twelve. The compliance team explains that the extract was pulled four days before the review window opened. The auditor records a deviation. The cycle repeats next quarter, with the same workflow, producing the same artefact, with the same finding.

The architectural reason for the pain is that access state changes (grants, revocations, role changes, joiner-mover-leaver events) are not recorded as first-class evidence events at the moment they happen. So the quarterly review becomes a reconstruction project. The reviewer reads a snapshot of the current state, with no record of what the state was, when it changed, who changed it, or why. The PCAOB AS 1105 update of December 2024 sharpened this exact criticism: external auditors now want the system-of-record events, not the spreadsheet, because the spreadsheet can be reconstructed after the fact.

What the major frameworks now require

The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.

SOC 2 (United States, AICPA). Common Criteria CC6.1 establishes least-privilege logical access; CC6.2 covers user provisioning and authorisation before access; CC6.3 mandates authorisation, modification, or removal of access based on roles, responsibilities, and changes. Periodic review is the explicit point of focus in CC6.3. The 2022 revised points of focus tightened service-account and system-account language in CC6.1 and CC6.6, and added explicit points of focus for reviewing roles and access rules, not just user-to-role mappings. Auditors looking at a Type II expect at least three or four completed review cycles inside a twelve-month observation window, spaced roughly ninety days apart. The most common adverse finding is rubber-stamp recertification: a manager approves a forty-seven-row list without challenge, the auditor pulls one user from the list, asks the manager what that user actually does, and the manager cannot answer.

ISO 27001:2022 (international). Annex A.5.18 requires access rights reviewed at planned intervals. A.5.15 covers access control policy; A.5.16 identity management; A.5.17 authentication information lifecycle; A.5.19 supplier access. A.8.2 covers privileged access rights as a separate control after the 2022 restructure. The 2022 standard removed the explicit clause that privileged access must be reviewed more frequently than standard, but every certification body still expects that pattern: quarterly for privileged, semi-annual or annual for standard, with re-review on every employment-change event. Surveillance auditors increasingly flag A.5.19 supplier-access review as the most commonly missed area.

PCI DSS 4.0.1 (international, payments). Requirement 7.2.4 explicitly requires all user accounts and related access privileges, including third-party and vendor accounts, to be reviewed at least once every six months, with management acknowledgement that the access remains appropriate. Requirement 7.2.5 requires application and system accounts to be assigned and managed based on least privilege. Requirement 7.2.5.1 requires application and system accounts reviewed at a frequency defined by a Targeted Risk Analysis. Requirement 8.2.6 mandates inactive user accounts be removed or disabled within ninety days of inactivity. Requirement 8.2.7 governs third-party remote access. Requirement 8.6, mandatory from 31 March 2025, treats non-human accounts as first-class identity objects with restrictions on interactive use, password rotation, and secrets management. The transition of 8.6 from "best practice" to "required" is the first time a major framework explicitly extended the access-review obligation to service accounts at the same rigour as human accounts.

NIST SP 800-53 Rev 5 (United States, federal). AC-2 Account Management requires accounts reviewed for compliance at organisation-defined frequency. AC-2(3) requires disabling accounts within a defined time period when expired, no longer associated with a user, in violation of policy, or inactive. AC-2(4) automates notification and logging of account creation, modification, enabling, disabling, removal. AC-2(7) covers privileged user accounts with role- or attribute-based provisioning, monitoring of role assignments and changes, and revocation when no longer appropriate. AC-2(13) requires disabling accounts of high-risk individuals within a defined time period of discovery. AC-6 Least Privilege and AC-6(7) Review of User Privileges complete the set. FedRAMP Moderate baseline requires AC-2 with enhancements (1), (2), (3), (4), (5), and (13); AC-2(7) is required for High baseline and increasingly required for Moderate via agency overlays.

HIPAA Security Rule (United States, healthcare). Section 164.308(a)(3) workforce security; 164.308(a)(4) information access management; 164.308(a)(5) security awareness and training; 164.312(a)(1) access control technical safeguard. The December 2024 NPRM removed the addressable carve-out, mandated notification within twenty-four hours when a workforce member's access to electronic protected health information is changed or terminated, required annual review of technology asset inventory and network map, and made annual workforce-access review explicit. Common OCR findings under the current rule already include access of departed clinicians remaining active in the electronic health record, emergency break-glass access used but not reviewed retroactively, and no documented workforce-access review.

NIS2 directive (European Union). Article 21(2)(i) cryptography sits alongside the broader access-control and asset-management measures across Article 21(2)(d), (g), (i), (j). Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 contains the binding annexes on identity management and access management. Annex requirements include policies and procedures for access control covering managing access rights, authentication and authorisation mechanisms, controlling privileged accounts, segregating administration systems, ensuring unique user identities, and applying multi-factor authentication. Entities must set, document, and monitor the frequency of access reviews proportional to risk. Early 2025 supervisor findings include entities with an access-control policy but no documented review cadence, and no evidence of privileged-account governance separate from standard access.

GDPR (European Union). Article 5(1)(c) data minimisation requires processing to be adequate, relevant, and limited to what is necessary. Article 32(1)(b) requires the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems. Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures. Article 32(4) requires controllers and processors to ensure that any person acting under their authority processes personal data only on instructions. EDPB guidance and national supervisory authority enforcement read Article 32 and Article 5(1)(c) together as requiring documented periodic access reviews limiting workforce access to what is strictly necessary. The CNIL and Garante have fined organisations under Article 32 specifically for broad-than-necessary workforce access with no evidence of periodic review.

SOX (United States, public-company financial controls). Section 404 of the Sarbanes-Oxley Act and PCAOB Auditing Standard AS 2201 govern IT general controls over financially relevant systems. Quarterly access certification is the de-facto standard for SOX-relevant applications: ERP, financial consolidation, treasury, key revenue systems. PCAOB AS 1105, effective for fiscal years ending on or after 15 December 2024, raised the bar on sufficiency and appropriateness of audit evidence; external auditors now demand stronger walkthroughs, independent corroboration, and additional evidence over entity-produced information. A 2024 PCAOB inspection cycle flagged roughly thirty-nine percent of audits for evidence or control deficiencies. Common deficiencies cited: access reviews exist on paper but managers rubber-stamp them; incomplete user population (system extract missed a subset); terminated users still active at quarter end; segregation-of-duties conflict observed but not remediated; evidence reconstructed after the auditor asked for it.

FINMA Circular 2023/1 (Switzerland). The circular requires selection, training, monitoring, and regular review of privileged access, plus implementation of a role- and function-specific authorisation system. Authentication options must include multi-factor authentication and single sign-on, designed for least privilege. Privileged users and service providers are explicitly called out as needing strict controls. Common finding: privileged-access review evidence absent for outsourced operations; role design exists but actual role assignments not periodically validated.

ADHICS V2 (United Arab Emirates). Access-control specifics include mandatory multi-factor authentication for all access to systems holding patient data, procedures for access control and authorisation, role-based privileges, and protected-health-information lifecycle management with consent. ADHICS audits are annual via the AAMEN platform; quarterly internal self-assessments are the practice expectation. Common finding: multi-factor authentication in place for clinicians but not for service accounts integrating the electronic health record with insurance and laboratory systems; quarterly self-assessment submitted without evidence of the IAM state review behind it.

SAMA Cyber Security Framework (Saudi Arabia). Domain 3.3.5 Identity and Access Management requires access on need-to-have / need-to-know basis; documented IAM policy covering onboarding, role changes, and offboarding; detailed audit trails of all access requests, approvals, changes, and revocations; multi-factor authentication for sensitive systems, remote access, and privileged accounts. Sub-control 3.3.5.3 governs privileged-account access. The framework explicitly requires the effectiveness of IAM controls to be measured and periodically evaluated. Common finding: privileged-access management tool deployed but session recordings not reviewed at expected cadence; privileged-account inventory missing service accounts; access review covers human users only.

Eleven framework references, six jurisdictions. The access-review obligation has shipped to every regulated buyer's procurement question.

The stale-entitlements problem

The pain at audit time is the surface. The real failure mode underneath is stale entitlements: the entitlements an organisation knows it has, plus the ones it does not.

Orphaned accounts. Account exists, owner has left, account never disabled. The classic SOX and ISO finding. The leaver path is automated for the primary identity provider but routinely fails for long-lived API keys the leaver created, SSH keys on bastion hosts, personal access tokens in continuous integration, contractor accounts in side systems.

Dormant accounts. Account exists, owner is present, but the account has not been used in ninety or more days. PCI DSS 8.2.6 addresses this explicitly. Most organisations track the threshold but disable accounts at one hundred and ten or one hundred and eighty days because the scripts run monthly with no cushion.

Lateral-movement accounts. The account is dormant for the human owner but still trusted for service-to-service calls. Discovered only at incident-response time.

Service accounts with broad privileges. Created during an integration project, scoped permissively to "make it work", never reviewed.

Mover residue. A user changes role but the old access never gets revoked. Privilege creep, in the standard industry term. The compliance answer is "trigger a re-review at every mover event", but most identity-governance platforms treat movers additively: the new role gets provisioned, the old one stays.

Each pattern is documented as a recurring audit finding. None of them gets solved by harder spreadsheets. They get solved by changing how the underlying access state is recorded.

Real incidents where stale access was the controlling factor

The 2024 breach cycle produced two cases that map directly onto the failure modes above.

The Microsoft Midnight Blizzard disclosure of January 2024 was an orphaned-account case. The Russian state actor used a password-spray attack against a legacy non-production test tenant account that did not have multi-factor authentication enabled. Unauthorised access began in November 2023 and was undetected until 12 January 2024. From the test tenant the actor pivoted to a legacy OAuth application with elevated access into the corporate environment, eventually accessing senior leadership, cybersecurity, and legal mailboxes. The controlling failure was an inactive, unreviewed legacy account that should not have existed at all and certainly should not have had a usable trust path into production. The companion article on MFA for admin access covers the authentication side; the access-review side is that no quarterly review caught the orphan because the test tenant was outside the standard population scope.

The Snowflake-customer compromises of mid-2024 were a dormant-credential case. Approximately one hundred and sixty-five organisations were affected, including AT&T, Ticketmaster, Santander, LendingTree, Advance Auto Parts, Neiman Marcus, and Bausch Health. The attacker group ShinyHunters used credentials harvested from infostealer infections dating back to 2020. The compromised accounts lacked multi-factor authentication and many were stale credentials still valid years after the underlying infostealer infection. Snowflake responded by releasing tools to identify stale users that no longer require access and made multi-factor authentication default for new accounts. Both of those are corrective controls; the structural failure was that the access state was never reviewed at a cadence that would have flagged the staleness.

Verizon's Data Breach Investigations Report 2025 records compromised credentials as the initial-access vector in twenty-two percent of all breaches and at some stage of thirty-two percent. CrowdStrike's 2024 Global Threat Report records a sixty percent rise in hands-on-keyboard interactive intrusions, a twenty percent jump in access-broker advertisements selling valid credentials, and a seventy-five percent rise in cloud intrusions year on year. Identity is the new perimeter, and stale identity is the soft entry point.

The questions that distinguish a real review from a rubber stamp

A short, uncomfortable checklist for any team running quarterly access reviews in 2026.

  1. Can the reviewer see what changed since the last review, not just the current state? Reviewing a list of forty-seven entitlements is rubber-stamp work. Reviewing the three entitlements granted to that user since last quarter, with the requester, the justification, and the approver each named, is real work.
  2. Are service accounts in scope? PCI DSS 8.6 made this explicit in March 2025; every other framework now treats non-human identity at parity with human identity. Reviews that cover human users only fail under the current rubric.
  3. Does the review evidence trace back to immutable system-of-record events, or to a manager-attested PDF? PCAOB AS 1105 (effective December 2024) requires independent corroboration of entity-produced information. The PDF is no longer sufficient evidence on its own.
  4. Are mover transitions handled as re-reviews rather than additive provisioning? If the answer is no, privilege creep is accumulating between reviews regardless of how diligent the reviewers are.
  5. Is the access-state event stream itself reviewable end-to-end? The companion article on tamper-proof audit trails covers the integrity layer. If the system can be queried for "every access change to record X since last quarter", the review becomes a confirmation of an already-current record rather than a reconstruction.

A platform that answers each of these with an artefact rather than a paragraph is producing access-review evidence as a continuous output. A platform that produces "the quarterly review PDF" is producing a 2010 artefact for a 2026 framework expectation.

The architectural answer

Quarterly access reviews stay painful as long as the underlying access events are not first-class evidence. The architectural answer makes them first-class: every grant, every revocation, every role change, every joiner-mover-leaver event emits a hash-chained audit record at the moment it happens, with the actor, the justification, the approver, the expiry, and the system-of-record reference all captured at creation time.

Novantra's access-event substrate sits on top of the continuous evidence stream covered in the companion article. The quarterly review surface reads the same event store the platform uses to enforce the access decision; there is no separate "review database" to keep in sync. When the auditor asks for every access change to record X over the last twelve months, the answer is a query, not a project.

Novantra's mover transitions trigger a focused re-review of the user's full entitlement set rather than additive provisioning. The HR system event flows through SCIM to the identity provider, which propagates to downstream applications and surfaces the delta to the role owner as a single attestation request. The companion article on the operating audit-ready rhythm covers why this matters at the cadence level: mover events that get re-reviewed within a day stop privilege creep from accumulating between quarterly cycles.

Novantra's service-account governance treats non-human identities at parity with human ones. Every workload identity has a named human owner, a scoped permission set, a logged usage stream, and an expiry. Short-lived workload identities (AWS IAM Roles Anywhere, GCP Workload Identity Federation, Azure Workload Identity, SPIFFE/SPIRE) replace long-lived API keys. PCI DSS 8.6 becomes a configuration fact rather than a compliance project.

Novantra's review attestation surface presents deltas, not state. Reviewers see what changed since the last cycle, with the requester, justification, approver, and timing all linked from the audit stream. The forty-seven-row spreadsheet becomes a three-event attestation, completed in minutes instead of ninety. The completion rate at deadline goes from sixty percent to ninety-plus percent because the work matches the time managers actually have.

Novantra's exception register captures every "approve with exception" decision as a first-class operational object with a justification, a compensating control, and a documented next-review date. Auditors reading the exception register see the organisation managing its own deviations, not discovering them under fieldwork.

For customers whose threat model or jurisdiction requires it, Novantra's Sovereign deployment runs the entire access-review stack inside the customer's own infrastructure, with the same architectural commitments.

None of this is a feature. Each is the architectural answer to a question every major framework is now asking in access-review language: not whether the review was done, but whether the evidence behind it is a continuous output of the system that grants and revokes the access in the first place. A platform built so that the access change and the audit event are the same write makes "quarterly recertification" a confirmation step rather than a reconstruction project. The frameworks have moved. The 149 person-days per quarter has not. The architecture decides which side wins.