Ops, safety & control planes

Change management

How planned and emergency work on the facility and its control systems is proposed, assessed, approved, carried out, checked and recorded. Terms follow ITIL change enablement and Uptime Institute operations guidance. Patch policy is on Security: Lifecycle; which framework controls require change records is on Governance: Design mapping. Sources checked 6 Oct 2026.

Change types

ITIL 4 sorts changes into three types by how they are authorized; the terms are still used in ITIL Version 5 Verify (ITSM.tools, Jan 2026, secondary). A change authority is whoever may approve a given class of change: a named role, a peer reviewer, or a board. Not every change needs the CAB (change advisory board).

CAB and risk assessment

Facility changes fail differently from IT changes: the blast radius is a power path, a cooling zone or a fire zone, not a host. Ask these questions for every normal change:

• What redundancy is left during the work, and what drops if one more component fails in that window?
• Which racks, feeds and cooling zones are affected? Pull the answer from DCIM, not memory (DCIM).
• Does anything single-corded or single-fed sit on the path being worked on?
• Does it clash with other work on the same path or zone, or with a business freeze?
• Is there a written back-out, and how long does it take?
• Does it touch an in-scope system or boundary (a regulated segment, PACS/VMS, BMS/OT network, log or time sources)? If so, record the security impact and get security review (Security: Policy drift).

Keep one change calendar for IT and facilities, so a network change and a UPS bypass do not land in the same night. Bring facilities, IT and, where they own plant, the landlord or colo provider to the CAB. Uptime’s outage data on failure to follow procedures is summarized on Facility: Operations matter.

MOPs and SOPs for facility work

A MOP (method of procedure) is the step-by-step script for one change that alters the state of critical plant: opening a breaker, closing a valve. An SOP (standard operating procedure) covers routine operation and can contain MOPs. An EOP (emergency operating procedure) is the sequence to follow when an abnormal event occurs. Uptime advises tying MOPs into change management, risk-assessing them so high-risk steps get extra review, and including go/no-go checkpoints with a back-out plan (Uptime Journal, Feb 2015). A useful MOP holds:

• Scope, equipment IDs, the change record number and the approver
• Prerequisites: people and qualifications, tools, spares, OEM procedure references, notifications sent
• Numbered steps with the expected reading or state after each, and go/no-go checkpoints
• Back-out steps from each checkpoint
• Sign-off for each step and for the finished work

Write the MOP from the OEM’s maintenance procedure and the site’s one-line and piping drawings. Typical MOP subjects: UPS transfer to maintenance bypass and back (Power: UPS), generator testing, CRAH or chiller isolation and loop changes (Cooling: Controls), and fire system impairments (below).

Fire system impairments

An impairment is any condition that may stop a fire protection system, or part of one, from working in a fire. It can be planned (a closed valve for work) or found (a failed component). Handle a planned impairment as a normal change, with the impairment procedure as its MOP. Handle a found one as an emergency change.

• Sprinkler and pre-action (NFPA 25): NFPA 25 Chapter 15 sets the impairment process. Where a system is out of service for more than 10 hours in a 24-hour period, the impairment coordinator arranges one of: evacuation of the affected area, an approved fire watch, a temporary water supply, or an approved program to limit ignition sources and fuel (NFPA blog, May 2022; secondary: Zion, QRFS). Some AHJs set a shorter threshold. Confirm the edition your AHJ enforces; 2026 is current (QRFS, Jun 2026) Verify.
• Fire alarm and detection (NFPA 72): NFPA 72 has its own impairment rules covering notification, mitigation and records. Confirm the edition and requirements your AHJ (authority having jurisdiction, usually the fire marshal) enforces.
• Clean agent (NFPA 2001): disable and restore agent release only by the system manufacturer’s documented procedure, and record both in the change.
• Notify and restore: the MOP lists who to tell when the system goes out of service and when it comes back: the AHJ, fire department, alarm monitoring company and insurer, as local code and your policy require. It also includes a functional check on restoration.

The systems themselves are under Fire & life safety.

Maintenance windows and concurrent maintainability

A concurrently maintainable design lets you work on one path without an outage. While you do, the site runs on the remaining path with no redundancy (Facility: Concurrent maintainability). That window is the riskiest planned state the site is ever in, so:

