A.7.11 Supporting utilities: requirements and evidence

What A.7.11 supporting utilities requires and why it is hard to evidence

A.7.11 asks that the information processing facilities holding your data are protected from power failures and other disruptions caused by failures in the utilities that support them, such as electricity, telecommunications, water and cooling. For a compliance lead, the question an assessor will ask is simple: if the utility feeding your server room fails tonight, what keeps your systems and data available, and how do you know that protection works? The risk is ordinary but serious. A failed UPS, a dropped carrier circuit or an overheating room can take down production systems, stop backups from completing and leave customer data unreachable, even when nothing has been attacked.

The control spans two groups that rarely work from the same records. Facilities teams own the generators, UPS units, cooling plant and utility contracts, while IT owns the systems that depend on them, the failover design and the restoration targets. Neither group alone can show that a power loss was survived. Evidence is therefore scattered: supplier contracts and service levels sit with procurement, maintenance and test records sit with the building operator, alarm history sits in a building management system, and application availability sits in monitoring tools that may not record why a service dropped. An assessor tracing a single outage may have to pull from four places, and gaps between them are where findings usually appear.

Before you plan any evidence, confirm three things with your facilities and IT leads: which utilities each information processing facility depends on, which of those dependencies have documented capacity and redundancy, and whether alarms from the building systems reach a place where someone is accountable for responding. Then decide where the single record of each utility test will live, because the assessor will ask for the same test to be shown from the operational side and the technical side. Our readiness work on this control usually starts with that map, so the evidence set is complete before the audit window opens.

Which facilities, utilities and third parties fall in scope for A.7.11

A.7.11 applies only to the information processing facilities and utilities inside the ISMS scope and the Statement of Applicability, so the scope statement is the first decision to get right. The cards below cover the sites, supporting services and provider arrangements that most often change the amount of evidence an assessor will ask for.

Owned data centers and server rooms

Each owned room that runs information processing needs a clear place in the ISMS scope. Document the power feeds, cooling plant, water connections and telecom entry points that serve it, because these are the supporting utilities the control protects. Confirm whether the room is a dedicated data center or a shared closet in an office building, since shared buildings often rely on landlord utilities that the organization does not control.

Comms closets and network rooms

Small network rooms are easy to leave out of scope and still hold switches, firewalls and access points that fail when power or cooling fails. List every closet that serves in-scope systems, record its UPS and cooling arrangements, and confirm whether each closet is covered by building services that an outside party maintains. An assessor will sample closets during a site walk, so an incomplete register is a visible gap.

Colocation space

In colocation, the facility operator supplies power, cooling and physical protection, but the organization still owns the cages, racks and equipment inside. Ask the operator for its own ISO 27001 certificate or SOC report and confirm which utility controls it covers. The contract should state the power and cooling service levels the organization relies on, so the A.7.11 evidence can show what was inherited and what was tested locally.

Cloud regions versus owned sites

When workloads run in a public cloud region, the provider operates the power, cooling and telecom services for that facility. The organization's own A.7.11 work moves to reviewing the provider's assurance evidence, checking that the chosen regions and availability zones match the stated resilience needs, and documenting any dependency on on-premises links or edge sites. Confirm which provider reports and which regions they cover before the scope is signed off.

Utilities that support the site

Electricity, telecommunications, water supply and HVAC are the utilities named in the control's scope. For each in-scope site, list the external supplier, the internal distribution (generators, transformers, chillers, pumps) and the internal owner. Utilities owned by a landlord or municipality still belong in the analysis, because the organization must know their failure modes and how it is alerted when they fail.

Statement of Applicability and scope wording

The ISMS scope statement defines which sites, services and suppliers are inside the management system, and the Statement of Applicability records whether A.7.11 applies and why. An exclusion of a site or utility needs a justification that an assessor can test, and an inherited control needs a named provider and evidence. Review the wording with the certification body before the first audit, since a scope that omits a facility the organization actually uses is a common source of findings.

How an assessor tests supporting utilities controls

