ISO 27001 Annex A 5.15 Access Control + Policy Template

ISO 27001 Access Control

ISO 27001 Annex A 5.15 Access Control is an ISO 27001 control that requires an organisation to implement the control of access to information and other assets based on business and information security requirements.

Key Takeaways

ISO 27001 Annex A 5.15 requires organisations to establish and implement rules for controlling both physical and logical access to information and other associated assets. Access control is a fundamental “preventive” security measure; it ensures that only authorised individuals and entities (like software services or machines) can interact with sensitive data. By applying the principle of Least Privilege, you minimise the risk of accidental data leaks, internal fraud, and external compromise.

Purpose

The purpose of ISO 27001 Annex A 5.15 is a preventive control that ensures authorised access and to prevent unauthorised access to information and other associated assets.

Definition

The ISO 27001 standard defines ISO 27001 Annex A 5.15 as:

Rules to control physical and logical access to information and other associated assets should be established

ISO 27001:2022 Annex A 5.15 Access Control

Explanation

ISO 27001 Annex A 5.15 Access Control is a security control that establishes rules to govern physical and logical access. By mandating the implementation of role-based access restrictions, it ensures only authorised entities interact with sensitive assets, delivering the critical reduction of internal fraud and external breach risks.

Core requirements for compliance

• Access Control Policy: You must have a documented topic-specific policy that outlines the organization’s rules for granting, reviewing, and revoking access.
• Asset Integration: You cannot control what you don’t know. Your access rules must be directly linked to your Asset Register (A.5.9) and Information Classification (A.5.12).
• Need-to-Know vs. Need-to-Use: Access should only be granted based on a clear business requirement to perform a job function (Need-to-Know) or a specific task (Need-to-Use).
• Role-Based Access Control (RBAC): For efficiency and consistency, access is best managed by assigning permissions to “Roles” (e.g., HR Manager) rather than individual users.
• Entities Coverage: The control applies not just to humans, but also to “entities” such as automated service accounts, APIs, and connected devices.
• Continuous Review: Access rights must be reviewed periodically (at least annually) to prevent “Privilege Creep,” where users accumulate unnecessary permissions over time.

Audit Focus

1. Approval Logs: “Show me the request and approval for the last person given access to the Finance system. Who authorized it?”
2. The Leaver Test: “Show me a list of employees who left in the last 3 months. Can you prove their access to the VPN and SaaS tools was revoked on their final day?”
3. Third-Party Access: “How do you manage access for your external IT consultants? Is it permanently open, or granted only when a fix is needed?”

FREE Training Video

In this free training video you will learn How to implement ISO 27001 Access Control (Annex A 5.15) and Pass Your Audit.

Implementation Guide

The control of access to information and other assets is going to require a topic specific ISO 27001 Access Control Policy. To implement control of access you are going to have to first identify what you have. We cannot control it if we do not know we have it so before you move on to access control be sure first to have completed your asset registers. We covered asset inventories in ISO 27001 Annex A 5.9 Inventory Of Information And Other Associated Assets.

Once you know what you have you are going to implement information classification which we covered in ISO 27001 Annex A 5.12 Classification Of Information. This is going to set out the classification levels of the organisation and the controls and restrictions for each classification.

The standard wants you to implement access control rules by defining and mapping appropriate access rights and restrictions to relevant entities. What it means by entities is the things that are doing the access which includes humans and also logical items such as services, devices and machines.

Access Control Principles

The principles on access control usually fall in to mainstream camps of thinking. They are:

Need to know

Need to know is the principle that you grant access to the information required to perform the tasks and duties.

Need to use

Need to use is the principle of granting access where a clear need is present

Let’s be fair the difference is subtle and barely material in that you grant access to what people need. You will not be quizzed on this and a simpler way to look at it is, do not give people access to things they don’t need.

Access Control Methodologies

There is no one right way to implement access control although the most common is role based access. It is the most common as it most often the most simple. The list of access control methodologies is

• MAC – mandatory access control
• DAC – discretionary access control
• RBAC – role based access control
• ABAC – attribute based access control

Access Control Granularity

The level of granularity of access control is based on your business and business risk. It is a wide range with examples of covering entire networks or systems all the way down to restricting access to individual fields. You can consider factors such as locations or how people connect or who connects from teams to individuals.

