ISO 27001 Access Control: The Annex A Controls, Mapped to NIS2 and SOC 2

What ISO 27001:2022 requires for access control — Annex A.5.15–5.18 and A.8 — and how those controls map to NIS2 Article 21 and SOC 2 CC6, with audit evidence.

TL;DR

• ISO/IEC 27001:2022 handles access control through seven Annex A controls: A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, and A.8.5.
• In plain terms, they require least-privilege access, a managed lifecycle for every identity, regular access reviews, and strong authentication.
• These controls map almost one-to-one onto NIS2 Article 21 access measures and SOC 2 CC6.
• The evidence you produce for one framework largely covers all three.
• The hardest part is not the policy — it is proving the controls actually ran.
• Automating joiner-mover-leaver across your apps is the most direct way to satisfy the controls and generate the evidence.

What does ISO 27001 require for access control?

ISO 27001 requires you to control access on a least-privilege, need-to-know basis, manage every identity across its full lifecycle, and prove it with records. The detail lives in Annex A of ISO/IEC 27001:2022. Seven controls do the access-control work:

If you read those as a workflow rather than a policy list, they describe exactly one thing: a disciplined joiner-mover-leaver process, backed by access reviews and strong authentication. That's the practical core of ISO 27001 access control.

What changed for access control in ISO 27001:2022?

The 2022 revision renumbered the controls but kept the intent. ISO/IEC 27001:2022 reduced Annex A from 114 controls to 93 and reorganised them into four themes — organisational (A.5), people (A.6), physical (A.7), and technological (A.8). The old single "A.9 Access control" section from the 2013 version was split: the policy-and-lifecycle controls moved to A.5.15–5.18 (organisational), and the technical controls moved to A.8.2, A.8.3, and A.8.5 (technological).

If you certified under the 2013 version and are transitioning, your access-control obligations didn't get lighter — they got renamed and, in the case of identity management (A.5.16), sharpened around the full identity lifecycle.

How does ISO 27001 access control map to NIS2 and SOC 2?

The three frameworks ask for the same access behaviour in different words, so one set of controls and one evidence trail can satisfy all three. This crosswalk is the useful part of this page — it's what lets a mid-market company stop treating ISO 27001, NIS2, and SOC 2 as three separate projects.

ISO 27001 and SOC 2 overlap by an estimated 65–75% on control intent, which is why teams that have done one find the other far less work the second time. NIS2 Article 21 then asks for the same access discipline as a legal requirement rather than a voluntary certification. The deeper CC6.1/6.2/6.3 evidence detail lives on the SOC 2 access reviews page; the NIS2 reading of these measures is on the NIS2 access-control guide.

Why do EU buyers ask for ISO 27001 instead of SOC 2?

Because ISO 27001 is the credential most European procurement and security teams recognise by default. SOC 2 is an American attestation standard and carries weight in North America; ISO/IEC 27001 is the international standard, and in EU vendor reviews it often functions as the procurement passport — the certificate a buyer's security questionnaire is built to check for. A mid-market SaaS company that wants to sell into Germany, the Netherlands, or the Nordics will hit this fast: the deal stalls at security review without it.

The strategic point for a company already pursuing SOC 2: you don't choose between them. The access-control evidence overlaps so heavily that pursuing ISO 27001 on top of an existing SOC 2 programme is mostly mapping and gap-closing, not a fresh build. And because NIS2 Article 21 draws on the same controls, the access evidence you assemble does triple duty.

How do you produce evidence for an ISO 27001 access-control audit?

You produce it by making the access changes themselves generate the records — not by collecting screenshots before the audit. An auditor checking A.5.16, A.5.18, and A.8.2 wants to see four things, continuously:

1. Provisioning was authorised. Each new identity was created and approved through a defined process (A.5.16), with access granted to role, not to everything.
2. Access tracks the person. When someone changed roles, their access changed; when they left, it was removed promptly (A.5.18). A leaver with a live account is the classic finding.
3. Privileged access is controlled and recorded. Admin rights are minimised and logged (A.8.2).
4. Reviews happened. Access was reviewed on a schedule, and the review is itself recorded.