• Run a pre-task check that the remaining path is healthy: no active alarms, its UPS on inverter, and dual-corded loads drawing from both feeds
• Confirm the surviving feed can carry the whole load (Power: Size A/B on the surviving feed)
• Freeze other changes on the same path and zone for the window
• Schedule a window long enough to finish or back out; a rushed window that is abandoned becomes deferred maintenance

Colo: provider change notices

In colocation the provider runs plant changes under its own process, and you get notices. Providers typically send planned-maintenance notices through the customer portal, email, and sometimes an API. Equinix, for example, describes notices that list the affected sites, the start and end times, rack-feed redundancy status, and whether resilience is affected (secondary; Equinix documentation was not reachable). Feed each notice into your own process:

• Log it as a change record of its own, linked to the provider’s reference, on your change calendar
• Assess impact from DCIM: which of your racks lose a feed or cooling redundancy, and anything single-corded
• Freeze your own changes on affected racks for the window, and staff a watcher if the risk warrants it
• For high-risk work, ask the provider for its MOP summary and back-out plan
• Remote-hands work you request is your change, not the provider’s: it needs your record, your MOP and your post-check

Notice periods, the right to defer, and maintenance reporting belong in the contract (Facility: Colo contract checklist).

Pre/post checks and rollback

• Before: snapshot alarm state and readings in DCIM, EPMS and BMS; save device configs; confirm redundancy; confirm the back-out works and who decides to use it
• Go/no-go: stop at each checkpoint if readings differ from the MOP; back out rather than improvise
• After: alarms clear, readings back to the pre-change baseline, both feeds and all cooling units back in their normal state, monitoring and alarm paths confirmed working (including fire alarm reporting after an impairment)
• Close: record the result, any deviations, and the actual start and end times against the window

Changes, DCIM/CMDB and as-builts

A change is not finished until the records match the floor. Reference DCIM or CMDB asset IDs in every change record, and use DCIM move/add/change workflows for installs so capacity, power and space data update with the work (DCIM). Update cabling as-builts (Racks: As-built records), one-line and piping drawings, and labels as part of the change, and make record updates a closure step.

Emergency change review

An emergency change skips the queue, not the record. Within a set time after the work, the emergency authority approves the change after the fact, the record is completed, and a short post-implementation review asks whether the emergency was real and whether the procedure worked. Track emergency changes as a share of all changes. A recurring emergency is a missing standard change, a missing EOP, or a reliability problem to fix.

Change evidence for auditors

Auditors sample change records and trace them both ways: from a record to the floor, and from a configuration or asset back to its record. Which controls require this is on Governance: Evidence and Design mapping. A sampled record should show:

• Request, risk assessment, and approval by the right change authority, made before the work (or, for an emergency change, recorded afterwards within the time your change policy sets; see Emergency change review)
• The MOP used, the pre- and post-check results, and the actual times
• Linked asset IDs and the updated records (DCIM, as-builts)
• For impairments, the notification and restoration records
• For significant changes to in-scope systems, the record of re-checking the affected security controls
• In colo, the provider’s notices you logged, and whether the provider’s SOC 2 system description and CC8.1 testing cover facility maintenance changes at your site, with any exceptions noted (Governance: Using a colo SOC 2)

Change design / build / manage

Design

• Define standard, normal and emergency change types and the change authority for each class of facility and IT work
• Use one change calendar for IT and facilities; put the colo provider’s notices on it
• Name the fire impairment coordinator and the notification list with the AHJ and insurer
• Colo: write notice periods, the right to defer, and MOP disclosure for high-risk work into the contract

Build

• Write MOPs for UPS bypass, generator tests, cooling isolation and fire impairments from OEM procedures before handover
• Link the change system to DCIM/CMDB asset IDs
• Build the standard-change templates for routine installs and swaps

Manage

• Run a pre-task redundancy check before every window, and post-checks against the baseline after it
• Close changes only after DCIM and as-built updates
• Review every emergency change after the fact; turn repeats into standard changes or fixes
• Keep change records retrievable for audit sampling for the retention period your policy sets (Governance: Design mapping)