ISO 27001 A.5.15: Access Control

ISO 27001 A.5.15 requires an organization to establish and maintain an access control policy that governs who may reach information and systems, based on business and information security requirements. It is an Organizational control (A.5), and teams most often get flagged on a missing document rather than a technical gap: access is granted case by case with no written policy stating the rules everyone is supposed to follow.

What is ISO 27001 A.5.15?

ISO 27001 A.5.15 Access control is the policy-level control for access across the ISMS. ISO/IEC 27001:2022, Annex A frames it around establishing rules for physical and logical access to information and other associated assets, based on business requirements and information security requirements. It is the control that says the organization must decide, in writing, how access is granted, changed, reviewed, and removed, and on what basis.

A.5.15 governs the rules rather than the mechanisms. It asks for a documented access control policy that sets the principles: need-to-know (users see only the information their tasks require), need-to-use (users reach only the systems their tasks require), least privilege, role-based access, segregation of duties, and how access rights get requested and approved. The controls that carry those rules out live elsewhere in Annex A. A.5.15 is where the organization writes down what appropriate access means before any system enforces it.

How do you implement A.5.15?

Implementing A.5.15 is a documentation and decision exercise rather than a tooling project. The policy is environment-agnostic; the same rules apply whether identities live in an identity provider or Active Directory. The sequence a team runs:

1. Write the access control policy tied to business and security requirements. State the purpose of access control, the assets in scope, and the principles the organization commits to: least privilege, need-to-know, and need-to-use. Reference the risk assessment so the policy is grounded in requirements rather than asserted in the abstract.
2. Define need-to-know and need-to-use explicitly. Name the rule that a user receives access to information (need-to-know) and to systems (need-to-use) only where a task requires it. This is the principle every later access decision is measured against.
3. Choose the access model: RBAC first, ABAC where it fits. Role-based access control (access mapped to defined job roles) is typically the default because it is the cleanest to document and audit. Attribute-based or dynamic access control (access decided at request time from attributes such as device posture, location, or data sensitivity) applies where a static role cannot capture the decision. State in the policy which model governs which systems.
4. Set the rules for requesting, approving, and reviewing access. Document who can request access, who approves it, what justification is required, and how often access is reviewed. The policy defines the process; the records that process produces are the evidence.
5. Cover physical and logical access in one policy. A.5.15 spans both. Align the rules so that physical entry to facilities and logical access to systems follow the same need-to-know and approval logic rather than being governed by two disconnected documents.
6. Enforce segregation of duties in the rules. State which combinations of access are incompatible (for example, the same person requesting and approving their own access, or developing and deploying to production unchecked) and how the organization separates or compensates for them on the team it has.

In cloud environments

Cloud environments carry the A.5.15 access control policy into identity provider configuration, so the written rules and the enforced configuration match:

• IdP groups mapped to policy roles. The RBAC roles named in the access control policy become groups in the identity provider (Okta, Entra ID, Google Workspace), so a role in the document corresponds to a group that grants access.
• SSO as the single enforcement point. Access to downstream applications flows through one identity, so the need-to-use rule is applied and evidenced in one place.
• Policy-as-config for dynamic access. Conditional access and attribute-based rules (device posture, location, group membership) implement the ABAC portion of the policy as version-controlled configuration that can be exported as evidence. Wiring that exported configuration into continuous evidence collection is the kind of work GRC engineering covers.
• Access requests through a documented workflow. Access request and approval run through a ticketing or IdP request flow that captures the requester, approver, and justification the policy requires.

On-prem / self-hosted

On-prem environments carry the same A.5.15 access control policy into directory and local-system configuration. The SOC 2 access control on-prem guide covers the full implementation; the shape is:

• AD groups and GPOs enforce the roles. The policy roles become Active Directory groups, and Group Policy Objects push the access and session rules to domain-joined systems.
• Documented local exceptions. Systems that cannot join the domain get named local accounts governed by the same policy, with an inventory recording why directory integration is unavailable and what compensating rule applies.
• A defined approval path in writing. Because the enforcement is spread across heterogeneous systems, the policy carries more weight: it names the single request-and-approval process that applies before access is provisioned on any system.

Cloud vs on-prem at a glance

What evidence demonstrates A.5.15?

Evidence for A.5.15 is led by the access control policy document, supported by the records that show the policy is followed rather than filed.

How does A.5.15 map to SOC 2?

A.5.15 is a Full overlap with SOC 2 CC6.1 and CC6.3. Organizations with an existing SOC 2 program can reuse the access control policy, role definitions, and access review records for the ISO 27001 certification audit without adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, and the SOC 2 to ISO 27001 reuse guide covers how much of an existing SOC 2 program transfers.

Related controls

A.5.15 sets the access control policy; the controls that carry it out surround it. A.5.16 Identity management covers the identities the policy grants access to, and A.5.18 Access rights covers the lifecycle of provisioning, changing, and revoking those rights against the policy. A.8.2 Privileged access rights is the mechanism for the elevated access the policy restricts most tightly, and A.8.3 Information access restriction is the technical enforcement of the need-to-know rule at the data layer. A.5.15 is the policy; A.5.18 and A.8.2 are the mechanisms. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are writing your access control policy as part of an effective security program and want a second set of eyes on the design, Truvo runs scoping calls.

Frequently Asked Questions

What is ISO 27001 A.5.15?

ISO 27001 A.5.15 Access control is an Organizational control in Annex A of ISO/IEC 27001:2022. It requires an organization to establish and maintain an access control policy for physical and logical access, based on business and information security requirements. It sets the rules, including least privilege, need-to-know, need-to-use, and role-based access, rather than the technical mechanisms that enforce them.

What evidence satisfies A.5.15?

A.5.15 evidence is led by the access control policy document, supported by records that show the policy operates. Auditors expect the approved policy, RBAC role definitions reflecting least privilege and need-to-know, access request and approval records with justification, and periodic access review records. The records are what demonstrate the policy is followed rather than only filed.

What is the difference between A.5.15 and A.5.18?

A.5.15 is the policy control: it establishes the rules for access, including least privilege, need-to-know, and role-based access. A.5.18 Access rights is the lifecycle control: it covers provisioning, modifying, reviewing, and revoking access rights in line with the A.5.15 policy. A.5.15 defines what appropriate access means; A.5.18 grants and removes it.

What is the difference between A.5.15 and A.8.2?

A.5.15 sets the overall access control policy for all users and systems. A.8.2 Privileged access rights is the more specific mechanism control for elevated access, such as administrator and root accounts, which the A.5.15 policy restricts most tightly. A.5.15 states the principle; A.8.2 implements the tighter controls, allocation, and review for privileged accounts.

Is A.5.15 a new control in ISO 27001:2022?

No. A.5.15 is not new to the 2022 revision. It merges two controls from the 2013 version, A.9.1.1 (access control policy) and A.9.1.2 (access to networks and network services), into a single Organizational control. The merge reduced the control count while keeping the requirement for a documented, business-driven access control policy.

Does A.5.15 require role-based access control?

A.5.15 does not mandate a single access model, but role-based access control is the common way to satisfy it because it is the cleanest to document and audit. The policy should state which model governs which systems. Attribute-based or dynamic access control applies where a static role cannot capture the access decision, such as rules based on device posture or location.