ISO 27001 access review evidence: a practical example
A list of accounts is the beginning of an access review, not the evidence that the review is finished.
If you coordinate access reviews for a small team, you need to show more than who had access on the day an export was taken. You need to show who considered that access, what they decided, and whether requested changes actually happened.
The information security management standard published by the International Organization for Standardization and the International Electrotechnical Commission is commonly called ISO 27001. Annex A reference A.5.18 concerns access rights; related references include A.5.15 and A.8.2. This guide paraphrases the task rather than reproducing licensed control text.
Use the ISO 27001 access review evidence example below to build one complete trail. It is a fictional teaching example, not a client record or a promise that a particular evidence pack will satisfy every audit.
What matters this week, and what can wait
This week, choose an important service and identify all routes through which people or automated processes can access it. Give the service owner a clear account list and a deadline for decisions. Verify any urgent removals rather than waiting for the review meeting.
An organisation-wide campaign and a new dashboard can safely wait until you have tested the process on one meaningful system. Known unnecessary privileges, orphaned accounts and access left after a departure should not wait for the rest of the spreadsheet.
Your useful output today is a review record that connects each decision to the account, the business reason and any completed action.
Define scope before requesting the export
An identity provider is a system that manages identities and authentication. A central directory export may show who can sign in through that provider, but not every account inside the application.
Ask the system owner about local accounts, supplier access, emergency accounts, service accounts and indirect membership through groups. A service account is used by software or an automated task rather than a person performing ordinary interactive work.
Record the environment, tenant or service boundary and the snapshot date. Production and testing environments may have different access paths. Do not imply a production review covers both unless it actually does.
Define whether you are reviewing account existence, assigned permissions or effective access. Effective access is what the account can actually do after group memberships, inherited permissions and other rules are considered.
If you cannot obtain a complete view, document the missing source and responsible owner. An honest limitation is better than claiming that a partial export represents the whole service.
Give the reviewer enough context to decide
The reviewer needs to understand the service and the business reason for access. A security coordinator can organise the process, but may not know whether a supplier still needs a particular support role.
For human accounts, link the account to an accountable person and current role. For service accounts, identify the owner, purpose, dependent service and what could break if permissions change. Avoid putting passwords, tokens or recovery codes into the review record.
Use explicit decisions:
- Retain, with the business reason recorded.
- Remove, with an action owner and urgency.
- Reduce or change, identifying the required permission set.
- Investigate, naming the missing information and reassessment date.
- Time-limited exception, with authorised conditions and expiry.
“Looks fine” is difficult to test. “Retain this support role because the named duty requires these functions, with review after the assignment ends” gives the decision context.
A fictional example: from account list to verified action
The following sample contains invented account labels, roles and events. It represents no real person, system or client. The labels demonstrate how a redacted working extract can retain decision context without exposing actual identities publicly.
| Example reference | Business context | Review decision | Follow-up and proof |
|---|---|---|---|
| EXAMPLE-USER-01 | Former project assignment ended; broader role remains | Reduce the service's administrator role | System owner changes role; reviewer checks a fresh permission view |
| EXAMPLE-SERVICE-02 | Scheduled processing task still needs access | Retain defined permissions; investigate unused scope | Task owner validates dependency before any change |
| EXAMPLE-SUPPLIER-03 | Support engagement ended | Remove remaining access | Access owner disables entry routes; independent check records result |
The review is not complete merely because the owner clicked “remove” in a worksheet. Keep a record of the implementation and verification. Where revoking one account does not revoke active sessions, local credentials or another access route, the system owner must consider those separately.
Do not make experimental privilege changes on a live critical service to produce evidence. Agree the safe implementation method with the responsible operator. Security improvement should not become an avoidable service interruption.
What the evidence pack should contain
Download the blank access review worksheet, open the fictional sample, or use the workbook. There is no registration requirement. The sample is deliberately small; it is not an exhaustive account inventory.
| Evidence element | What it demonstrates | Common weakness |
|---|---|---|
| Scope and source record | Which service and access paths were examined | A directory export presented as complete application access |
| Dated account and permission snapshot | The population considered | A screenshot with no date, system or coverage |
| Reviewer identity and authority | Who could judge the need | An unexplained initials column |
| Decision and business rationale | Why access should remain or change | Every row approved without context |
| Action record | What was requested and delivered | A removal ticket with no completion result |
| Verification and unresolved issues | Whether the change worked | Review closed while actions remain untested |
| Review date and next trigger | When the conclusion will be reconsidered | A recurring date detached from departures or role changes |
Keep the original source protected. If you share an extract externally, preserve enough context to support the review while removing unnecessary personal information, internal addresses and sensitive configuration details.
Redaction should not destroy your internal ability to trace the evidence. Keep the secure original and a controlled way for authorised reviewers to relate the redacted copy to it. Do not publish that mapping or sensitive account data with the article.
Verify actions before closing the review
Ask the system owner to demonstrate the relevant state after the change. Depending on the service, that may mean a fresh permission export, an administrative record or another reliable check. Keep the method and result, not merely an assertion that work was completed.
Record when the change took effect and who verified it. A request date, an implementation date and a verification date describe different events.
For a service account, test the required function safely after reducing permissions. If a change cannot be made immediately, document the risk, interim restriction, decision authority and next action. Do not mark an exception as “removed”.
A review can have completed decisions while corrective actions remain open. Report those states separately. Otherwise a clean completion percentage can hide the very access problems the exercise was meant to address.
Set a proportionate review cadence
There is no single review frequency in this guide for every account and system. Consider service criticality, privilege level, changes and applicable obligations when choosing a schedule.
Review after people leave, change roles or complete an assignment, rather than treating the calendar cycle as the only trigger. The United Kingdom's National Cyber Security Centre recommends regularly checking unnecessary privileges and revoking access when it is no longer required.
For privileged accounts, which can make significant system or security changes, pay particular attention to named ownership and separation from everyday activity. A shared account with no accountable operator weakens both access control and the reliability of the evidence.
If an obligation or contractual retention period is uncertain, obtain qualified advice. Software cannot make legal determinations about the adequacy of your review or the lawfulness of retaining personal information indefinitely.
Connect findings to controls and risk treatment
A missing reviewer decision is an evidence gap. A former supplier still having unnecessary access may be an operating-control failure. An account with an unknown owner is a question that needs investigation. Keep those distinctions visible.
Use the evidence collection guide to retain the scope and provenance of the review. Link the activity to the appropriate control through the controls management guide. If a repeated failure requires changes to the process, record a treatment action rather than only correcting the individual account.
In GRCompliance Core, verified public capabilities include controls, implementation status, a risk register and evidence linked to controls. You can evaluate those building blocks using a fictional review record. The presence of an evidence item does not mean the application has independently checked the underlying permissions.
Try the live demo using sample information only, or inspect the free open-source Core. No automatic account discovery, live privilege verification or worksheet import is claimed here.
Frequently asked questions
Is an account export enough access review evidence?
No. It shows a population at a point in time. Keep the scope, reviewer decisions, rationale, follow-up actions and verification needed to demonstrate that the access was actually assessed.
Who should review access?
Choose someone with the authority and knowledge to judge the business need, usually the relevant service or information owner. The coordinator and technical operator can support the review without silently making every business decision.
Should service accounts be included?
Yes, where they provide access within the defined scope. Identify an accountable owner, purpose and dependencies. Review permissions carefully so changes do not interrupt a required automated task.
Does completing the worksheet guarantee conformity?
No. It is an operating aid, not an official standard form. The scope, decisions, actual control performance and applicable requirements still need assessment; software cannot make legal determinations or guarantee certification.
Sources
Reviewed 7 November 2026. Standard references are paraphrased; the worksheet and sample are practical suggestions, not prescribed standard text.
- International Organization for Standardization: information security management standard; Annex A references A.5.15, A.5.18 and A.8.2; documented-information context in clause 7.5.
- Information security controls guidance overview.
- United Kingdom National Cyber Security Centre: identity and access management: account lifecycle, privilege reviews and accountable access.
- GRCompliance Core documentation: controls and linked evidence; no automatic access-review capability assumed.
Try the live demo
Open the public demo to see the product. Use fictional data only.