ISO 27001 A.5.15: Access control
Access rules should explain who may reach information and associated assets, for what purpose, and under whose authority. The review needs to cover physical and logical access within the ISMS scope. Start with the sensitive information and systems, then check how a person or service gains and loses access to them.
Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.
Requirement summary
Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements.
Check the source wording and scope in ISO/IEC 27001:2022. The guidance below explains how to approach a review.
In Plain Language
The policy is only the starting evidence. Compare it with actual permissions and recent decisions. A role description may say that support staff can view records while a inherited group grants export or administrative rights. Review the effective access, including nested groups, direct grants and emergency accounts.
The level of control should follow the risk and business need. Role-based access can be useful where job functions are stable; other systems may need attributes, per-resource rules or additional approval. Neither a particular access model nor a commercial privileged-access product is a universal requirement. What matters is that the rules are justified, implemented and checked.
A.5.15 establishes the rules. Read it alongside the controls on identity management, authentication information and access rights, then examine how the lifecycle works from a real request to eventual removal. A person changing jobs inside the company is as important to that review as a new starter or leaver.
How to Implement
Identify the systems, information stores and physical areas covered by the access policy. Record the owner who can approve access and the evidence needed for that decision. Include administrators, service identities, supplier access and emergency access. Document exceptions so a reviewer can distinguish a deliberate decision from an accidental permission.
For each important system, trace a sample of access requests through approval and implementation. Compare the requested permission with the permission actually granted. Check whether a reviewer can establish who made the decision and why it was appropriate. Where the same person requests and grants access, assess the risk and any compensating review instead of assuming a larger organisation's workflow will fit.
Test changes and removal using recent examples. Check connected and standalone systems, physical entry, tokens and supplier accounts where relevant. An identity-provider disablement may not revoke a separate account or an active session. Establish what the offboarding procedure actually reaches and how exceptions are followed up.
Set review frequency using sensitivity, privilege, staff turnover and the rate of system change. A critical administrative role may need more frequent review than access to low-risk internal material. Define triggers for an earlier check, such as a role change or suspected misuse. The review should record decisions and resulting changes, not merely a list of users signed off without challenge.
Verify that corrective actions took effect. If a reviewer removes a permission, confirm the actual entitlement changed. If access must remain as an exception, retain the reason, approver and review point. Repeat the sample after a material change to the access model.
Evidence to review
- Access policy with system scope and decision authority
- Role or permission definitions for the systems reviewed
- Sample access requests, approvals and effective permissions
- Joiner, mover and leaver records across connected and standalone systems
- Administrative, service and supplier-account access records
- Review decisions and evidence that removals took effect
- Exceptions with a reason, approver and review point
Common Mistakes
- A policy describes intended access but has not been compared with effective permissions
- Role changes add new permissions without removing old ones
- Reviews sign off lists without recording decisions or following up changes
- Offboarding misses standalone accounts, service credentials or physical access
- Emergency access remains available after the incident with no follow-up review
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| SOC 2 | SOC 2 CC6.1: Logical and Physical Access - Security Software, Infrastructure, and Architectures | Equivalent |
| SOC 2 | SOC 2 CC6.2: Logical and Physical Access - User Registration and Authorization | Related |
| SOC 2 | SOC 2 CC6.3: Logical and Physical Access - Role-Based Access and Least Privilege | Related |
| GDPR | GDPR Art.32: Security of Processing | Related |
| NIS2 | NIS2 Art.21(2)(i): Human Resources Security and Access Control Policies | Related |
Frequently Asked Questions
Must we use RBAC or a privileged-access tool?
How often should access be reviewed?
Related Articles
Compliance Costs: Budgeting for DIY, Consulting and Software
Compare staff time, audit fees, consulting, software and remediation without treating different services as interchangeable.
Read article →ISO 27001 Certification Cost: Build a Budget from Your Scope
Separate certification fees, preparation, staff time and remediation. Learn what to include in a quote request and a first-year ISO 27001 budget.
Read article →How to Get ISO 27001 Certified: A Step-by-Step Guide
A practical walkthrough of the ISO 27001 certification process - from scoping to stage 2 audit. Covers timelines, costs, common mistakes, and what auditors actually look for.
Read article →Track ISO 27001 compliance in one place
Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.
Start Free AssessmentStart without an account · Sign up only to save