Who should own segmentation decisions for facilities systems?

How segmentation ownership should be organised for facilities systems

Segmentation decisions work best when they are treated as a shared control, not a facilities-only network change or a security-only policy decision. Security brings the threat model and segmentation standard, facilities understands building and utility dependencies, and clinical engineering understands how connected devices behave in practice. That mix is what makes the decision defensible, safe and operationally workable.

The ownership question matters because facilities systems often sit at the intersection of availability, physical safety and clinical workflow. A segmentation boundary can change who can reach alarms, HVAC, badge systems, BMS controllers or medical-support equipment, so the final design needs input from the teams that own those consequences. Without that shared ownership, decisions are easy to make but hard to operate.

Good ownership also means clear accountability for exceptions. If a system cannot be segmented cleanly because of vendor support, legacy protocols or an urgent operational dependency, the same cross-functional group should decide whether the exception is acceptable, how long it lasts and what monitoring compensates for it. That prevents the most dangerous failure mode, where everyone assumes someone else approved the risk.

Why single-team ownership creates blind spots

When one team owns segmentation in isolation, the design often optimises for that team’s priority and misses the real coupling between systems. Security may over-restrict traffic and break uptime, facilities may preserve connectivity but leave a broad trust path in place, and clinical engineering may inherit a design that works on paper but fails during maintenance, failover or vendor support.

Facilities environments are especially prone to hidden dependencies. A controller that seems local may depend on remote management, shared authentication, time sync, name resolution or vendor diagnostics. If those dependencies are not visible to all three owners, segmentation can create unintended outages or leave alternate paths open that defeat the control’s purpose. That is why the decision has to be reviewed as an architecture issue, not just a firewall rule request.

Ownership also affects change control. If segmentation is updated without joint review, later changes to a building system or clinical device can silently bypass the intended boundary. Shared ownership gives the organisation one place to validate impact before a port, subnet, vendor tunnel or remote support path is approved.

What the shared decision should cover

The shared owner group should decide which systems are safety-critical, which are business-critical and which can tolerate temporary isolation during maintenance or incident response. It should also define who can approve remote access, what monitoring is required at each boundary and which dependencies must be documented before a system goes live. In practice, that means the decision is not just “can we segment it?” but “what level of reachability is still safe and supportable?”

A useful model is to place security in charge of policy, facilities in charge of asset and dependency knowledge, and clinical engineering in charge of operational reality for medical or life-support related equipment. That division keeps the control from becoming either purely technical or purely operational. It also creates the evidence trail needed to show why a given boundary exists and who accepted any residual risk.

For network and control-system environments, external guidance such as NIST SP 800-207 Zero Trust Architecture is useful because it reinforces least-privilege access and explicit trust decisions, while NIST SP 800-82 Rev 3, OT Security Guide is a strong reference for segmentation in operational technology and building-control environments.

Risk and Threat Considerations

Segmentation failures in facilities systems usually show up as either overexposure or operational breakage. If the boundary is too open, an attacker or misconfiguration can pivot from a low-trust network into systems that affect physical comfort, safety alarms or remote control channels. If the boundary is too strict, critical devices may lose reachability for monitoring, maintenance or incident response.

Failure mechanism: A single-owner design often misses hidden dependencies, alternate management paths and vendor support channels, so the intended segment is bypassed or the control breaks normal operations.

Impact: The organisation can inherit silent exposure, unsafe fallback paths, delayed recovery and avoidable downtime across building or clinical support systems.

Practitioner Guidance

What to prioritise: Put one joint ownership group around the decision, with named representatives from security, facilities and clinical engineering. That group should own the segmentation standard, the exception process and the acceptance of residual risk, not just the initial design.

What to verify: Before approving a boundary, confirm the real dependencies, remote support paths, maintenance needs and emergency access requirements for each system class. If those cannot be listed, the segmentation decision is not ready.

Practitioner takeaway: The safest segmentation decisions are those that balance security, operability and safety in one forum, because the control only works when the people who understand the dependencies also own the consequences.

Related resources from NHI Mgmt Group

• How can organizations manage unauthorized agents in their systems?
• Who should own exploitability decisions when a vulnerability affects privileged systems?
• Who should own decisions when platform teams, security teams, and AI systems all influence cloud access policy?
• How should organisations govern AI systems that can make consequential decisions?