PE-11: Emergency Power

PE-11 requires you to provide uninterruptible power supply (UPS) capability so your system can perform the defined “emergency power objective” (the organization-defined parameter in the control) when primary power fails. To operationalize it, you must define what must stay powered, size and deploy UPS coverage accordingly, and retain test and maintenance evidence tied to your boundary. ¹

Key takeaways:

• Define the PE-11 organization-defined parameter first; it drives sizing, scope, and auditability. ¹
• Treat PE-11 as an engineering control plus an evidence program: diagrams, inventories, runbooks, and test records. ²
• Map ownership and recurring artifacts so assessors can trace requirement → implementation → operating evidence quickly. ¹

The pe-11: emergency power requirement sounds simple (“have a UPS”), but assessors rarely fail you for missing hardware alone. They fail you because the emergency-power objective is undefined, the UPS coverage does not match the declared boundary, or nobody can prove the UPS will support the required behavior during an outage. PE-11 is a facilities-and-IT crossover control: Facilities may manage electrical infrastructure and generators, while IT owns the system boundary, critical loads, and recovery behaviors. The compliance leader’s job is to make that handshake explicit and testable.

Operationalizing PE-11 starts with a clear statement of what must remain powered and for what purpose when utility power drops. That objective becomes the organization-defined parameter referenced in the control text, and it should tie directly to availability requirements, contingency planning, and incident response expectations for power events. Once you define it, you can translate it into a load list, runtime requirement, UPS topology, monitoring, and maintenance plan. The rest is documentation discipline: keep artifacts that show scope, configuration, testing, and corrective actions within your authorization boundary. ³

What PE-11 requires (plain English)

PE-11 requires you to provide uninterruptible power so your system can carry out your defined emergency-power objective during a loss of primary power. Practically, that means you identify the equipment that must stay up (or must shut down cleanly), install UPS capacity to support that objective, and prove through testing and maintenance records that it works as intended. ¹

The control intentionally leaves one key element to you: the organization-defined emergency power objective (ODP). If you do not define it, you cannot prove compliance because there is no measurable target for the UPS to “facilitate.” ¹

Regulatory text

“Provide an uninterruptible power supply to facilitate {{ insert: param, pe-11_odp }} in the event of a primary power source loss.” ¹

What the operator must do with this text:

1. Replace pe-11_odp with a specific, testable statement (for example: “maintain power to support orderly shutdown of hypervisors and storage,” or “maintain continuous power to network edge and identity services until generator cutover”). Your statement must be measurable during a test. ¹
2. Implement a UPS solution that can achieve that statement for the systems in scope. ¹
3. Maintain evidence that the UPS exists, is correctly connected to in-scope loads, and is periodically tested and maintained. ²

Who it applies to (entity and operational context)

PE-11 applies to:

• Federal information systems and
• Contractor systems handling federal data where NIST SP 800-53 is in scope through an authorization or contractual requirement. ²

Operationally, it applies wherever a loss of primary power could affect confidentiality, integrity, or availability because systems fail abruptly, controls stop working (badging, cameras, networking), or recovery becomes chaotic. Common contexts:

• On-prem data centers, server rooms, telecom closets, and security operations areas.
• Colocation spaces where you control the rack PDU and UPS allocation.
• Cloud deployments only for the parts you control (for example, your office networking and identity dependencies), plus any on-prem connectivity or edge equipment that supports cloud operations.

What you actually need to do (step-by-step)

1) Define the emergency power objective (the ODP)

Write the PE-11 objective as a short requirement statement that an assessor can test.

• Decide whether the objective is continuous operation for specific services, bridge time until generator cutover, or orderly shutdown to prevent data corruption.
• Define success criteria: what stays powered, what must remain reachable, and what “safe shutdown” means in your environment.
• Tie the objective to your system boundary and dependencies (identity, networking, storage, key management). ¹

Deliverable: a PE-11 control statement in your SSP or control narrative that explicitly fills in pe-11_odp. ²

2) Build an in-scope “critical load list”

Create an inventory of everything the UPS must support to meet the objective:

• Compute (hosts, hypervisors), storage, network devices, management consoles, security appliances.
• Supporting infrastructure required for the objective (console access paths, out-of-band management, jump hosts, identity components, monitoring).
• Physical dependencies: PDUs, ATS units, branch circuits, and which outlets are UPS-backed.

This is where most teams discover the gap: the UPS exists, but critical pieces are plugged into “normal” power.

Deliverable: dated load list with ownership, location, and whether each item is on UPS power.

3) Validate UPS architecture against the objective

Align engineering choices to the defined objective:

• UPS type (rack UPS vs. room UPS), redundancy (single vs. N+1), and battery runtime expectations.
• Monitoring and alerting (battery health, load %, bypass mode, self-test failures).
• Graceful shutdown integration for virtualization/storage if your objective includes orderly shutdown.

If Facilities owns the UPS, you still need IT-facing telemetry and a clear escalation path.

Deliverable: architecture diagram showing upstream utility → UPS → PDUs → in-scope loads, with demarcation of responsibility.

4) Implement operating procedures (runbooks)

Document the steps people follow during an outage:

• What alerts trigger the “power event” process.
• Who confirms utility loss and UPS status.
• What actions occur if the UPS runtime drops below what you need (prioritized shutdown order, service shedding, comms plan).
• How you restore normal operation after power returns.

Deliverable: “Power loss / UPS event” runbook referenced in incident response or contingency procedures. ²

5) Test the control and keep the records

Your tests must map to the PE-11 objective.

• Tabletop tests validate decision-making and communications.
• Operational tests validate monitoring, alerting, and shutdown automation.
• Where safe and approved, controlled power-transfer testing demonstrates real behavior.

