Access provisioning and review: the clause the question tests
How access is granted, reviewed on a cycle and removed when people move or leave.
How the customer usually asks it
example"How often are user access rights reviewed, and by whom?"
Anchor clauses
6 frameworks| Framework | Anchor clause |
|---|---|
| ISO/IEC 27001:2022 | 5.18 Access rights |
| SOC 2 (Trust Services Criteria) | CC6.2 Prior to granting access, registration and authorization processes are established |
| SIG (Shared Assessments) | domain H Access Control |
| NIST Cybersecurity Framework 2.0 | PR.AA-05 Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties |
| NIST SP 800-53 Rev 5 | AC-2 Account management |
| PCI DSS v4.0.1 | 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed |
Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.
Evidence expected
The access request and approval records, the last completed access review with its sign-off, and leaver records showing when access was removed.
The clauses, with what an assessor asks for
ISO 27001 5.18 Access rightsProvision, review, modify and remove access rights in line with the access control policy.
Where answers usually fall short: Reviews lack documented corrective actions; Access changes not tied to approved request workflow
Source: ISO/IEC 27001:2022
SOC 2 CC6.2 Prior to granting access, registration and authorization processes are establishedNamed, not quoted: the criteria text is not held in full here.
Where answers usually fall short: Access granted first and approved retrospectively, which reverses the order the criterion requires; Approval by the requester's peer or by the person implementing the change, so no independent authorisation exists
Source: SOC 2 (Trust Services Criteria)
SIG domain H Access ControlWhat it asks for, in one line (the standard's own text is not quoted here):
Implement formal access provisioning, periodic recertification, least privilege, separation of duties, and privileged access management across systems hosting in scope data.
Where answers usually fall short: Privileged accounts shared; User reviews completed without manager attestation
Source: SIG (Shared Assessments)
NIST CSF PR.AA-05 Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of dutiesAccess permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
Where answers usually fall short: Standing privileges still common; Access reviews rubber stamped
Source: NIST Cybersecurity Framework 2.0
SP 800-53 AC-2 Account managementRequires accounts to be managed across their full life cycle: permitted and prohibited account types defined, account managers assigned, membership prerequisites and approvals required, accounts created, modified, disabled and removed under documented criteria, usage monitored, and access reauthorized on a defined frequency.
Where answers usually fall short: Shared and service accounts sit outside the joiner mover leaver process entirely; Recertification is signed off in bulk without any account actually being removed
Source: NIST SP 800-53 Rev 5
PCI DSS 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewedWhat it asks for, in one line (the standard's own text is not quoted here):
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:; At least once every six months.; To ensure user accounts and access remain appropriate based on job function.
Where answers usually fall short: Consent capture mechanism does not record purpose, time, and version of notice shown; Withdrawal of consent not as easy as giving consent
Source: PCI DSS v4.0.1