Segments that stay segments.
A.8.22 is the ISO 27001:2022 control about segregation of networks: groups of services, users, and systems are separated into network segments, so that a compromise or a mistake in one segment does not simply walk into another. Where a perimeter decides who gets in from outside, segregation decides how much of the inside can reach the rest of the inside. In a cloud-native stack the segments are declared in code: VPCs and subnets, security groups, Kubernetes network policies. Which means one change to one policy file can quietly merge two zones that were separate the day before.
The shapes the same control failure takes.
A.8.22 weakens when a segment stops being separate. The recurring shapes:
An isolation policy widens to allow-all
The source selector on a tier's network policy or security group is emptied or replaced with a wildcard, so the tier that a few workloads could reach now accepts connections from any source the cluster's network policy layer admits.
A segment loses its policy entirely
A network policy is deleted in a cleanup as dead configuration. If no other ingress policy selects those pods, Kubernetes leaves them non-isolated and permits ingress by default.
A sensitive tier merges with a general one
A payments or data tier ends up on the same flat network as general workloads, because a shared subnet or a permissive rule replaces the dedicated segment that kept the sensitive systems in their own zone.
Egress goes unrestricted
A policy that limited which destinations a component could call is removed, so a buggy or compromised component can now reach arbitrary systems, inside or outside, instead of only its documented dependencies.
A management plane opens to every workload
An admin API, metadata service, or bastion that only operations systems should reach becomes reachable from every pod or node in the segment, so the internal audience for the sensitive plane is now everything.
A network policy that opens the data tier to every source on one port.
A new analytics service needs to read usage events from the data tier, which only pods in the API namespace could reach. The right change is an explicit allow path: the analytics workload, the one database it reads, on the port it uses. What ships instead is a from list emptied to nothing, with a comment promising to scope it later. The rule now admits every source that can route to the tier, and the widening stays in place.
ingress:- - from:- - namespaceSelector:- matchLabels:- kubernetes.io/metadata.name: api+ - from: [] # analytics also needs this; scope it later ports: - port: 5432An empty from list matches every source: the data tier's policy no longer limits ingress to the API namespace, so any workload whose traffic can route to the selected pods can connect on this port, unless source-side egress or another network layer blocks it. A.8.22 expects groups of systems to be segregated so a compromise in one segment does not simply reach another, and the data tier is the segment worth keeping narrow. Scope the allow path instead (the analytics workload's namespace and labels, on the port it uses), and land it in the same change as the service. If this policy is relied on to isolate the cardholder data environment, the widening could defeat that segmentation, and reachability testing is what would confirm it.
The diagram is evidence, not the control.
In an ISO 27001 audit, an architecture diagram is only one piece of the evidence: an auditor can compare documented network boundaries against live rules, configuration, change records, and available test results, and sample the controls around the most sensitive tiers. Where PCI DSS scope relies on segmentation, the segmentation controls get penetration-tested to confirm they isolate the cardholder data environment from out-of-scope systems. A policy emptied to allow-all can leave the diagram untouched while the enforced boundary disappears. Reviewing it at the diff can expose drift between the declared design and the policy being changed.
A review, not a firewall.
heygrc flags changes that merge network segments and cites A.8.22 so the allow path is scoped in the pull request. It does not manage your network policies or run reachability tests. It can flag the change that merges the segments, while the policy is still under review.