ISO 27001 Annex A 7.11: supporting utilities, power and failover

The due-diligence questionnaire asks when you last tested your UPS and your internet failover. There is a UPS in a cupboard somewhere, and a 4G router nobody has ever switched over to. This guide explains what ISO 27001 Annex A 7.11 expects, how to scope it for a 25–250-person firm that runs mostly in the cloud, and how to collect the evidence as a by-product of tickets and telemetry.

It is written for information security managers, IT operations leads and compliance heads who inherited the control without ever owning the plant room.

What does ISO 27001 Annex A supporting utilities (A.7.11) require?

ISO 27001 Annex A 7.11 requires you to protect the utilities your systems rely on from failure and disruption: power, connectivity, cooling and, in larger premises, water. In practice that means knowing which dependencies matter, keeping the equipment behind them serviced and tested, alerting on drift, and adding a second path where risk justifies it.

Most of that matches practice you already want. ISO 27002 classes the control as both preventive and detective. The preventive half is the redundancy, maintenance and segregation that stop a utility failure reaching your systems. The detective half is the monitoring that tells you one is under way, so an alert that reaches a person is part of the requirement.

Read ISO 27001 supporting utilities as five things asked of each dependency:

• Identify which dependencies matter: power, connectivity, cooling, plus heating, water or gas in larger premises.
• Maintain the equipment behind them on the manufacturer's schedule.
• Test the backup paths on purpose, not by accident.
• Alert a person when a reading drifts out of range.
• Duplicate the path with a battery, generator or second line where risk justifies it.

Availability is the headline property, but integrity is in play too, because a hard power loss corrupts whatever it interrupts. For the firms we serve, the exposure is rarely a data-centre generator. It is the office switch stack with no UPS, the single internet line with no 4G fallback, and client SLAs that assumed neither would ever fail.

A power blip that hard-crashes the NAS, or a dead line that silences the support desk for a day, becomes an availability incident you explain to clients. Regulated clients, under DORA-style operational resilience expectations, increasingly ask how your operations survive exactly this.

The 2022 wording adds a modern sting. The controllers behind utilities, such as building management and smart HVAC, are networked computers. The control expects them on a separate network, with internet access tightly limited. Auditors have started asking about your smart thermostat for that reason.

How do you scope A.7.11 for a cloud-first firm, and who owns it?

A cloud-first firm scopes A.7.11 to the office layer, not an imaginary data centre: clean-shutdown arrangements for network kit, internet resilience if an office outage stops client work, and segregated building systems. Document provider reliance in the Statement of Applicability, and name one owner, typically whoever owns information security, with facilities as a named contributor.

The first trap is importing data-centre controls. Generator quotes and N+1 cooling make sense for an office running production on-premises, and none for one whose workloads sit in AWS or Azure. Over-scoping wastes budget, and it invites questions about plant you do not operate.

Three questions set an honest scope:

• Does the office going dark stop client work? If it does, internet resilience is in scope.
• Which network kit needs a clean shutdown? The switch stack, firewall, NAS and any on-premises server qualify.
• Which building systems are networked? Smart HVAC, door controllers and building management kit belong in scope whatever you host.

Ownership is the second trap, and it sits between two departments. IT assumes facilities looks after the plant. Facilities assumes IT cares about the rack. The result is maintenance records that live nowhere.

The owner does not service the UPS personally. They make sure someone does, and that the record lands where you can retrieve it. Facilities contributes by name, so the contractor visit and the ticket arrive together.

That boundary also keeps the risk assessment honest. Every outage you list as likely should have a scoped control that answers it.

How do you right-size power resilience with a UPS?

Size a UPS on the comms rack to ride out short cuts and shut equipment down cleanly. NIST SP 800-53 PE-11 describes the purpose as an orderly shutdown or transition to alternate power. Test that the UPS actually signals servers to power down, service batteries on the manufacturer's schedule, and revisit capacity as racks multiply.

The NIST SP 800-53 Rev. 5 PE-11 Emergency Power Supplemental Guidance treats a UPS as short-term power. Battery duration is relatively short, but it is enough to start a standby source or properly shut the system down. That gives you a sizing test: does the battery buy the time your slowest server needs to stop cleanly?

Five steps put the power path in place:

1. List the power-dependent kit. Switch stack, firewall, wireless controllers, NAS and any on-premises server. For each, ask what breaks when power fails and how you would find out.
2. Size for the comms rack. Add up the load and choose a unit with enough runtime for a clean shutdown.
3. Make graceful shutdown real. The UPS tells the servers to power down before its battery dies, and someone has watched that sequence work.
4. Service on the manufacturer's schedule. Batteries age, so record each service date.
5. Revisit capacity as the firm grows. The unit sized for one rack quietly becomes undersized for three.

A UPS that only delays the crash by ten minutes is theatre.

The usual pitfall is the UPS as furniture. It was installed at fit-out, the batteries were never replaced, the self-test never ran, and the first real cut revealed it dead.

At this scale, one monitored rack-mounted unit and a scheduled drill satisfy both the auditor and the enterprise customer's questionnaire.

How do you prove connectivity failover and monitor the environment?

Add a second internet connection on a different medium, typically a 4G/5G failover router at this scale, then prove it by pulling the primary line and watching traffic move. Confirm the two links do not share a duct. Add temperature, humidity and water-leak sensors that alert someone, so you find out before a user complains.

Run the failover drill in a quiet window, in this order:

1. Warn staff that a short interruption is coming.
2. Pull the primary line by unplugging the WAN cable or powering the primary router down.
3. Watch traffic move. Check that the VPN, softphones and the SaaS tools you cannot work without reconnect, and note how long it takes.
4. Restore the primary and confirm traffic returns to it.
5. Record the date, the result and who ran it, ideally as a closed ticket.

