PE-11(1): Alternate Power Supply — Minimal Operational Capability

PE-11(1) requires you to provide an alternate power supply that activates at a defined point and can keep the system running at a minimally required operational capability during an extended primary power loss. To operationalize it, define “minimal” per system, design tested power failover (UPS/generator/cloud), and retain run-time, test, and maintenance evidence. ¹

Key takeaways:

• Define “minimally required operational capability” in business terms (what must stay up, for how long, and at what service level) and get it approved.
• Engineer alternate power that activates at your chosen trigger (automatic vs manual) and validate it with repeatable tests.
• Evidence matters as much as engineering: keep diagrams, run-time calculations, test results, and maintenance logs mapped to the system boundary. ²

PE-11(1): alternate power supply — minimal operational capability requirement is easy to misunderstand because teams jump straight to “buy a generator” without first defining what “minimal operations” means for the specific system. The control is narrower and more operational than many policy-heavy requirements: you must have alternate power, it must activate at a defined point, and it must sustain the system’s minimally required operational capability through an extended outage. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a design-and-evidence control. You are coordinating facilities, IT operations, cloud/platform, and continuity planning to produce three outcomes: (1) a documented minimum operational state, (2) implemented alternate power architecture that meets that minimum, and (3) proof that it works under test conditions and is maintained. Done well, PE-11(1) also reduces incident impact, prevents unsafe shutdowns, and supports broader resilience expectations you will face under related NIST physical/environmental controls. ²

Regulatory text

Requirement (verbatim): “Provide an alternate power supply for the system that is activated {{ insert: param, pe-11.01_odp }} and that can maintain minimally required operational capability in the event of an extended loss of the primary power source.” ¹

Operator translation (what you must do):

1. Provide alternate power within the system’s operating environment (facility, data center, wiring closet, edge site, or cloud hosting arrangement as applicable to your boundary).
2. Define the activation point (the parameter in the text). You choose and document the trigger, such as automatic cutover on utility failure, cutover after UPS low-battery threshold, or manual start with defined response time. ¹
3. Sustain minimal operations long enough to cover an extended outage, based on what your organization defines as “minimally required operational capability” for that system. ²

Plain-English interpretation

PE-11(1) is a continuity-of-operations control for power loss scenarios. It does not demand full capacity or normal user experience during an outage. It demands that you identify the smallest set of functions that must remain available (or fail safely) and then ensure alternate power keeps those functions operating.

“Extended loss” is intentionally contextual. For an on-prem environment, it usually means “longer than UPS-only runtime,” which pushes you toward generator, dual utility feeds, battery systems sized for longer durations, or a designed shutdown that still preserves the “minimal capability” you defined (for example, keeping storage and network up long enough to replicate, checkpoint, and maintain integrity).

Who it applies to

Entity types

• Federal information systems and contractor systems handling federal data adopting NIST SP 800-53 Rev. 5 controls. ²

Operational contexts where PE-11(1) shows up in audits

• On-prem data centers and server rooms (enterprise or colocation).
• Edge and OT-like deployments (branch sites, plant floors, remote cabinets).
• Hybrid environments where on-prem power supports identity, connectivity, or security tooling needed even when primary apps are “in cloud.”
• Third-party hosted facilities: your system boundary may rely on a third party’s power architecture; you still need assurance and evidence.

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

Step 1: Set control ownership and boundary

• Assign a control owner (often facilities + IT ops jointly) and a GRC owner accountable for evidence completeness.
• Define the system boundary: which racks, network devices, storage, and supporting services are in scope for “system” in this control.

Deliverable: Control implementation statement tied to the system security plan or equivalent, naming owners and in-scope components. ²

Step 2: Define “minimally required operational capability”

Write a short, testable definition. Keep it measurable even if you avoid hard numbers. Include:

