Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which IAM artifacts prove access control works?
Updated
Access control is evidenced across a lifecycle: an approval before provisioning, a record of the grant, a periodic review with a named reviewer, and a removal record on departure. Enforcement configuration supports each stage.
IAM evidence map, last verified 10 September 2026 against the AICPA Trust Services Criteria CC6 (logical and physical access), ISO/IEC 27001:2022 Annex A 5.15 to 5.18 and 8.2, NIST SP 800-53 Rev. 5 AC family, and PCI DSS v4.0.1 Requirements 7 and 8. Only one of those names a review cadence: PCI DSS v4.0.1 Requirement 7.2.4 asks in-scope entities to review user accounts and access privileges at least once every six months. The others require review without specifying a frequency, so a quarterly or annual cadence is your defensible choice rather than a mandate. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a security engineer, IT operations lead, or compliance owner who needs access control to be provable rather than merely believed. Access is the category auditors and enterprise customers test first, and the one where evidence gaps are most visible.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Last verified 10 September 2026.
The mental model that makes IAM evidence tractable: every access has a beginning, a middle, and an end, and each of the three needs its own artifact. Teams usually have the middle — a current list of who has access — and are missing the beginning, the approval that justified it, and the end, the removal record with a date you can compare against a leaving date. A current list on its own cannot evidence a period.
- Population before sample. The population for access evidence is every system in scope and every account in it, including service accounts, contractor accounts, and accounts in systems the security team does not administer.
- Reconciliation is the strongest access artifact you can produce cheaply: the leaver list from your HR system compared against the removal records from each in-scope system, with the gap explained.
- Service and machine identities count. They are usually the most over-privileged and the least reviewed, and an auditor who asks about them and gets a blank look will widen the sample.
- Enforcement evidence and activity evidence are different. A policy requiring multi-factor authentication is enforcement; a report showing every account has a registered factor is activity. Bring both.
Access-lifecycle-to-evidence map
Read the first column as the lifecycle stage, the second as the artifact, the third as the control assertion, and the fourth as the common failure that makes the artifact unusable. Last verified 10 September 2026. Not legal advice.
| Lifecycle stage | Evidence artifact | Control assertion it supports | Common failure |
|---|---|---|---|
| Request and approval (joiner) | The access request with the requested role, the approver's identity, and the approval timestamp — from a ticket, a workflow tool, or an identity-governance request | Access is granted only on documented authorisation. AICPA TSC CC6.1–CC6.2; ISO/IEC 27001:2022 Annex A 5.16 and 5.18; PCI DSS v4.0.1 Requirement 7.2.1 where in scope. | The grant exists but no approval does, because the account was created directly in the target system. The grant then evidences the opposite of the control. |
| Provisioning | The identity-provider or target-system record showing the account creation, the assigned role, and the time; provisioning logs where SCIM or an HR-driven connector is used | Access provisioned matches access approved. AICPA TSC CC6.1; Annex A 5.16. | Roles granted are broader than those approved, with no record of who widened them. |
| Role change (mover) | The record of the role change, the new approval, and evidence that the prior access was removed rather than accumulated | Access reflects current responsibilities. AICPA TSC CC6.2–CC6.3; Annex A 5.18. | Additive-only role history: people accumulate access across roles and nobody can show what should have been removed. |
| Authentication enforcement | The policy requiring multi-factor or phishing-resistant authentication, its enforcement scope, and a report showing registration or usage across all in-scope accounts | Only the intended person can use the account. AICPA TSC CC6.1; Annex A 5.17; PCI DSS v4.0.1 Requirement 8 where in scope. | A policy exists in report-only or pilot scope while the control description says enforced. |
| Privileged access | The list of privileged accounts and roles per system, the justification per holder, time-bound elevation records where used, and the log of privileged actions | Elevated access is limited, justified, and observable. AICPA TSC CC6.1 and CC6.3; Annex A 8.2 privileged access rights; NIST SP 800-53 Rev. 5 AC-2(7) and AC-6. | No definition of what counts as privileged, so the list cannot be complete and nothing reconciles. |
| Least privilege verification | Evidence of unused-permission analysis or role right-sizing, and the record of action taken — reduced, retained with justification, or scheduled | Access is the minimum necessary. AICPA TSC CC6.3; Annex A 8.2; NIST SP 800-53 Rev. 5 AC-6. | Analysis is produced and never acted on, which evidences that you knew about excess access and left it. |
| Periodic access review | The review artifact: scope, population, reviewer name, decision per account, exceptions, and completion date — plus proof that revocations were executed | Access remains appropriate over time. AICPA TSC CC6.2–CC6.3; Annex A 5.18; PCI DSS v4.0.1 Requirement 7.2.4 at least every six months where in scope. | A review with decisions but no evidence that the removals actually happened. The review then evidences an intention. |
| Deprovisioning (leaver) | The removal record per system with a timestamp, reconciled against the termination date from the HR system, and the exception record where removal was delayed | Access is removed promptly on departure. AICPA TSC CC6.2; Annex A 5.18; PCI DSS v4.0.1 Requirement 8.2.5 where in scope. | Removal from the identity provider only, leaving local accounts, personal access tokens, and cloud keys alive. |
| Service and machine identities | The inventory of service accounts, tokens, and keys with owner, purpose, and age; evidence that long-lived credentials are restricted or absent; rotation records | Non-human access is inventoried and controlled. Annex A 5.16 and 5.17; NIST SP 800-53 Rev. 5 IA-5 and AC-2. | No inventory at all, or an inventory that omits credentials created in cloud consoles and CI systems. |
| Third-party and contractor access | The list of external accounts with sponsor, expiry, and scope; the contract or data-processing terms; and the removal record at engagement end | External access is authorised, scoped, and time-bound. AICPA TSC CC6.1 and CC9.2; Annex A 5.19–5.22. | External accounts with no expiry date and no internal sponsor, discovered during the audit. |
| Access to the evidence itself | Permissions on the evidence repository and on log archives, showing that the people whose actions are logged cannot alter the records | Records are protected from the parties they describe. AICPA TSC CC7.2; Annex A 8.15. | Administrators of the logged system also administer the log store, so no record is independent. |
A sample access-review artifact
This is the shape of a review record that survives an auditor's questions. It states its scope and population, names the reviewer, records a decision per row, and — crucially — records the removal evidence, not just the decision to remove. The table below is a worked example with illustrative rows; it is a format to copy, not real data about anyone. Last verified 10 September 2026. Not legal advice.
| Field or row | Example content | Why an auditor looks for it |
|---|---|---|
| Header — scope | Systems in scope: production cloud accounts (4), source-control organisation, identity provider, customer support tool. Systems excluded: internal wiki (no customer data) — exclusion reason recorded. | Establishes the population boundary, and shows exclusions were decided rather than forgotten. |
| Header — population and source | Population: 148 human accounts and 26 service accounts, exported from the identity provider and each cloud account on 1 July 2026 by the named exporter. | Shows completeness and that the list came from the system of record, not from memory. |
| Header — reviewer and period | Reviewer: named engineering manager for their direct reports; named security lead for privileged and service accounts. Review period: Q3 2026. Completed 14 July 2026. | Attributes the judgement to a person competent to make it, and dates the operation of the control. |
| Row — retained access | Account: an engineer's identity-provider account. Roles: source-control write, staging cloud read. Decision: retain. Reviewer note: role unchanged; access matches current duties. | Shows the reviewer made an affirmative decision, not a silent default. |
| Row — reduced access | Account: a support engineer with production database read. Decision: reduce to the read-only support role. Removal executed 15 July 2026; evidence: identity-provider audit entry referenced by its event identifier. | Shows least privilege being enforced, and links the decision to proof it happened. |
| Row — revoked access | Account: a contractor account past engagement end. Decision: revoke. Executed 14 July 2026; evidence: account disabled entry plus cloud access-key deletion record. | Closes the loop across more than one system, which is where reconciliation usually fails. |
| Row — exception | Account: a shared build account with broad permissions. Decision: retain with exception. Justification, compensating monitoring, owner, and review-again date recorded. | An exception with an owner and an expiry is defensible; an unexplained retention is a finding. |
| Row — service account | Account: a deployment service account. Owner named. Credential type: federated workload identity, no long-lived key. Decision: retain; key-creation restriction confirmed. | Non-human identities are in the population, with a named owner — frequently the weakest area. |
| Footer — reconciliation | Leavers in the period per the HR system: 6. Accounts removed: 6. Longest gap between termination date and removal: 1 business day. Exceptions: none. | This single line answers the most commonly asked access question and shows the control's timeliness. |
| Footer — storage and retention | Stored in the evidence repository under access reviews, retention 3 years, immutable copy in the log archive. Next review due October 2026. | Shows the artifact itself is retained and that the cadence is scheduled rather than ad hoc. |
Review cadence: mandated, guided, or chosen
Quarterly access reviews are so common that teams assume they are required. For most organisations they are not. Only PCI DSS names a period among the sources on this page. Record why you chose your cadence, and the choice becomes defensible instead of arbitrary. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 7.2.4: review all user accounts and related access privileges at least once every six months. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not set a cadence for entities with no cardholder data in scope, and does not mean six months is right for privileged access, where more frequent review is common. |
| AICPA TSC CC6.2 and CC6.3 require that access be reviewed and modified as appropriate. | Attestation criteria, applying because you sought a SOC 2 report or a contract requires one. They require the review; they do not name a frequency. | Does not mandate quarterly. Your stated cadence becomes the thing you are tested against, so state one you can sustain. |
| ISO/IEC 27001:2022 Annex A 5.18 requires access rights to be reviewed in line with the organisation's topic-specific policy on access control. | Certification requirement where you seek or hold certification. It points at your own policy for the period. | Does not name a frequency. It does mean your policy's number becomes auditable, so do not write monthly if you do it annually. |
| NIST SP 800-53 Rev. 5 AC-2(j) — review accounts for compliance with account-management requirements at an organisation-defined frequency. | Regulatory and standards guidance, binding on US federal systems through separate authority. | Does not supply a frequency; it explicitly asks you to define one. |
| Review privileged and third-party access quarterly and all other access at least annually, and reconcile leavers monthly. | Industry best practice, and a widely accepted pattern. | Not a requirement in any source above. Adopt it, write it in the policy, and then meet it — an unmet policy cadence is worse than a modest one. |
| Attach the removal evidence to each revoke decision in the same artifact, and record the longest termination-to-removal gap in the period. | ShipReady Metrics recommendation. | Not required by any framework named here. It exists because reviews without removal proof are the most common access finding. |
Checklist
A question list for the access side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Do we have a written list of systems in access scope, and does it include systems the security team does not administer?
- For a sample of current accounts, can we produce the original approval, not only the grant?
- Can we reconcile the HR leaver list for the period against removal records in every in-scope system, and state the longest gap?
- Is multi-factor authentication enforced by policy for all in-scope accounts, and can we show registration coverage rather than just the policy?
- Do we have a definition of privileged access, and a complete list of who holds it in each system?
- Are service accounts, tokens, and cloud keys inventoried with a named owner and an age, and are long-lived credentials restricted?
- Do external and contractor accounts have an expiry and an internal sponsor?
- Does our last access review include population, reviewer, per-account decisions, exceptions, and proof that removals executed?
- Does our stated review cadence match what we actually did in the last two cycles?
- Can the administrators of an in-scope system alter its access logs?
What to do now
Ordered so the most commonly failed access controls close first. None of these steps is a legal determination, and none files anything with an auditor.
- Write the system scope list. Access evidence fails on population more often than on configuration, and the forgotten system is rarely the obvious one.
- Run the leaver reconciliation for the last twelve months now. It takes an afternoon, it is the question you will certainly be asked, and the result tells you whether deprovisioning works.
- Produce one review artifact in the format above, including removal evidence per revoke decision. One good review beats four undocumented ones.
- Define privileged access in writing, then produce the complete privileged list per system. Without the definition, the list cannot be complete.
- Inventory service accounts and long-lived credentials, assign each an owner, and restrict new long-lived key creation where the platform allows it.
- Set expiry dates on all external and contractor accounts, and give each an internal sponsor.
- Align the policy cadence with reality — lower the stated frequency if necessary — and then meet it. Being tested against your own unmet number is avoidable.
- Re-verify the cited requirements annually against the primary sources below, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not provision or deprovision access in your systems, does not run access reviews for you, does not enforce multi-factor authentication, and does not file anything with an auditor.
The GitHub App is read-only and includes the organisation Members scope, so organisation membership is visible as connected data. It does not change permissions, does not remove members, and does not configure authentication.
If you already have a session: signed-in app → Compliance holds evidence collection, which records control-mapped artifacts for starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Access-review artifacts are typically manual rows reviewed that way. That overlay is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion.
The obligation map lists frameworks your organisation marked in-scope. That mark is a scoping input you control, not a legal opinion that a framework applies. Readiness is an internal indicator, not certification.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
AICPA Trust Services Criteria CC6 (logical and physical access) are professional attestation criteria. ISO/IEC 27001:2022 Annex A 5.15 access control, 5.16 identity management, 5.17 authentication information, 5.18 access rights, and 8.2 privileged access rights are certification requirements. NIST SP 800-53 Rev. 5 AC family, including AC-2 account management and AC-6 least privilege, is guidance for commercial organisations. PCI DSS v4.0.1 Requirements 7 and 8, including the six-month review in 7.2.4, bind entities in scope through card-brand and acquirer contracts. Not a complete list, and not legal advice.
The AWS, Azure, and GCP pages in this cluster give platform-specific paths for the artifacts above. The access-review checklist template on this site is a fillable starting point; the change-management page covers the approval side of privileged action.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of the access lifecycle to evidence, with every source labelled by the kind of authority it carries. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Are quarterly access reviews required?
Not by most of the sources on this page. PCI DSS v4.0.1 Requirement 7.2.4 asks in-scope entities to review accounts and privileges at least once every six months. The AICPA criteria, ISO/IEC 27001 Annex A 5.18, and NIST SP 800-53 AC-2 all require review at a frequency you define. Quarterly is common best practice; choose a cadence you can sustain and then meet it, because your own stated number is what you are tested against.
Is a current user list enough for an access review?
No. A list evidences today. A review artifact evidences that a competent person examined a complete population and reached a decision per account during the period — and that decisions to remove access were actually executed. The removal proof is the part most often missing, and a review without it evidences an intention rather than a control.
Do service accounts need to be in the access review?
Yes, and they are usually the weakest area. Service accounts, API tokens, and cloud access keys are typically more privileged than human accounts and less frequently reviewed. Give each a named owner, record its purpose and credential type, restrict long-lived key creation where the platform allows, and include them in the population with their own decisions.
Does ShipReady Metrics run our access reviews?
No. It does not provision, deprovision, or review access in your systems. Access-review artifacts are handled as manual evidence rows, where a named human accepting a row renders it met and rejecting it renders it a gap, with a timestamp. The read-only GitHub App can see organisation membership as connected data; it cannot change permissions or remove anyone.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.