This table walks through the areas an assessor typically examines for A.7.11, from the physical walkthrough of power and cooling to alarm and test records. Read each row as a question the assessor will ask, the evidence that answers it, and where organizations most often fall short. The main takeaway is that an untested backup system is treated as an unverified one, so test records matter as much as the equipment itself.

Assessment area	What the assessor does	Evidence expected	Common findings
Power walkthrough	Walks the facility from utility feed to rack, tracing each path that carries power to information processing equipment	Single-line diagrams matched to the physical site, and labeled distribution panels	Diagrams that no longer match installed equipment after a later change
Cooling and environmental plant	Inspects HVAC units, chillers and their controls, and checks which systems the critical room depends on	Equipment inventory, maintenance contracts, and environmental set points with recorded alarm thresholds	Cooling depends on a single unit with no documented fallback
Capacity and load records	Compares current load on UPS, generators, circuits and cooling against rated capacity	Trend reports or periodic load readings, with the date and author of each review	No capacity review since the last hardware expansion
Redundancy design	Confirms that UPS, generators, dual power feeds and carrier connections are in place as the design states	Design documents, contracts for each carrier or feed, and the configuration of transfer switches	Redundant paths share one upstream feed or one carrier route
Generator and UPS testing	Asks when generators were last run under load and when batteries were last tested, then reviews the results	Dated test logs with load, duration, outcome and corrective actions for any failure	Generators started but never run under load, or tests skipped during maintenance windows
Alarm configuration	Checks which utility faults raise alarms, who receives them, and whether alarms reach someone who can act	Alarm rule lists, notification routing, and records of alarms raised and acknowledged	Alarms configured but routed to a mailbox nobody monitors
Telecommunications supply	Reviews the carrier arrangements that keep network connectivity to the facility	Carrier contracts, diverse route documentation, and records of failover tests	Two carriers that share the same building entry point
Incident and outage records	Looks at past utility failures and how the organization responded and improved	Incident tickets, root cause notes and changes made after each outage	Outages recorded without a review of why the backup did or did not work

How to implement A.7.11 step by step

This sequence turns A.7.11 from a statement about utilities into a documented set of dependencies, tested safeguards and recurring evidence that an assessor can trace from the risk register to the test record. Each step produces an artifact that the next one depends on.

Inventory facilities and utility dependencies
List every room, rack, data hall, network closet and site that houses information processing facilities, then record which utilities each depends on: electricity feeds, backup generators, uninterruptible power supplies, cooling, water, fire suppression and telecommunications circuits. Facilities staff, building managers and the IT platform team should sign off together, because the building often holds the utility knowledge the IT team lacks. The output is a dependency map that ties each facility to its utility suppliers and upstream feeds. The step is done when every information processing location appears on the map and each dependency has a named owner.
Assess capacity and failure impact
For each dependency, record the design capacity, current load, growth expectations and the consequence of loss, such as how long systems can run on battery or how quickly temperature rises if cooling stops. Compare the load on each supply against its rating and note where a single feed or single cooling unit carries critical services. Link each high-impact dependency to an entry in the risk register so the treatment decision is visible. The output is a capacity record and a failure impact assessment, reviewed by the risk owner. The step is done when every critical dependency has a documented capacity figure and an accepted or treated risk entry.
Define redundancy and monitoring requirements
Based on the impact assessment, set the redundancy each facility needs, such as dual power paths, standby generation, spare cooling capacity or diverse telecommunications routes, and state the monitoring each dependency requires, including what is measured, the threshold and who receives the signal. Some requirements will be met by the landlord or a colocation provider, so write those obligations into the contract or service schedule and request their evidence. The output is a written requirements register. The step is done when each requirement has an owner, a measurable target and a source of evidence.
Configure alarms and escalation paths
Implement the monitoring defined in the previous step with the tools the organization already runs. Open-source options include Prometheus, which collects metrics from instrumented jobs over HTTP and stores them as time series, and Grafana Alerting, which builds alert rules from queries across multiple data sources and manages them from one view. Facility sensors such as power meters and temperature probes often need exporters or a building management integration, so confirm each signal's source before relying on it. Define escalation: who is paged, the fallback contact, and the expected response. The output is the alert rule set and the escalation matrix. The step is done when a test signal reaches the named on-call person.
Schedule tests and maintenance
Set a calendar for testing each safeguard, covering generator start and load transfer, UPS discharge behavior, failover of cooling and telecommunications circuit switchover, and the maintenance routines the suppliers recommend. Agree in advance what a pass means for each test and how a failed test is logged and fixed. Where a test requires a planned outage or affects customers, coordinate it through change management. The output is a test schedule and a set of test reports, each showing the date, scope, result, observed gaps and corrective actions. The step is done when at least one full cycle of tests has been executed and recorded.
Review results and feed the risk register
Once a test or alarm exposes a gap, record it, decide whether to fix, accept or transfer the risk, and update the dependency map, capacity record and risk register accordingly. Management should review the trend of alarms, test failures and supplier incidents at a defined cadence and document the decisions. Supplier performance, such as response times or maintenance visits, should be checked against the contracts. The output is a review record that shows what changed and why. The step is done when every finding has a documented decision and an owner, and the risk register reflects the current state of the utilities.