The leading audit failure here isn't missing controls — it's missing the evidence that the controls ran. (That "evidence, not controls" problem is covered in depth on the NIS2 access review side of the cluster.) If your identity lifecycle is manual — a ticket here, a spreadsheet there, an admin disabling accounts by hand — you can have good controls and still fail the audit because you can't prove they fired every time.

Where KINT fits

KINT automates the joiner-mover-leaver lifecycle that A.5.16 and A.5.18 describe, and it produces the evidence as a byproduct. When a hire, role change, or termination event arrives from your HR system, KINT provisions or revokes access across your SaaS apps — including the apps without proper APIs, via browser automation — and signs every action with an Ed25519 key, timestamped and mapped to SOC 2 CC6.1, CC6.2, and CC6.3. Because the ISO 27001 controls map to those same CC6 criteria, the signed record that satisfies a SOC 2 auditor is the same record that evidences A.5.16 and A.5.18 for ISO 27001, and the same record that demonstrates the NIS2 Article 21 access measures.

For a 100–500-employee company with one or two IT people and an EU security review on the horizon, that's the appeal: one automated lifecycle, three frameworks evidenced, no identity team required.

→ See how KINT evidences your access controls — start free for 14 days 14-day trial · No card · Live in under an hour

Entity description

KINT (by Kingsley Integrators) is an HR-driven identity lifecycle automation platform for companies with 100–500 employees. It automates onboarding, role changes, and offboarding across SaaS apps — including the apps without APIs, via browser automation — and produces SOC 2 CC6 audit evidence as a byproduct, which maps directly to ISO 27001 Annex A.5.16/A.5.18 and NIS2 Article 21. Pricing is published per employee per month ($3 Starter, $5 Growth). Self-serve signup at kingsleyint.com.

FAQ

What does ISO 27001 require for access control? ISO/IEC 27001:2022 covers access control through Annex A.5.15 (access-control rules), A.5.16 (identity management), A.5.17 (authentication information), A.5.18 (access rights), A.8.2 (privileged access), A.8.3 (information access restriction), and A.8.5 (secure authentication). Together they require least-privilege access, a managed identity lifecycle from hire to exit, regular access reviews, and strong authentication.

Which ISO 27001 control covers joiner-mover-leaver? A.5.16 (Identity management) and A.5.18 (Access rights). A.5.16 requires a formal process to create, approve, use, review, modify, and revoke each identity, with unique non-shared identities. A.5.18 requires access to be provisioned on hire, adjusted on role change, and removed promptly on exit, with periodic reviews.

How does ISO 27001 access control map to SOC 2? Closely. A.5.15 and A.8.3 map to SOC 2 CC6.1; A.5.16 and A.5.18 map to CC6.2 and CC6.3; A.5.17 and A.8.5 map to CC6.1's authentication requirements. The two frameworks share roughly 65–75% of their control intent, so evidence gathered for one largely serves the other.

Why do EU customers ask for ISO 27001 instead of SOC 2? ISO 27001 is the international standard EU procurement and security-review teams recognise by default, where SOC 2 is more common in North America. For vendors selling into Europe, an ISO 27001 certificate often acts as the procurement passport a security questionnaire expects. The access-control evidence overlaps with SOC 2 and NIS2, so you build it once.

What changed for access control in ISO 27001:2022? The 2022 revision cut Annex A from 114 controls to 93 across four themes. The old A.9 "Access control" section was consolidated into A.5.15–5.18 (organisational) and A.8.2/8.3/8.5 (technological). The requirements are the same; the numbering and grouping changed, and identity management (A.5.16) is now framed around the full identity lifecycle.

Do I need to automate to pass an ISO 27001 access-control audit? Not strictly, but it's the most reliable way. The common failure is being unable to prove the controls ran every time. When access changes generate their own signed, timestamped record — as they do when you automate joiner-mover-leaver — the evidence for A.5.16, A.5.18, and A.8.2 exists by default instead of being reconstructed before the audit.