PE-11(2): Alternate Power Supply — Self-contained

PE-11(2) requires you to provide a self-contained alternate power supply for the system that activates under defined conditions, so mission- or safety-critical functions can keep running during a loss of primary power. To operationalize it quickly, define the activation trigger, select a self-contained power source (typically UPS or generator with onsite fuel), test failover, and retain evidence that proves the capability works. ¹

Key takeaways:

• “Self-contained” means the alternate power source can operate independently of normal utility power and external dependencies you do not control.
• Auditors look for proof of activation conditions, runtime capacity, and recurring test results tied to specific systems and locations.
• The fastest path is a documented design decision, a tested runbook, and repeatable evidence collection mapped to an owner and schedule.

The pe-11(2): alternate power supply — self-contained requirement is a physical and environmental protection expectation that becomes a cybersecurity and availability control in practice. If your system loses power and cannot fail over cleanly, you can lose security controls (logging, access control, monitoring), corrupt data, and create an incident that looks like poor resilience rather than “just a facilities problem.” For federal information systems and contractor environments handling federal data, assessors usually treat this as an operational control: they want to see a power design that matches your availability objectives, is triggered under defined conditions, and is validated through tests you can reproduce.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to turn the requirement into a short implementation plan. You will leave with (1) a plain-English interpretation, (2) a concrete build-and-test checklist, (3) the evidence artifacts to collect, and (4) the audit questions you should be ready to answer. Where teams stumble is not buying hardware; it’s failing to define activation criteria, failing to show the power source is actually self-contained for the system boundary, and failing to keep clean evidence over time.

Regulatory text

Requirement excerpt: “Provide an alternate power supply for the system that is activated {{ insert: param, pe-11.02_odp.01 }} and that is:” ¹

What this means for operators (practical reading):

• You must provide an alternate power supply for the system (define the system boundary: site, room, racks, network gear, supporting services).
• The alternate power must be activated based on an organization-defined parameter (the pe-11.02_odp.01 placeholder). Your job is to set and document the activation condition(s), then implement them.
• The enhancement name “Self-contained” means the alternate supply must not depend on external power sources or external services you cannot ensure during an outage. In common implementations, that’s an onsite UPS and/or generator capacity that can carry the system for the required runtime. ²

Plain-English interpretation (what you’re really being asked to prove)

You need to prove three things:

1. A defined trigger exists: you have an explicit rule for when alternate power kicks in (power loss, voltage drop, transfer switch condition, UPS on-battery event, etc.).
2. Alternate power is self-contained for your system boundary: the system can keep running without relying on utility power or a third party you cannot guarantee in an outage.
3. It works and stays working: you test it, you maintain it, and you can produce records tying results to the system and location.

A common audit failure is “we have building generators” with no mapping to which systems are covered, no runtime assumptions, and no test records demonstrating the system remained available during transfer. Treat this like any other control: scope, implement, test, evidence, repeat.

Who it applies to

Entity types

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational contexts where PE-11(2) is typically in scope

• Data centers, server rooms, IDF/MDF closets supporting security boundaries.
• Systems requiring continuity to preserve security functions (e.g., authentication services, centralized logging, monitoring, badge/access control integration).
• Environments with explicit availability objectives, incident response requirements, or continuity planning requirements tied to mission functions.

Key scoping decision Document whether the “system” includes only compute, or also includes the supporting network, storage, cooling dependencies, and physical access controls necessary for operation. Assessors will usually test the completeness of your boundary definition by asking, “If utility power fails, what exactly stays up, and for how long?”

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

1) Assign an owner and write the control intent

• Assign a control owner (often Facilities for equipment, IT Ops for system scope, GRC for evidence and assessment readiness).
• Create a short control statement: “The system has self-contained alternate power that activates on defined trigger(s) and is tested on a recurring basis.” ¹

2) Define the activation parameter (the missing ODP)

You must fill in pe-11.02_odp.01 with your organization-defined activation condition(s). Write them as testable rules, not vague language.