How redundancy, alarms and monitoring fit together for supporting utilities

A.7.11 is met by a chain of linked parts rather than a single device, so the organization should first map how those parts connect. The utility feeds (mains power, telecommunications circuits, water and the cooling plant) each need a defined failure mode, a backup path and an alarm that reaches a person who can act. Backup power such as uninterruptible power supplies and generators, and cooling sized for the load, must be designed against the same risk assessment that drives the rest of the physical controls for the site. Which feeds are dual-sourced, how long backup power must carry the facility, and what temperature or humidity limits trigger action are decisions the organization owns. An implementation partner can document and build these choices, but it cannot make them for the organization or certify that they are adequate.

Environmental sensors give the control its observable signals. Temperature, humidity, power quality and generator or UPS status can be exported as metrics to a self-hosted collector such as Prometheus, which gathers values from instrumented jobs over HTTP and stores them as time series on local storage that can be queried with PromQL. Grafana Alerting can then build alert rules from those queries, combine metrics with logs, and route notifications through a single view. The alert thresholds, escalation paths and on-call owners belong in the organization's own runbook. Ask whether each threshold traces back to a documented requirement for the equipment, and whether a test alarm has been triggered and acknowledged on a schedule. Confirm each integration with the vendor of the sensor or UPS, since not every device exposes the same data.

Monitoring data is the evidence an auditor uses to see the control working between certification audits, because it shows real readings, alarms and responses over time instead of a single snapshot. Keep the alert history, acknowledgement records, failover tests and maintenance tickets together so one incident can be traced from the sensor reading to the response. The NIST crosswalk maps A.7.11 to contingency planning controls (CP-8, and the PE family controls PE-9 through PE-15), and ENISA's NIS2 mapping links it to the supporting utilities point of Implementing Regulation (EU) 2024/2690. NIST cautions that mapped controls are not always equivalent, so these mappings are useful starting points for planning, not proof that one control satisfies another. Confirm with the certification body how it wants this evidence presented.

Evidence that passes A.7.11 and how to keep it current

An assessor testing A.7.11 Supporting utilities wants to see what the facility depends on, how much headroom it has, and whether the protections work when tested. Each card below is one record that answers part of that question. Every record needs a named owner and a date, and most need a scheduled refresh so the evidence still describes the site when the auditor arrives.

Facility dependency register

A register lists every utility the information processing facility relies on: grid feeds, telecom carriers, water for cooling, chilled water and HVAC units, and the breaker panels that serve each rack. For each dependency, record the provider, the supplied capacity, the protected load and the failure mode. Review it after any change to racks, circuits or providers, and at least once a year. Ask whether a dependency has no named owner, because an unowned utility is usually the one that fails unnoticed.

Capacity and load reports

Load reports show actual power draw and cooling demand against the rated capacity of the UPS, generators, and HVAC plant. Assessors look for trend data rather than a single snapshot, and for a documented threshold that triggers capacity review. Export the readings on a fixed schedule, store them with a date stamp, and name the engineer who signs off each report. A report that shows headroom shrinking over several months is evidence that the process works, even before any outage occurs.

UPS and generator test logs

Test logs record each transfer test, load bank run, and battery check for the uninterruptible power supply and standby generators. Each entry should show the date, the test type, the duration, the load applied, the result, and the technician who carried it out. Keep the logs in the same system for the whole assessment period so gaps are visible. Confirm that tests cover real transfer under load, not only a visual inspection, because an auditor will ask how the organization knows the backup works.

Utility contracts and service records

Contracts with electricity, telecom and water providers, plus maintenance agreements for generators, UPS units and cooling plant, define the service levels the organization depends on. Store each contract with its start date, renewal date, named contact, and the response times in the agreement. Service visit reports show who attended, what was done and whether the fault was closed. Ask the procurement team to flag contracts that are nearing renewal, since an expired service agreement often surfaces only during an audit.

Alarm configuration exports and alert history

Alarm configuration exports show which conditions raise alerts, such as loss of mains supply, UPS on battery, generator fault, high temperature or water leak, and who receives each one. Alert history shows when those alarms fired and how long each took to acknowledge. Grafana Alerting and Prometheus can hold metric and log based rules for power and environment data, so export the rule definitions with version history. Confirm that alerts reach a staffed channel outside working hours.

Corrective action records from failed tests

When a generator fails to start or a cooling unit drops below its set point, the corrective action record shows the cause, the fix, the retest result and the approver. These records are often the strongest evidence in an assessment because they show the control detected a failure and the organization acted on it. Link each record to the original test log entry, and set a date by which the corrective action must close. An open action with no owner or deadline is a finding waiting to be written.

What meeting A.7.11 costs in money and effort

This table separates the cost components of supporting utility protection by who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where self-hosted open-source monitoring removes license spend, while the facility and utility costs stay with the organization. No figures are given because none are supplied; ask each vendor and contractor for their own pricing against a written scope.

Cost component	Who is paid, one-time or recurring	What drives it up or down
Backup power and cooling hardware	Equipment vendors and installers. One-time capital cost, with replacement and servicing recurring	Redundancy level, load size, site count and whether capacity is added in stages
Utility and carrier contracts	Electricity, water and telecom providers. Recurring service fees and usage charges	Contracted capacity, diverse supply paths, contract term and renegotiation at renewal
Monitoring tooling and licenses	Software vendors for commercial tools. Recurring subscriptions or support fees	Number of sensors and data sources, retention period and alert volume; open-source alternatives remove license fees but not hosting effort
Engineering time for alert build-out	Internal staff or implementation partner. One-time setup, then recurring tuning	Number of utility feeds to monitor, alert routing complexity and integration with existing on-call processes
Facilities and engineering time for testing	Internal facilities staff or contractors. Recurring, per test cycle	Test frequency, whether tests include live failover, and the number of sites that must be tested
Evidence upkeep	Internal compliance or operations staff. Recurring	Frequency of test records, how automatically logs and dashboards are exported, and how many sites must show evidence
External review and auditor sampling	Independent certification body or auditor. Recurring with each audit cycle	Number of sites in scope, sampling approach and the completeness of records ready at audit time

Open-source monitoring tools that produce A.7.11 evidence

A.7.11 is easier to demonstrate when power, cooling and utility signals are recorded continuously and alerts leave a trail. Prometheus collects and stores the readings, and Grafana Alerting turns them into alerts and an auditable history. Both run inside the organization's own infrastructure, so the evidence stays under its control.

Prometheus metric collection

Prometheus scrapes metrics from instrumented jobs over HTTP using a pull model, then stores them as time series identified by metric name and labels. For A.7.11, the question is whether the site's power, cooling and network signals reach Prometheus at all. Confirm which sensors, PDU or UPS interfaces and building management outputs can be exposed as metrics, and whether a separate exporter or gateway is needed for each. Record the scrape targets and their configuration as part of the evidence set.

Facility signals as time series

