ISO 27001 Access Control: What Annex A Requires and How to Prove It

ISO 27001 access control means you decide who may reach which information and systems, give them only what they need, and keep evidence that you grant, review and remove that access on a defined schedule. In the 2022 edition of the standard, the core control is Annex A 5.15, supported by related controls for identity management, access rights and privileged access. This guide explains what those controls require, what auditors look for, and how to build a process that produces evidence without manual work.

Anyscim

Keep Access Changes in Sync

Anyscim syncs Google Workspace user and group changes to SCIM-compatible apps, with real-time updates and audit logging for clearer evidence.

Explore Anyscim

TL;DR

ISO/IEC 27001:2022 is the current edition of the ISMS standard. Certification is optional, but customers and regulators often expect it.
Annex A 5.15 requires access rights to be provided, reviewed, modified and removed according to a topic-specific access control policy, based on need to know and least privilege.
Auditors want evidence, not intent: approvals, review records, exception justifications and proof that offboarding reaches downstream apps.
Disabling a user in your identity provider is not enough on its own. You must show that access is revoked in every connected application.
Automating provisioning with SCIM turns Google Workspace changes into logged, repeatable events across your apps.

What ISO 27001 means by access control
Annex A 5.15: the core requirement
Related controls auditors test alongside 5.15
What auditors look for in practice
Technology is only one of three pillars
A practical access control workflow for Google Workspace organizations
Automating provisioning with SCIM
Perspective: why read-only and logs matter for audits
Evidence checklist for your next audit
How ISO 27001 relates to NIST
Common mistakes to avoid
FAQ
Sources

What ISO 27001 means by access control

Access control in ISO 27001 is not one technical feature. It is a set of rules and the mechanisms that enforce them. The rules state who may reach information and associated assets, for what purpose, and under whose authority, as AuditFront's control guidance puts it. The mechanisms include authentication, role assignment, approvals, reviews and removal.

The standard is a management framework. ISO/IEC 27001:2022 is the third edition, published in October 2022. It is not a legal requirement and certification is not mandatory. Still, following it helps organizations meet sector-specific legal and contractual obligations, and many enterprise buyers ask vendors for a certificate or an equivalent assurance report.

The 2022 edition has 93 controls in four themes: organizational, people, physical and technological. Access control spreads across several of them. That is why a policy document alone never satisfies an auditor.

If you are reading older guides that cite Annex A.9, note that the 2013 structure used a dedicated access control domain. In the 2022 edition the same subject is covered mainly by controls numbered 5.15 to 5.18 and 8.2 to 8.5. The intent is the same. The numbering and grouping changed.

Annex A 5.15: the core requirement

Control 5.15 requires that access to information and other associated assets is provided, reviewed, modified and removed in line with the organization's topic-specific access control policy and its business and information security requirements. Rules must follow the principles of need to know and least privilege, according to ISMS.online.

In practice that breaks into five parts.

A documented policy. It states how access is requested, who approves it, and how it is changed and removed.
Defined roles. Access is tied to job function so that decisions are consistent, not made ad hoc.
Least privilege. Users receive the minimum permissions required for their work.
Need to know. Information is available only to those whose duties require it.
A lifecycle. Access is granted, reviewed, modified and removed, and each step leaves a record.

The lifecycle is where most findings occur. Teams write good policies and then run access by hand, so records are incomplete and removals are late.

Write topic-specific policies, not one blanket policy

The 2022 edition asks for topic-specific policies. For cloud-heavy organizations, practitioners recommend replacing a single organization-wide access policy with policies aimed at specific business functions or applications. A practical split looks like this:

A general access control policy that sets principles, roles and approval authority.
A policy for privileged and administrative access.
A policy for production systems and customer data.
A policy for third-party and contractor access.
A joiner, mover and leaver procedure that applies to all of them.

Keep each document short enough that staff can follow it. An auditor will interview people, and they should be able to describe the process the policy defines.

Auditors rarely test 5.15 alone. The ISMS.online control page links it to controls 5.16, 5.17, 5.18 and 8.2. The table below maps each one to the evidence an auditor usually asks for.

Control	Subject	Typical evidence
5.15	Access control policy and rules	Approved policy, role definitions, review schedule
5.16	Identity management	Unique user IDs, joiner and leaver records, directory export
5.17	Authentication information	Password and MFA settings, credential handling rules
5.18	Access rights	Provisioning tickets or logs, review records, removal records
8.2	Privileged access rights	List of admins, approval records, privileged review results
8.5	Secure authentication	MFA enforcement settings, sign-in policy
8.15	Logging	Retained logs of access and administrative events, log protection