Examples of acceptable activation definitions (choose what fits your design):

• Automatic transfer upon loss of utility power to the protected electrical panel feeding system racks.
• UPS transitions to battery on power anomaly, followed by generator start and automatic transfer.
• Manual activation only for a narrowly scoped system, with a defined on-call response procedure and maximum allowable downtime (document the rationale).

Store this in your SSP/control narrative and your facilities runbook so it is consistent across teams.

3) Confirm “self-contained” design for the system boundary

Build a simple dependency map:

Dependency	Covered by alternate power?	Evidence you should have
Compute hosts / hypervisors	Yes/No	Rack/PDU/circuit mapping
Storage	Yes/No	Storage power feed mapping
Network (switches, routers, firewalls)	Yes/No	UPS outlet list, diagrams
Identity (AD/IdP)	Yes/No	Service mapping, hosting location
Monitoring/logging	Yes/No	Architecture diagram
Cooling (if needed to sustain operation)	Yes/No	Facilities design docs

If a dependency is not covered, decide explicitly: either (a) extend alternate power coverage, or (b) change the system boundary, or (c) document compensating measures and acceptance of reduced capability.

4) Select and implement the alternate power source

Common patterns that satisfy “self-contained” for many environments:

• UPS sized for clean shutdown or short runtime plus bridging to generator.
• Onsite generator with onsite fuel or contracted refueling plans aligned to your continuity objectives.
• Dual power feeds to redundant UPS units, with separate circuits, if your design calls for higher resilience.

Your compliance deliverable is not the brand/model. It is the traceability from system components to protected circuits and runtime assumptions documented and tested.

5) Create operating procedures (runbooks)

Write an outage runbook that covers:

• Detection and notification (what alerts fire on UPS on-battery, generator start, ATS transfer).
• Decision points (when to shed load, when to initiate controlled shutdown).
• Manual steps if automation fails.
• Post-event recovery steps (battery recharge validation, generator inspection, event ticketing).

Keep it short enough that an on-call engineer can execute it under stress.

6) Test failover and record results

Design tests to prove your activation condition and self-contained capacity:

• Simulate utility failure (where safe and approved) and observe: UPS transfer, generator start, ATS transfer, system continuity.
• Validate key services remain available (auth, network, logging, monitoring, critical apps).
• Record any exceptions and remediation actions.

Tie tests to specific assets/locations. “Generator tested” is not the same as “system stayed up during transfer.”

7) Operationalize ongoing maintenance and evidence capture

This requirement fails over time when batteries degrade, circuits get moved, or loads increase. Put recurring tasks into your GRC calendar:

• Battery health checks and replacement planning.
• Generator maintenance records.
• Change management gates: any new rack/PDU load requires re-check of UPS capacity and circuit mapping.

Daydream (or any GRC system you use) should track: owner, procedure, test cadence, and a consistent evidence checklist so each period produces assessor-ready artifacts without rework. ¹

Required evidence and artifacts to retain

Keep evidence tied to system, location, and time period:

Design & scope

• System boundary statement and architecture diagram showing what is protected by alternate power.
• Electrical one-line diagram or rack-level power mapping (circuits → PDUs → devices).
• UPS/generator/ATS specifications and commissioning records (as available).

Operation

• Outage/failover runbook and on-call procedures.
• Monitoring/alerting configuration (screenshots or exports showing UPS/generator alerts routed to responders).

Testing & maintenance

• Test plans, test results, and tickets showing outcomes and fixes.
• Maintenance logs for UPS batteries, generator, ATS inspections.
• Change records showing review of capacity impacts when equipment is added/moved.

Common exam/audit questions and hangups

Expect these questions:

• “What is your activation condition for alternate power, and where is it documented?”
• “Show me that the system stayed operational during transfer. Which services did you validate?”
• “Which components are on protected power, and which are not? Why?”
• “How do you ensure alternate power remains self-contained if the outage is prolonged?”
• “How do you prevent silent drift (new loads, moved circuits, degraded batteries)?”

