Somewhere in your ISO 27001 audit, the auditor asks how you implement A.8.22 — segregation of networks — in production. If production is Kubernetes, the honest answer involves NetworkPolicies, namespace isolation, and host-network settings across a few hundred workloads. What most teams actually produce is a screenshot of a dashboard and a paragraph of prose, because nobody has written down which Kubernetes objects evidence which Annex A clause.
This guide is that mapping. We walk the ten technological Annex A clauses a cluster scan can genuinely evidence, name the Kubernetes controls behind each one, follow a single clause end to end from requirement to failing workload, and — just as important — name the four clauses no scanner can prove, so nothing in your evidence pack overclaims.
Why ISO 27001 needs a Kubernetes translation
ISO/IEC 27001:2022 is a management-system standard: it certifies your organisation's ISMS, not a piece of software. Its Annex A lists 93 controls across four themes — organisational, people, physical, and technological. The standard tells you what must be controlled ("networks shall be segregated"); it deliberately does not tell you how in any given technology.
That abstraction is the whole problem for platform teams. "Privileged access rights shall be restricted" is a sentence; ClusterRoleBinding objects granting cluster-admin to a group nobody remembers creating is a fact. The audit goes well when you can walk from the sentence to the fact — clause, to the Kubernetes control that operationalises it, to the specific workloads that currently pass or fail it.
One scoping honesty note before the mapping: a Kubernetes cluster can only ever evidence a subset of Annex A — the technological clauses that manifest as cluster configuration. Your ISMS still needs policies, supplier management, and HR controls that live entirely outside the cluster. A tool or consultant claiming a cluster scan "covers ISO 27001" is overclaiming; the useful question is which clauses it covers, and how honestly it labels the rest.
The mapping: ten technological clauses a cluster scan can evidence
Here is the clause-by-clause translation. The middle column is what the clause asks in plain language; the right column names the Kubernetes controls and objects that evidence it.
| Annex A clause | What it asks | Kubernetes controls that evidence it |
|---|---|---|
| A.8.2 Privileged access rights | Restrict and manage privileged access | cluster-admin bindings audit, RBAC wildcard verbs/resources, impersonate rights, privileged containers, host namespace access (hostPID/hostIPC) |
| A.8.3 Information access restriction | Limit access to information per policy | Namespace-scoped Roles vs ClusterRoles, ServiceAccount token auto-mounting, secrets access in RBAC rules |
| A.8.5 Secure authentication | Enforce secure authentication | Anonymous auth disabled, ServiceAccount token handling, exec/attach permission scoping |
| A.8.8 Technical vulnerabilities | Manage exposure to known technical weaknesses | Configuration-level checks for known exploitable patterns (e.g. kubelet subPath CVE-2021-25741, ingress-nginx snippet CVE-2021-25742), image registry allow-lists |
| A.8.9 Configuration management | Establish and enforce secure configurations | securityContext posture (runAsNonRoot, readOnlyRootFilesystem, capability drops), seccomp/AppArmor profiles, resource limits, immutable defaults |
| A.8.16 Monitoring activities | Monitor for anomalous behaviour and events | Audit logging enabled, event capture configuration, terminal/exec session records |
| A.8.20 Networks security | Secure and manage networks | Exposed services and dashboards, hostNetwork pods, NodePort sprawl, ingress TLS |
| A.8.22 Segregation of networks | Segregate groups of services and systems | NetworkPolicy coverage per namespace, default-deny posture, cross-namespace reachability |
| A.8.24 Use of cryptography | Use cryptography effectively | Secrets encryption at rest in etcd, TLS on ingress, no plaintext credentials in specs or ConfigMaps |
| A.8.28 Secure coding | Apply secure development practices | Image provenance and signature verification, registry allow-lists, no latest-tag deployment patterns |
Notice what the mapping does to audit preparation: instead of assembling evidence per clause from scratch, you run one assessment of the live cluster and read the results clause-first. Each clause aggregates its mapped controls into a status — compliant, partial, non-compliant — with the failing workloads attached. That inversion, from "collect documents" to "score the running system," is what makes Kubernetes compliance sustainable rather than a quarterly scramble.
See your cluster scored against ISO 27001 Annex A, clause by clause.
Free, read-only, one click — private clusters included. Nothing changes in your cluster.
The mapping above covers what a scan can see. An honest evidence pack is defined just as much by the next section — what it cannot.
The honest split: ten technological clauses a live-cluster assessment can score, four organisational clauses it must label manual.
The four clauses a scan cannot prove — and why saying so matters
Four organisational and people clauses show up in any serious Kubernetes-ISO mapping precisely so they can be marked manual:
- A.5.1 Policies for information security. Whether your infosec policy exists and is approved lives in your document management system, not in etcd.
- A.5.19 Information security in supplier relationships. Vendor assessments and contractual clauses — including for your cloud provider — are ISMS artefacts.
- A.6.1 Screening. No cluster scan can evidence background checks on the people who hold cluster access.
- A.6.3 Awareness, education and training. Training records live in your HR system.
Why insist on this? Because auditors calibrate trust on exactly this behaviour. A tool that paints every clause green is a tool whose green means nothing; a report that says "these ten are scored from the live cluster, these four require your ISMS evidence" gives the auditor a clean division of labour and gives you a defensible pack. In our experience the manual labels are the part of the report auditors comment on positively — it shows the scoring is grounded rather than generated.
Walking one clause end to end: A.8.22 segregation of networks
Abstract mappings convince nobody, so here is the full chain for the clause this article opened with.
From clause to control to workload: the chain an auditor can actually follow.
The clause asks that groups of information services, users, and systems be segregated on networks. The mapped Kubernetes controls check three things: namespaces without any NetworkPolicy (the flat-network finding), internal services exposed beyond their intended scope, and pods running with hostNetwork: true that bypass pod networking entirely. The failing workloads come back not as a count but as identities — Kind, name, namespace — with the offending field path in the spec.
Verification is a two-liner per namespace:
kubectl get networkpolicy -n payments
No resources found in payments namespace.
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'
kube-system/aws-node-x7k2p
monitoring/node-exporter-4hs9dThe first result fails the clause (no segregation policy exists for a namespace that handles payment flows); the second needs judgement — DaemonSets like CNI plugins and node exporters legitimately use host networking, which is exactly why a human reviews findings rather than bulk-accepting them. The remediation path is the default-deny-then-allow rollout covered in our network policies implementation guide, and once policies exist, the clause status moves from non-compliant to partial to compliant on re-scan — an evidence trail with timestamps, not a screenshot.
Every clause in the mapping table decomposes the same way. A.8.2 walks to your cluster-admin bindings and privileged pods (pair the cleanup with our RBAC authorization guide); A.8.24 walks to etcd encryption and plaintext credentials in specs (the fix architecture is in our secrets management comparison); A.8.9 walks to the securityContext posture that Pod Security Standards enforce.
How Atmosly built this mapping — and what it does with it
A fact worth knowing if you evaluate tooling for this: Kubescape, the CNCF scanner underneath most Kubernetes posture tools, does not ship a native ISO 27001 framework. The clause mapping in Atmosly is an original overlay built on top of it: 14 Annex A clauses modelled, 26 Kubescape controls hand-mapped to them (including a derivation through SOC 2 Common Criteria tags for the overlapping set), with the four organisational clauses explicitly labelled manual rather than scored.
In practice that gives a compliance lead three things. First, a clause-first report: each Annex A clause carries a score, a status (compliant / partial / non-compliant / manual), and the list of controls and workloads behind it, sorted most-actionable first. Second, reach into the clusters you cannot expose — the scan runs inside the cluster via an outbound-only agent, so a private EKS cluster behind a corporate firewall is as assessable as a public one, with no inbound port and no exposed API server. Third, a remediation loop instead of a findings PDF: every failing control drills to the exact manifest field path, generates a verification command and a fix, and pre-loads them into an audited, namespace-scoped in-browser terminal — a human runs them, deliberately (guided remediation, not auto-remediation), and the re-scan updates the clause status. Scans are one-click and on-demand, and the security scanning surface is available on every plan, including the free tier. It is also the workflow our own team uses — Atmosly is built by an ISO 27001-certified organisation, so this mapping is the one we answer our own auditors with.
Preparing for the audit: a practical sequence
If your certification or surveillance audit is on the calendar, this order of operations works:
- Baseline scan. Run the assessment against every production cluster and record the clause-level statuses. This is your gap register — do not clean anything up before capturing it, because the improvement delta is itself evidence of a functioning ISMS.
- Fix by clause severity, not finding count. Non-compliant clauses touching access (A.8.2, A.8.3) and networks (A.8.20, A.8.22) first; partials second.
- Attach manual evidence to the manual clauses. Policy documents for A.5.1, supplier assessments for A.5.19, HR records for A.6.1/A.6.3 — filed alongside the scan output so the pack reads as one artefact.
- Re-scan on a cadence you can defend. Before the audit, after any significant platform change, and after each remediation batch — the timestamped scan history is what turns point-in-time compliance into a demonstrable process.
- Rehearse one chain. Pick a clause, and practise walking the auditor from clause to control to workload to fix. One well-walked chain buys credibility for the whole pack.
Common pitfalls when mapping Kubernetes to ISO 27001
Four mistakes show up repeatedly in Kubernetes evidence packs, and all four are avoidable:
- Overclaiming coverage. Presenting a cluster scan as "ISO 27001 compliance" invites the auditor to test the claim — and the pack fails on the first organisational clause. Frame it as what it is: technological-clause evidence for the in-scope clusters, one component of the ISMS.
- Scoping the wrong clusters. If your Statement of Applicability covers production, then staging clusters that hold production data copies are in scope too — and the cluster nobody scanned is always the one the auditor samples. Enumerate clusters explicitly; environment cloning and preview environments make "what is production-adjacent" a real question, not a rhetorical one.
- Ignoring the shared-responsibility line. On EKS, GKE, or AKS, control-plane hardening is the provider's attestation, not yours — reference the provider's own certifications (AWS, Google, and Azure all publish ISO 27001 certificates) for that layer, and evidence only what you configure: audit log settings, workload posture, RBAC, network policy.
- Static mappings against a moving standard. The 2022 revision restructured Annex A from 114 controls to 93; teams still carrying 2013-era mappings (A.9, A.12, A.13 numbering) present evidence against clauses that no longer exist. Date the mapping, name the revision, and re-validate it when either the standard or your scanner's control library changes.
The common thread: auditors reward precision about boundaries. Every pitfall above is a boundary claim made carelessly — clusters, clauses, responsibility, or versions.
What this guide deliberately does not cover
- The full ISMS. Risk assessment methodology, Statement of Applicability, management review — ISO 27001 is mostly organisational machinery, and this guide covers only the clauses a cluster evidences.
- SOC 2. The same cluster evidence maps onto SOC 2's Trust Services Criteria differently; that mapping has its own guide in SOC 2 for Kubernetes.
- CIS benchmark mechanics. Running kube-bench and Kubescape, and remediating the checks that fail by default on EKS, is covered step by step in our CIS Kubernetes Benchmark implementation guide.
- CVE and image vulnerability scanning. Everything here is configuration and compliance posture. Whether packages inside your images carry known CVEs is a separate scanning discipline with separate tools.
Key takeaways
- ISO 27001 doesn't mention Kubernetes — the mapping is on you. Ten technological Annex A clauses translate cleanly into scannable cluster controls; write the translation down before the auditor asks.
- Clause-first beats finding-first. Scoring the live cluster and reading results by Annex A clause turns evidence collection into a query, not a quarterly document hunt.
- Honesty is the differentiator. Four clauses (A.5.1, A.5.19, A.6.1, A.6.3) cannot be evidenced by any scan — labelling them manual makes the other ten credible.
- Evidence is a chain, not a screenshot. Clause → mapped control → failing workload → field path → fix → re-scan. Rehearse walking it.
- The scan history is the process proof. Timestamped clause statuses over time demonstrate a working ISMS better than any point-in-time report.
To see the clause-by-clause mapping run against your own cluster, start a free ISO 27001 scan with Atmosly — read-only, one click, private clusters included, with every finding carrying the field path that fails and the command that fixes it.