Control 8.15 matters more than it first appears. Logging requires event records of who did what, when and from where, and protecting those logs from tampering, including by privileged insiders, according to UpGuard's guide to the control. If your administrators can edit or delete the records that prove their own actions, you have a control gap.

What auditors look for in practice

The standard tells you what to achieve. Audit practice shows where organizations fail. Four patterns come up repeatedly.

Offboarding that stops at the identity provider

Most IT administrators assume that suspending a user in the primary identity provider ends their access everywhere. Auditors check this assumption. They look for evidence that offboarding actually revokes tokens and active sessions in downstream applications. A disabled Google Workspace account does not always remove the user's account in a SaaS tool that keeps its own local login or long-lived session.

Disabled identity account with an active SaaS session

Sample a leaver from the last quarter and trace them through every application. If any app still lists them as active, you have a finding waiting to happen.

Exceptions with no paper trail

Reviewers often cannot tell a deliberate exception from a configuration error. AuditFront recommends recording the business justification, the approver and the next review point before you grant the exception, not after. A simple exception register with four columns covers it: user, access granted, justification and approver, and review date.

Review frequency that ignores risk

There is no fixed review interval in the standard. Guidance says to calibrate frequency to risk: data sensitivity, privilege level, staff turnover and how often systems change. Administrative roles need more frequent review than low-risk internal tools. Write your chosen intervals into the policy and then keep to them.

A workable starting point:

Administrative and privileged roles: reviewed more often than any other group.
Systems holding customer or regulated data: reviewed on a regular schedule set by risk.
Low-risk internal tools: reviewed less often, but still reviewed.
Any system after a reorganization or a large wave of departures: reviewed outside the normal cycle.

No separation of duties in access management

Auditors check that the same person cannot request, approve and implement their own access to a sensitive system. Successful organizations use independent request, approval and implementation steps, or independent audit logs that show the separation clearly. For a small team where one admin does everything, the logs become the compensating evidence.

Three access steps with compensating audit logs

Technology is only one of three pillars

According to ISO's own guidance, a working information security management system balances people, policies and technology. Relying on tooling alone is a common cause of audit gaps. Even a fully automated provisioning setup needs documented procedures, named owners and management oversight. ISO's overview of access control is a good plain-language reference to share with non-technical stakeholders.

A short ownership model helps:

HR owns the trigger for joiners, movers and leavers.
IT owns the implementation of access and the directory.
Application owners approve who needs access to their system.
Security or compliance owns the policy, review cadence and evidence.
Management signs off on the policy and reviews results.

A practical access control workflow for Google Workspace organizations

If Google Workspace is your source of truth for identities, build the process around it. The steps below produce the evidence that controls 5.15, 5.16 and 5.18 call for.

Define roles and groups. Create Google Workspace groups that match job functions and access tiers. Name them consistently, for example by team and permission level.
Map groups to application roles. Document which group grants which role in each app. This mapping is your access matrix and a core audit artifact.
Set the approval path. Decide who approves membership in each group. Keep approval separate from the person who implements the change.
Provision from the directory. Push users and group membership from Google Workspace to each application, so the directory is the single place where access is changed.
Remove access at departure. When HR marks a leaver and the Google Workspace account is suspended or deleted, the change must propagate to every connected app.
Log every change. Retain records of who was created, changed or removed, and when.
Review on schedule. Export group membership and application access, compare, and record the outcome and any corrections.
Test the leaver path. Each quarter, take a sample of departures and confirm their access is gone everywhere.

Steps 4 to 6 are where manual processes break. Tickets get missed, someone forgets a tool that only a few people use, and the log lives in a spreadsheet nobody trusts.

Automating provisioning with SCIM

SCIM 2.0 is the standard protocol for creating, updating and deactivating user accounts and group memberships in applications from a central source. Most enterprise SaaS tools support it, usually on higher plans. Instead of an admin creating accounts by hand, the identity source sends the changes.

For access control, SCIM gives you three things auditors value:

Consistency. The same rules apply to every user, every time.
Speed of revocation. A departure in the directory becomes a deactivation in the app without a ticket.
A record. Each provisioning event can be logged and exported.