• Critical functions: authentication, core transaction processing, logging/SIEM forwarding, backup integrity, safety controls, or “safe shutdown.”
• Minimum service state: read-only mode, reduced capacity, queued processing, or “preserve data integrity and resume within defined recovery procedures.”
• Dependencies: network, DNS, IAM, storage, cooling, fuel contracts, ATS, monitoring.

Tip: If stakeholders argue, force a decision: during an outage, do you need “continue operating” or “controlled stop that preserves integrity”? Both can satisfy “minimal capability” if documented and supported by power design.

Deliverable: “Minimal Operational Capability” annex approved by system owner/business owner.

Step 3: Choose the activation model (the parameter)

The control explicitly requires that the alternate power supply is activated at a defined point. Decide and document one of these:

• Automatic failover (preferred for many environments): utility loss triggers ATS and generator start; UPS bridges the gap.
• Manual activation with strict procedure: acceptable where automation is impractical, but auditors will scrutinize response time, staffing, and test records.

Deliverable: Activation criteria and procedure (runbook), including who is paged and how cutover is verified. ¹

Step 4: Implement the alternate power design

Common design patterns (pick what fits your boundary):

• UPS-only for short bridging plus controlled shutdown to meet minimal capability.
• UPS + generator for longer runtime.
• Dual power feeds / redundant PDUs for equipment resilience.
• Cloud approach: if the “system” is in cloud, your alternate power may be a facility responsibility for the endpoints you still own (network, identity appliances, security sensors) plus documented reliance on the cloud provider for platform power. Keep the evidence focused on your boundary and your third-party assurance.

Deliverables: One-line diagram, rack power map, list of protected loads, and inventory of UPS/generator assets.

Step 5: Prove runtime and load assumptions

You need to show that the alternate supply can maintain the minimal capability. Do the engineering homework:

• Identify the minimal load (which devices stay powered).
• Document how runtime is achieved (battery runtime calculations, generator capacity, fuel plan, or shutdown sequencing).

Deliverable: Runtime justification worksheet tied to the minimal capability definition.

Step 6: Test and maintain on a schedule

Auditors expect that alternate power works when needed.

• Perform planned failover tests (utility pull / ATS test / UPS transfer test as appropriate).
• Validate monitoring and alerting: power event detection, ATS state, generator alarms, UPS battery health.
• Track maintenance: battery replacements, generator servicing, fuel checks, breaker inspections.

Deliverables: Test scripts, test results, issue tickets, corrective actions, and maintenance logs mapped to the system.

Step 7: Map to your broader resilience program

PE-11(1) should connect to incident response and continuity artifacts:

• Power-loss scenario in tabletop exercises.
• Restoration procedures (order of operations for bringing services back).
• Third-party dependencies (colocation or managed data center) and contract/SLA evidence.

Practical note: Daydream-style control mapping helps here because the pass/fail outcome often hinges on missing evidence, not missing hardware. Maintain a single evidence list with clear recurrence (tests, maintenance) and owners.

Required evidence and artifacts to retain

Use an evidence register that ties each artifact to the system and review period.

Evidence item	What it proves	Typical owner
Minimal Operational Capability definition + approval	What “minimal” means and who accepted it	System owner / GRC
Power architecture diagram (UPS/ATS/generator/feeds)	Alternate power exists and scope is clear	Facilities / IT
Asset inventory of UPS/generator and protected loads	What is covered	IT ops
Activation criteria + runbook	Trigger is defined and actionable	IT ops / Facilities
Runtime/load justification	Alternate power sustains minimal state	Facilities engineer
Test plan + results + remediation tickets	Operability under outage conditions	Facilities / IT ops
Maintenance logs and service reports	Ongoing reliability	Facilities
Third-party attestations / reports (if hosted)	Assurance for outsourced facility power	Third-party risk / GRC