The level of granularity has a direct correlation on cost and security.

The more granular you are the more cost you will incur in time and resources but the more secure you will be.

The less granular you are then the less cost in time and resources but the more insecure (potentially) you will be.

The art is to find the balance that is right for you.

Access Matrix Example

Role	HR System	Finance System	IT Admin Panel	ISO 27001:2022 Control
HR Manager	Read/Write	Read Only (Payroll)	No Access	Annex A 5.15 / 5.18
Finance Clerk	No Access	Read/Write	No Access	Annex A 5.15 / 5.18
IT Admin	No Access	No Access	Full Control	Annex A 5.15 / 8.15
Standard User	Read Self (Profile)	No Access	No Access	Annex A 5.15

Considerations when implementing access control

Let us take a look at considerations when defining and implementing access control rules

• Working to the principle of least privilege which means we restrict access to everything unless needed as opposed to the principle of everyone has access to everything unless forbidden.
• Account for automation in process and technology where permissions are changed automatically
• Implement a review of the approval processes at least annually or based on significant change
• It is important to ensure we are consistent in our approach to both access rights and information classification
• Physical perimeter security should be considered if it is appropriate and to be consistent with access rights
• Where dynamic access control is in play to consider the factors and elements and how they can be reflected

Steps in implementing access control

You are going to have to

• Establish and communicate a topic specific ISO 27001 Access Control Policy
• Complete your physical and virtual asset register
• Complete your data asset register
• Decide on your access control methodology / approach
• Implement your access control

Access Control Policy Template

The access control policy sets our your approach to access control.

How to implement it

Implementing ISO 27001 Annex A 5.15 is about more than just setting passwords: it is about governing the entire lifecycle of access to your organisation’s information assets. As a Lead Auditor, I expect to see a robust framework where access is granted based on business necessity and strictly enforced through technical controls. Follow these ten steps to build a compliant and secure access control environment.

1. Formalise the Access Control Policy

Create a comprehensive policy document that defines the rules for both logical and physical access across the organisation. This policy serves as your “Source of Truth” during an audit and must be approved by senior management. Requirements include:

• Defining access rules based on the “Need to Know” and “Least Privilege” principles.
• Establishing clear guidelines for different classifications of information.
• Distinguishing between standard user access and administrative privileges.

2. Map Roles to the Asset Register

Consult your Asset Register to identify every information asset and its respective owner. This step ensures that access is authorised by the person responsible for the data, rather than IT acting in isolation. Requirements include:

• Identifying all software, hardware, and data assets within the ISMS scope.
• Assigning an Asset Owner to every entry in the register.
• Documenting which job roles require access to specific assets to perform their duties.

3. Standardise User Registration and De-registration

Establish a formal workflow for the onboarding and offboarding of employees, contractors, and third parties. This process prevents “Shadow Access” where accounts are created without proper oversight. Requirements include:

• Implementing a Joiner process that verifies identity before provisioning unique IDs.
• Ensuring a Leaver process that revokes all access immediately upon termination of employment.
• Maintaining a Record of Evidence (ROE) for all registration and de-registration activities.

4. Provision Access via Role-Based Access Control (RBAC)

Use an RBAC model to provision access rights based on job functions rather than individual requests. This ensures consistency and reduces the risk of excessive permissions. Requirements include:

• Creating IAM (Identity and Access Management) roles that mirror organisational positions.
• Ensuring that access is only provisioned after formal authorisation from the Asset Owner.
• Verifying that temporary access for contractors is set to expire automatically.

5. Segregate Privileged Access Rights

Strictly control accounts with elevated permissions, such as Domain Admins or Superusers, as these represent the highest security risk. Privileged access must be handled via a separate, audited process. Requirements include:

• Provisioning dedicated administrative accounts that are separate from standard user accounts.
• Restricting privileged access to the absolute minimum number of individuals.
• Implementing a “Just-In-Time” (JIT) access model for sensitive configuration changes.

6. Enforce Strong Authentication and MFA

Implement technical controls to verify the identity of users attempting to access the network. Multi-Factor Authentication (MFA) is a mandatory requirement for remote and privileged access. Requirements include:

• Mandating MFA for all external access via VPN or cloud services.
• Setting minimum password complexity and rotation requirements in line with industry standards.
• Prohibiting the use of shared or generic accounts for any information asset.