Google Workspace does not provide SCIM provisioning to every application you may use. That gap is the reason we built AnySCIM.

Where AnySCIM fits

AnySCIM synchronizes users and groups from Google Workspace to any SCIM 2.0 compatible app, including custom SCIM endpoints, without scripts. Changes in Google Workspace, such as an employee departure, are synced in real time. It connects to Google Workspace with read-only access, so the sync tool cannot change your directory. Group and attribute mapping is customizable, and preconfigured templates are available for common vendors. Detailed audit logs are exportable, which supports the evidence side of controls 5.18 and 8.15.

Plans are tiered by the number of users in the managed directory and organization size, and every subscription starts with a 14-day free trial. Published prices on the pricing page are:

Plan	Monthly	Yearly
Startup	$49.99 per month	$249.99 per year
Scale	$199.99 per month	$999.99 per year
Enterprise	Contact for pricing	Contact for pricing

One caution: a sync tool supports your controls but does not make you compliant. You still need the policy, approvals, reviews and management oversight described above.

Perspective: why read-only and logs matter for audits

We see the same pattern in teams preparing for an ISO 27001 audit. The access policy is written, the identity provider is configured, and the gap sits in the middle: dozens of applications with accounts that someone has to create and remove by hand.

Two design decisions follow from that. First, a provisioning tool should read from your directory and never write to it. If the tool that syncs your users can also change them in Google Workspace, it becomes another privileged system that you must review under control 8.2. A read-only connection keeps the directory as the single, controlled place where access decisions are made. Second, the log has to be usable by an auditor. A record of every create, update and deactivate event, exportable on demand, lets you answer a sampling request in minutes rather than assembling screenshots.

We also think the offboarding test deserves more attention than it gets. Disabling an account is an action. Showing that every downstream account was deactivated afterward is evidence. Build the process so the second follows from the first automatically.

— Nicolas

Evidence checklist for your next audit

Prepare these items before the auditor asks. Each maps to the controls above.

Approved access control policy and topic-specific policies, with version and approval date.
Role and group definitions, and the mapping from groups to application roles.
A current list of all applications in scope and how each receives provisioning (SCIM, manual or single sign-on only).
A list of privileged accounts with approvers and last review date.
Completed access reviews with outcomes and corrections.
An exception register with justification, approver and review date.
Leaver samples showing the departure date and the deactivation date in each downstream app.
Exported provisioning and administrative logs, with proof of how they are protected.
MFA and sign-in policy settings.

Keep these in a single evidence folder organized by control. It shortens the audit and makes internal reviews easier.

How ISO 27001 relates to NIST

US readers often ask whether to follow ISO 27001 or NIST. The two are not rivals. ISO 27001 is a flexible, risk-based management framework recognized worldwide. NIST SP 800-53 is a detailed catalog of security and privacy controls often used by US federal agencies, and its Revision 5 publication covers access control in its own family. Organizations often map one to the other and use both. If you already run access reviews and leaver testing for one, most of the evidence carries over.

Common mistakes to avoid

Treating the access policy as a one-time document and never reviewing it.
Granting broad roles for convenience and promising to tighten them later.
Keeping shared admin accounts that hide who performed an action.
Leaving contractors and service accounts out of reviews.
Reviewing access by looking only at the directory, not at what each application actually holds.
Granting an exception first and writing the justification afterward.

FAQ

Is ISO 27001 a legal requirement?

No. ISO states that the standard is voluntary and certification is not referred to in the standard itself. Some contracts, customers and sector rules may still require it or an equivalent, so check your agreements.

Which control covers access control in ISO 27001:2022?

Annex A 5.15 is the main control. It works together with 5.16 on identity management, 5.18 on access rights and 8.2 on privileged access rights. Auditors usually test them as one process.

How often should access rights be reviewed?

The standard sets no fixed interval. Base the frequency on risk: data sensitivity, privilege level, staff turnover and rate of system change. Privileged roles should be reviewed more often than low-risk access, and the intervals should be written into your policy.

Is disabling a user in Google Workspace enough for offboarding?

Not by itself. Auditors look for proof that access is revoked in downstream applications, including active sessions and tokens. Provisioning through SCIM, plus a logged record of each deactivation, gives you that proof.

Is ISO 27001 outdated?

No. The current edition is ISO/IEC 27001:2022, published in October 2022. Organizations certified to the earlier edition move to the 2022 requirements, including its reorganized Annex A controls.