For Annex A control 5.18, "Access rights", the useful evidence is a dated export of who holds which permissions, a record of who approved each grant, and a record that leavers and role changes lost access. Source host, CI and cloud permission exports cover most of it for engineering teams.
What 5.18 sits next to
In the 2022 edition, control 5.18 is titled "Access rights" and sits in the organizational theme beside 5.15 "Access control", 5.16 "Identity management" and 5.17 "Authentication information". Technological controls 8.2 "Privileged access rights", 8.3 "Information access restriction" and 8.4 "Access to source code" cover the system side.
A practical split: 5.15 is your policy, 5.16 and 5.17 are how identities and credentials are handled, and 5.18 is the lifecycle of the permissions themselves. That lifecycle has three moments an assessor can sample: grant, review and removal.
Evidence for each moment
| Moment | Engineering artifact | What it proves |
|---|---|---|
| Grant | Access request ticket with approver | Someone with authority said yes |
| Grant | Team membership change in the identity provider | The grant went through the managed path |
| Review | Dated permission export plus reviewer sign off | Rights were checked, not just assumed |
| Removal | Offboarding ticket linked to account disablement | Leavers lost access |
| Role change | Ticket showing old rights removed | Access did not pile up |
For source hosts, export organization members, team memberships and outside collaborators. For CI, export who can edit pipelines, who can read secrets and which service accounts exist. For cloud, export role assignments by account.
A review routine that fits a small team
- Export permissions from each system on the same day.
- Put them in one sheet with columns for person, system, role and last active date.
- Ask each team lead to mark every line keep, reduce or remove.
- Make the changes and attach screenshots or a second export that shows them.
- Save the sheet, the second export and the lead sign offs as one dated bundle.
Quarterly is a common rhythm for privileged roles, with a lighter pass for the rest, but your own policy sets the rule and the evidence should match it.
Common weak spots
Outside collaborators who were added for a project and never removed. Service accounts and deploy keys with no named owner. Shared accounts. Admin roles held by people who only needed them once. Exports taken only once a year, which leaves a long window where a leaver keeps access.
Whatever your list shows, follow through. A review that finds twelve stale accounts and removes none is worse evidence than a review that finds two and closes both.
Where Safeguard fits
Safeguard includes agent identity and an MCP Guardrail, along with compliance and evidence automation, if you need access and tool call records for AI agents. You can try the free scan at gold.safeguard.sh/scan. An auditor decides what counts as sufficient evidence.
Quick check
Do screenshots count as evidence?
They can, but a dated export is easier to compare and harder to dispute. Use screenshots to show a change was made and exports to show the full state.
Does 5.18 cover service accounts and AI agents?
The title says access rights without limiting them to people. Treat service accounts and agents as identities with owners, scoped permissions and review dates, and check your own scope statement.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