7. Configure Resource-Level Restrictions

Apply technical “Read, Write, and Delete” permissions at the file and database level to enforce the policy. This ensures that even if a user is on the network, they can only interact with data relevant to their role. Requirements include:

• Configuring Access Control Lists (ACLs) on all file servers and cloud storage.
• Restricting access to specific applications and functions based on user roles.
• Verifying that “Everyone” or “Guest” access is disabled on all internal resources.

8. Execute Quarterly User Access Reviews

Perform regular “re-certification” of user access rights to ensure permissions remain appropriate as the organisation evolves. This is a critical check for an ISO 27001 auditor. Requirements include:

• Distributing user lists to Asset Owners for periodic verification and sign-off.
• Removing access for any users who no longer have a valid business requirement.
• Documenting the review process and the results in an Audit ROE.

9. Automate Account Adjustment for Movers

Update access rights immediately when an individual changes roles within the organisation to prevent “Privilege Creep.” This ensures that old permissions are removed when they are no longer needed. Requirements include:

• Triggering an access review whenever a user’s department or job title changes in HR systems.
• Revoking old permissions before granting new ones to ensure “Least Privilege.”
• Reviewing and adjusting physical access rights (e.g., key cards) for internal movers.

10. Document the Control Environment in an ROE

Maintain a centralised Record of Evidence (ROE) that proves your access controls are functioning as intended. Without documentation, you cannot prove compliance to an external auditor. Requirements include:

• Collecting logs of account creation, modification, and deletion.
• Storing signed authorisation forms and quarterly review sign-offs.
• Maintaining a history of MFA enrolment and privileged access logs for at least 12 months.

How to comply

To comply with ISO 27001 Annex A 5.15 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to

• Implement and ISO 27001 Access Control Policy
• Complete your physical and virtual asset register
• Complete your data asset register
• Decide on your access control methodology / approach
• Implement your access control

How to audit ISO 27001 Annex A 5.15

Auditing ISO 27001 Annex A 5.15 requires a rigorous examination of how your organisation manages the full lifecycle of user access. As a Lead Auditor, I look for evidence that access is not merely granted, but is governed by business necessity and strictly enforced through technical controls. Follow these ten steps to ensure your access control environment meets the required standard of compliance.

1. Review the Formal Access Control Policy

Examine the overarching policy documentation to ensure it aligns with business requirements and risk assessments. A successful audit outcome confirms that the policy defines clear rules for both logical and physical access across all information assets. Requirements include:

• Verification that the policy is approved by senior management.
• Confirmation that access rules are based on the “Need to Know” and “Least Privilege” principles.
• Evidence of regular policy updates to reflect changes in the technical environment.

2. Validate the Asset Register and Ownership

Cross-reference your access controls with the central Asset Register to ensure every information asset has a designated owner. This step ensures that access is authorised by the individual responsible for the data. Requirements include:

• Evidence that asset owners have defined access levels for their respective assets.
• Verification that the Asset Register is accurate and up to date.
• Mapping of user roles to specific asset classifications.

3. Audit the Joiner Process and Initial Provisioning

Inspect the workflow for new employees or contractors to verify that access is only granted through a formalised process. This prevents “shadow access” where accounts are created without proper oversight. Requirements include:

• Review of HR records against IAM (Identity and Access Management) logs.
• Verification of signed non-disclosure agreements before access is provisioned.
• Confirmation that unique user IDs are assigned to every individual.

4. Evaluate the Mover Process and Role Changes

Assess how access rights are adjusted when an individual changes roles within the organisation. This prevents “privilege creep,” where users retain old permissions that are no longer required. Requirements include:

• Evidence of a formal notification system between HR and IT for internal transfers.
• Verification that old permissions are revoked before new ones are granted.
• Review of recent “Mover” tickets to ensure no residual access remains.

5. Verify the Leaver Process and Immediate Revocation

Test the effectiveness of the termination process to ensure access is revoked immediately upon departure. This is a critical security step to prevent unauthorised access by former personnel. Requirements include:

• Checking timestamps of account deactivation against the employee’s final working day.
• Verification that physical access tokens or keys were collected.
• Confirmation that remote access and VPN accounts are disabled.

6. Inspect Privileged Access Management (PAM)