Ask each carrier where its cable enters the building, and look for yourself. A cellular link avoids the shared-duct problem by design, but only if the signal at the rack is usable, so test it there.

Sensors close the loop on cooling and water. Temperature, humidity and leak sensors in the comms room should feed the alert channel your team already watches. Most firms discover that their answer to "how would we find out?" is "when someone complains", and a sensor that pages a person fixes that cheaply.

Cover the basics people forget: where the power cut-off is, whether emergency lighting works, and supplier emergency numbers that do not live only on the intranet the outage just took down.

How do you secure smart building systems and HVAC controllers?

Put building management systems, smart HVAC and door controllers on their own network segment, off the corporate LAN. Keep them unreachable from the internet unless genuinely needed, and then only through authenticated access, never a port-forward. NCSC segmentation guidance and NIST SP 800-82r3 both support that separation.

The NCSC Network Security Fundamentals on Network Segmentation describes breaking a network into smaller networks so you control how traffic flows and what access is allowed between them. The NCSC Guidance on Preventing Lateral Movement adds that systems with no need to interact belong in separate segments. The NIST SP 800-82r3 Guide to Operational Technology (OT) Security recommends separating OT networks from the corporate network, and building automation falls under it.

Five actions turn that into a configuration:

• Inventory every networked building device. Building management, smart HVAC, door controllers and anything an installer connected.
• Move them to a dedicated VLAN with a firewall rule that denies traffic to the corporate segment.
• Remove inbound exposure. No port-forwards; if a supplier needs remote access, put authentication in front of it.
• Replace installer defaults, starting with credentials.
• Draw the segment on the network diagram, because auditors increasingly ask for that specific document.

The pitfall is the controller the installer defaulted onto the corporate LAN while nobody looked. An internet-exposed HVAC controller on the office network is a documented breach path, and it is also the finding an auditor will enjoy most.

Done once, the segment costs little. The diagram then answers a question auditors have learned to ask.

What evidence proves A.7.11 operates?

Auditors expect dated maintenance records for UPS and cooling, test records for the UPS and the exercised ISP failover, monitoring configuration with an example alert, a network diagram showing building systems segregated, and emergency contacts. Small firms add a Statement of Applicability entry scoping the control; a dedicated utilities procedure is a mid-size artefact.

Each artefact proves one thing:

• Maintenance and service records for UPS, cooling and any generator, with dates that show a schedule rather than a one-off. They prove the equipment is looked after.
• Test records: UPS self-tests and shutdown drills, and the ISP failover actually exercised. They prove the backup paths work.
• Monitoring and alert configuration, an example alert and what happened next. They prove the detective half operates.
• A network diagram with building systems segregated from the corporate LAN. It proves the separation exists.
• A utility dependency assessment, however lightweight, showing capacity was weighed against growth.
• Emergency information: cut-off locations, supplier contacts and the escalation path.

A one-page dependency assessment and a clear Statement of Applicability entry beat a procedure nobody reads. Scale the paperwork to the firm, and let the records carry the weight.

A maintenance log kept only by the facilities contractor is evidence you don't own.

The control may well operate, but you cannot show it. Ask the contractor to send the service sheet to a shared mailbox or ticket after every visit, so the record arrives on your side without anyone chasing it.

How do auditors test ISO 27001 Annex A 7.11 in the walkthrough?

Expect a blackout scenario: "The power goes out at 2pm on a Tuesday. Walk me through the next thirty minutes." Auditors then ask when the UPS and failover were last tested, whether internet links share a physical path, what network building systems sit on, and for the UPS maintenance history.

Sampling follows those questions:

• The maintenance log, traced against the manufacturer's schedule for one or two units.
• The most recent failover or shutdown test record.
• The network diagram, cross-checked against reality for the building-systems segment.
• The comms rack itself, where the auditor looks for the UPS that is present but years past its battery life.

Certification-body practice grades findings in a recognisable pattern:

• Major: no resilience at all against the outages your risk assessment admits are likely, meaning no UPS, no connectivity fallback and no shutdown procedure, in an availability-sensitive firm.
• Minor: a lapsed maintenance record, an untested failover, or a building controller found on the corporate LAN.
• Major by aggregation: several minors that together form a pattern.

Prepare by rehearsing the blackout answer aloud with your named owner. The UPS carries the rack, signals shutdown, the failover router takes the internet, and the alert pages whoever is on call. If any step is a guess, that is the finding you would otherwise receive.

How do you turn A.7.11 into continuous compliance evidence?

Wire utility telemetry into your existing alert channel, and schedule each serviceable unit as a recurring maintenance ticket on its manufacturer cadence. Put quarterly failover and UPS drills on the calendar, and run a periodic scan proving the building-systems VLAN cannot reach the corporate segment. Evidence becomes a by-product, and "when did you last test it?" becomes a query.

The detective half of the control is naturally continuous, and cheap to wire up at this scale:

• Utility telemetry. UPS status (most units speak SNMP or have a cloud app), environmental sensors and connectivity monitoring feed the place your other alerts live. The alert history is standing evidence that monitoring operates.
• Maintenance tickets. Completion with the service sheet attached builds the maintenance trail without extra effort.
• Drill tasks. Results are recorded on the task, so the last test date is never a memory.
• Segment watch. A logged scan result turns the network diagram from a claim into a monitored control.

This is the continuous monitoring and automated evidence work our GRC engineering service builds. The human layer stays small: someone judges whether an alert mattered and signs off the drill. The auditor's request for the maintenance history of a UPS becomes a filter on a ticket queue.

Frequently asked questions