A Practical Guide to ISO 27001 Access Control (A.5.15-A.5.18)

Access control is the most frequently cited area of nonconformity in ISO 27001 audits. Controls A.5.15 through A.5.18 (plus related technical controls A.8.2 through A.8.5) cover the full lifecycle of identity and access management — from policy through provisioning, review, and revocation.

Here's what each control requires, what auditors actually look for, and where startups consistently stumble.

A.5.15 — Access Control Policy and Enforcement

Tier: Critical | NIST: AC-1, AC-2, AC-3, AC-6

This control requires that access to information and systems is restricted based on business and security requirements, following the principle of least privilege.

What auditors look for

Auditors want to see the access control policy and evidence it's being followed. They'll sample 3-5 joiners and 3-5 leavers to verify access was provisioned and revoked correctly. They look for quarterly access reviews with documented decisions — not just screenshots of user lists.

Common startup pitfall

The policy says "least privilege" but admin accounts are used for daily work. There's no documented process for access requests — "just Slack the admin" isn't auditable. Access reviews either never happen or are done once and abandoned.

Evidence to collect

• Access control policy document
• Quarterly access review records with reviewer name and decisions
• IAM policy exports from cloud platforms
• User list with role assignments from your identity provider

A.5.16 — Identity Management

Tier: Critical | NIST: AC-2, IA-2, IA-4, IA-8, IA-12

Manage the full lifecycle of identities from provisioning through deprovisioning. Each person must have a unique identity. Shared accounts should be documented exceptions.

What auditors look for

Generic accounts like "admin@" or "deploy@" are red flags. Auditors check for unique user IDs and evidence of identity lifecycle: joiner provisioning, mover role changes, leaver deprovisioning. Service accounts count as identities and need owners and review cycles.

Common startup pitfall

Shared credentials for deployment. A single API key used by multiple developers. Service accounts without assigned owners.

A.5.17 — Authentication Information

Tier: Critical | NIST: IA-1, IA-5

Manage authentication credentials through their lifecycle — passwords, tokens, keys, certificates. Define minimum strength requirements and enforce MFA.

What auditors look for

MFA is the number one item auditors check. If it's not enforced on production systems and admin accounts, expect a finding. They verify that password policy in the IdP matches the documented policy. API keys and tokens need rotation schedules.

Common startup pitfall

SSH keys created during onboarding and never rotated. API tokens with no expiration date. "We'll rotate if compromised" is not a policy.

A.5.18 — Access Rights

Tier: Critical | NIST: AC-2, PS-5

Provision, review, modify, and revoke access rights in accordance with the access control policy. Review at regular intervals and revoke promptly when no longer needed.

What auditors look for

The "48-hour rule": auditors expect access revocation within 24-48 hours of termination. They cross-reference HR termination dates with last-active dates in systems. Role changes should trigger access reviews — people accumulate permissions over time.

Common startup pitfall

Orphaned accounts: users who left the company but still show as active. No offboarding checklist connecting HR termination to IT deprovisioning.

A.8.2 — Privileged Access Rights

Tier: Critical | NIST: AC-6

Restrict and manage privileged access — admin, root, superuser. Privileged access should be time-limited where possible and subject to enhanced monitoring.

What auditors look for

A complete list of all privileged users across all systems. If you can't produce this list, it's a finding. "Everyone is admin" is a guaranteed nonconformity. Privileged access should have separate credentials from daily-use accounts.

What to implement

• Documented list of all admin accounts and their owners
• Separate admin credentials from daily-use accounts
• Enhanced MFA for privileged access (hardware keys)
• Quarterly review of privileged access assignments

A.8.3 — Information Access Restriction

Tier: Critical | NIST: AC-3, AC-6

Systems should enforce access restrictions — not rely on user self-governance. Access must be restricted based on the access control policy.

What auditors look for

Cross-environment access is a common gap: developers with direct production database access "for debugging." API keys that grant broad access when narrow scope would suffice.

A.8.5 — Secure Authentication

Tier: Critical | NIST: AC-7, IA-2, IA-6, IA-8, SC-23

Implement secure authentication mechanisms: MFA, session management, account lockout, and authentication feedback controls.

What auditors look for

• MFA enforcement on all production and admin access (non-negotiable)
• Session timeout configuration (15-30 minutes for sensitive systems)
• Account lockout after failed login attempts
• SSO preferred over individual application passwords

Putting It Together

Access control is not a single control — it's an interconnected set of requirements covering the entire identity lifecycle. The controls work together:

1. A.5.15 sets the policy framework
2. A.5.16 manages identities from creation to deletion
3. A.5.17 handles how those identities prove who they are
4. A.5.18 manages what those identities are allowed to do
5. A.8.2-A.8.5 add technical enforcement and privileged access controls

A weakness in any one link affects the entire chain. Invest in access reviews and offboarding automation first — they address the most common audit failures at once.

Want to know where your access controls stand? Schedule an internal audit for a control-by-control assessment.