Power draw, UPS battery state, generator status, temperature and humidity readings become time series that can be queried over any period. An assessor can then see whether supporting utilities were monitored continuously, not only when someone looked. Define which labels identify each site, room and feed so that a single query can show the state of a specific utility during a specific window. Local storage retention should match the review cycle your organization sets.

PromQL queries for utility checks

PromQL expresses checks such as a sustained drop in UPS charge, a temperature trend that exceeds an agreed threshold, or a feed that stops reporting. Saved queries are repeatable, so the same check can be run during internal reviews and audit sampling. Document each query, its threshold and the owner who reviews it. Thresholds should come from the facility design and the risk assessment, not from default values.

Grafana Alerting rules

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so a rule can combine Prometheus metrics with logs from building or facility systems. Rules route notifications to the people responsible for power, cooling and telecom services. Confirm that the alert conditions, notification paths and escalation contacts are written down and reviewed, since assessors test whether alerts reach someone who acts on them.

Alert history and single-view management

Grafana lets teams create, manage and act on alerts from one view, which supports the evidence of who responded to a utility failure and when. Export or retain alert state history and the acknowledgement notes that accompany it. Keep these records together with incident tickets so that a supporting utility outage can be traced from the first alert to the recovery and any follow-up test.

AGPL-3.0-only license and exporter checks

Grafana is licensed under AGPL-3.0-only, which carries source disclosure obligations if the software is modified and offered to users over a network. Have counsel review the terms before modifying Grafana or embedding it in a service. Prometheus is Apache-2.0. Facility hardware exporters vary widely, so confirm with each vendor that a suitable exporter exists for your UPS, generator, CRAC unit or metering equipment, and that its license is compatible with your use.

Who owns A.7.11 and what an implementation partner can take on

Your organization owns A.7.11 in full. The control covers the utilities that keep information processing facilities running, so the decisions about power, cooling, water and telecommunications capacity sit with the people who run the site and sign the supplier contracts. An implementation partner can advise on those decisions, but it cannot make them for you, and an auditor will ask who approved each one.

Utility contracts and service levels: Your team holds the contracts with electricity, telecom and facilities suppliers, and records the service levels and maintenance commitments those contracts contain.
Capacity and redundancy decisions: Your team decides the required capacity, the level of redundancy and the acceptable downtime for each facility, and records the reasoning.
Facility and alarm ownership: Your team assigns who responds to utility alarms, who approves changes and who is accountable for the monitoring rules.
Testing approval: Your team approves the test plan for failover, generator runs and UPS tests, and signs off the results.
Statement of Applicability entry: Your team decides how A.7.11 applies to each site and records that decision in the Statement of Applicability.

Check that each of these items has a named owner, a review date and a record that shows who approved it.

Common gaps in supporting utilities controls and how to close them

Auditors who test A.7.11 Supporting utilities usually find the same weaknesses: equipment that has never been exercised, thresholds nobody wrote down, and alerts with no one accountable for them. The cards below describe each gap, why it matters for the control, and the practical fix the organization owns, with an implementation partner able to prepare the systems and evidence.

Backup generators never tested under load

A generator that starts on a timer but has never carried the real facility load is an untested assumption, not a control. Many sites run short self-tests with no load bank, no transfer test and no record of fuel quality or battery condition. Fix it by writing a test schedule that covers start, transfer and sustained run, recording the results, and logging every failed start as a finding with an owner. Confirm the test procedure and frequency with your facilities vendor and your own risk assessment.

No documented capacity thresholds

A.7.11 expects supporting utilities to be sized for the information processing facilities they serve, yet many organizations never write down the power, cooling or network capacity they rely on or the level at which action is required. Document the design capacity, the warning and critical thresholds for each utility, and who acts at each level. Review the figures whenever racks, circuits or cooling units change.

Utility alarms with no owner

Environmental and utility alarms often fire into a shared mailbox or chat channel that nobody watches after hours. An auditor will ask who receives each alarm, how acknowledgement is recorded and what happens when no one responds. Assign a named owner and a backup for every alarm class, define escalation steps with time limits set by your own service levels, and keep acknowledgement records. Metrics tools such as Prometheus and Grafana Alerting can route alerts from power and temperature sensors to these owners, but routing must be configured and tested, and the team must confirm the alert rules match the thresholds on file.

