Annex A 5.15: Access Control

Annex a 5.15: access control requirement expects you to define, implement, and keep evidence of access rules that limit system and data access to authorized users, roles, and services. Operationalize it by publishing an access control policy, standardizing joiner/mover/leaver workflows, enforcing least privilege and segregation of duties, and proving control operation through logs, reviews, and approvals. ¹

Key takeaways:

• Document the access control rules, then make them real in IAM, endpoints, apps, and cloud.
• Standardize provisioning and deprovisioning with approvals, least privilege, and periodic access reviews.
• Evidence matters: tickets, access review outputs, IAM exports, and logs must show control operation. ¹

Annex A 5.15 is one of the controls auditors use to test whether your ISMS can reliably prevent unauthorized access, not just whether you have an “access policy” on paper. The control sits in the organizational controls section of ISO/IEC 27001:2022 and sets an expectation that you define access rules and enforce them consistently across people, systems, and services. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 5.15 as a measurable operating model: who can approve access, how access is granted, how privileged access is handled, and how access is removed. Then you map those rules to the technical controls already in place (SSO/IAM, HRIS, ticketing, cloud IAM, endpoint management) and set up recurring evidence capture so you can demonstrate the control works during internal audits, certification audits, and customer security reviews. ¹

This page gives requirement-level implementation guidance: applicability, step-by-step actions, the artifacts you must retain, common audit hangups, and a practical execution plan you can hand to IAM, IT, and Security Operations without rewriting it.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.15 implementation expectation (Access Control).” ¹

Operator interpretation (what you must do): You must define access control rules and implement controls that restrict access to information and other associated assets based on business and security requirements. Practically, an auditor expects: (1) documented rules (policy/standards), (2) consistent processes (provisioning, changes, removal), (3) technical enforcement (IAM configurations), and (4) evidence that the processes operate as designed over time. ¹

Plain-English interpretation of the requirement

Annex a 5.15: access control requirement means:

• People and systems only get the access they need to do approved work.
• Access is approved by the right owner before it is granted.
• Privileged access is treated as exceptional and tightly controlled.
• Access is removed promptly when no longer needed (role change, termination, contract end).
• You can prove all of the above with repeatable evidence. ¹

Who it applies to (entity and operational context)

Applies to: Service organizations running an ISMS aligned to ISO/IEC 27001:2022. ²

Operational scope (typical):

• Workforce identities: employees, contractors, interns, temps.
• Third-party identities: vendors/consultants with network, application, or support access (treat as “third party” access within your access control model).
• Non-human identities: service accounts, API keys, CI/CD tokens, integrations.
• Environments: corporate IT (email, collaboration), production and non-production systems, cloud consoles, source code platforms, support tooling, data warehouses, and SaaS admin panels. ¹

What you actually need to do (step-by-step)

1) Define and publish access control rules (policy + minimum standards)

Create an Access Control Policy that states, at minimum:

• Principles: least privilege, need-to-know, default deny, role-based access where feasible.
• Approval model: who approves access (system owner, data owner, manager) and for what types of access.
• Segregation of duties (SoD): which combinations are prohibited or need compensating controls (for example, “developer cannot approve their own production access”).
• Privileged access: when it is allowed, how it is time-bounded, and how it is monitored.
• Exceptions: how to request, approve, time-limit, and review exceptions. ¹

Operator tip: Write the policy so it can be tested. If a rule cannot be verified from tickets, IAM logs, or access review output, rewrite it into something observable.

2) Build an authoritative inventory of systems and “access owners”

You need a list of in-scope systems with:

• System name, environment, data type handled, and criticality.
• System owner (business) and technical owner (IT/Security).
• How access is granted (SSO group, local account, SCIM, manual admin).
• Where evidence comes from (ticketing system, IAM export, app audit logs). ¹

This inventory becomes the backbone for access reviews and joiner/mover/leaver controls.

3) Standardize joiner/mover/leaver (JML) workflows in ticketing + IAM

Implement a single, consistent workflow for:

• Joiners: access requested based on role; manager approval; system owner approval for sensitive systems; provisioning via IAM groups.
• Movers: access adjusted when role changes; remove old entitlements before granting new ones if SoD risk exists.
• Leavers: immediate disablement of identity; removal from groups; revoke tokens/keys; terminate sessions; remove local accounts. ¹

Control design goal: make IAM the first-class mechanism (SSO, SCIM, groups). Manual access should be the exception and always ticket-backed.

4) Implement privileged access controls you can prove

For administrative access (cloud admin, database admin, production break-glass):

• Require named accounts; prohibit shared admin accounts unless you can show accountability and compensating controls.
• Put privileged access behind an approval step and log collection.
• Time-bound elevated access where your tooling supports it (for example, “just-in-time” access). If not supported, enforce compensating controls (manager + system owner approval; heightened monitoring; post-use review). ¹

5) Enforce access reviews (and make them survivable)

Access reviews fail when the reviewer cannot understand what they are approving. Make reviews:

• System-scoped: one system at a time, with clear entitlement descriptions.
• Owner-led: system owners attest; security facilitates.
• Outcome-driven: keep, remove, or remediate with a ticket for each change.
• Evidence-backed: save the reviewer’s attestation and the before/after access lists. ¹

Set a review cadence based on risk (critical systems more often; low-risk systems less often). ISO does not mandate a specific frequency in the provided excerpt, so choose a cadence you can sustain and defend with risk logic. ²

6) Cover non-human access (service accounts, API keys, tokens)

Auditors will ask how you control “machine” access because it often bypasses HR-driven JML. Minimum expectations:

• Maintain an inventory of service accounts and integrations.
• Require an owner, purpose, and system scope for each.
• Store secrets in a controlled system; restrict who can retrieve them.
• Rotate secrets on a defined schedule you can meet; rotate immediately on compromise or personnel change affecting the owner. ¹

7) Map 5.15 to control operation and recurring evidence capture

Turn the requirement into a repeatable evidence routine:

• Monthly (or your chosen cadence): export IAM group membership for privileged groups; store it.
• Each access request: ensure ticket shows requester, approver(s), system, access level, dates, and implementation proof.
• Each leaver: retain HR trigger, disablement record, and confirmation of access removal for key systems.
• Each review cycle: retain review outputs and remediation tickets. ¹

Where Daydream fits naturally: Use Daydream to map annex a 5.15: access control requirement to a documented control narrative, assign control owners, schedule recurring evidence tasks, and keep evidence packets audit-ready without rebuilding the tracker every cycle. ¹

Required evidence and artifacts to retain

Keep artifacts that show both design and operation:

Design artifacts

• Access Control Policy and any supporting standards/procedures.
• RACI for approvals (manager vs system owner vs security).
• System inventory with owners and access methods.
• Role/entitlement catalog (even if partial for high-risk systems first). ¹

Operating evidence

• Access request tickets with approvals and implementation timestamps.
• Termination/mover tickets showing access removal.
• IAM exports (group membership, privileged group lists) and change logs.
• Access review packages: reviewer list, access listing, attestations, remediation tickets, closure evidence.
• Audit logs for privileged actions (cloud admin logs, SaaS admin logs) where available.
• Exception register: approved exceptions, expiry dates, and periodic re-approval evidence. ¹

Common exam/audit questions and hangups

Expect these questions from internal audit, certification auditors, and customer assessors:

• “Show me your access control policy and how it is enforced in practice.” ²
• “Pick two recent hires and prove approvals and provisioning steps for key systems.”
• “Pick two terminations and show deprovisioning across SSO and critical applications.”
• “Who can grant themselves access? Show controls preventing self-approval.”
• “How do you control admin access to cloud consoles and production?” ¹
• “How do you review access periodically, and what changes resulted from the last review?”

Hangups that slow audits:

• No single source of truth for “who has access.”
• Manual access grants without tickets.
• System owners who cannot interpret entitlements during reviews.
• Service accounts with unclear ownership or stale tokens. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Policy exists, but IAM doesn’t match it	Auditors test reality, not intent	Create a control mapping: policy rule → IAM config → evidence source 1
Treating access reviews as a spreadsheet exercise	Reviewers rubber-stamp; removals never happen	Tie each removal to a ticket and close it with proof
Over-reliance on shared admin accounts	No accountability; weak forensics	Move to named admin accounts; log privileged actions
Ignoring non-human identities	Service accounts become permanent backdoors	Inventory, owner assignment, secret storage, rotation process
Exceptions never expire	Access creep becomes normal	Put expiry dates on exceptions; review and re-approve or remove

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement. Practically, 5.15 failures create direct breach pathways: unauthorized access, privilege escalation, inability to contain insider risk, and weak incident investigations because activity cannot be tied to a responsible identity. These are also common drivers of failed customer security reviews and delayed sales cycles for service organizations. ¹

A practical 30/60/90-day execution plan

Days 1–30: Make access control auditable

• Publish Access Control Policy and approval RACI.
• Identify in-scope “crown jewel” systems and assign system owners.
• Standardize access request tickets (required fields, required approvers).
• Start privileged group monitoring for your IAM/SSO. ¹

Days 31–60: Reduce access pathways and manual work

• Move key systems to SSO and group-based access where feasible.
• Implement a defined JML process with HR triggers and IT/SecOps execution steps.
• Stand up the service account inventory with owners and purposes.
• Run your first access review for one high-risk system; generate remediation tickets. ¹

Days 61–90: Prove control operation and close gaps

• Expand access reviews to additional systems based on risk.
• Implement privileged access tightening (named admins, approvals, logging).
• Formalize exception management with expirations and re-approval workflow.
• Build an “audit packet” template for 5.15 in Daydream: policy, tickets, IAM exports, review outputs, and log samples stored by period. ¹

Frequently Asked Questions

Does annex a 5.15: access control requirement require a specific access review frequency?

The provided ISO 27001 materials here do not specify a fixed frequency for reviews. Set a risk-based cadence you can sustain and prove with evidence, then document it in your standard and follow it consistently. ²

Are service accounts in scope for access control?

Yes. Treat non-human identities as first-class access subjects with an owner, documented purpose, controlled secret storage, and evidence of lifecycle management. ¹

What evidence is strongest in an ISO 27001 audit for access control?

Auditors typically want a trace from policy to operation: approved tickets, IAM/group membership exports, access review records, and logs that show administrative actions tie back to named identities. Keep evidence by time period so sampling is easy. ¹

How do we handle third party access (vendors/consultants) under 5.15?

Put third party users through the same JML and approval steps as employees, plus contract-based limits and end dates. Require a business sponsor and remove access when the engagement ends. ¹

What if a legacy system can’t integrate with SSO?

Document the exception, implement compensating controls (ticketed approvals, periodic account listing review, strong authentication where possible), and plan a migration. Auditors accept constraints when the residual risk is managed and evidenced. ²

Who should own this control: IT, Security, or GRC?

GRC should own the requirement mapping and evidence expectations; IT/Security should own technical enforcement and process execution; system owners must approve access and perform attestations. Make ownership explicit in RACI and ticket workflows. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview