The first step is to convene the stakeholders who understand risk, operations, and governance, including security, legal, finance, and business leaders. They should agree on which assets are the crown jewels and map the risk of those assets and applications using a framework such as NIST CSF. That gives the organisation a practical starting point for prioritising controls and sequencing segmentation work.
Why segmentation planning starts with assets, not subnets
When segmentation is not yet in place, the first useful move is to identify what must be protected before debating network design. That means agreeing on the crown jewels, the business processes they support, and the applications or data flows that make them reachable. Without that shared scope, segmentation becomes a generic infrastructure project instead of a risk-reduction decision.
This early step matters because segmentation only helps when it is anchored to real exposure. A team that starts with zones and firewalls before understanding asset criticality can isolate the wrong systems, miss lateral-movement paths, or over-segment low-value services while leaving high-value assets too easy to reach.
How stakeholders turn crown-jewel analysis into a segmentation backlog
The most effective workshop is cross-functional. Security, operations, legal, finance, and business owners each bring a different part of the risk picture: operational dependency, regulatory impact, recovery cost, and revenue disruption. The output should be a small set of priority assets, their primary dependencies, and the control objective for each one, such as reducing blast radius, separating trust zones, or protecting regulated data.
That map is then translated into a practical backlog. The first segmentation work usually focuses on the highest-value, highest-exposure paths, especially where privileged administration, shared services, or flat east-west traffic creates the broadest attack surface. If the team cannot explain why a segment exists, it is probably not the right first segment.
For organisations looking for a governance baseline, NIST Cybersecurity Framework 2.0 is a sensible way to structure the identify and protect work that precedes segmentation. If the environment is operational technology or industrial control, NIST SP 800-82 Rev 3, OT Security Guide is especially useful because segmentation decisions must respect safety, uptime, and process-control boundaries.
What good first-step segmentation decisions look like
Good first decisions are narrow, evidence-based, and reversible. They do not try to redesign the whole estate at once. Instead, they establish where trust is currently excessive, which application paths are truly required, and which assets can tolerate immediate separation without breaking operations. That usually produces a first-wave focus on a small number of critical systems rather than an enterprise-wide rule set.
Teams should also expect that the first segmentation pass will expose gaps in inventory and ownership. That is not a failure, it is part of the point. If no one can confidently name the owner, data sensitivity, or upstream dependency for an asset, the organisation is not ready to segment it safely and should treat that uncertainty as a prioritisation signal.
For a defence model that pairs well with this approach, NIST SP 800-207 Zero Trust Architecture reinforces the idea that access should be narrowed around verified trust boundaries, not assumed by default network location.
Risk and Threat Considerations
The main risk of delaying segmentation is that flat connectivity preserves broad lateral movement paths. If one system is compromised, an attacker can often pivot to adjacent services, shared administration planes, or high-value data stores with very little resistance. The risk is not only external compromise, it is also internal propagation, accidental misrouting, and hidden dependency on shared trust.
Failure mechanism: Teams optimise for speed or convenience and leave the environment logically flat, or they segment by technical convenience rather than asset criticality. That preserves trust chains that an attacker or misconfiguration can exploit across applications, credentials, and management paths.
Impact: A single compromise can become a multi-system incident, increasing blast radius, recovery time, and the chance of data exposure or operational disruption. The longer segmentation is deferred, the more difficult it becomes to untangle dependencies without business interruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Segmentation planning depends on knowing the assets and systems to protect. |
| ID.RA-01 — Asset vulnerabilities are identified and documented | Prioritisation requires identifying exposure and weak points around crown jewels. | |
| PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Segmentation scope often depends on which privileged paths and access routes must be constrained. | |
| Recommendation — Inventory the assets and systems that will shape segmentation priorities. Document vulnerabilities and exposure around the assets you plan to segment. Restrict and audit the access paths that segmentation must eventually contain. | ||
| NIST SP 800-53 Rev 5 | RA-2 — Security Categorization | Crown-jewel analysis is a form of impact-driven categorization before control design. |
| AC-4 — Information Flow Enforcement | Segmentation is fundamentally about controlling allowed information flows between systems. | |
| Recommendation — Categorize assets by impact before selecting segmentation boundaries. Define and enforce the information flows each segment is allowed to use. | ||
| NIST Zero Trust (SP 800-207) | SC-2 — Segmentation | The question is about the practical starting point for introducing segmentation. |
| Recommendation — Use segmentation to narrow trust boundaries around the highest-value assets first. | ||
Practitioner Guidance
What to prioritise: Start with the assets whose compromise would cause the highest business or regulatory impact, then trace the minimum required pathways to and from those assets. That gives you a defensible first segmentation boundary instead of a theoretical network architecture.
What to verify: Before drawing zones, verify asset ownership, dependency chains, and which traffic is genuinely required for operations. If the dependency map is incomplete, treat the missing information as a blocker for any irreversible segmentation decision.
Practitioner takeaway: The best first step is not to design the final segmentation model, but to align leaders on what matters most, because segmentation only reduces risk when it reflects real asset criticality and real traffic dependency.
