Emergency Power

The emergency power requirement in NIST SP 800-53 Rev 5 PE-11 means you must have an uninterruptible power supply (UPS) that keeps your system running long enough to shut down cleanly if primary power fails. Your goal is controlled shutdown (or controlled failover if your architecture supports it), backed by documented configuration, testing, and evidence. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Provide UPS coverage that supports an orderly shutdown for the systems in your FedRAMP Moderate scope. (NIST Special Publication 800-53 Revision 5)
• Operationalize PE-11 with a UPS design, shutdown/runbook automation, monitoring, and routine testing tied to change management.
• Keep auditor-ready evidence: UPS specs, mappings to in-scope assets, test results, alarms, maintenance logs, and incident records.

“Emergency Power” sounds like a facilities issue, but under FedRAMP Moderate it becomes a systems assurance requirement: your information system must be protected from abrupt power loss that can corrupt data, damage components, or create availability and integrity incidents. PE-11 is intentionally narrow: it does not require a generator, a second utility feed, or a specific runtime. It requires a UPS sufficient to “facilitate an orderly shutdown” of the system when primary power is lost. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PE-11 as an engineering-backed control with clear acceptance criteria: (1) identify what “the system” includes in your authorization boundary; (2) define what “orderly shutdown” means for each major component (hypervisors, storage, network, management plane, supporting services); (3) implement UPS coverage and automated shutdown behavior; and (4) retain evidence that proves it works and stays working through changes, maintenance, and incidents.

This page gives requirement-level guidance you can hand to facilities, datacenter ops, cloud ops, and your assessor without translating between compliance and engineering.

Regulatory text

Requirement (excerpt): “Provide an uninterruptible power supply to facilitate an orderly shutdown of the system in the event of a primary power source loss.” (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

You need a UPS that bridges the gap between normal power and a safe state. “Safe state” is typically:

• Systems keep running long enough to flush writes and shut down cleanly, or
• Systems fail over to another power-protected zone while the impacted components shut down cleanly.

PE-11 is satisfied by proving that loss of primary power does not create uncontrolled outages or corrupt system state. The control is less about buying UPS units and more about engineered outcomes, testing, and evidence. (NIST Special Publication 800-53 Revision 5)

Who it applies to

Entity types

• Cloud Service Providers (CSPs) operating a FedRAMP Moderate environment. (NIST Special Publication 800-53 Revision 5)
• Federal agencies hosting in-scope systems (including on-prem or agency-run facilities). (NIST Special Publication 800-53 Revision 5)

Operational context (where PE-11 usually lands)

• On-prem datacenters, colocation cages, and “private cloud” environments where you control power distribution.
• Hybrid deployments where part of the authorization boundary sits in facilities you manage and part sits with a third party (for example, colo provider power plus your racks).
• Any environment where an abrupt power loss can create data integrity risk (storage arrays, databases, message queues, virtualization hosts) or recovery complexity.

Boundary note (common FedRAMP pitfall): Your “system” includes supporting components in scope, not just application servers. If management plane or security tooling is in scope and depends on the same power chain, it must be covered by UPS or be architected to tolerate sudden loss without unsafe outcomes. (NIST Special Publication 800-53 Revision 5)

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

1) Define “orderly shutdown” per component

Create a short, reviewable definition for each major platform layer:

• Compute: hypervisors, Kubernetes nodes, bare metal. Define whether they should shut down, hibernate, or drain workloads first.
• Storage: storage controllers, SAN/NAS, object storage gateways. Define write-flush and shutdown order.
• Network: switches, firewalls, load balancers that must stay up during shutdown for management access.
• Management/security tooling: logging pipelines, identity services, monitoring systems required to supervise the shutdown.

Your definition should include:

• Shutdown sequencing (what goes first, what stays last)
• Dependencies (DNS, IAM, storage, management network)
• “Stop conditions” (when you accept that shutdown is complete)

2) Map UPS coverage to in-scope assets and power paths

Build a simple power dependency map:

• Utility feed → PDUs → UPS → rack PDUs → equipment PSUs
• Identify single points of failure: one UPS serving both redundant power supplies, or one PDU feeding “A” and “B” sides.
• Confirm which assets are in authorization scope and must be included.

Deliverable: a UPS coverage matrix that lists each in-scope rack/device and its UPS source(s).

3) Set engineering acceptance criteria you can audit

PE-11 doesn’t specify runtime. You still need a defensible internal requirement that ties to your shutdown design. Example acceptance criteria (write your own, keep it measurable):

• UPS runtime supports completion of the defined shutdown sequence under expected load.
• UPS status is monitored and alarms route to an on-call function.
• Loss of primary power triggers automated shutdown or a documented, tested manual runbook.
• Shutdown does not cause data corruption and supports predictable recovery.

Avoid picking numbers you can’t consistently meet. Assessors will test your claims against evidence.

4) Implement UPS configuration, monitoring, and alerting

Core implementation pieces auditors look for:

• UPS devices installed and correctly sized for the protected load.
• Management connectivity (network card/agent) so UPS state is visible.
• Alerts for: on-battery, low battery, battery fault, bypass mode, overload, comms failure.
• Integration into your ticketing/incident process (alerts generate tracked work).

If the UPS is managed by a third party (colo), ensure the contract and SLA include access to maintenance logs, test results, and incident notifications. Treat the colo as a third party dependency in your due diligence.

5) Implement shutdown automation or a controlled manual procedure

You need a reliable path from “power loss” to “orderly shutdown.”

• Automation route: UPS signals a management host/agent; automation drains workloads, flushes storage, and powers down in a controlled order.
• Manual route: a runbook with clear triggers, roles, and steps. Manual is acceptable but creates operational risk if you cannot execute under stress or outside business hours.

Minimum runbook content:

• Trigger criteria (what indicates primary power loss vs transient event)
• Operator actions (including how to verify shutdown progression)
• Communications and escalation
• Post-event recovery steps and integrity checks

6) Test, document results, and feed the findings into corrective action

Testing is where PE-11 becomes real.

• Perform a controlled test that simulates loss of primary power (as safely as your environment allows).
• Validate alarms, shutdown sequencing, and recovery.
• Record evidence and open remediation items for any missed alerts, failed scripts, or incorrect sequencing.

Tie remediation into change management. If you adjust shutdown scripts or re-balance loads, retest the control.

7) Keep PE-11 current through change management

Every meaningful change can break PE-11:

• Adding high-draw equipment to a UPS-backed circuit
• Rewiring A/B feeds
• Moving workloads to new racks
• Changing shutdown scripts, orchestration, or storage configuration

Add a PE-11 check to change review: “Does this change affect UPS sizing, power paths, monitoring, or shutdown behavior?”

8) Make audits faster with a single PE-11 evidence package

Create a dedicated folder/package that includes:

• UPS inventory, diagrams, and coverage mapping
• The shutdown runbook or automation design
• Recent test report(s)
• Monitoring configuration and sample alerts
• Maintenance/battery replacement records
• Incident records related to power events

If you manage controls in Daydream, store the evidence package as a control “bundle” with owners, review cadence, and a simple checklist so audits do not become a scavenger hunt.

Required evidence and artifacts to retain

Use this as your evidence checklist for PE-11:

• UPS asset list (model, capacity, location, serials, management interface)
• Power dependency diagram (one-line diagram is fine) tied to in-scope boundary
• UPS coverage matrix mapping UPS-backed circuits to in-scope equipment
• Shutdown procedure (runbook) and/or automation workflow documentation
• Monitoring and alerting evidence: screenshots/config exports, routing rules, on-call schedule linkage
• Test evidence: test plan, execution record, results, issues found, corrective actions
• Maintenance records: battery health checks, battery replacement, UPS self-test logs
• Power event tickets/incidents: timeline, actions taken, outcomes, post-incident review notes

Common exam/audit questions and hangups

Auditors and 3PAOs tend to focus on:

• “Show me which in-scope assets are on UPS, and prove it.”
• “What happens when primary power drops? Who does what, and how do you know it worked?”
• “When did you last test the shutdown behavior, and what were the results?”
• “How do you ensure changes don’t overload UPS capacity or bypass shutdown sequencing?”
• “If a third party manages the facility, how do you get maintenance and test evidence?”

Typical hangup: teams provide a UPS purchase order and a policy statement, but no mapping, no test, and no proof of orderly shutdown behavior.

Frequent implementation mistakes (and how to avoid them)

• Mistake: UPS exists but isn’t connected to the right loads. Fix: validate rack-level wiring and A/B feeds; keep the coverage matrix current.
• Mistake: “Orderly shutdown” is undefined. Fix: document per-tier shutdown sequencing and dependencies; keep it short and executable.
• Mistake: No monitoring visibility. Fix: require UPS network management, alert routing, and periodic alert tests.
• Mistake: Testing is skipped because it feels risky. Fix: design a safe test method, even if it’s staged. Record what you tested and what you couldn’t test, with compensating checks.
• Mistake: Colo dependency unmanaged. Fix: contract for evidence access, include UPS and power as part of third party oversight, and retain their maintenance/test artifacts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat PE-11 risk as assurance and resilience rather than enforcement-driven. The operational risk is straightforward: uncontrolled power loss can create data integrity issues, extended recovery times, and availability incidents that cascade into SLA misses and reporting obligations. PE-11 reduces that risk by making power loss a managed event with a predictable system outcome. (NIST Special Publication 800-53 Revision 5)

Practical execution plan (30/60/90-day)

Use this as a GRC-led plan you can run with facilities and engineering. Adjust sequencing to your environment.

First 30 days (stabilize and document)

• Name an owner for PE-11 across facilities and system operations.
• Define “orderly shutdown” for each in-scope platform layer.
• Create the authorization-boundary power mapping and UPS coverage matrix.
• Confirm UPS monitoring exists and alerts reach an accountable on-call channel.
• Draft the shutdown runbook (even if automation exists, document it).

By 60 days (prove it works)

• Run a controlled test or tabletop-plus-technical validation that demonstrates: alerting, shutdown sequence, and recovery steps.
• Capture test artifacts and create remediation tickets for gaps.
• Ensure third party facility evidence (if applicable) is obtained and stored with your PE-11 package.
• Add PE-11 checks into change management templates.

By 90 days (make it repeatable)

• Close or formally accept high-risk remediation items with compensating controls.
• Standardize evidence collection: monthly UPS health review, maintenance log capture, alert test schedule.
• Build an auditor-ready PE-11 evidence bundle and keep it current.
• If your tooling supports it, track tasks, owners, and evidence in Daydream so the control stays operable between audits.

Frequently Asked Questions

Does PE-11 require generators?

PE-11 only states you must provide a UPS to facilitate orderly shutdown on loss of primary power. It does not specify generators or extended runtime requirements. (NIST Special Publication 800-53 Revision 5)

What counts as an “orderly shutdown” in a cloud-native environment?

It’s a defined, repeatable sequence that prevents data corruption and supports predictable recovery. For Kubernetes, that often means draining workloads and stopping nodes in a dependency-aware order, backed by evidence from a test.

If we host in a colocation facility, whose responsibility is the UPS?

You can rely on a third party for parts of the control, but you still need evidence. Build contractual rights to receive maintenance logs, test results, and incident notifications, and map their UPS coverage to your in-scope assets.

What evidence does an auditor usually accept for PE-11?

They typically expect a UPS inventory, mapping to in-scope systems, monitoring/alert configuration, and a recent test record showing that primary power loss leads to orderly shutdown. (NIST Special Publication 800-53 Revision 5)

How do we handle systems designed for high availability instead of shutdown?

Document the architecture decision: what fails over, what remains running, and what shuts down cleanly in the affected zone. Your evidence should still show controlled behavior during primary power loss, not abrupt failure.

We can’t safely cut power to test. Are we stuck?

No, but you need a defensible alternative: staged testing in a non-production environment, vendor-supported UPS self-test logs, and a tabletop exercise tied to verifiable technical checks (alarms, scripts, and controlled shutdown of representative components).