ISO 27001 Access Control: From Business Rules to Operating Evidence

Access control begins with a business decision: who needs to do what, with which information, under what conditions, and for how long. Technology enforces that decision, but it cannot supply missing ownership or risk judgement.

ISO/IEC 27001:2022 Annex A addresses access across several organisational and technological controls, including access rules, identity management, authentication information, access rights, privileged rights, information restriction and source-code access. The organisation selects and tailors controls through risk treatment; it should not apply a control number without defining the intended outcome.

Define the access decision

Every material access path should answer:

• Subject: Which person, service, device or workload requests access?
• Resource: Which application, data, system, facility or code repository is involved?
• Action: What can the subject read, create, change, approve, execute or administer?
• Condition: Which network, device, authentication strength, location or time constraint applies?
• Approver: Which accountable owner authorises the access?
• Duration: Is it permanent, time-bound or just-in-time?
• Evidence: How will approval, enforcement, use and removal be proved?

These questions turn “least privilege” into an auditable rule. A statement such as “users receive appropriate access” is too subjective unless roles, owners and exceptions are defined.

Use the Annex A control lookup to explore related controls, then record the organisation’s actual rules and rationale.

Establish ownership before provisioning

Business or information owners should decide acceptable access to their resources. Identity teams can operate the process, and system administrators can implement the decision, but neither should silently become the risk owner.

A practical ownership model identifies:

• the process owner who defines business need;
• the resource or information owner who approves access;
• the identity team that maintains identities and workflows;
• the technical owner who enforces permissions;
• the manager who initiates joiner, mover and leaver events;
• the security function that sets guardrails and monitors risk; and
• the reviewer who evaluates exceptions and operating evidence.

The ISO 27001 RACI guide can help separate accountability from performance.

Design the identity lifecycle

Joiners

Create identities from an authoritative source, verify the person’s relationship and assign baseline access through an approved role. Avoid manual account creation that bypasses the personnel or contractor record. Initial credentials should be delivered securely and changed or activated under controlled conditions.

Movers

Role changes are often riskier than new starters because access accumulates. Reassess old permissions when responsibilities change; adding the new role without removing the old one creates toxic combinations and excessive privilege.

Leavers

Trigger timely disablement from the authoritative event. Cover employees, contractors, temporary workers, shared facilities, physical badges, remote access, secrets and locally managed applications. Define urgent termination handling separately from routine departure.

Non-human identities

Service accounts, application identities, API keys and workloads require owners, purpose, scope, credential protection, rotation or managed alternatives, monitoring and retirement. They should not disappear from review because they lack a human manager.

Choose an authorisation model

Role-based access can provide consistent baseline permissions where jobs are stable. Attribute- or policy-based methods can account for resource, device, risk or context. Direct grants may be necessary for specialist cases but are harder to govern at scale.

Whichever model is chosen:

1. define roles or policies in business language;
2. identify incompatible duties;
3. keep sensitive and privileged access separate;
4. require owner approval for exceptions;
5. expire temporary access;
6. test that enforcement matches design; and
7. review the model after process or system change.

Group membership is implementation detail. The audit question is whether membership produces authorised business capability and no more.

Govern privileged access

Privileged access can alter controls, evidence and production data. Treat it as a separate population, not merely a higher role.

Good design may include named administration accounts, separation from daily-use accounts, strong authentication, approval, limited duration, session or command logging, secure emergency access and prompt review of unusual activity. The exact combination should reflect risk and technology.

Emergency access needs a controlled break-glass path. Pre-authorise the conditions, protect the credentials, alert on use, review the session and rotate or reset access afterward. An undocumented shared administrator password is not a resilient emergency process.

Protect authentication information

Manage passwords, keys, tokens, recovery codes and other authentication information through their lifecycle. Define issuance, storage, reset, recovery, rotation where appropriate, revocation and disposal. Help-desk recovery deserves the same scrutiny as normal sign-in because it can bypass a strong primary mechanism.

Multi-factor authentication can be an important treatment, but ISO 27001 does not make one mechanism universally mandatory for every account. Selection should follow risk, applicable requirements and architecture. The related MFA evidence guide explains scope, strength, recovery and bypass testing.

Build three kinds of evidence

Design evidence

This shows what should happen: access rules, role definitions, ownership, workflow, segregation constraints, review frequency, exception criteria and termination requirements.

Implementation evidence

This shows that systems reflect the design: identity-source integration, role mappings, workflow configuration, privileged-access settings, authentication policy and logging.

Operating evidence

This proves performance over time: sampled requests, approvals, provisioning timestamps, mover adjustments, leaver removal, periodic reviews, privileged sessions, exception expiry, alert cases and remediation.

The implementation-versus-operating-evidence guide provides a deeper method for separating these layers.

Make access reviews effective

An access review should support a decision, not merely generate a spreadsheet. Give reviewers enough context: user or identity, employment status, role, resource, permission meaning, privilege level, last use, approval history and conflicts.

Track certification, removal and exception decisions to completion. Measure overdue reviews, revoked access not yet removed, inactive privileged accounts and recurring exceptions. A manager clicking “approve all” in seconds is evidence of completion but weak evidence of effective evaluation.

Frequency should reflect risk. High-impact privileged access may need more frequent or event-driven review than stable low-risk access. Reviews do not replace joiner, mover and leaver controls; they detect what preventive processes missed.

Audit sampling

Build separate populations for human identities, non-human identities, privileged access, access requests, terminations, role changes, reviews and exceptions. Sample by risk rather than choosing only convenient records.

Include:

• a new starter;
• a mover with prior access;
• a normal and urgent leaver;
• a privileged user;
• a dormant or rarely used account;
• a service identity;
• a temporary exception; and
• an access-review revocation.

For each sample, trace business need, approval, technical enforcement, use where relevant, review and removal. Reconcile system evidence with the authoritative source rather than trusting a workflow status alone.

Use the risk score calculator to structure access-risk discussions while applying the organisation’s own criteria.

Pass, partial and fail examples

Pass: Owners define access, lifecycle events drive timely change, privileged and non-human identities receive enhanced governance, and period evidence shows reviews and removals operating effectively.

Partial: Central applications follow the process, but several specialist systems use manual accounts. Reviews occur, yet service identities lack owners and mover access is not consistently removed.

Fail: Administrators grant access from informal messages, shared accounts are common, leaver removal cannot be evidenced and periodic reviews approve permissions without business context.

These examples illustrate evidence strength rather than mandatory audit grades.

Common weaknesses

Avoid:

• treating access control as only a password setting;
• allowing IT to decide business entitlement;
• adding mover access without removing prior rights;
• excluding service identities from ownership and review;
• mixing normal and privileged use in one account;
• keeping standing emergency access without monitoring;
• reviewing group names without explaining permissions;
• retaining completion reports without remediation evidence; and
• testing current state only when operation over time matters.

Practical conclusion

Effective access control is a governed chain from business need to enforced and reviewed permission. Define the decision, assign accountable owners, automate lifecycle events where dependable, protect privileged paths and retain evidence that covers the audit period.

The strongest proof is not a policy or an identity-system screenshot. It is a sample that connects authorised need, correct implementation, appropriate use, timely review and removal.