Does your building belong in your information-system map?

Your business application is working.

The servers are available. So is the network. The database is responding normally.

Then the cooling system in the server room stops.

A short time later, temperatures rise, equipment starts entering protective shutdown modes, and the service becomes unavailable.

No server was attacked. No account was compromised. No ransomware was deployed.

Yet the information system no longer works.

This raises a simple question: where does the information system really end?

In September 2026, NIST published a new draft revision of its guidance on operational technology security. Its scope explicitly includes building automation systems, physical access control systems and environmental monitoring systems.1

In France, ANSSI likewise notes that building management systems can be critical, particularly in hospitals, laboratories and manufacturing environments.2

The boundary between IT, buildings and physical operations is becoming increasingly difficult to draw.

An asset can sit outside IT and still be part of the dependency chain

A traditional architecture map may show:

business process → application → database → server → network

That chain is useful.

But it may stop too early.

Consider a hospital application hosted in a server room. Its operation also depends on power, cooling and sometimes fire detection or physical access-control systems.

The actual dependency chain can therefore become:

care service → application → servers → server room → cooling → building management system

A building management system is not a business application.

It may even be operated by facilities teams rather than IT.

Yet if its failure can make a digital service unavailable, it belongs to the operational dependency chain of the information system.

NIST explicitly broadens the OT perimeter

NIST SP 800-82 Rev.4 defines Operational Technology as a broad set of programmable systems and devices that interact with the physical environment.

The document includes industrial control systems, building automation, transportation, physical access control and environmental monitoring.1

This changes the question.

It is no longer only:

“Which industrial systems do we own?”

It becomes:

“Which digital systems can modify, measure or control the physical environment our activity depends on?”

The answer may reveal assets that have long remained outside IT maps.

Building management is now a digital system in its own right

Building management systems can supervise heating and cooling, ventilation, electrical distribution, lighting, lifts, security systems and other technical functions.

These environments now include controllers, servers, consoles, network protocols, IP equipment, user accounts and remote connections.

ANSSI also stresses that building management is frequently outsourced and can be critical in certain environments.2

In other words, part of the infrastructure an organisation depends on can be:

digital, connected and remotely administrable, while still remaining largely outside the traditional IT perimeter.

The maintenance provider is part of the architecture too

Consider a cooling installation supervised by a building management system.

The equipment is maintained by an external company.

A technician can intervene remotely.

The chain becomes:

provider → remote access → gateway → technical network → BMS → controller → physical equipment

This representation changes the risk analysis.

The provider is no longer merely a contractual supplier.

Its access is a technical relationship that can act on a physical system the information system depends on.

In June 2026, NIST published a reference architecture for secure remote access to critical OT environments, with particular attention to authentication, access control and connection architecture.3

IT and OT can no longer be analysed separately

The old distinction was intuitive:

IT = data and applications

OT = machines and physical processes

It remains useful, but it is no longer sufficient for dependency analysis.

OT systems can use directories, DNS, Windows endpoints, hypervisors, conventional networking, supervision tools, VPN connections or cloud services.

Conversely, IT applications can depend on physical infrastructure controlled by OT.

The result can be a circular architecture:

IT → OT → physical environment → IT availability

NIST SP 800-82 Rev.4 strengthens guidance on asset management, network monitoring and OT security architecture.1

An asset inventory is not enough

Adding “BMS” or “controller” to an inventory is a first step.

But knowing an asset exists does not explain why it matters.

Its relationships must also be represented.

For example:

BMS → controls → cooling

cooling → protects → server room

server room → hosts → servers

servers → host → application

application → supports → business process

The important dependency is therefore not simply:

“we have a BMS”

but:

“this BMS indirectly helps maintain a critical business service.”

NIST’s June 2026 OT asset-management project notes that incomplete inventories reduce the ability to understand cyber risk, manage configurations and changes, and prepare for incidents.4

The physical access-control case

The same reasoning applies to another system often considered peripheral: physical access control.

Imagine a server room that can only be entered using a badge system.

That system has a server, identity database, controllers, readers, network and administration console.

A compromise may enable unauthorised physical access.

But an outage may also prevent authorised teams from reaching critical areas during an incident.

A badge system can therefore be simultaneously:

a physical-security control, a digital system and an operational dependency of disaster recovery.

This triple role is precisely what a purely application-centred architecture view can miss.

Backing up a controller is not the same as backing up a server

OT resilience also has specific constraints.

NIST’s OT Backup Quick Start Guide recommends integrating backups into change management, creating them regularly, testing them and reviewing them during recovery exercises.5

An OT backup may contain controller configuration, programs, parameters, HMI configuration, supervision rules or specialised network settings.

This creates another relationship worth documenting:

OT asset → configuration → backup → restoration procedure → required skills

Having the configuration file does not necessarily mean the organisation can restore the installation.

Constructed case: a hospital

Consider a fictional hospital.

Its electronic patient record is identified as critical.

The IT architecture is correctly mapped as:

EPR → SQL database → virtual machines → hypervisor → storage

Operational analysis then reveals:

hypervisor → server room

server room → cooling

cooling → controller

controller → BMS

BMS → technical network

technical network → administration gateway

gateway → maintenance provider

The complete chain becomes:

provider → remote access → BMS → cooling → server room → servers → EPR → care

None of these relationships means that an attack would automatically propagate from one end to the other.

But the chain makes better questions possible: which components can interrupt the service? who can administer them? which accesses exist? what alternatives are available? how long can the organisation operate without them?

Map several kinds of dependency

To represent cyber-physical systems correctly, it helps to distinguish at least four relationship types.

Technical dependency: A needs B to function.

Physical dependency: B provides a condition A requires, such as power, cooling or environmental stability.

Administrative dependency: C can modify or stop B.

Maintenance dependency: an internal or external actor is required to restore B.

The same infrastructure can combine several relationship types.

This prevents architecture mapping from becoming a simple list of equipment and cables.

A simple test: remove the asset from the map

Select an asset considered “outside IT” and ask:

“If this asset disappeared for 24 hours, which digital service would become impossible?”

For a BMS:

BMS unavailable → which building functions disappear?

For cooling:

cooling unavailable → which rooms or infrastructures are affected?

For access control:

system unavailable → which operations become impossible?

For backup power:

equipment unavailable → how long can IT remain operational?

If the answer reaches a critical business process, the asset probably belongs in the system’s dependency representation.

The useful boundary is not organisational

IT does not necessarily manage the building.

Facilities teams do not necessarily manage applications.

The BMS provider may know nothing about business processes.

Yet all of them can participate in the same availability chain.

The useful mapping boundary is therefore not:

“who owns this equipment?”

but:

“what does our activity actually depend on?”

NIST’s broader OT scope and ANSSI’s building-management guidance make this question increasingly concrete.12

Information-system mapping becomes less a picture of “IT” and more a representation of the digital and physical dependencies required for the organisation to operate.