Hangup to anticipate: Facilities may test generators, and IT may test app uptime, but nobody tests the end-to-end chain. Your job is to connect those into one control story and one evidence package.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Relying on “building generator” statements without system mapping.
   Fix: Maintain a rack/circuit mapping and show exactly which panels and outlets back the system.

2. Mistake: No documented activation parameter (ODP).
   Fix: Publish the trigger condition(s) in the SSP and runbook, then test against those triggers.

3. Mistake: Testing equipment, not outcomes.
   Fix: During power tests, validate service availability for the systems in scope and retain results.

4. Mistake: Ignoring upstream dependencies.
   Fix: Include network and identity dependencies in the system boundary review, or document exclusions and compensating measures.

5. Mistake: Evidence scattered across teams.
   Fix: Centralize evidence requests and retention in your GRC workflow so each test/maintenance event produces a predictable artifact set.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat the driver as assessment and contractual risk rather than a specific published penalty narrative. ¹

Operational risk is straightforward: power loss can create downtime, data integrity issues, and security control gaps. In federal or contractor settings, repeated inability to demonstrate continuity controls can lead to assessment findings, delayed ATO decisions, and customer trust impact. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Name the control owner and backups; confirm Facilities/IT/GRC responsibilities.
• Define the activation parameter(s) for pe-11.02_odp.01 and publish in the SSP/control narrative. ¹
• Create the system power dependency map (what must stay up for the system to function).
• Inventory existing alternate power equipment and identify gaps against the system boundary.

Days 31–60 (implement and document)

• Update or build circuit/rack mapping for all in-scope equipment.
• Write the outage/failover runbook and add monitoring/alert routing validation.
• If gaps exist, execute change requests to move equipment to protected circuits or add UPS capacity.
• Set up the evidence checklist in Daydream (or your GRC tool): required artifacts, owners, and storage location conventions. ¹

Days 61–90 (test, remediate, and make it repeatable)

• Run an end-to-end power failover test (planned, approved, and safety-reviewed).
• Validate service continuity for key functions and document results.
• Remediate issues (load shedding, battery runtime gaps, miswired circuits, alerting failures).
• Establish recurring maintenance/test evidence cycles and tie them to change management gates.

Frequently Asked Questions

What counts as “self-contained” alternate power for PE-11(2)?

It means the alternate power source can sustain the system during a primary power outage without relying on external utility power for the covered period. Common implementations include UPS and onsite generator capacity tied directly to the system’s circuits. ³

Do we have to use a generator to satisfy PE-11(2)?

Not always. If a UPS alone meets your continuity objectives for the system and you can prove it through testing and evidence, that can meet the intent for some environments. Your activation condition and system boundary documentation matter. ¹

How do we define the activation parameter (the ODP placeholder) in a way auditors accept?

Write a specific, testable trigger such as “loss of utility power to the system’s electrical panel causes automatic transfer to UPS/generator.” Then retain a test record that shows the trigger occurred and the system remained available. ¹

Our data center provider says they have redundant power. Does that satisfy this requirement for our system?

It can, but only if you treat the provider as a third party dependency and retain evidence that maps your system to the provider’s protected power design and testing results. Your assessor will still expect you to show coverage for your specific cages/racks and critical services.

What evidence is the fastest to collect if we are behind?

Start with a current system boundary diagram, a rack-to-circuit mapping, the runbook, and the most recent UPS/generator/ATS test and maintenance records. Then schedule an end-to-end failover test to close the proof gap.

How do we keep this from becoming a yearly fire drill?

Put evidence collection on a recurring schedule and tie it to change management so moves/adds/changes trigger a capacity and mapping review. Track tasks, owners, and artifacts in Daydream so each cycle produces the same evidence packet. ¹

Footnotes

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

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

3. NIST SP 800-53 Rev. 5