An enterprise network segmentation blueprint

Create zones that mean something

Typical zones include user devices, public services, application workloads, databases, management, security tools, third parties, guest networks and critical or OT systems. Cloud workloads may need equivalent policy boundaries across accounts and virtual networks.

Each zone needs entry criteria and an owner. Avoid grouping systems only because they share an address range.

• Internet edge and DMZ
• User and corporate services
• Production application and data tiers
• Management and security infrastructure
• Third-party and guest access
• High-value or operational technology

Define controlled conduits

Document the allowed source, destination, service, direction and reason. Deny other paths by default where the operating environment supports it.

Administration should use separate hardened paths and identities. A jump service is not enough if administrators can also connect directly from everyday devices.

• Application-specific flows
• Dedicated admin access
• Restricted egress
• Monitored partner connections

Migrate without a big-bang outage

Begin with visibility. Compare observed traffic to owner-approved flows and investigate unknown dependencies. Pilot one service, enforce in stages and maintain a tested rollback.

Time-box temporary broad rules. Migration exceptions that never expire become the new flat network.

• Traffic observation period
• Owner validation
• Pilot and staged enforcement
• Expiry on temporary rules

Prove containment

Test denied paths and simulate a compromised user or workload. Confirm security operations can see blocked and allowed movement and can isolate a zone quickly.

Review policy after system changes and incidents. Keep diagrams tied to configuration and ownership records rather than a presentation file updated once a year.

• Automated path testing
• Firewall and security-group recertification
• Lateral movement exercise
• Documented isolation procedure

A practical 30-day field plan

Week one — Discover. Assets, owners, criticality and current flows. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Design. Zones, conduits, administration and exceptions. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Migrate. Observe, pilot, enforce and communicate. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Validate. Test paths, review logs and exercise containment. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Internet edge and DMZ — owner, current state, last validation and any open exception
• Application-specific flows — owner, current state, last validation and any open exception
• Traffic observation period — owner, current state, last validation and any open exception
• Automated path testing — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the security architecture outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?