Network Segmentation and Micro-Segmentation for Compliance

Network segmentation in regulated environments serves a dual purpose: it is a primary data protection control and a scope-reduction mechanism for regulatory compliance. PCI DSS v4.0 Requirement 1 (Network Security Controls) mandates that the cardholder data environment (CDE) be isolated from all other networks, with all traffic between the CDE and other zones passing through a firewall or network security control with documented, approved rule sets. PCI DSS further requires that segmentation be validated through penetration testing (Requirement 11.4.5) at least once every 12 months and after any changes to segmentation controls. HIPAA does not explicitly require network segmentation but the HHS OCR breach settlement practice has consistently cited inadequate network segmentation as a contributing factor in breaches — creating a de facto compliance expectation. DORA Article 11 requires network security monitoring covering "anomalous communications or activities" within ICT infrastructure, which presupposes network architecture with defined trust zones.

Traditional network segmentation relies on VLANs, firewall rules, and DMZ architectures to create trust zone boundaries. For regulated data environments, the minimum segmentation model separates: production from development and test environments (SOX ITGC, PCI DSS 6.4); internet-facing services (DMZ) from internal application tiers; regulated data stores (CDE, ePHI systems) from general enterprise networks; privileged management networks from user networks; and operational technology (OT/SCADA) from IT networks. Firewall rule sets for CDE boundaries must be reviewed at least every six months under PCI DSS Requirement 1.3.2 and all changes must go through change management. Micro-segmentation extends this model to the workload level using software-defined networking (SDN): each application workload, container pod, or cloud VM has a security policy applied to it regardless of network location, enforced at the virtual switch or hypervisor level using tools such as VMware NSX, Cisco ACI, or cloud-native security groups.

In cloud environments, network segmentation is implemented through VPC architecture: separate VPCs or VNets for production, staging, and development; private subnets with no internet gateway for regulated data tiers; VPC peering or Transit Gateway with explicit route tables for controlled inter-environment connectivity; and security group rules at the instance level that enforce principle of least privilege. Kubernetes network policy is the micro-segmentation mechanism for containerized workloads: Calico, Cilium, or Antrea CNI plugins enforce pod-level ingress/egress policies that must be defined for all namespaces containing regulated data. A critical nuance in regulated cloud environments is the east-west traffic problem: traditional perimeter segmentation does not inspect lateral traffic between workloads within the same subnet, enabling post-breach lateral movement. East-west inspection requires service mesh (Istio, Linkerd) with mTLS and network policy enforcement, or cloud-native tools such as AWS Network Firewall or Azure Firewall in the traffic path.

We design network segmentation architectures for regulated environments covering physical and virtual segmentation for CDE and ePHI isolation, cloud VPC/VNet design with private subnet topology, Kubernetes network policy implementation, micro-segmentation using SDN tools, and penetration test programs to validate segmentation effectiveness for PCI DSS and DORA requirements.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.