Conduct a deep dive into accounts with elevated permissions, such as Domain Admins or Superusers. These accounts represent the highest risk to the organisation and require stricter controls. Requirements include:

• Evidence that privileged access is restricted to the absolute minimum number of users.
• Verification that administrative tasks are performed using dedicated admin accounts rather than standard user accounts.
• Review of the authorisation logs for granting temporary elevated rights.

7. Test Authentication and MFA Enforcement

Verify that the technical implementation of authentication matches the policy requirements. Multi-Factor Authentication (MFA) is now a baseline expectation for ISO 27001 compliance. Requirements include:

• Verification that MFA is active for all remote and privileged access points.
• Testing password complexity and rotation settings in Active Directory or Cloud Identity providers.
• Ensuring that default vendor passwords have been changed on all hardware and software.

8. Review Resource Access Restrictions

Examine the technical configuration of folders, databases, and applications to ensure users can only access what is necessary for their role. This validates the technical enforcement of the policy. Requirements include:

• Sampling folder permissions on file shares to check for “Everyone” or “Authenticated User” groups with excessive rights.
• Verifying database-level permissions for sensitive customer or financial data.
• Reviewing Role-Based Access Control (RBAC) configurations in SaaS applications.

9. Confirm Periodic Access Reviews

Check for evidence that management performs regular reviews of user access rights. This “re-certification” ensures that access remains appropriate over time. Requirements include:

• Review of the Record of Evidence (ROE) showing that asset owners have signed off on user lists.
• Verification that any discrepancies found during reviews were remediated promptly.
• Confirmation that the frequency of reviews matches the risk level of the asset.

10. Formalise the Audit Record of Evidence

Consolidate all findings into a structured report to demonstrate compliance to external auditors. A clear audit trail is essential for maintaining ISO 27001 certification. Requirements include:

• Compilation of all screenshots, logs, and ticket samples collected during the audit.
• Documentation of any non-conformities and the associated corrective action plans.
• Final sign-off by the Lead Auditor or Information Security Manager.

How to pass the audit

To pass an audit of ISO 27001 Annex A 5.15 you are going to make sure that you have followed the steps above in how to comply.

What the auditor will check

The audit is going to check a number of areas. Lets go through the most common

1. That you have not done something stupid

The auditor is going to check the rules, procedures and access control methodolgy and make sure you followed them. As with everything having documented evidence of anything you can is going to be your friend. So practical things like asset registers, access control procedures that you can evidence are in operation, reviews of access. Work through recent hires for example and ensure the processes were followed and look for the gotchas. Is there an approval audit trail. When you log into the system that was approved does the users access match what was requested

2. That you have rules, processes and you have followed them and have trained people

This is obvious but they are going to look that you have documented what you say you do, that you follow it and that you have trained people. The biggest gotcha here is having people with access that have left. In other words you didn’t have or follow a leaver process and so people’s access remain even though their contract has ended.

3. Documentation

They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match. Doing anything else would be a massive own goal.

Top 3 Mistakes People Make and How to Avoid Them

The top 3 Mistakes People Make For ISO 27001 Annex A 5.15 are

1. People have left but they still have access

Make sure that access to systems is up to date and that people or third parties that have left no longer have access.

2. Third parties have open access

Third parties should follow process and the process should be to grant access to them when the access required and remove it when it is not. It should not be open and continual access. Consider the example where you need a third party to fix something. You would grant access to allow the fix and then remove it. You would not have open ended access granted.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Applicable Laws and Related Standards

