ISO 27001 Control 5.15: Access Control Requirements, Implementation, and Audit Guide

Every year, breach investigations trace the same root cause: someone had access they should not have had, and nobody noticed until data was already moving. Whether it is an orphaned service account, an overprivileged contractor, or a former employee whose credentials were never revoked, the failure is always the same — access was never governed as a business process. ISO 27001 Annex A 5.15 exists to close that gap.

What 5.15 Requires

ISO 27001 control 5.15 requires your organization to define, implement, and enforce rules that govern who and what can access information and associated assets. That scope is deliberately broad: it covers physical access to server rooms and offices, logical access to applications and databases, and extends to every entity that touches your environment — employees, contractors, service accounts, APIs, and automated processes.

The requirement breaks down into three operational obligations. First, you need a documented access control policy that specifies how access is requested, approved, provisioned, reviewed, and revoked. Second, that policy must be grounded in business requirements — access decisions should flow from what someone needs to do their job, not from what is convenient or historically precedented. Third, the policy must enforce the principle of least privilege: every entity gets the minimum access necessary, nothing more.

The reason this control exists is practical, not bureaucratic. Without formal rules, access decisions become ad hoc. Managers approve requests based on what the last person in the role had. Service accounts accumulate permissions across projects and are never cleaned up. The result is an environment where nobody can confidently answer the question: “Who has access to what, and why?”

Why 5.15 Matters

In a common pattern, an attacker compromises a single set of credentials — often through phishing or credential stuffing against a reused password — and discovers that the account has far more access than the role requires. From there, lateral movement is straightforward. The attacker escalates privileges, accesses systems beyond the initial foothold, and exfiltrates data or deploys ransomware before anyone detects the intrusion. The Verizon 2025 Data Breach Investigations Report found that stolen credentials have been involved in 31% of all breaches over the past decade — making credential-based access failures one of the most persistent threat vectors in cybersecurity.

Organizations that fail to implement access control as a structured discipline face compounding risks. Regulatory penalties under frameworks like GDPR and DORA carry financial teeth, but the operational damage is often worse: forensic investigations stall when nobody can produce access logs, incident response teams cannot determine the blast radius without an accurate picture of who had access to what, and auditors issue major nonconformities that jeopardize certification.

The risk class here is unauthorized access — and the severity scales with how much access an attacker inherits from a single compromised account.

What Attackers Exploit

• Orphaned accounts: Employees leave, but their Active Directory, SaaS, and VPN accounts persist for months. These dormant credentials are invisible to most monitoring tools and ideal for attackers.
• Privilege creep: Users accumulate permissions as they change roles. A developer who moved to product management still has production database access two years later.
• Missing approval workflows: Access is granted via Slack message or verbal request with no documented trail. Nobody can audit what was approved or by whom.
• Shared and generic accounts: Teams share a single admin credential for convenience, eliminating individual accountability and making incident attribution impossible.
• Unmonitored privileged access: Admin accounts operate without session logging or alerts, giving attackers unrestricted movement once they gain elevated access.
• No periodic access reviews: Permissions are granted once and never revisited, even as business needs and personnel change.
• Third-party accounts with persistent access: Vendor accounts remain active between engagements, often with broad permissions that were scoped for a specific project and never narrowed.

How to Implement 5.15

Access control implementation splits into two domains: what you enforce within your own organization, and what you verify across your vendor ecosystem. Both require structured processes, not just technical tooling.

For Your Organization (First-Party)

1. Draft an access control policy. Define who can request access, who approves it (typically the asset owner or line manager), and how access is revoked when roles change or employment ends. The policy should specify account types (standard user, privileged, service account), approval workflows, and review cadence.

2. Inventory assets and classify information. You cannot control access to assets you have not catalogued. Link your access control rules to your asset register (ISO 27001 control 5.9) and information classification scheme (control 5.12). For a structured approach, use an ISO 27001 implementation checklist to track progress across controls. Access restrictions should escalate with classification level — public assets need minimal controls, confidential data requires explicit authorization.

3. Implement role-based access control (RBAC). Assign permissions to roles, not individuals. When an employee changes positions, you update their role assignment rather than manually adjusting dozens of individual permissions. This makes both provisioning and deprovisioning predictable and auditable.

4. Enforce least privilege by default. New accounts should start with zero standing access. Every permission requires a documented justification tied to a business function. This is harder than it sounds — it requires pushing back on “just give me the same access as [colleague]” requests.

5. Tie provisioning and deprovisioning to HR processes. Joiner, mover, and leaver workflows should trigger automated access changes. When HR processes a termination, the identity provider should disable the account within hours, not days. Common tooling categories include identity providers like Okta or Microsoft Entra ID for lifecycle management and privileged access management (PAM) solutions for elevated accounts.

