Regulated industries do not get to treat network security as a configuration detail. Under DORA, financial entities must demonstrate that critical functions are isolated and that a breach in one segment cannot cascade into another. NIS2 extends comparable obligations to energy operators, healthcare providers, and digital infrastructure. GDPR demands that personal data be technically separated from systems that have no business touching it. The common architectural answer to all three is microsegmentation, and the gap between organisations that have implemented it rigorously and those that have not is becoming a regulatory liability.

This guide covers what microsegmentation actually means at the infrastructure level, how to design a segmentation model that satisfies the specific controls these frameworks demand, and what to watch for when you are running workloads on cloud infrastructure rather than on-premises hardware you physically control.

What microsegmentation is and is not

Traditional perimeter security draws a hard boundary around the network and assumes everything inside is trustworthy. Microsegmentation abandons that assumption entirely. Instead of one perimeter, you define granular security zones around individual workloads, services, or data classes, and you enforce policy at the workload level rather than at the network edge.

The distinction matters because most regulatory frameworks now explicitly require lateral-movement prevention. If an attacker or a compromised workload can move freely between systems once inside the perimeter, your segmentation is insufficient regardless of what your firewall rules say at the border. DORA’s ICT risk management requirements, for instance, call for controls that limit the propagation of incidents across interconnected systems. NIS2 requires operators of essential services to implement appropriate and proportionate technical measures, and supervisory authorities interpret that to include workload-level isolation.

Microsegmentation is not a product you buy. It is a policy model you enforce, and its value depends entirely on how precisely you have defined the zones and how consistently you have applied the controls.

Practically, microsegmentation is implemented through a combination of software-defined networking controls (security groups, network policies, virtual firewall rules), identity-aware proxies, and service mesh configurations that enforce mutual TLS between workloads. The enforcement point moves from the physical switch to the hypervisor, the container runtime, or the sidecar proxy.

Designing a segmentation model for regulated workloads

Start with a data classification exercise before you draw a single network boundary. You need to know which systems process personal data under GDPR, which systems are in scope for DORA’s critical or important function classification, and which assets fall under NIS2’s essential service definition. These classifications drive your zone design: systems with higher sensitivity or regulatory exposure belong in tighter zones with more restrictive egress and ingress rules.

Zone design principles

A workable zone model for a financial or healthcare environment typically has four to six tiers. A public-facing tier handles load balancers and API gateways. An application tier runs business logic. A data tier contains databases and object storage with personal or sensitive data. A management tier hosts monitoring, logging, and orchestration tooling. An external integration tier manages third-party connectivity and is treated with the same suspicion as the public tier.

Each zone boundary is a deny-by-default policy. Traffic between zones requires an explicit allow rule, scoped to the specific protocol and port the workload actually uses, not a broad subnet-to-subnet permission. This is where many implementations fall short: teams define zones correctly but then punch wide holes between them because it is operationally convenient. Those holes are precisely what regulators and auditors look for.

Identity as the segmentation anchor

On cloud infrastructure, IP addresses are ephemeral. Containers and virtual machines spin up and down, and IP-based rules become stale quickly. A robust microsegmentation model anchors policy to workload identity rather than IP. In Kubernetes environments, this means network policies keyed on pod labels and namespace selectors. In VM environments, it means security group membership tied to instance roles. In service mesh configurations, it means mTLS certificates issued to service accounts.

This approach also satisfies GDPR’s requirement for access controls based on the principle of least privilege. When a payment processing service can only reach the specific database schema it owns, and that constraint is enforced cryptographically rather than by convention, the data isolation is technically demonstrable, not just documented in a policy.

Microsegmentation for compliance: what auditors actually check

Regulatory auditors under DORA and NIS2 are increasingly technical. They do not accept architecture diagrams as evidence of control; they ask for firewall rule exports, network flow logs, and penetration test results that specifically target lateral movement. Your segmentation model needs to be auditable, which means every rule must be documented with a business justification, and the rule set must be reviewed on a defined cycle.

For GDPR network isolation specifically, the Article 32 requirement for appropriate technical measures is interpreted by data protection authorities to include demonstrable separation between systems processing personal data and systems that do not need access to it. In practice, this means your CRM database should not be reachable from your marketing analytics platform unless there is a documented, approved, and technically enforced data flow between them.

Logging is non-negotiable. Every accepted and rejected connection attempt at a zone boundary should generate a log entry, and those logs should be retained in an immutable store outside the segmented environment. Under NIS2, incident detection depends on this telemetry. Under DORA, the ICT incident classification and reporting obligations require you to reconstruct what happened and how far it spread, which is only possible if you have complete flow records.

Cloud-specific considerations for European infrastructure

When you run segmented workloads on cloud infrastructure, you are dependent on the cloud provider’s network virtualisation layer to enforce your policies. This is where European sovereignty considerations become technically relevant, not just politically. If your cloud provider is subject to foreign jurisdiction, a legal order served on that provider could potentially expose traffic metadata or configuration data that reveals your segmentation architecture. Operating on infrastructure that is governed exclusively by European law removes that vector.

Beyond jurisdiction, verify that the network policy enforcement mechanisms your provider offers give you genuine workload-level control. Some providers offer only VPC-level segmentation with limited intra-VPC policy granularity. If you cannot enforce deny-by-default between two workloads in the same virtual network, you cannot implement microsegmentation regardless of how your architecture diagram looks.

Practical implementation checklist

  • Map all data flows before defining zones: undocumented flows become policy violations the moment you enforce deny-by-default.
  • Use workload identity, not IP addresses, as the policy anchor in dynamic environments.
  • Set egress rules as strictly as ingress rules: data exfiltration exploits permissive outbound policy.
  • Enable flow logging at every zone boundary and ship logs to an immutable, out-of-band store.
  • Run quarterly rule reviews and retire any rule that cannot be tied to an active business requirement.
  • Test lateral movement explicitly in penetration tests: ask your testers to assume a compromised workload in each zone and document what they can reach.
  • Document every rule with a business justification and a review date for audit readiness under DORA and NIS2.

Operationalising segmentation without grinding delivery to a halt

The most common failure mode for microsegmentation programmes is organisational, not technical. Security teams define zones and policies, but development and operations teams find the controls too restrictive and either work around them or get exceptions approved that gradually hollow out the model. Segmentation policy needs to be embedded in the deployment pipeline, not bolted on after the fact.

Treat network policy as code. Store zone definitions and firewall rules in version control alongside application manifests. Enforce policy through CI/CD gates so that a new workload cannot be deployed without a reviewed and approved network policy. When policy is code, it gets the same review, testing, and audit trail as any other infrastructure change, which is exactly the evidence trail that DORA’s change management requirements call for.

Microsegmentation implemented this way stops being a compliance checkbox and becomes an operational capability: one that gives you genuine visibility into what is talking to what, the ability to contain incidents before they propagate, and documented evidence that your network isolation controls are real and current.