Standard / Law	Relevant Section	Relationship to Access Control (Annex A 5.15)
UK Data (Use and Access) Act 2025	Security of Processing	The UK’s evolution of GDPR. While it reduces “red tape” for some admin tasks, it maintains high security thresholds. Annex A 5.15 provides the “appropriate technical measures” required to protect personal data from unauthorised access.
Cyber Security and Resilience Bill (UK)	Supply Chain & MSP Security	The UK’s version of NIS2. It mandates that Managed Service Providers (MSPs) have strict access controls in place to prevent “pivot attacks” where a breach of the provider leads to a breach of the client.
NIS2 Directive (EU)	Article 21 (Cybersecurity Risk Management)	Mandates “Identity and Access Management” (IAM) as a core pillar. A 5.15 is the direct implementation of the “hygiene” and “training” requirements for entities in critical sectors.
DORA (Digital Operational Resilience Act)	Article 9 (ICT Security)	Specifically requires financial entities to implement “strict logical access” policies. A 5.15’s focus on role-based access control (RBAC) and least privilege is a non-negotiable requirement for DORA compliance.
GDPR (EU/UK)	Article 32 (Security of Processing)	Requires the “Confidentiality” of processing systems. Access control is the primary mechanism used to ensure that only authorised personnel can view or process PII (Personally Identifiable Information).
NIST Cybersecurity Framework (CSF) 2.0	PR.AA (Authentication and Authorisation)	NIST focuses heavily on Identity Management. A 5.15 maps directly to NIST’s requirements for verifying identities and authorising access based on risk and business need.
SOC2 (Trust Services Criteria)	CC6.0 (Logical and Physical Access)	SOC2 audits look for the exact same evidence as ISO 27001: request logs, approval workflows, and immediate revocation. A 5.15 is essentially the blueprint for SOC2’s access criteria.
CIRCIA (USA)	Incident Reporting Requirements	While CIRCIA focus is on reporting, poor access control is the leading cause of “reportable” incidents. A 5.15 acts as a preventive control to avoid the 72-hour reporting mandate triggered by unauthorised access.
EU Product Liability Directive (PLD)	Cybersecurity Flaws Liability	Extends strict liability to software providers. If a product lacks robust access control mechanisms (as defined in A 5.15), the provider can be held liable for damages resulting from cybersecurity flaws.
ECCF (European Cybersecurity Certification Framework)	Harmonised Security Labels	The framework uses ISO 27001 as a baseline. To achieve a “High” assurance level label, an organisation must demonstrate the “Least Privilege” and “MFA” requirements found in A 5.15.
EU AI Act / ISO/IEC 42001	Data Governance & Robustness	AI systems require strict data segmentation. A 5.15 ensures that “Training Data” is kept separate from “Production Data” and that only authorised Data Scientists can modify model weights.
HIPAA (USA)	§ 164.312 (Technical Safeguards)	For healthcare data, access control is a legal requirement. A 5.15 provides the framework for “Unique User Identification” and “Automatic Logoff” required by HIPAA.
CCPA / CPRA (California)	Right to Limit Use & Security	Requires businesses to implement reasonable security procedures. Implementing A 5.15 is considered “industry standard” evidence of fulfilling this legal duty to protect Californian residents’ data.

Applicability across different business models

Business Type	Applicability & Interpretation	Examples of Control
Small Businesses	Owner-Defined Rules. In small teams, “Roles” are often fluid. Compliance means defining clear, high-level rules (e.g., “Only the owner can approve payments”) rather than complex matrixes.	• The “Owner Approval” Rule: A policy stating that any access to the bank account or payroll system requires explicit approval from the Director. • Least Privilege: Defaulting all new email accounts to “Standard User” rather than “Administrator” to prevent accidental system-wide changes.
Tech Startups	RBAC & Attribute-Based Access. Startups must move away from “Everyone is Admin.” The focus is on Role-Based Access Control (RBAC) where permissions are linked to the job title, not the person.	• Role Definitions: Defining strict roles in your policy (e.g., “Junior Dev” has Read-Only access to Prod; “Senior Dev” has Deploy access). • Dynamic Access: Using Attribute-Based Access Control (ABAC) rules, such as “Developers can only access Production logs via the VPN during work hours.”
AI Companies	Data Segmentation Rules. Access control is critical for IP protection. The policy must strictly separate “Research/Training” environments from “Inference/Production” environments to prevent data leakage.	• Need-to-Know Datasets: A rule enforcing that Data Scientists only have access to the specific datasets required for their current project, not the entire Data Lake. • Service Account Rules: Mandating that automated training bots have “Write” access to model buckets but only “Read” access to raw customer PII.

FAQ

Related ISO 27001 Controls and Further Reading

• ISO 27001 Annex A 5.18 Access Rights: Annex A 5.18
• ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing
• The complete guide to ISO 27001 risk assessment

ISO 27001 controls and attribute values

Control type	Information security properties	Cybersecurity concepts	Security domains
Preventive	Confidentiality	Protect	Protection
	Integrity
	Availability

About the author