Microsegmentation for NIS2 and PCI DSS: What the Rules Require and What Auditors Check

Neither NIS2 nor the PCI SSC segmentation guidance uses the word microsegmentation. NIS2 asks for appropriate and proportionate security measures and, for cloud, data centre and managed service providers, spells out network segmentation in an implementing regulation. PCI DSS says segmentation is not required at all, but without it the whole network is in scope, and any segmentation you rely on must be penetration tested. So the auditor will ask to see your zones, the flows you allow between them, and the record of every change to those rules. That record is firewall change management.

This guide is for the person who has to answer that question: the network or security lead who owns the segmentation programme and the audit that follows it. How to build the segments technically, from zone models to rule volumes, is covered in our firewall microsegmentation implementation guide. Here we look at what the two frameworks actually demand and how to run segmentation so the evidence exists when the auditor arrives.

What does NIS2 require on network segmentation?

NIS2 itself requires risk-based measures, not segmentation by name. Article 21 of Directive (EU) 2022/2555 obliges essential and important entities to take "appropriate and proportionate technical, operational and organisational measures", taking into account "the state-of-the-art and, where applicable, relevant European and international standards". The list in Article 21(2) includes "policies on risk analysis and information system security" and "human resources security, access control policies and asset management". In our view, segmentation is a common way to implement those two points, but the directive leaves the method to you.

The detail sits in Commission Implementing Regulation (EU) 2024/2690. Point 6.8 of its annex, "Network segmentation", requires entities to "segment systems into networks or zones in accordance with the results of the risk assessment" and to "restrict access and communications between and within zones to those necessary for the operation of the relevant entities or for safety". It also requires a separate administration network, segregated management channels, and production kept apart from development and testing.

Read the scope before you quote it. Article 1 limits the regulation to DNS providers, TLD registries, cloud computing, data centre and content delivery providers, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers. For a manufacturer or a hospital, point 6.8 is not binding law. In our view it is still the best yardstick available, because it is the only EU text that says in plain words what adequate segmentation looks like.

What changes in Germany?

Germany transposed Article 21 as § 30 of the BSI Act (BSIG). Its first paragraph adds a sentence that matters for any segmentation programme: "Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren", meaning entities must document that they comply. § 30(3) gives the EU implementing regulation priority for the entity types listed above.

For everyone else, the practical German reference is the BSI's IT-Grundschutz module NET.1.1 Network architecture and design. It requires at least three physically separated zones (internal network, DMZ and external connections) with firewalls at the zone boundaries, clients and servers in different segments, and network documentation that includes "alle durchgeführten Änderungen im Netz", every change made to the network.

What does PCI DSS require on segmentation?

PCI DSS does not require segmentation, but it punishes its absence. The PCI Security Standards Council's guidance on scoping and network segmentation (May 2017) states that isolating the cardholder data environment "is not a PCI DSS requirement" and, in the next breath, that without adequate segmentation "the entire network is in scope of the PCI DSS assessment". Segmentation is the tool that shrinks the audit, the cost and the number of systems that need full PCI controls.

If you use segmentation to reduce scope, three duties follow:

• The assessor checks it. The same guidance says the assessor "must verify that the segmentation is adequate to reduce the scope of the assessment".
• You penetration test it. According to the same guidance, all segmentation controls must be penetration tested at least annually. For service providers, PCI DSS Requirement 11.4.6 raises this to "at least once every six months, and after any changes to the segmentation methods", according to PCI SSC FAQ 1447 (June 2025).
• Confirm scope every year. At least annually, the entity should identify all locations and flows of cardholder data and every system connected to the CDE, and retain the documentation for the assessor.

The firewall rules themselves fall under PCI DSS Requirement 1, which we cover control by control in our PCI DSS firewall requirements guide.

Which evidence do auditors ask for?

Auditors ask for the same four things under both frameworks: where the zones are, why they are there, which flows are allowed, and proof that changes to all of this were controlled. The table maps each source requirement to the firewall change evidence that answers it.

Source	Requirement	Firewall change evidence that answers it
CIR 2024/2690, 6.8.1	Zones follow the risk assessment	Zone model with a reference to the risk assessment entry behind each zone
CIR 2024/2690, 6.8.2(e)	Only necessary flows between and within zones	Zone-to-zone flow matrix; every allow rule linked to an approved request with a business owner
CIR 2024/2690, 6.8.2(f)(g)	Separate administration network and channels	Rules showing management access only from the admin zone; no exceptions without a ticket
CIR 2024/2690, 6.8.3	Review at planned intervals and after significant changes	Dated rule recertification records and a review triggered by major changes
BSIG § 30(1)	Compliance must be documented	Change records, approvals and review results kept and retrievable
BSI NET.1.1.A2	Network documentation includes all changes	Change log reconciled with the current rule base
PCI DSS scoping guidance	Segmentation adequate to reduce scope	CDE boundary rules, scope documentation, annual scope confirmation
PCI DSS 11.4.6 (service providers)	Pen test every six months and after segmentation changes	Changes flagged as segmentation-relevant, each linked to a retest

