A.5.18 Access rights: requirements and evidence

What A.5.18 access rights requires in an ISO 27001 audit

An auditor testing A.5.18 Access rights will usually pick a handful of people and systems, then ask for the full access history behind each one: who requested the access, who approved it, when it was granted, when it was last reviewed and when it was removed or changed. The control asks that access rights to information and other associated assets are provisioned, reviewed, modified and removed in line with the organization's access control policy and rules, which is why the auditor starts from the policy and works outward. Your job before the audit is to be able to produce that trail for any sampled account without reconstructing it from memory. The two failure modes auditors look for are access that accumulates as people move between roles and access that outlives its business need, such as contractor accounts that remain active after a project closes.

This control is hard in practice because no single team owns it end to end. HR knows when someone joins, moves or leaves, IT operates the directory and identity provider, and application owners decide what a role inside their system may do. A joiner, mover or leaver event that reaches only one of those groups leaves access behind. Before the audit, confirm which trigger source is authoritative for each system, who is accountable when a trigger fails, and how an application's local accounts are linked to the central identity record. Local accounts that bypass central provisioning are a common gap that a sample will expose.

A.5.18 merges three ISO/IEC 27001:2013 controls: A.9.2.2 User access provisioning, A.9.2.5 Review of user access rights and A.9.2.6 Removal or adjustment of access rights. If your certification predates 2022, your existing evidence for those three controls maps forward, but the 2022 wording expects one coherent process rather than three separate procedures. In this theme, access rights generate more sampled evidence than almost any other control, so it is worth checking, before the auditor arrives, that every provisioning ticket, periodic review record and removal record can be linked back to the access control policy that authorizes it.

Which systems, people and third parties A.5.18 covers

A.5.18 applies only to the access rights inside your ISMS boundary, so the scope you draw determines which accounts, groups and grants an assessor can sample. Each decision below changes the population you must review, the evidence you must keep and the work your team carries each quarter.

In-scope applications and directories

Decide which applications, identity directories and cloud consoles hold information inside the boundary. Every system you include adds a population of accounts and role grants that needs provisioning records, review evidence and removal records. Start with the directory that issues identities, such as a FreeIPA or Keycloak realm, then list each downstream application that keeps its own local users. A local account outside the directory is easy to miss and is often the first exception an auditor finds.

Privileged and shared accounts

Administrator, root, break-glass and service-owner accounts carry the widest rights, so assessors usually test them separately from standard users. Decide whether privileged grants sit in the same population or a separate one, and whether shared accounts are in scope at all. Shared accounts need a named owner and a documented reason to exist, or they cannot show who held the access at a given time. Confirm how each privileged grant is approved and how often it is re-certified.

Contractors and suppliers with access

Third parties that log in to your systems are people or organizations whose access must still follow the provisioning, review and removal rules. Include them in the access population if they hold accounts, VPN credentials or delegated admin rights. Confirm how their end dates are set, who approves them, and how their access ends when the contract does. Supplier-side controls sit in the supplier theme, but the account itself is an A.5.18 record in your environment.

Physical access areas

A.5.18 concerns access rights to information and associated assets, and physical access to a data room or server cage can hold information. Decide whether badge and key rights for in-scope areas join the access population or stay with the physical controls. If included, you need the same joiner, mover and leaver records for badges as for logins, and a review of who still holds entry. Document the decision either way so the boundary is consistent.

Non-human identities

Service accounts, API clients, CI pipelines and automation tokens hold rights without a person behind them, and they are often the access that nobody reviews. Decide whether these identities are in scope, which owner is accountable for each one, and how a retired workload triggers removal. Confirm that each token has a documented owner and expiry, since an unowned token is hard to justify in a sample. The A.5.16 identity life cycle covers how these identities are created and retired.

Access that leaves the directory

Access granted through a source outside the central directory, such as a spreadsheet of vendor logins, a shared password vault or a SaaS admin console, can escape every review. Inventory these sources during scoping and decide whether each one is in the boundary. Where a system is in scope, confirm that its grants can be listed, reviewed and revoked from one place. Unlisted sources are the most common reason an access population turns out to be incomplete.

How an auditor tests access rights provisioning, review and removal

This table sets out what an assessor does for each stage of the access rights life cycle, the evidence requested and the findings that most often appear. Read each row as a test an auditor will run on a sample, then check whether your own records would pass it without reconstruction.

Test area	What the assessor samples or checks	Evidence requested	Common findings
Joiner provisioning	Takes a sample of recent starters from the HR records and traces each to the system accounts and access rights granted to them	HR start records, access request tickets, approval records and account creation logs for each sampled person	Accounts created with no matching HR record, or access granted without a documented request
Approval before grant	Checks that the approval for each sampled access right was recorded before the grant date, by someone authorized under the access control rules	Dated approvals, approver role or ownership records, and the grant timestamp from the system	Grants that predate approval, self-approved requests or approvals from people without authority over the resource
Mover changes	Samples people who changed role and checks whether old access was removed or adjusted when the new access was granted	Role change records from HR, access before and after snapshots, and change tickets	Access accumulating across roles with no removal of earlier rights and no review that caught it
Leaver removal	Takes a sample of leavers and compares the HR termination date with the disablement or removal date in each system	HR termination records, directory and application account status history, and removal tickets	Accounts still active after the leaving date, late removal for privileged or shared access, or accounts never disabled
Orphaned and dormant accounts	Compares system account lists against HR and contractor registers to find accounts with no owner or no current relationship	Full account extracts from directories and key applications, reconciled against HR and contractor lists	Orphaned accounts, service accounts with no named owner, or contractor accounts that outlive the contract
Periodic access review	Checks that reviews happen at the defined interval, that reviewers were the designated owners and that each item received a decision	Review campaign records, reviewer assignments, item-level decisions and evidence of action taken	Reviews with no recorded decisions, reviewers who reviewed their own access, or revocations never actioned
Review follow-up	Traces revoke or change decisions from a review to the system to confirm the change was made	Revocation tickets, system change logs and re-review or closure notes	Decisions recorded as revoke but access still present in the target system
Consistency with the access control rules	Compares the actual grants and reviews with the access control policy and topic-specific rules the organization wrote	Current access control rules, version history and records showing staff followed them	Rules that describe a process nobody runs, or exceptions granted with no documented approval

Implementing joiner, mover, leaver and review handling

This sequence turns A.5.18 from a policy statement into a working cycle: rules are set first, HR events drive identity changes, and every grant, change and removal leaves a record that an auditor can sample. Periodic reviews then confirm that the cycle is still working.

Define access control rules and owners
Start from the access control policy that A.5.15 requires and write the rules that govern who may request access, who approves it and how long it lasts. Name an owner for each system, application and data set, and record which roles each owner may approve. The output is an approved access matrix that maps roles to systems, permission levels and approvers, signed off by the asset owners and the policy owner. Auditors use this matrix as the reference point for every sampled grant.
Link HR events to the identity lifecycle
Identify the HR events that should change access: hire, transfer, role change, leave of absence, termination and contract end. Agree which system is the source of truth for employment status and how a change in that system reaches the directory or identity provider. Confirm with HR and the identity team which events trigger which actions, including contractors and non-human accounts that HR does not manage. The output is a documented trigger map that shows each HR event, its owner and the access action it starts, which also supports the identity lifecycle controls in A.5.16.
Implement provisioning with recorded approvals
Build the joiner path so that access is granted only through a request that names the person, the role, the business reason and an approver defined in the access matrix. Where the identity platform supports it, use group or role assignments rather than direct grants to individual applications. Keep the request, approval and grant as linked records. The output is a provisioning workflow record for each grant, which lets an auditor trace a live account back to a documented approval.
Build mover handling to remove accumulated access
When someone changes role, the old access must be reviewed and removed as well as the new access granted. Define the rule that a transfer triggers a comparison between current entitlements and the matrix for the new role, and that anything not required is revoked or re-approved. Tools such as authentik's SCIM provider can push group changes to target applications, which reduces manual steps, but the rule itself must be written and tested. The output is a mover checklist and a sample of transfers showing removed entitlements, which addresses access accumulation.
Automate or script leaver removal
Configure the leaver path so that termination in the HR source of truth disables the identity centrally and propagates removal to connected applications. Where an application cannot be reached by automation, document a manual revocation task with a named owner and a completion record. Include shared accounts, service credentials and access granted outside the directory, and confirm that revocation covers them. The output is a leaver test record showing a disabled identity and the removal of its application access, along with the list of applications that still need manual steps.
Schedule and run periodic access reviews
Set a review schedule for each system based on its risk, and assign reviewers who are not the people who requested the access. Export current entitlements, ask each reviewer to keep, change or revoke each item, and track decisions to completion. Certification tools such as midPoint can run these campaigns and enforce a decision timeframe, while the schedule itself is set by the organization. The output is a signed review campaign with recorded decisions and the revocations they triggered, which is the evidence auditors sample most often in this theme.
Close the loop with exception and metric records
Record every exception to the access matrix, such as temporary elevated access or an application that cannot follow the standard path, with an approver, an expiry and a review date. Feed the results of joiner, mover, leaver and review checks into the internal audit and management review cycle so that gaps lead to corrective action. Confirm with your certification body which records it expects to see and how long they must be retained. The output is an exception register and a set of corrective actions tied to the review findings.

How central identity and access campaigns produce the evidence

A central identity provider is where joiner, mover and leaver changes can be made once and carried into connected applications. In a self-hosted open-source setup, authentik is one option: its SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. That gives the organization a log of what was pushed and when, which is the kind of record an auditor can sample against a leaver ticket.

Provisioning events: creation, change and deletion events for users and groups, with the target application they were sent to.
Hourly full sync: a scheduled reconciliation that shows the state of each target at a point in time, not only the changes.
Deprovisioning on loss of access: removal from the target when a user stops qualifying for the application, which is the step that closes most leaver findings.
Group membership history: the group changes that drive role-based access, useful when an auditor asks why an account held a right.
What it cannot prove alone: that every application is connected, that local accounts created outside the provider were removed, or that the approval for a grant was appropriate.

Confirm with the vendor and your own tests which applications support SCIM provisioning in your version, and keep a list of applications that still need manual account handling.

Which access evidence passes an A.5.18 audit

Auditors testing A.5.18 Access rights trace one person's access from the request to the removal and check that each step left a record. The cards below cover the artifacts that connect those steps, and each one only holds up if it is maintained continuously rather than rebuilt before the audit.

Provisioning requests with approvals

Every grant of access should start from a request that names the person, the system, the role and the business reason, and carries an approval from the owner of the information or application. Auditors pick sampled grants and ask for the request, the approver and the timestamp of the change. Keep the request record linked to the account change so the two can be matched without interviews. Check monthly that no account exists without a matching approved request.

Joiner and leaver tickets matched to HR events

Joiner and leaver tickets show that access was granted when employment started and removed when it ended or changed. An auditor will compare HR start and end dates against the account activity, so the ticket should reference the HR event that triggered it. Reconcile the HR feed against active accounts at a set interval and record exceptions, such as accounts still active after a termination date. Ask your HR and identity owners to confirm which system is the source of truth.

Periodic access review records with reviewer decisions

A periodic review record lists each user, group or role with the access it holds, the reviewer who checked it and the decision to keep, change or revoke. Auditors look for evidence that reviewers were the right owners and that revocations were carried out. Keep the decisions as dated records rather than spreadsheet edits, and keep the follow-up tickets that prove removals happened. Confirm the review frequency and scope with your own risk assessment before the first cycle.

Removal and deprovisioning logs