Utility dependencies missing from the asset inventory

Asset registers usually list servers and applications but omit the power distribution units, UPS units, chillers, carrier circuits and building management links those systems depend on. When a single feed fails, the team cannot tell which services are affected. Record each utility as an asset with its owner, its supplier, the systems it supports and its dependencies, and link it to the continuity plan. The inventory should be reviewed when a site or supplier changes.

Test and maintenance results not retained

Teams often run a generator test or a cooling failover, fix what they find, and then have no record of the result. An auditor sampling the control will ask for the most recent tests and the findings that followed. Keep dated records of each test, including the procedure used, the result, the defects found, the corrective action and the person who signed off. Store them in the evidence repository your ISMS already uses, with retention set by your own policy.

Redundancy assumed but never proven

Dual power feeds, second network carriers and spare cooling units are often described in diagrams but never failed over in practice. A.7.11 links directly to A.8.14 Redundancy of information processing facilities, so an untested failover leaves both controls weak. Schedule planned failover exercises for each supporting utility, record the time taken to restore service, and feed the lessons into the capacity and continuity documents. Confirm failover design with your facilities and network providers before any live test.

Questions buyers ask about A.7.11 cost, effort and outside help

What drives the cost of meeting A.7.11 supporting utilities?

The cost depends mostly on how much of the power, cooling, network and water chain is already documented, monitored and tested, and how many sites hold information processing facilities. Your organization pays for its own facilities work, such as generator or UPS maintenance, cooling capacity and carrier contracts, which often exist already for business reasons. Added cost comes from monitoring build-out, alert routing, test records and any capacity upgrades an assessment exposes. Costs that recur include test runs, alert tuning and quarterly review time. When you ask for a quote, ask the partner to separate one-time build work from recurring support, and to list which sites and utilities are in scope.

Can a small team handle A.7.11 in-house?

A small team can usually handle A.7.11 in-house if it has a named owner, a short list of facilities, and access to the people who manage power and cooling. The work is mostly documentation, monitoring and testing rather than new engineering. Where a small team struggles is in producing consistent test records and keeping alerts reviewed over time. Outside help makes sense when no one has the time to run the test cycle, when the environment spans several sites, or when an assessor needs an independent view of the setup. Decide the split before you start, so the internal owner knows which records they must keep.

How long does the evidence work for A.7.11 take?

The duration depends on the number of sites, the state of existing monitoring, and how often the organization must run its test cycle before an assessor reviews the records. No fixed duration applies across environments, so ask any partner for a timeline based on your written scope. Plan for the work to span at least one full cycle of inspection, alarm testing and failover checks, because assessors look for records across time rather than a single snapshot. Ask the partner which milestones produce evidence, and when your internal team must sign off each one.

What does A.7.11 need from facilities and IT teams?

Facilities teams own the physical side: power feeds, uninterruptible power supplies, generators, cooling, fire suppression and water supply to the building. IT teams own the monitoring, alert routing and the records that show systems stayed available or recovered during a disruption. Both groups should agree on who reviews alarms, who approves test plans and where records are kept. Typical inputs include maintenance logs, capacity reports, carrier service levels and alert histories. Confirm these owners and inputs in writing before the assessment starts, since gaps there tend to surface as nonconformities.

Can we inherit A.7.11 controls from our cloud provider?

Partly. A cloud provider can supply evidence about the physical and power infrastructure in its data centers, usually through its compliance documentation and audit reports. Your organization still has to show how its own information processing facilities depend on that infrastructure, including regions, redundancy choices, backup locations and how it monitors availability. Read the provider's shared responsibility terms and its available audit reports, then map the parts that cover your workloads. Any inherited evidence should be documented as inherited, with the scope and date it covers, and the gaps left for your own team should be listed clearly.

What can an implementation partner sign off for A.7.11, and what can it not?

