- The asset inventory and system boundary worksheet — you cannot zone what you have not listed
- Current firewall and switch configurations, exported and read
- The honest list of business-to-production data flows, from the people who use them, not just from the diagram
ATL-025PLANEDITORIAL REVIEW COMPLETE
Network Segmentation Plan Worksheet
A plan for dividing the network into zones an intruder cannot freely cross: zone definitions, a from/to allowed-flows matrix in which every cell is a decision, an enforcement inventory, validation tests that prove boundaries hold, and a phased rollout that keeps production running while the walls go up.
Using this artifact
Purpose, inputs, and completion
Purpose. A flat network turns one phished laptop into everything; segmentation turns it into one zone's problem. This worksheet plans that division end to end: what the zones are, which flows between them are deliberately allowed, what enforces each boundary, and how each boundary was proven to hold. It is written for organizations doing this with one firewall and a maintenance window, not a data-center refit.
When to use it. Complete the zone table and the flows matrix on paper before touching a firewall — the matrix argument is cheaper to have in a conference room than in a change window. Then roll out in the phased order in section five, validating after each phase and dating the results. Revisit the matrix semiannually: allowed flows accumulate like sediment, and the review exists to scrape them off.
- Define zones by what lives in them and how much damage their compromise causes — not by how the switches happen to be wired today.
- Fill the flows matrix from-zone by to-zone; every cell is either a named protocol with a purpose or DENY — an empty cell is an undecided cell, not a safe one.
- Write down what enforces each boundary; a zone with no enforcement row is a drawing.
- Roll out in phases — log-only first, then block — and run the validation tests after every phase.
- Schedule OT boundary enforcement into maintenance windows with the process owner and a tested rollback; segmentation that stops the line gets rolled back and blamed for a planning failure.
Keeping it honest
Evidence, validation, and failure modes
- A zone model with a written purpose and sensitivity for each zone
- A from/to flows matrix in which every cell is a recorded decision
- Dated validation-test results showing boundaries behave as declared
- From a machine in the business zone, attempt to reach a production address the matrix marks DENY; the attempt must fail and must appear in the boundary log.
- Pick three ALLOW cells and confirm each names a protocol and a purpose someone still vouches for.
What looks done but is not
- Zones exist on the diagram, but a legacy any-any rule above the new rules quietly allows everything — and nobody ever tests from inside.
- The matrix keeps 'temporary' broad allowances for a vendor project that ended two years ago.
- Enforcement changes hit live production without a window or rollback, the line stops, and segmentation itself takes the blame.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain superseded plans and the validation-test results for each rollout phase; the record of what was verified when is the difference between a segmentation claim and a segmentation fact.
Full document
Preview — exactly what prints
PLAN · NETWORK & SEGMENTATIONv1.0 · REVIEWED 2026-08-06
Network Segmentation Plan Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
A flat network turns one phished laptop into everything; segmentation turns it into one zone's problem. This worksheet plans that division end to end: what the zones are, which flows between them are deliberately allowed, what enforces each boundary, and how each boundary was proven to hold. It is written for organizations doing this with one firewall and a maintenance window, not a data-center refit.
How to use it
Complete the zone table and the flows matrix on paper before touching a firewall — the matrix argument is cheaper to have in a conference room than in a change window. Then roll out in the phased order in section five, validating after each phase and dating the results. Revisit the matrix semiannually: allowed flows accumulate like sediment, and the review exists to scrape them off.
Zone definitions
A zone is a blast radius you have chosen in advance. Define each by purpose and by consequence of compromise, and keep the count small enough to govern.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Zone | Purpose | What lives there | Sensitivity / impact if compromised |
|---|---|---|---|
| EXAMPLE: Business LAN | Office computing | Staff laptops, printers, file server | High — contract data lives here |
| EXAMPLE: OT production | Run the plant | PLCs, HMIs, historian collector | Critical — safety and uptime; no direct business reach |
| EXAMPLE: OT DMZ | Broker business-to-production flows | Historian mirror, jump host, patch staging | Medium — exists so the two zones above never touch |
| EXAMPLE: Guest / IoT | Visitors and untrusted devices | Guest Wi-Fi, cameras, break-room TV | Low trust — reaches the internet and nothing else |
Allowed-flows matrix
One row per from-zone/to-zone pair. Every cell is either a named protocol with a purpose or DENY; a pair with no row is a decision not yet made, and the matrix is not done until none remain.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| From zone | To zone | Allowed protocols and purpose — or DENY | Rule reference |
|---|---|---|---|
| EXAMPLE: Business LAN | OT production | DENY — no direct flows; historian data crosses via the OT DMZ only | FW-CORE ruleset §12 |
| EXAMPLE: OT DMZ | OT production | OPC-UA (4840/tcp) from historian collector to PLC subnet, read-only | FW-OT rule 7 |
| EXAMPLE: Guest / IoT | Business LAN | DENY — internet egress only | FW-CORE ruleset §3 |
Enforcement inventory
Every boundary in the matrix needs something that physically enforces it — and someone who reviews that something's rules.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Boundary | Enforced by | Managed by | Last rule review |
|---|---|---|---|
| EXAMPLE: Business LAN ↔ OT DMZ ↔ OT production | OT firewall (FW-OT), deny-by-default both directions | OT / network admin, changes via change record | 2026-07-14 |
Validation tests
A boundary is validated by trying to cross it and failing. Expected result for a DENY test is always 'blocked, and the block appears in the log' — a silent block proves half of what you need.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Test | From zone | Target | Expected result | Actual result | Date / tester |
|---|---|---|---|---|---|
| EXAMPLE: Reach attempt, Modbus port | Business LAN | PLC subnet 10.20.30.0/24, port 502 | Blocked and logged | Blocked; log entry FW-OT #99172 | 2026-07-14 / N. Alvarez |
| EXAMPLE: Allowed-flow check | OT DMZ | PLC subnet, OPC-UA 4840/tcp | Succeeds from collector only; fails from any other DMZ host | As expected | 2026-07-14 / N. Alvarez |
Phased rollout
Segmentation fails politically before it fails technically — one surprise outage and the project loses its mandate. Phasing exists to spend surprise in log files instead of downtime.
Rollout order
- Phase 0 — observe
- Put the intended DENY boundaries in log-only mode for two to four weeks.
- Every observed flow either earns an ALLOW cell with a named purpose or gets a scheduled end date.
- Phase 1 — enforce the lowest-risk boundary first
- Start with guest/IoT, where a mistake inconveniences nobody, and build the change-and-validate muscle there.
- Phase 2 — enforce business boundaries
- Announce the date, keep the rollback loaded, and run the validation tests the same day.
- Phase 3 — enforce production boundaries in windows
- OT boundary changes happen only inside an approved maintenance window with the process owner present and a tested rollback (see the next section).
- After every phase — validate and date it
- Run the section-five tests and record actual results; an unvalidated phase is not complete.
OT zones and conduits
For the plant, think in zones and conduits: group production assets into zones by function and by consequence, and treat every path between zones as a named conduit with a defined purpose, direction, and protocol. If a flow into production cannot be named and justified, it should not exist — and the OT DMZ exists precisely so that business systems and controllers never speak directly.
Window discipline is non-negotiable
No enforcement change touches a production boundary outside an approved maintenance window, without the process owner's agreement, or without a rollback that has actually been tested. Blocking a flow can stop a line as surely as malware can — the difference is whether it happens at 2 p.m. on a scheduled Saturday with the vendor on call, or mid-shift with a customer order on the machine. Where vendor-supported equipment is behind the boundary, coordinate the change with the vendor so support access is re-established through the approved conduit, not through an emergency workaround that never gets removed.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Network admin |
| Approval authority | IT leader |
| Review frequency | Semiannual, and at every firewall replacement, new zone, or significant architecture change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded plans and the validation-test results for each rollout phase; the record of what was verified when is the difference between a segmentation claim and a segmentation fact. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.