Removal logs show when access was revoked in each target system, not only in the central directory. Auditors test whether a leaver lost access everywhere it was granted, so the log should cover every connected application and any local accounts. Where provisioning is automated, keep the sync history and error reports, since a failed sync that nobody saw is a common finding. Review failed removals each week and record how each one was closed.

Access control rules and their change history

The access control rules are the written policy and procedures that define who may approve access, how roles are built and how exceptions are handled. Auditors use them as the yardstick for every other record, so the document must match what the systems actually do. Keep version history with approvals, and record each change to role definitions or group membership rules. Confirm with the policy owner that the rules are reviewed at planned intervals and after significant changes.

Identity directory and role assignment exports

Directory exports show the current state of users, groups and role assignments at a point in time, and they let an auditor compare the population against approvals and HR records. Generate them on a schedule and store them with a timestamp and the identity of the person who ran the export. A stored export with no change log cannot prove what changed between dates, so pair exports with their audit trail. Confirm which directory and identity platform hold the authoritative data for each system.

What meeting A.5.18 costs in money and effort

This table breaks the cost of meeting A.5.18 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it before requesting quotes so you can compare scopes on the same basis, and note that no prices or durations are given because none are supplied for this control.

Cost component	Who is paid or who bears effort	One-time or recurring	What drives it, and what to ask for in a quote
Identity tooling or licenses	Software vendor or subscription provider; self-hosted open source has no license fee	Usually recurring for commercial tools, one-time setup for self-hosted	Number of identities and applications in scope. Ask whether the quote includes licenses, hosting and support, or only implementation.
Engineering time to integrate HR and applications	Internal platform or IT team, or an implementation partner under a fixed-scope agreement	Mostly one-time, with changes whenever a system is added	Number of source systems (HR, directory, ticketing) and target applications. Ask which connectors are included and how new applications are onboarded.
Joiner, mover and leaver workflow design	Internal HR, IT and security owners, with partner support if requested	One-time design, then recurring maintenance	Volume of joiners, movers and leavers and how many role changes exist. Ask how the workflow handles role changes, not only hires and exits.
Manager review effort for access reviews	Business managers and application owners, paid through their existing roles	Recurring, once per review cycle	Number of review cycles per year, number of access items per reviewer, and whether reviews are scoped by application or by person. Fewer, well-scoped items reduce effort.
Evidence upkeep	Internal compliance or security owner, sometimes supported by a partner	Recurring	How often evidence is exported, how many systems hold records, and whether logs and review decisions are retained automatically. Ask where evidence is stored and who maintains it.
External testing or review	Independent tester or reviewer, engaged separately from the auditor	Recurring if scheduled, one-time for readiness checks	Scope of access testing, such as role design or privileged access. Ask whether testing covers the access review process itself, not only technical controls.
Auditor sampling	Independent certification body, paid under its own audit agreement	Recurring with each audit cycle	Number of joiners, leavers and reviews the auditor selects, and how many systems are in scope. Clean, consistent records reduce sampling follow-up.

Who owns access rights, who implements them and who tests them

Your organization owns the access control rules and every access decision that falls under A.5.18. The control asks that access rights be provisioned, reviewed, modified and removed according to your topic-specific access control policy, so the policy, the approvers and the review owners must be named by your people, not delegated to a vendor. Management is also accountable for deciding who may approve access to sensitive systems and how often reviews happen.

Policy and rules: Write and approve the access control rules that the provisioning, review and removal steps follow.
Approvals: Name the approvers for each system or data class and keep the approval record for each grant.
Access reviews: Assign reviewers who are accountable for keeping, changing or revoking access, and decide the review cycle.
Leaver and mover decisions: Confirm when access ends or changes after HR events and who signs off exceptions.
Exceptions: Authorize and time-limit any access granted outside the standard path.

Confirm that every decision in your sample has a named owner, a date and a recorded outcome, because the auditor will test those decisions directly.