(Requirement basis: NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

• “Show me what ‘minimal operational capability’ means for this system.” If it’s vague, you will spend the audit arguing instead of demonstrating.
• “What is the activation point?” Auditors look for a documented trigger and evidence it is configured or practiced. ¹
• “Prove the runtime.” They will ask what stays powered, how long, and why that meets your definition.
• “Is the alternate power included in the system boundary?” If facilities owns it, you still need system-level evidence and clear accountability.
• “Show the last test and what you fixed.” A perfect test record is less believable than a record that found issues and closed them.

Frequent implementation mistakes and how to avoid them

1. Buying equipment without defining minimal operations. Fix: write and approve the minimal capability statement first; it becomes your sizing and scoping input.
2. Assuming a building generator covers the system. Fix: document protected circuits, ATS paths, and whether cooling and network closets are on backed power.
3. No evidence of activation settings. Fix: keep ATS configuration, UPS settings, and runbook steps under change control.
4. Testing only the generator, not the full chain. Fix: test end-to-end: utility loss, UPS transfer, ATS operation, load acceptance, monitoring alerts, and restoration steps.
5. Third-party blind spot. Fix: if a third party hosts the environment, obtain and retain their relevant assurance artifacts and map them to your system boundary.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, PE-11(1) risk shows up as operational outages that become security events: uncontrolled shutdowns can cause data corruption, gaps in logging, missed detections, and delayed incident response. Your goal is to prevent power events from turning into integrity and availability failures that trigger reporting, customer impact, or contractual breaches.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Assign owners (facilities + IT ops + GRC) and confirm the system boundary.
• Draft and approve “minimally required operational capability.”
• Document the activation point and current-state power architecture.
• Build an evidence register and collect existing maintenance and test records.

Days 31–60 (close design gaps and formalize procedures)

• Perform a gap assessment: what loads are not on backed circuits, what lacks redundancy, and where monitoring is weak.
• Update runbooks for power events; put them under change control.
• Confirm third-party responsibilities and obtain relevant assurance documents if hosting is outsourced.
• Create a repeatable test plan and success criteria tied to minimal capability.

Days 61–90 (prove operation and make it repeatable)

• Execute an end-to-end power failover test (or the closest safe equivalent for your environment).
• Remediate findings with tracked tickets and documented closure.
• Establish recurring maintenance and testing cadence with named owners and evidence retention rules.
• Package the control narrative and evidence so an assessor can validate PE-11(1) quickly. ²

Frequently Asked Questions

Does PE-11(1) require a generator?

No. It requires an alternate power supply that can maintain your minimally required operational capability during an extended outage. A generator is one way to meet that, but UPS plus controlled shutdown can also meet the requirement if it matches your defined “minimal.” ¹

What does “activated at a defined point” mean in practice?

You must define and document the trigger for switching to alternate power, such as automatic cutover on utility loss or a manual procedure with clear initiation criteria. Auditors will expect that trigger to be configured or practiced, not just described. ¹

How do we define “minimally required operational capability” without overcommitting?

Define the smallest set of functions needed to protect mission outcomes and data integrity during an outage, and document an approved degraded mode. Keep it system-specific and tie it to dependencies like identity, logging, and storage.

We’re mostly cloud-hosted. How does PE-11(1) apply?

Your cloud provider handles platform power, but your system boundary may still include network equipment, endpoints, security sensors, or connectivity required to operate or recover. Document what you own, what the third party provides, and keep the assurance artifacts that support reliance.

What evidence is most commonly missing in audits?

Teams often have equipment but lack proof of runtime assumptions, failover tests, and maintenance history mapped to the system boundary. Build an evidence register and treat it as an operational checklist, not a one-time compliance task.

How do we handle branch offices or remote sites with limited facilities support?

Start by defining minimal capability for that site (often safe shutdown, local authentication, or connectivity for critical services). Then choose a realistic activation model and testing approach that matches staffing and access constraints, and document compensating procedures where automation is not feasible.

Footnotes

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

2. NIST SP 800-53 Rev. 5