6. Schedule periodic access reviews. Quarterly reviews for high-risk systems, semi-annual for standard access. Asset owners — not IT — should sign off, because they understand whether the business justification still holds.

7. Log and monitor privileged access. Every admin session should produce an audit trail. SIEM platforms can flag anomalous patterns, but the baseline requirement is that privileged actions are recorded and reviewable.

Common mistakes:

• Granting admin access “temporarily” for a project and never revoking it
• Relying on manual spreadsheets for access tracking instead of automated provisioning
• Reviewing access annually when quarterly reviews are needed for high-risk systems
• Excluding service accounts and API keys from access reviews because “they are not people”
• Treating access control as an IT problem rather than a business process owned by asset owners

For Your Vendors (Third-Party Assessment)

When assessing vendor compliance with access control requirements, your security questionnaire should go beyond “Do you have an access control policy?” and test for operational maturity. Understanding third-party risk requirements under ISO 27001 is essential for structuring these assessments.

Questions to ask:

• “Describe your access control policy and how it is enforced across your environment.”
• “How do you implement least privilege for employees and service accounts?”
• “What is your process for revoking access when personnel change roles or leave the organization?”
• “How frequently do you conduct user access reviews, and who signs off?”

Evidence to request: Access control policy document, recent access review reports with sign-off, IAM architecture diagram showing how identities are managed, and privileged access management procedures.

Red flags:

• No documented access control policy or a policy that has not been updated in over two years
• Access reviews conducted only annually — or not at all
• Shared admin accounts across teams
• No multi-factor authentication on privileged accounts
• Inability to produce access review evidence within a reasonable timeframe

Verification beyond self-attestation: Conduct thorough vendor risk assessments and request SOC 2 Type II reports with access control criteria (CC6.1, CC6.3) in scope. Ask for evidence of their last access review cycle — not just the policy, but the output. If they claim automated provisioning, ask for a walkthrough of the joiner/leaver workflow.

Audit Evidence for 5.15

Auditors assessing ISO 27001 control 5.15 will request specific artifacts that demonstrate both policy existence and operational enforcement. Preparing for an ISO 27001 audit means having these artifacts ready before the assessor arrives. The table below maps the evidence types you should have ready.

Cross-Framework Mapping

ISO 27001 control 5.15 does not exist in isolation. If your organization operates under multiple compliance frameworks, you are likely implementing the same access control principles under different names. The table below maps 5.15 to its closest equivalents, using the official NIST OLIR crosswalk for the NIST SP 800-53 Rev. 5 mappings. For deeper context on how ISO 27001 relates to ISO 27002:2022 implementation guidance, see the companion standard.

Organizations managing compliance across multiple frameworks can use 5.15 as the anchor control and map evidence artifacts once rather than duplicating effort for each audit.

Related ISO 27001 Controls

Access control does not function as a standalone discipline. It depends on upstream processes like asset management and identity lifecycle, and it feeds into downstream enforcement mechanisms. The controls below are functionally connected to 5.15.

Frequently Asked Questions

What is ISO 27001 5.15?

ISO 27001 Annex A 5.15 is the access control requirement within the ISO 27001:2022 standard. It mandates that organizations establish and enforce rules governing who and what can access information and associated assets, covering both physical and logical access. The control applies to all entities — employees, contractors, service accounts, and automated processes — and requires enforcement of least privilege, need-to-know, and formal approval workflows.

What happens if 5.15 is not implemented?

Without control 5.15, organizations cannot demonstrate governance over who accesses their systems and data, which creates conditions for privilege escalation, lateral movement, and data exfiltration. From a compliance perspective, auditors will issue a major nonconformity against this control, which can block initial ISO 27001 certification or trigger corrective action requirements during surveillance audits. The operational consequence is an environment where no one can answer the fundamental question: who has access to what, and is that access still justified?

How do you audit 5.15?

Auditors verify control 5.15 by reviewing the documented access control policy, sampling access request and approval records to confirm formal workflows exist, and checking that periodic access reviews are conducted and signed off by asset owners. They also test deprovisioning by cross-referencing recent leavers against active account lists, and confirm that privileged access is logged and monitored. The strongest audit evidence combines policy documentation with operational artifacts like review reports, provisioning logs, and PAM session records.

How UpGuard Helps

Monitor Access Risk Across Your Organization and Vendors

UpGuard User Risk gives you continuous visibility into access-related risks across your internal environment and third-party ecosystem. Identify overprivileged accounts, track vendor access control posture, and surface gaps before auditors do — so your ISO 27001 access control evidence is always current.

Explore UpGuard User Risk