Who should be involved in a segmentation programme across application and infrastructure teams?

Segmentation works best as a team effort. Application owners should validate dependencies, infrastructure teams should explain core services, and security specialists should guide the control design. Those roles bring the operational, technical, and policy perspectives needed to set sensible communication rules and avoid blocking legitimate application traffic while tightening access.

Who should shape a segmentation programme?

Segmentation is most effective when it is designed as a cross-functional control, not as a network-only change. Application owners, infrastructure and platform teams, and security practitioners each see different failure modes, so the programme should be built around shared service dependencies, business flows, and enforceable policy boundaries rather than isolated technical preferences.

Application teams are the best source for understanding which services actually need to talk to each other, which ports and protocols are genuinely required, and what would break if a rule is too narrow. Infrastructure teams know the hosting patterns, shared services, routing layers, and platform constraints that determine where segmentation can be applied cleanly. Security specialists provide the control objective, risk tolerance, and review discipline so the design does not simply mirror the current flat network.

A good operating model usually includes system owners for the target application or service, network or platform engineering for enforcement, security architecture for policy design, and operational support teams for change and rollback planning. In larger environments, architecture, incident response, and compliance stakeholders may also need a voice where segmentation affects resilience, monitoring, or regulated data flows.

Why application and infrastructure input both matter

Segmentation fails when it is designed from topology alone or from application wish lists alone. Application owners can tell you what is truly required for business function, but they may not know where dependencies are shared across environments or where a rule would unintentionally expose a common service. Infrastructure teams can explain those shared layers, but they need the application context to avoid creating blanket exceptions that weaken the control.

The practical goal is to translate business communication paths into technical policy that is narrow enough to reduce blast radius, yet broad enough to preserve service health. That usually means identifying the minimum set of source, destination, protocol, and environment combinations that must be allowed, then testing them against representative workloads before broad rollout. The more fragmented the estate, the more important that joint validation becomes.

Security leadership should challenge any proposal that relies on undocumented dependencies, inherited trust, or “temporary” broad access. Segmentation programmes often stall when teams treat the current state as the baseline instead of an artefact to be improved. The strongest designs are the ones that can be defended with service ownership, traffic evidence, and a clear exception process.

How to organise collaboration without slowing delivery

The simplest effective model is a working group with clear decision rights: application owners confirm required flows, infrastructure engineers map feasible enforcement points, and security approves the policy standard and exception threshold. That group should work from a common inventory of applications, services, environments, and dependencies so the programme does not become a series of one-off negotiations.

For execution, start with critical applications, shared services, and zones where lateral movement would be most damaging. Use a staged approach: discover dependencies, draft rules, test in monitor mode where possible, then enforce in controlled waves. That sequence reduces the chance of breaking production traffic while still forcing the organisation to learn what is actually in use. Where the environment spans cloud and on-premises, both sides need to agree on how policies are expressed and who owns drift correction.

Segmentation also works better when teams agree on evidence. Change tickets, service maps, test results, and exception approvals should all be retained so the control can be reviewed later. Without that artefact trail, segmentation becomes hard to audit and even harder to maintain as applications change.

Risk and Threat Considerations

When the wrong teams are left out, segmentation tends to fail in one of two ways: either it blocks legitimate traffic and drives shadow exceptions, or it stays so broad that it offers little protection against lateral movement. Both outcomes increase operational risk, because the control becomes either brittle or largely decorative.

Failure mechanism: Missing application context leads to overblocking, while missing infrastructure context leads to unrecognised shared paths, inherited trust, and rules that are too coarse to contain compromise.

Impact: The organisation can suffer service disruption, weaker containment, and a false sense of security if the segmentation policy does not match how the environment actually communicates.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	5.1 — Zero Trust Principle of Least Privilege Access	Segmentation is about narrowing communication paths and trust boundaries.
Recommendation — Apply least-privilege network policy to limit each service to only required flows.
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	Segmentation directly enforces allowed communication paths between systems and zones.
	CM-2 — Baseline Configuration	Segmentation programmes need a controlled baseline for network and system settings.
	CA-7 — Continuous Monitoring	Segmentation only works if policy drift and unexpected flows are monitored.
Recommendation — Define and enforce approved information flows between applications and infrastructure zones. Establish a segmentation baseline and track deviations through change control. Monitor permitted flows continuously and investigate policy drift promptly.
CIS Controls v8	CIS-12 — Network Infrastructure Management	Segmentation relies on sound network design, management, and enforcement.
Recommendation — Implement and maintain network segments and controlled boundaries for critical services.

Practitioner Guidance

What to prioritise: Start with the applications and shared services whose compromise would create the largest blast radius. If you cannot describe the dependency in business and technical terms, do not lock it into policy yet.

What to verify: Require application owners to validate required flows, infrastructure teams to confirm the enforcement point, and security to sign off the exception criteria. A segmentation rule is not trustworthy until all three perspectives align on the same traffic path.

Practitioner takeaway: The right participants are the ones who can jointly explain required communication, platform constraints, and risk tolerance, because segmentation is a dependency-management exercise as much as it is a security control.