Building Controls Handover: Prove the Building Can Recover

A building management system should not be accepted solely because its graphics are complete and the contractor can connect remotely. OlbrichCo’s recommendation is to make recoverability a separate handover deliverable: the owner must know what keeps working locally, what becomes unavailable, who may intervene, and how the approved configuration can be restored. Start with the essential operating service, such as cooling for a temperature-sensitive space, rather than a list of server features.

Australia’s July 2026 CI Fortify guidance identifies dependencies such as identity services, time synchronisation, storage and certificates that can frustrate operational-technology isolation. Its critical-infrastructure context is broader than a building; the transferable lesson is to plan and test dependencies before disconnection. [6]

NIST includes building automation within operational technology and treats performance, reliability and safety as explicit security considerations. [1]

For an Iranian project, ask the controls designer and operator to define acceptable degraded operation for each consequential service. Record the permitted duration, local indication, alarm response, staffing and conditions requiring safe shutdown or evacuation under the project plan. Do not assume that removing internet access removes internal control communication, or that either action is safe. Fire, smoke-control, access and other life-safety interfaces need their responsible specialists’ explicit review.

The 2025 joint OT inventory guidance calls for assets to be classified by function and criticality, with attributes such as location, model, protocols and accounts. It treats the inventory as a maintained record, not a one-off discovery result. [2]

Require the integrator to reconcile the physical panels with the delivered record. Include controllers, supervisory servers, engineering workstations, network equipment, gateways and packaged-plant interfaces. For each, identify the owner, exact hardware and software version, approved configuration reference, support status and replacement route. Add a simple connection drawing showing which service depends on which device, network or external party. Mark unknown entries as unresolved work rather than hiding them inside an apparently complete spreadsheet.

Trace practical dependencies during a joint walk-through: where are schedules executed, alarms evaluated and histories stored? What supplies time, addressing, authentication, licences and certificate services? Which functions require the supplier’s account or laptop? Collect information through approved documentation, inspection and vendor-supported methods. Do not run an unapproved network scan or interrupt a working controller to improve the inventory. Keep a controlled Persian operating summary, with original equipment identifiers and an accessible offline copy.

The CISA-led remote-access guide recommends least privilege, risk-based just-in-time access or two-factor authentication, logging and network segmentation. Remote support is therefore an access-governance decision as well as a connectivity feature. [3]

Specify one owner-approved service route, named technicians, limited permissions, an authorised time window and a record of the work. Require the IT/security and controls teams to agree the boundary and test necessary communications before acceptance. Do not expose a controller or supervisory interface directly to the public internet. Where equipment cannot support the chosen authentication method, have the security specialist assess a controlled access gateway and compensating measures; an undocumented shared password is not a solution.

At handover, reconcile contractor accounts, temporary connections and remote-management tools. Revoke access no longer authorised and preserve an auditable emergency-access procedure in the owner’s secure custody. For sites with uncertain connectivity or distant service support, price local attendance, replacement lead time and offline diagnostic capability into the service agreement. Avoid an emergency procedure that needs the same unavailable cloud service to authorise every action. None of this permits untrained staff to override plant protections.

BACnet International describes BACnet Secure Connect as an encrypted datalink using TLS and certificates for authenticated communication. BACnet/SC complements existing BACnet options; it is one component of building-system cybersecurity, not a replacement for every security control. [4]

If BACnet/SC is proposed, ask for a maintainable certificate plan as part of the controls package. Assign responsibility for issuing, installing, renewing and replacing certificates, maintaining correct time, and handling a failed device. Demonstrate the workflow with the exact products and software versions, not just a protocol logo. Agree how authorised staff recover service if a certificate expires or a supplier changes. Keep private keys and administrative credentials out of general handover folders.

Map any legacy-protocol segment and the gateway where protection changes. Do not infer end-to-end security from an encrypted link on only part of the route. Compare the security benefit with actual device compatibility, local technical capability, renewal effort and spare availability. A phased upgrade may be sensible, but document the residual risks, approved boundaries and replacement trigger. Retain network segmentation, access control and change review alongside the protocol choice; do not claim immunity from cyber incidents.

The UK NCSC’s OT information guidance treats architecture and configuration records as sensitive information. It also advises considering how information remains accessible during incidents and protecting backups against ransomware. [5]

Define the recovery package before final payment terms are agreed. Request the approved controller applications, supervisory database, graphics, point mappings, schedules, alarm settings and network configurations, plus the authorised tools, installation media, licence arrangements and instructions required to use them. Identify what cannot be exported and how that component will be rebuilt. A readable schedule or PDF is useful evidence, but ask the supplier to demonstrate the actual import or rebuild path rather than assuming the document can restore a device.

Have the owner’s security team store controlled backups separately from routine administrator access, with protection appropriate to the site and an offline recovery route. Record date, revision, equipment compatibility and custody. Check integrity and trusted provenance; matching a file hash alone does not establish that the configuration is safe or uncompromised. After every approved controls change, refresh the recoverable baseline and relevant instructions. Include a second authorised custodian so recovery is not dependent on one individual’s availability.

NIST recommends testing backup restoration and including backups in change management. It also cautions that restoring OT state variables can disrupt physical processes—for example, a restored valve position may be inappropriate for ongoing cooling. [1]

Agree a witnessed exercise with the operator, integrator, IT/security lead and responsible engineers. Begin on a spare or suitably representative test environment; any live exercise needs an approved outage, risk assessment, safe fallback and rollback plan. Demonstrate retrieval of the owner-held package, restoration of a representative controller or server, correct point mapping and the approved operating sequence. Test the agreed loss-of-connectivity case separately. Record precisely what was simulated, what was tested physically and which dependencies remain untested.

Before returning to service, verify alarms, permissions, schedules, time, retained overrides and the required interlocks against the approved commissioning record. Keep unsafe or unexplained behaviour as an open defect. Measure elapsed recovery time, configuration age, unsupported dependencies, successful restoration coverage and unresolved access exceptions against project-defined targets. A sampled test does not prove the whole building is recoverable: prioritise the remaining critical services and schedule their verification. Exercise again after material hardware, network, software or supplier changes.

Use the findings to decide whether to accept, accept only a contractually defined limited scope, or require corrective work. This is OlbrichCo’s implementation advice, not a compliance certificate or a promise of uninterrupted operation. Governing Iranian requirements, contracts, actual plant behaviour, manufacturer instructions and competent local engineering and cybersecurity review control the final design, test authority and acceptance decision.