An implementation partner can prepare the monitoring, test plans, runbooks and evidence packs that show A.7.11 is in place, and it can review those artifacts against the control. It cannot issue an audit report, attestation or certificate. Those come only from an independent auditor or certification body. The organization owns the control, makes the risk decisions and signs the Statement of Applicability. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Ask any partner to state these boundaries in writing within the scope of work.

What should we ask a partner to include in a fixed-scope quote?

Ask for a written scope that lists the sites, facility types, utilities, monitoring tools and systems in scope. Request the deliverables by name, such as alert configurations, test procedures, test records templates, runbooks and an evidence index. Ask which items are one-time and which recur, and what support or retainer applies after the first cycle. Confirm your own obligations, including who provides facility access and who approves changes. DeployOpen plans most engagements on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts, and provides a quote that follows from that written scope.

Where A.7.11 sits relative to NIST and NIS2 requirements

The cross-references for A.7.11 Supporting utilities matter most when one set of evidence has to satisfy several frameworks at once. Start with the lineage: A.7.11 is the 2022 successor to control A.11.2.2 Supporting utilities in the 2013 edition, and the correspondence table in ISO/IEC 27002:2022 Annex B traces one to the other. If your existing ISMS already had A.11.2.2 evidence, such as UPS test records and generator run logs, that evidence carries forward, but you should re-check it against the 2022 control attributes and purpose rather than assume it still reads the same.

NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022, posted to the OLIR catalog in November 2023, relates A.7.11 to seven SP 800-53 controls: CP-8 from the Contingency Planning family and PE-9, PE-10, PE-11, PE-12, PE-14 and PE-15 from the Physical and Environmental Protection family. In practice this points you toward the same artifacts: telecommunications service priority, power equipment and cabling, emergency shutoff, emergency power, temperature and humidity controls. NIST itself cautions that mapped controls are not always equivalent, so a mapped control is a starting point for your own gap analysis, not proof that one control satisfies another.

ENISA's mapping table for its NIS2 technical implementation guidance, version 1.2 (August 2025), links A.7.11 to point 13.1 on supporting utilities in the Annex to Commission Implementing Regulation (EU) 2024/2690. If you are an in-scope entity under NIS2, confirm with your national competent authority and your assessor whether that link is sufficient for your obligations. Mappings are guidance. Before you cite one in a Statement of Applicability or a regulator submission, ask your certification body or assessor to confirm equivalence in writing, and record which mapping you relied on and why.

How DeployOpen prepares supporting utilities evidence

DeployOpen prepares the evidence for A.7.11 Supporting utilities as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before work starts. The scope usually names the information processing facilities in question, such as a server room, a colocation cage or the rack space hosting the client's self-hosted platforms, and lists each utility feed that matters there: utility power, UPS and generator, cooling, network carriers and water or fire suppression where relevant. Writing this list down first gives the client a fixed boundary that an auditor can walk and test. DeployOpen does not own these utilities or the facility contracts behind them. The client owns its controls, and the client's facilities or landlord team owns the physical plant.

Inside the client's own infrastructure, DeployOpen can deploy self-hosted monitoring and alerting so that utility failures leave a record. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series, which suits readings from UPS and PDU exporters, temperature sensors and network device health. Grafana Alerting builds alert rules from queries across those data sources and can route alerts to the people who must respond. The configuration, alert thresholds, notification routes and retention settings are then stored as code so the client can show what was set and when it changed. Before handover, the client should confirm that each vendor-specific exporter exists for its hardware and that the monitoring stack has its own power and network path, because a monitor that fails with the facility it watches proves nothing.

DeployOpen then prepares test procedures and an evidence pack that the client and its independent auditor can use. Typical test steps include a documented power failover test, a check that generator start and fuel reserves are recorded, an alarm test that confirms a threshold breach reaches a named person, and a review of the logs from the last test cycle. The evidence pack holds the scope statement, the monitoring configuration, dated test records with results and corrective actions, and the responsible owner for each utility. The client decides how often these tests run, who signs them off and how findings enter its risk register. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or certification body does that, and the client should confirm early which body will review the evidence.