ISO/IEC 27001:2022 · derived mapping target
A.5.15Access control
Set and enforce rules for who can access which information and systems, based on business and security needs. Granting only the access people actually require limits the damage from any single account.
Mapping at a glance
A.5.15Access controlISO/IEC 27001:2022
RCF-0006Roles & responsibilitiesGovernance & Risk · TechnicalRCF-0061Identity lifecycleIdentity & Access Management · PolicyRCF-0064Strong authentication (MFA)Identity & Access Management · PolicyRCF-0067Least privilege / RBACIdentity & Access Management · PolicyRCF-0069Least privilege / RBACIdentity & Access Management · Technical
A.5.15 is covered by 16 Sekit CSF controls. +11 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0006Roles & responsibilities · TechnicalsupportsConfiguring systems so each defined responsibility can only be exercised by the assigned person is access control applied to governance roles, backing A.5.15's requirement that access maps to genuine need.RCF-0061Identity lifecycle · PolicyenablesA documented identity lifecycle gives access control something stable to act on: without a clear rule for how accounts are created and changed, A.5.15's access decisions have no reliable account to attach to.RCF-0064Strong authentication (MFA) · PolicysupportsRequiring a second factor on email, the identity platform and systems holding important data is a specific access control rule A.5.15 asks organisations to enforce based on business need.RCF-0067Least privilege / RBAC · PolicysupportsSekit's Least privilege / RBAC control defines the access each role needs and makes that the default grant, the policy half of A.5.15's set-and-enforce requirement; the platform-level enforcement that completes it is mapped separately on this page.RCF-0069Least privilege / RBAC · TechnicalsupportsEnforcing permissions at the platform level, with no shared logins standing in for real access control, is what makes A.5.15's role-based rules hold in practice.RCF-0070Privileged access management · PolicysupportsKeeping administrative privileges in separate, approved, tracked accounts is A.5.15's least-privilege principle applied specifically to the accounts capable of the most damage.RCF-0073SSO & federation · PolicyenablesRouting sign-in through a central identity provider gives A.5.15's access rules one place to be enforced consistently, rather than scattered across every application's own login system.RCF-0074SSO & federation · ProcessenablesConnecting each new application to the identity provider before staff start using it means access control applies from day one instead of being retrofitted later.RCF-0075SSO & federation · TechnicalenablesAuthenticating critical applications through the central identity provider rather than local accounts is the technical foundation that makes A.5.15's access rules enforceable across the estate.RCF-0079Session management · PolicysupportsSetting a maximum idle time before sessions lock is a concrete access control rule for who can act on an already-authenticated session, not only who can start one.RCF-0082Remote access · PolicysupportsDefining allowed connection methods and devices for remote work is A.5.15's access control principle extended to the case where the person is not on the office network.RCF-0085Access reviews (recertification) · PolicysupportsCommitting to a periodic access review is how A.5.15's access-based-on-need principle stays true over time, instead of only being checked the day an account is created.RCF-0138API security · TechnicalsupportsEnforcing authentication, per-endpoint authorisation and rate limiting on APIs is A.5.15's access control principle applied to machine-to-machine access, not only human logins.RCF-0184Zero Trust network access · PolicysupportsGranting access per request based on verified identity and device state rather than network location is a stricter, explicit form of the access control A.5.15 requires.RCF-0185Zero Trust network access · ProcesssupportsChecking identity and device posture on every access grant, and reviewing the conditional rules periodically, keeps A.5.15's access decisions current rather than a one-time check.RCF-0334Cloud IAM · PolicysupportsGoverning cloud roles, restricting administrator access and reviewing rights on a schedule extends A.5.15's access control requirement into cloud platforms specifically.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
MFA enrollment evidence
The proof that a second verification step (beyond the password) is required to access important systems.
From the Sekit evidence catalog
In practice
Access control in practice means role-based permissions in the identity provider, MFA required everywhere that matters, and no shared logins standing in for individual accounts. Auditors pull the MFA enrolment evidence and cross-check it against the full user list looking for gaps: contractors, service accounts, or a few long-tenured employees grandfathered out of enrolment years ago and never circled back to. The most common finding is access granted by copying an existing colleague's permissions rather than from a documented role definition, which quietly accumulates privilege nobody can explain months later.
Common gaps
A handful of long-tenured accounts were never enrolled in MFA when the requirement was rolled out and nobody has gone back to close that gap.
New hires are granted access by copying a colleague's existing permissions rather than from a documented role definition, so nobody can explain why each person has what they have.
Shared or generic logins are still used for a legacy system because migrating it to individual accounts was deprioritised.
Questions your auditor will ask
How do you decide what access a given person should have?
Point to the role definitions that state the access each role needs, granted from that definition rather than by copying an existing colleague's permissions.
Is multi-factor authentication enforced everywhere it should be?
Show the MFA enrolment evidence covering email, the identity platform, remote access and every system holding important business data, including known coverage gaps and the plan to close them.
How is administrative access handled differently from regular access?
Describe the separate, approved administrative accounts, tracked in a current register, distinct from each person's everyday login.
What stops access from accumulating as people change roles over time?
Reference the periodic access review that checks current access against current duties and removes what a role change made unnecessary.
Where regulation demands it
NIS2 art. 11.1 (Access control policy) requires the same access-by-need approach A.5.15 asks organizations to enforce.
ENS op.acc.2 (Requisitos de acceso) sets the equivalent expectation for defined access requirements tied to business need.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.15?”
Also via MCP, free with account