In our experience, the last row is where programmes most often fail. A retest after "any changes to the segmentation methods" only happens if your change process knows which changes those are.

Why is microsegmentation a change programme, not a project?

Microsegmentation turns one perimeter into hundreds of zone boundaries, and every boundary is a set of firewall rules that will change for as long as the applications behind it change. The initial rollout is a project. Everything after go-live is change management: new applications, new flows, decommissioned servers, temporary exceptions that someone has to remove again.

Both frameworks build that ongoing duty in. Point 6.8.3 of the implementing regulation requires review "at planned intervals and when significant incidents or significant changes to operations or risks" occur. For service providers, PCI ties the retest to changes in the segmentation. In our experience, a segmentation programme that is not wired into the change process is accurate on the day of the audit it was built for and drifts from the next day on. Our post on policy drift detection shows how that drift is caught.

How do you run microsegmentation as a change programme?

Run it in phases, and make each phase produce its own evidence. The order below is the one we would use for an estate that must satisfy NIS2, PCI DSS or both.

Phase	What you do	Evidence it leaves
1. Discover flows	Collect traffic logs or run new segment rules in monitor mode to see what actually talks to what	Flow inventory with dates and sources
2. Define zones	Derive zones from the risk assessment and the asset inventory; name an owner per zone	Zone model linked to the risk assessment
3. Design rules	Allowlist per zone pair, written as requests with owner, purpose and expiry where temporary	Approved requests, flow matrix
4. Enforce in stages	Switch one zone at a time from monitor to block, with a tested rollback	Change records with implementation and verification steps
5. Tag changes	Mark every later change that touches a zone boundary as segmentation-relevant	Filterable change history
6. Test	Penetration test segmentation on schedule and after tagged changes	Test reports linked to change IDs
7. Recertify	Owners confirm or remove the rules in their zone at a fixed interval	Signed recertification results

Phase 5 costs almost nothing and saves the most audit pain. One field in the change ticket, "touches a zone boundary: yes/no", is enough to produce the list of changes that need a PCI service-provider retest or a NIS2 review. Phase 7 is the same exercise we describe in the firewall rule recertification guide, applied zone by zone.

What does the auditor want to see on the day?

On the day, the auditor wants to pick one rule and follow it back. Which zone pair does it connect, who requested it, who approved it, when was it implemented, was it verified, and when did its owner last confirm it? If you can answer that for a random rule in a few minutes, the segmentation evidence is in order. Our NIS2 firewall evidence guide lists the full record set for Article 21.

Which mistakes break segmentation evidence?

The mistakes that break segmentation evidence are rarely technical. They are gaps between the network as built and the network as documented. These five come up again and again:

• VLANs without filtering. A VLAN separates broadcast domains, not traffic. If the routing between VLANs has no firewall policy, the zones exist only on the diagram.
• Management paths that bridge zones. A jump host or monitoring server that reaches every zone undoes the segmentation. NET.1.1 says it plainly: bridging network segments must be ruled out.
• Temporary rules that stay. Rollout weekends produce broad "temporary" rules. Without an expiry date in the change record, they become permanent.
• Untagged changes. If nobody can list which changes touched the CDE boundary since the last test, the service-provider retest after changes cannot be shown.
• Documentation drawn once. A zone diagram from the rollout project is accurate until the first change. Reconcile it with the rule base at every review.

Industrial networks add their own constraints, such as legacy protocols and maintenance windows measured in years. Our OT/IT segmentation architecture post covers that case separately.

Do you need a microsegmentation service provider?

You may need outside help for flow discovery and tooling, but in our view the zone model and the change approvals should stay with your own team. A service provider can map flows faster and bring experience with microsegmentation platforms. What it cannot do is decide which business flows are necessary, and that decision is exactly what NIS2 and PCI DSS ask you to justify.

If you bring in a provider, put three things in the contract: the flow inventory and zone model are delivered to you in a format you can maintain, every rule they create goes through your change process, and the handover includes the evidence set from the table above. A zero-trust programme raises the same question for change control in general, which we discuss in zero trust firewall change controls.

Next step

Segmentation is only as defensible as the change records behind it. Check whether yours would survive an auditor following one rule back to its approval. The free NIS2 Readiness Check walks through the records a firewall change process has to produce, including the ones a segmentation programme depends on.