Where access rights controls usually fail the audit

Auditors testing A.5.18 Access rights usually find the same few gaps: accounts that outlive the business need, access that piles up as people change roles, and reviews that happen without a recorded outcome. Each card names one gap, the fix that closes it and the evidence an assessor will ask to see.

Leavers still active after exit

Accounts stay enabled after a contract ends or an employee leaves, often because removal depends on a manual ticket that nobody closes. Check how HR and contractor end dates feed the identity source, and confirm that disabling an identity removes access to every connected application, not just the directory login. The evidence is a leaver sample: the termination date, the removal ticket or automated deprovisioning log, and the timestamp showing access was actually gone.

Movers keeping old role assignments

When people change teams, new access is granted but earlier access is often never removed, so permissions accumulate over time. Require a mover workflow that compares the new role against the old one and revokes what the new job does not need. Assessors look for a mover sample in which the prior entitlements are visibly removed, and for approval records that match the new role. This gap also weakens segregation of duties under A.5.3.

Reviews without recorded decisions

A review that produces no documented outcome cannot show that access was checked. Each reviewer should record a decision to keep, change or revoke every access item, within a deadline the organization sets and writes into its procedure. Keep the campaign scope, the reviewer list, the decisions and the follow-up revocations together. Access certification features in tools such as midPoint can hold these decisions, but the organization must still define who reviews what.

Shared accounts with no owner

Shared administrative or service accounts have no single person accountable for their use, so nobody can confirm who holds the credentials or why. Assign a named owner to each shared account, record the business purpose, and tie the account to a review cycle. Where sharing cannot be removed, document the compensating controls, such as vaulted credentials and logged sessions. Assessors commonly ask who can use a given shared account today and who approved that access.

Access rules that do not match grants

The access control policy may say that access follows least privilege and role approval, while the directory shows direct grants that no rule explains. Compare the written rules with the groups, roles and application entitlements that actually exist, and close the gaps in either direction. Consider the identity and access control items as one set: A.5.15 sets the rules and A.5.18 provides the grant trail. Evidence is a reconciliation report that maps each entitlement back to a rule and an approver.

Unclear control ownership in FreeIPA or Keycloak

Central directories such as FreeIPA or single sign-on platforms such as Keycloak reduce duplicate accounts, but they still need named administrators and a change record for every delegated right. Confirm which administrators can create groups, change memberships and assign roles, and log those actions to a store the organization controls. Without this, an assessor cannot tell whether a grant was authorized or made by someone who simply had admin rights.

Common questions about A.5.18 access rights

How much effort do joiner and leaver handling take?

The effort depends less on the number of people than on how many systems hold access and how many of them are wired to a central identity source. A small team with one identity provider and a handful of applications can run joiner and leaver handling with a documented request form and a short checklist. Effort rises when each application has its own local accounts, because every new hire, role change and departure then needs a separate action in each system. Ask your provider to estimate effort from a list of your applications, how each one authenticates, and whether provisioning can be automated. Recurring effort is mostly the handling of exceptions, such as contractors, shared accounts and urgent revocations, not the routine cases.

How often do access reviews have to happen, and who performs them?

ISO/IEC 27001:2022 does not set a review frequency for A.5.18. The organization sets it in its access control rules, based on the sensitivity of the information and its own risk assessment, and then follows that schedule consistently. Auditors check that the schedule exists, that reviews happened as planned, and that the reviewer had enough context to decide. Reviews of privileged and high-value access are usually more frequent than reviews of standard user access. The reviewer should be the owner of the system or data, not the person who granted the access, so that the review is a genuine check. Confirm the frequency with your own policy owner and your certification body before you commit to it.

Can a team handle A.5.18 without an outside partner?

Yes, many organizations run access rights internally, and the control does not require an external party. A team can do it alone when it owns its identity source, has clear system owners and can produce evidence of provisioning, changes, removals and reviews. Outside help is most useful when the environment is fragmented across many applications, when the team lacks time to automate provisioning, or when it needs an independent view of its own review process before a certification audit. Any partner prepares systems and evidence. Only the independent certification body issues the certificate, and the organization keeps ownership of its access decisions.

