ISO 27001 Access Control Policy Annex A 5.15

Introduction

In ISO 27001:2022, the Access Control Policy is captured under Annex A 5.15 and sits at the centre of your whole access management model. In your Comply Agent configuration, this is represented by the “Access control” control (ID: UC‑AC‑815) within the Access Control category and Policy and Procedures subcategory. The description states that the organisation must “establish and implement access control rules based on business requirements, including the principle of least privilege and need‑to‑know, and formal authorization processes,” and that documentation for access control policies and standards must be maintained.

The objective of this control is “to ensure that access to information and systems is appropriately restricted and managed according to business requirements and security policies.” This makes clear that the Access Control Policy is not just a document written for the audit; it is the rulebook that drives how identities, roles, and permissions are actually configured across systems, applications, and networks. Your Basic Information screenshot neatly shows all of this in a single pane, mapping business language directly to ISO 27001 Annex A 5.15.

Implementation & Guidance

Your Implementation & Guidance section sets a clear expectation for how this policy becomes operational:

“Develop and maintain a comprehensive Access Control Policy that defines rules for access, roles and responsibilities, and authorization procedures. Regularly review and update access rights based on job roles and business needs, enforcing the principle of least privilege.”

This breaks down into several practical implementation steps.

1. Define access control principles

At policy level, you need to explicitly state:

• Least privilege – users receive only the minimum access required to perform their job.
• Need‑to‑know – access to sensitive data is granted only when there is a legitimate, documented business purpose.
• Segregation of duties – critical processes (like payment approval or user provisioning) cannot be fully executed by a single person.
• Accountability – all access must be tied to unique, identifiable accounts rather than shared credentials.

These principles should be written into the Access Control Policy and mirrored in supporting standards or technical baselines (for AD groups, application roles, firewall rules, etc.).

2. Roles, responsibilities, and ownership

Your guidance explicitly calls out “roles and responsibilities”. A strong policy should identify:

• Control owner – in your configuration, this is the CISO, responsible for maintaining the policy and ensuring it’s followed.
• System and data owners – accountable for deciding who should have access to their systems and data.
• IT / IAM team – responsible for enforcing technical controls (group membership, ACLs, firewall rules) in line with the policy.
• HR and line managers – responsible for triggering joiner/mover/leaver events and validating that access matches job roles.

Documenting this in the policy avoids gaps where everyone assumes someone else is responsible.

3. Access request and authorisation procedures

The guidance’s mention of “authorization procedures” means your policy should:

• Require all access changes to be requested via a controlled channel (ITSM ticket, access portal, or IAM workflow).
• Specify which roles must approve particular types of access (line manager, system owner, data protection officer for high‑risk data, etc.).
• Differentiate between standard, privileged, and emergency access, with stricter workflows for higher‑risk access.
• Include rules for third‑party and remote access, including contractual and MFA requirements.

Your evidence examples—“Access request and approval workflows/records” and “Regular access review reports and remediation actions”—show that Comply Agent expects these authorisation rules to be both documented and provably executed.

4. Role‑based access and mapping to job functions

To keep the policy actionable, you should define or reference role‑based access models:

• Define business roles (e.g., “HR Analyst”, “Finance AP Clerk”, “Customer Support Agent”).
• Map each role to access privileges in key systems.
• Document exceptions and temporary access rules.

The policy doesn’t need every technical detail, but it should point to standards or matrices that define what each role can and cannot access.

5. Periodic access reviews and remediation

Your guidance calls for “regular access review reports and remediation actions.” The policy should therefore mandate:

• Review frequency (e.g., quarterly for critical systems, at least annually for others).
• Review responsibilities (system/data owner signs off).
• Criteria for revoking or adjusting access (no longer required, role changed, dormant accounts).
• How remediation is tracked and reported (tickets, Comply Agent tasks, or IAM campaigns).

Operational Details

The Operational Details screenshot for this control shows:

• Frequency: Quarterly
• Review Cycle: Quarterly
• Owner Role: CISO
• Responsible Role: CISO
• Automation Score: 60%
• Last Updated: 23 March 2026, 10:50:46 PM

This configuration demonstrates that access control is treated as an ongoing governance activity rather than a one‑time document update. A quarterly frequency means:

• Policy and related standards are checked regularly against new systems, business models, and regulatory changes.
• Access review outcomes, audit findings, and incidents are quickly fed back into policy improvements.

Having the CISO as both owner and responsible role is appropriate for a cross‑cutting, organisation‑wide policy like Annex A 5.15; technical teams and system owners implement the details, but the overarching rules come from information security leadership.

The 60% automation score suggests you already have some automated support in place, for example:

• Centralised access logs and review dashboards.
• Auto‑collected configuration snapshots (ACLs, group memberships).
• Workflow engines for access requests and approvals.