Capture exceptions and corrective actions. “We tested” without artifacts will not survive an assessment.

Deliverable: test plan, test results, issues list, and remediation tickets.

6) Assign ownership and recurring evidence

PE-11 needs a named control owner who can produce:

• Current UPS inventory and diagrams.
• Latest test evidence.
• Maintenance evidence.
• Proof that changes to electrical layout trigger updates (change management hooks). ¹

Daydream fit: teams often track PE controls inconsistently because they span Facilities and IT. Daydream can act as the system of record for the PE-11 control statement (including the filled ODP), the owner, and the recurring evidence checklist so audit requests do not turn into a scavenger hunt. ¹

Required evidence and artifacts to retain

Keep artifacts that answer three assessor questions: What is the objective? What is implemented? Does it work?

• PE-11 control narrative with the defined ODP and boundary statement. ¹
• UPS inventory: model, serial, location, circuits/outlets covered, monitoring method.
• Critical load list mapped to UPS-backed outlets.
• One-line electrical diagram and/or rack elevation diagrams showing UPS path to loads.
• Monitoring screenshots or exported alerts demonstrating active health monitoring (battery, load, bypass).
• Maintenance records: battery replacement, firmware updates, vendor service reports.
• Test artifacts: plan, execution notes, logs, results, and corrective actions.
• Change management evidence showing UPS-impacting changes were reviewed (moves/adds/changes, rack rework, circuit changes).

Common exam/audit questions and hangups

Assessors and auditors tend to focus on:

• “Show me your pe-11_odp value. How did you decide it?” ¹
• “Which in-scope components are on UPS? Prove it for these three devices.”
• “What happens when the UPS battery is degraded? Who gets alerted?”
• “When was the last test? Did it validate the objective or just press the self-test button?”
• “How do you ensure new equipment gets placed on UPS power and not a non-backed outlet?”

Hangup pattern: IT says “Facilities handles UPS,” and Facilities provides a contract, but no mapping to the system boundary or objective.

Frequent implementation mistakes (and how to avoid them)

1. Undefined objective (ODP). Fix: write a testable statement and attach it to the system boundary. ¹
2. UPS exists, but critical dependencies are off-UPS. Fix: maintain a load list and perform periodic plug/trace verification after changes.
3. No evidence of operation. Fix: schedule recurring exports of monitoring status and keep test records with dates, results, and tickets.
4. Treating UPS self-tests as end-to-end tests. Fix: test the behavior that matters (alerting, transfer, shutdown steps) against the stated objective.
5. Split ownership with no single throat to choke. Fix: assign a PE-11 control owner with authority to coordinate Facilities, IT, and third parties.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PE-11, so this page does not cite enforcement actions.

Risk-wise, PE-11 failures typically show up as:

• Availability incidents (unexpected downtime) and integrity issues (data corruption from abrupt power loss).
• Security control failure during outages (loss of monitoring, logging, badge readers, network segmentation).
• Assessment findings due to missing objective, scope mismatch, or missing evidence. ²

Practical 30/60/90-day execution plan

First 30 days: define and scope

• Assign PE-11 control owner and backup owner; document RACI across IT, Facilities, and any colocation or managed service third party. ²
• Define pe-11_odp in SSP/control narrative with clear success criteria. ¹
• Produce critical load list and initial diagram mapping UPS to in-scope equipment.
• Identify immediate gaps (devices off-UPS, missing monitoring, expired maintenance).

Next 60 days: implement and document operation

• Remediate coverage gaps: move plugs, re-balance loads, add monitoring, fix bypass states, update runbooks.
• Create a power event runbook and align it to incident response and contingency planning documentation. ²
• Centralize evidence collection (inventory, diagrams, monitoring exports, maintenance records) in a controlled repository; track evidence requests and renewal dates.

By 90 days: test, close findings, make it repeatable

• Run a PE-11 test that validates the ODP and captures artifacts.
• Open and close remediation tickets for test failures; record lessons learned.
• Add change-management triggers: any rack move, circuit change, or new critical system requires UPS mapping validation.
• Set a recurring cadence for maintenance and evidence refresh so the control stays audit-ready. ²

Frequently Asked Questions

How do I choose the right pe-11_odp value?

Pick an objective you can test and defend: continuous operation for named services, bridge time to another power source, or orderly shutdown. Tie it to your system boundary and contingency planning assumptions so the statement matches how you actually operate. ¹

Does PE-11 require a generator?

PE-11 specifically requires an uninterruptible power supply to facilitate your defined objective during primary power loss. A generator may be part of your broader strategy, but the control text is satisfied by UPS capability aligned to the objective. ¹

What if our systems are in a colocation or managed data center?

You still need evidence that the in-scope loads supporting your system objective are on UPS power and that you can obtain test/maintenance evidence from the third party. Put those evidence and testing obligations into the contract or service reports you can retain.

How do we handle cloud services where we don’t control facility power?

Scope PE-11 to what you control: office network, identity edge, on-prem connectivity, and any hardware appliances supporting cloud workloads. Document the boundary clearly in the control narrative so assessors see what is and is not in scope. ²

What evidence is most likely to satisfy an assessor quickly?

A filled-in ODP statement, an up-to-date diagram showing UPS-backed power to critical loads, and a recent test record that demonstrates the objective. Add monitoring status and maintenance records to show the control operates over time. ³

We have UPS devices everywhere, but no single inventory. Is that a problem?

Yes, because you can’t prove coverage or maintenance without an inventory tied to the boundary and critical load list. Build a single source of truth and assign an owner who can produce it on demand. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON