Start network segmentation with the connection you cannot safely block

The proposed network boundary looks sensible until the payroll team explains that its application still calls a shared service in another environment. Blocking the connection would make the diagram cleaner and payroll unusable. Leaving a broad exception would preserve both the application and much of the exposure the project was meant to remove.

A network security architect needs to resolve that dependency before scaling segmentation. The useful first boundary is one the organisation can enforce, explain and maintain.

Follow one transaction across the boundary

Choose a business flow with an accountable owner and a clear result. Map the application components it uses, then include supporting services such as identity, name resolution, time, monitoring and administration. Recovery and maintenance paths deserve their own observations; they may be absent from ordinary daytime traffic.

Flow records show communication, not necessarily business necessity. An observed connection might belong to a retired integration, a discovery tool or an incorrectly configured client. Ask the service owner to explain why it exists and what would happen if it stopped. Conversely, a connection missing from a short observation window may be needed for a quarterly process.

That distinction prevents two common outcomes: copying every existing connection into the new allow policy, or blocking an infrequent dependency because it was not observed last week. Use the application calendar and operating procedures alongside traffic evidence.

Make each exception smaller than the uncertainty

In a hypothetical payroll pilot, the application might need one service endpoint during a scheduled exchange. A rule permitting the entire application subnet to reach an entire shared-services subnet would conceal the unresolved detail. First determine which destination, protocol and initiating component are required.

If that detail cannot be established before the pilot, define the temporary allowance, its owner and the evidence needed to narrow it. An exception without a review event tends to become the permanent architecture. The review should follow something concrete, such as completing a batch cycle or replacing the integration.

Also decide whether the shared service itself is the wrong dependency. A segmentation programme can reveal that many supposedly separate environments rely on one administrative path. Buying a more granular enforcement tool will not, by itself, remove that concentration.

Test the enforcement mechanism you actually have

For a dual-stack estate, test the same security rule over IPv4 and IPv6. A denied connection on one path does not establish that the other path is closed.

Azure network security groups illustrate why rule deployment and access termination need separate tests. Microsoft documents NSGs as stateful: changing a rule affects new connections while existing connections can remain uninterrupted. An established administrative session therefore cannot prove that a new deny rule failed, or that a newly opened connection would still be allowed.

For the pilot, test fresh connections from both permitted and denied origins. Verify the ordinary transaction, the maintenance route and a representative recovery operation. Record the source, destination and rule responsible for the result. A successful request from the correct place is only half the evidence; the rejected request from the wrong place establishes the intended boundary.

Have a controlled reversal available if an essential dependency was missed. Reversal should restore the known previous policy, with someone responsible for analysing the missed dependency before a second attempt. Repeatedly adding broad emergency rules is a warning that discovery has not caught up with enforcement.

Keep an acceptance record for each allowed flow

NHS England’s segmentation guidance describes grouping assets and controlling communication between segments. Applying that principle requires a record the operating team can use after the project ends.

Use the record during change approval. If a new destination appears, decide whether it belongs to the same service relationship or needs a separate review. Avoid letting an application change silently broaden the original boundary.

Where device admission is also changing, coordinate the network access control rollout with these flow tests. Admitting an authenticated device and permitting a workload connection are separate decisions; both need an owner and evidence.

Measure the boundary rather than the rule count

The number of policies deployed says little about how far an unwanted connection can travel. More useful measures describe the flows tested, the unnecessary paths removed and the unresolved exceptions. State the observation window and the services excluded from the pilot.

After acceptance, connect rule maintenance to application changes. A new integration should trigger a dependency decision before somebody opens a broad route to make it work. Retired applications should lose their allowances. Ownership must survive the project handover.

Remote-user access remains a related but distinct decision. Choosing between ZTNA and VPN access addresses how a person reaches an application; this segmentation exercise addresses which workload connections remain possible behind it. Treating both boundaries explicitly produces a more defensible design than calling the whole network zero trust.