Raising this automation level over time (e.g., via IAM integration, policy‑as‑code for infrastructure, and automated review campaigns) will further strengthen evidence for auditors and reduce manual overhead.

Compliance & Risk Management

In your Compliance & Risk Management panel, the control is described as:

• Control Type: Administrative
• Risk Domain: Unauthorised Access
• Maturity Level: 4
• Compliance Status: N/A
• Clause Reference: ISO 27001:2022 A.5.15

Classifying it as an Administrative control recognises that access control at this level is primarily about rules, processes, and governance rather than specific technologies. The policy sets expectations that are then enforced by identity management, privileged access, network segmentation, and application‑level controls.

The Unauthorised Access domain aligns this policy with downstream technical controls (identity management, access rights, privileged access, network ACLs). A Maturity Level 4 rating indicates:

• A formal, approved policy and supporting procedures exist.
• Roles and responsibilities are clearly defined.
• Evidence from actual operations (access requests, logs, configuration files, reviews) regularly feeds into policy improvements.
• Metrics or KPIs (e.g., percentage of access with documented approvals, age of unreviewed access, exceptions) are monitored.

This is exactly the maturity level certifying auditors expect from a modern ISO 27001 implementation.

Framework Mappings

Your Framework Mappings view shows how this single Access Control Policy supports multiple frameworks:

• ISO 27001: A.5.15 Access control (exact) – the primary clause requiring defined access rules and policy.
• SOC 2: CC6.1 (partial) – requires logical access security, including policies for authorising and restricting access based on job responsibilities.
• GDPR: Article 32 (related) – demands appropriate technical and organisational measures, including access control, to ensure security of personal data.
• DORA (enriched) – Article 10 (ICT risk management) and Article 11 (ICT‑related incident management) both depend on clear access governance for critical systems.
• NIST CSF (enriched) – PR.AC‑1 and PR.AC‑4, which cover identity and access management and access enforcement under the Protect function.

This mapping helps you position the Access Control Policy as a single source of truth that satisfies client due diligence questionnaires and regulatory expectations across multiple frameworks, rather than maintaining separate, inconsistent policy sets.

Evidence Library

The Evidence Library for this control contains three core artefact types:

1. Policy Document
   Your primary Access Control Policy and related standards or procedures. This shows how you interpret Annex A 5.15 and translate it into concrete, enforceable rules.
   
   
2. Configuration Files (auto‑collect)
   Access Control Lists (ACLs) from systems, applications and network devices (e.g., AD group memberships, firewall rules, Azure AD role assignments, GitHub repo permissions). Auto‑collection means Comply Agent can periodically ingest and archive these configurations, proving that real‑world settings match policy intent.
   
   
3. Access Logs (auto‑collect)
   Logs demonstrating access reviews and authorisation workflows, usually from SIEM platforms or IAM systems. These can include who approved what, when access was granted or revoked, and evidence of review campaigns.

Together, these artefacts give you:

• Design evidence (policy document).
• Implementation evidence (configuration files/ACL snapshots).
• Operating effectiveness evidence (access logs and review records).

This trilogy aligns tightly with what ISO 27001 auditors look for when testing Annex A 5.15.

FAQs: Access Control Policy ISO 27001 (Annex A 5.15)

1. What does ISO 27001 Annex A 5.15 “Access control” actually require?

Annex A 5.15 requires organisations to establish and implement rules that govern who can access information, systems, applications, networks and physical locations, based on business need and risk, and to keep those rules documented and regularly reviewed.

2. How is an Access Control Policy different from Identity or Access Rights controls (A.5.16 and A.5.18)?

A.5.15 defines the overall access control framework and policy rules; A.5.16 governs how identities are created and managed; A.5.18 governs how specific access rights are assigned, reviewed and revoked for those identities. Together they form a complete access management model.

3. What should an ISO 27001‑compliant Access Control Policy include?

It should define access principles (need‑to‑know, least privilege, segregation of duties), roles and responsibilities, request and approval procedures, role‑based access rules, requirements for remote and third‑party access, ties to information classification, and requirements for monitoring and periodic access reviews.

4. How often should the Access Control Policy be reviewed?

Best practice is at least annually or when there are major changes in systems, organisation, or risk profile. Your Comply Agent configuration uses a quarterly review cycle owned by the CISO, which comfortably exceeds typical ISO 27001 expectations.

5. What evidence do auditors expect for Annex A 5.15?

Auditors usually ask for the approved Access Control Policy and procedures, access request and approval records, configuration files or ACLs from key systems and network devices, and access logs showing that reviews and authorisation workflows are enforced in practice.

6. How does an Access Control Policy support other regulations like GDPR and DORA?

A strong Access Control Policy demonstrates how access is restricted and justified for personal and critical data, helping meet GDPR Article 32 and DORA requirements for ICT risk and incident management, user access control, and protection of confidential information.