Kubernetes and ISO 27001: Which Controls the Architecture Satisfies

TL;DR. A Kubernetes platform can satisfy roughly a dozen Annex A controls structurally, meaning the architecture enforces them rather than a policy describing them: access control, network segmentation, configuration management, change management, logging, and capacity. It cannot satisfy any control whose subject is a decision, an obligation or a person, which is most of the organisational and people themes. The failure mode is not a missing control, it is a control that is enforced by the platform and cannot be evidenced, because the evidence aged out of a default retention window.

ISO 27001:2022 lists 93 controls in Annex A across four themes: organisational, people, physical and technological. Platform teams tend to read the technological theme, recognise most of it, and conclude the cluster does the heavy lifting. Auditors tend to read the organisational theme, see none of it in a cluster, and conclude the cluster is irrelevant. Both readings are wrong in the same way: they treat the platform as either the whole control set or none of it, when it is a specific and stable slice.

This post sets out that slice. It assumes a platform built the way most competent teams build one now: declarative manifests in Git, reconciled continuously, admission control enforcing policy, RBAC that is not cluster-admin for everyone, and network policy in place. Nothing exotic.

What the architecture enforces structurally
What it enforces only if you configured it that way
What no cluster can satisfy
The evidence problem, which is the real one
How this maps onto the UAE Information Assurance Standards

1. What the architecture enforces structurally

These are the controls where a correctly built platform is not evidence of the control, it is the control. The distinction matters: for these, an assessor examining the cluster is examining the control itself rather than a report about it.

A.5.15 Access control and A.8.2 Privileged access rights. Kubernetes RBAC is a real, enforced authorisation model with a deny-by-default posture. Bind roles to groups from the identity provider rather than to individuals, and the joiner-mover-leaver process becomes a group membership change rather than a cluster operation. The trap: most clusters carry at least one long-lived service account with cluster-admin, created during installation and never removed, which unpicks the control quietly.

A.8.20 Network security and A.8.22 Segregation of networks. NetworkPolicy is enforced by the CNI, not documented in a diagram. A default-deny posture per namespace plus explicit allow rules is a segmentation control an assessor can test by attempting a connection.

A.8.9 Configuration management. This is the strongest fit in the whole standard. Declarative manifests reconciled continuously mean configuration drift is detected and reverted by the system, which is a stronger claim than any organisation makes about its servers. Admission policy turns the standard into an executable rule.

A.8.32 Change management. A change is a pull request with a review, an approval, and a reconciliation. The approval record is the control evidence and it exists whether or not anyone remembers to produce it.

A.8.6 Capacity management. Requests, limits and autoscaling are capacity management expressed as code, with historical data behind it.

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: payments
spec:
  podSelector:
    matchLabels: {app: ledger}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: {name: edge}
          podSelector:
            matchLabels: {app: gateway}
      ports:
        - protocol: TCP
          port: 8443

A.8.20 and A.8.22 as enforced objects rather than a diagram

2. What it enforces only if you configured it that way

These controls are within the platform's reach and are not satisfied by default. Every one of them is a decision somebody has to have made, which is why they are the controls most likely to be claimed and not held.

A.8.7 Protection against malware and A.8.8 Management of technical vulnerabilities. Image scanning in the pipeline is necessary and not sufficient: a scan at build time says nothing about an image that has been running for four months. What closes the control is admission control refusing unsigned or unpinned images, plus a rebuild cadence. The policy below fails closed, which is the only setting that means anything.

yaml

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-signed-images
spec:
  failurePolicy: Fail            # closed, not open
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    - expression: >
        object.spec.template.spec.containers.all(c,
          c.image.startsWith('registry.internal/') &&
          c.image.contains('@sha256:'))
      message: "images must be internal and pinned by digest"

A.8.8 enforced at admission, failing closed

A.8.24 Use of cryptography. Secrets in Kubernetes are base64-encoded, not encrypted, unless encryption at rest is configured against a KMS. Assessors know this and ask. An external secrets operator pulling from a real secret manager is the pattern that survives the question, because it also answers who holds the key.

A.8.15 Logging and A.8.16 Monitoring activities. The control plane audit log is where the answer to "who did what" lives, and it is frequently off, or on with a retention window measured in days. Workload logs are not a substitute: they show what the application did, not who changed the platform.

A.8.13 Information backup. Backing up etcd is not backing up the platform, and neither is backing up volumes without the objects that reference them. The control is satisfied by a restore you have performed, not by a job that reports success.

3. What no cluster can satisfy

Roughly two thirds of Annex A is out of reach of any platform, and pretending otherwise is how a certification programme runs aground three weeks before the audit. The organisational theme asks who decided, on what authority, reviewed how often. The people theme asks about screening, terms of employment, disciplinary process, and what happens on the day somebody leaves. The physical theme asks about the building.

Three specifically catch platform-heavy organisations:

A.5.7 Threat intelligence and A.5.24 to A.5.28, incident management. A cluster produces alerts. It does not produce an incident process, a severity model, an escalation path, or the record that an incident was reviewed afterwards.
A.5.19 to A.5.22, supplier relationships. Every managed service in the platform is a supplier, and the control asks what you verified about them and when, not which vendor you chose.
A.5.23 Information security for use of cloud services. The one control that looks like it belongs to the platform team and does not. It is about the decision to use the service, the terms it was accepted under, and what happens at exit.

The useful mental model: the platform can enforce a rule, it cannot own an obligation.

4. The evidence problem, which is the real one

Here is the failure we see most often, and it is not a missing control. The platform is genuinely well built. RBAC is tight, network policy is enforced, admission control rejects bad images, every change went through review. The audit asks the organisation to demonstrate that these controls were operating during the period under review, and the answer is a screenshot of the current state.

Current state is not evidence. A control that was operating all year but cannot be shown to have been operating scores the same as one that was not, because the assessor has no way to distinguish them. Default retention in most clusters is short enough that the beginning of the assessment window is already gone.

   Git (declared state)                    Cluster (actual state)
   ┌──────────────────────┐                ┌──────────────────────┐
   │ manifests + policy   │  reconcile ──▶ │ workloads            │
   │ reviewed, signed,    │ ◀── drift      │ RBAC, NetworkPolicy  │
   │ merged by 2 people   │                │ admission decisions  │
   └──────────┬───────────┘                └──────────┬───────────┘
              │                                       │
              │ commit history                        │ audit log + events
              ▼                                       ▼
   ┌────────────────────────────────────────────────────────────┐
   │ Evidence store (retained ≥ assessment window)              │
   │  who changed what, when, who approved, what was rejected   │
   └────────────────────────────────────────────────────────────┘
                              │
                              ▼
              Control shown OPERATING, not DECLARED

Both halves of the platform already emit the evidence

The fix is architectural rather than procedural. Both halves of the picture, the declared state in Git and the actual state in the cluster, already emit a durable record. Git carries who proposed a change, who approved it, and when it merged. The cluster carries the audit log, admission decisions including the rejections, and reconciliation events. Route both into a store with retention that exceeds your assessment window, and every control above becomes demonstrable as a query rather than as an exercise.

The rejections matter more than most teams expect. An admission policy that has never rejected anything is indistinguishable from one that is not enforcing, and the rejection log is the cheapest possible proof that the control is live.

5. How this maps onto the UAE Information Assurance Standards

For organisations in the Emirates the same platform work counts twice. The UAE IA (NESA) Standards carry 188 controls across 15 families, and the technical families T1 to T9 cover the same ground as the Annex A technological theme: asset management, access control, network security, monitoring and cryptography. A platform built for the ISO controls above will hold most of the technical UAE IA controls with mapping rather than rework.

What does not transfer is the shape of the obligation. UAE IA marks 35 controls Always Applicable regardless of your risk assessment, all of them management controls, and it sequences the rest into priority tiers where P1 may be augmented and never reduced. That is stricter than the ISO model, where applicability follows the risk assessment and the Statement of Applicability justifies the outcome. A team that has built to ISO and assumes the risk-based logic carries over will find the gap in exactly the controls the cluster was never going to satisfy.

Where the cluster runs on a public cloud there is a further layer, since a control operated by the provider still has to be evidenced by you. We set that out in the cloud security controls reference.

Kubernetes and ISO 27001: Which Controls the Architecture Actually Satisfies

Contents

1. What the architecture enforces structurally

2. What it enforces only if you configured it that way

3. What no cluster can satisfy

4. The evidence problem, which is the real one

5. How this maps onto the UAE Information Assurance Standards

Further reading