What does A.5.18 need from HR and application owners?

A.5.18 depends on two inputs that sit outside IT. HR must trigger joiner, mover and leaver events in time, ideally from the system of record for employment, and must confirm the effective date of each change. Without a reliable feed, access stays open after people leave. Application owners must define what each role grants, approve requests for their systems and perform periodic reviews of who has access. Write these responsibilities into the access control rules and agree service levels for each handoff with HR and the owners. Keep records of the approvals, because they are the evidence an auditor will ask for first.

What do auditors sample when they test access rights?

Auditors usually start with a sample of people, both recent joiners and leavers, and trace each one through the process. For a joiner, they look for a request, an approval by the right owner, and provisioning that matches the approved role. For a leaver, they compare the termination date with the date access was removed in each system. For reviews, they check that the review occurred on schedule, that the reviewer was appropriate, and that actions such as revocations were carried out. They also compare system account lists with the HR list to find orphaned or shared accounts. Keep these records together so each sample can be traced without manual reconstruction.

Which technical tools help produce access rights evidence?

Several open-source tools support the technical side, though each needs to be checked against your environment. authentik's SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0, run a full sync every hour, and deprovision users from the target when they lose access. FreeIPA stores users and groups in 389 Directory Server with centralized access control and delegated administration. Keycloak provides single sign-on, so access is granted and removed in one place for applications that support its protocols. For periodic access certification, midPoint's campaigns let designated reviewers keep, change or revoke access items within a set timeframe. Confirm each tool's fit with your applications before relying on it for evidence.

What drives the cost of access rights work?

The main cost drivers are the number of applications that need their own accounts, the degree of automation, the quality of the HR data feed and the number of access reviews the schedule requires. Costs are both one-time and recurring. One-time work includes designing roles, connecting identity sources, configuring provisioning and building the review process. Recurring work includes operating joiner and leaver handling, running reviews and maintaining role definitions as systems change. When requesting a quote, ask the provider to separate build work from ongoing support, to list each application and integration in scope, and to state which evidence it will prepare. No figure is given here because cost depends on your environment and written scope.

How DeployOpen scopes and prepares A.5.18 access evidence

DeployOpen plans, implements and documents the self-hosted identity and access components that support A.5.18 Access rights, inside the client's own cloud accounts, data center or air-gapped network. In practice this can cover a directory such as FreeIPA, a single sign-on layer such as Keycloak, and a provisioning and certification tool such as authentik or midPoint, depending on what the organization already runs. Before any build starts, the written scope names which applications feed into the joiner, mover and leaver workflows, which groups and roles are in use, and which review campaigns will produce the records an assessor samples. DeployOpen does not issue audit reports or certifications. An independent auditor or certification body reaches that conclusion, and the organization's own management decides who gets access, at what level, and for how long.

Engagements are fixed-scope, so the deliverables are agreed in writing before work begins. Typical written deliverables for this control include the configured provisioning and deprovisioning paths, the access review procedure and its schedule, the reviewer assignments, and an evidence register that maps each access event to its source system. The organization keeps ownership of every access decision. Reviewers, approvers and the people who sign off on exceptions must be named by the organization, and the configuration must reflect those decisions rather than encode choices made by the implementer. Ask any partner to show, in the statement of work, which of these artifacts you will own after handover and how they will be stored.

Before you commission work, confirm three things with your auditor and your own team: which systems fall inside the ISMS scope, how far the access control policy under A.5.15 already defines review frequency and approval authority, and whether your current tools can export deprovisioning and review records in a form an auditor can sample. Those answers shape the effort more than any tool choice does. If they are unclear, make them the first deliverable of the scoping phase so the quote reflects real work instead of assumptions.

A.5.18 Access rights