PE-10: Emergency Shutoff
PE-10 requires you to provide a reliable, clearly accessible way to shut off power to defined equipment or areas during an emergency, and to prove it works in practice. To operationalize it quickly, define the shutoff scope, install and label emergency power-off capability, control access to prevent misuse, and retain test, training, and maintenance evidence. 1
Key takeaways:
- Define exactly what “power shutoff” covers for your environment, then map it to facilities and IT assets. 1
- Implement emergency shutoff hardware and procedures that responders can execute quickly and safely, without confusion. 2
- Treat PE-10 as an evidence-heavy control: diagrams, labels, work orders, test logs, and training records carry audits. 1
PE-10: Emergency Shutoff is a physical and environmental protection requirement in NIST SP 800-53 Rev. 5 that expects an organization to have a practical way to cut electrical power during an emergency. It is simple to describe and easy to fail in an assessment because the hard part is scope and proof: auditors want to see which systems are covered, where the shutoff is located, who can activate it, and how you confirm it remains functional over time. 1
This requirement shows up most often for on-prem data centers, comms rooms, network closets, OT/ICS spaces, and colocation footprints where your organization has responsibility for the facility build or for tenant-side controls. It can also apply to cloud-adjacent setups like dedicated cages, managed hosting, and leased suites where power distribution is shared and emergency shutoff responsibilities must be contractually defined with a third party. 2
Your goal is operational clarity: in a fire, water leak, electrical event, or equipment failure, authorized personnel must be able to shut off power to the correct target quickly, without creating additional hazards. This page gives requirement-level implementation guidance you can execute immediately and defend during an audit.
Regulatory text
Requirement (PE-10): “Provide the capability of shutting off power to {{ insert: param, pe-10_odp.01 }} in emergency situations;” 1
What the operator must do:
- Provide an emergency shutoff capability for the defined scope (the parameter placeholder means your organization must specify what equipment/areas are covered). 1
- Make it usable in real emergency conditions: it must be accessible to the right people, clearly identified, and maintained so it works when needed. 2
Plain-English interpretation (what PE-10 means in practice)
You need a “kill switch” capability for power, scoped to the facilities and equipment that matter for your system. This is typically an Emergency Power Off (EPO) function for a data center/room, a local disconnect for specific equipment, or a controlled breaker/shunt-trip arrangement that can rapidly de-energize a space or distribution path. 2
PE-10 is not asking you to remove all risk from power events. It is asking for a deliberate, documented capability to shut off power in emergencies, with defined ownership and repeatable operation. 1
Who it applies to (entity and operational context)
Entity scope
- Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls. 2
Operational scope (where PE-10 usually bites)
- Organization-operated data centers, server rooms, MDF/IDF closets, and network rooms.
- Colocation cages/suites where you control tenant power distribution or must coordinate EPO access with the colo provider (a third party).
- OT/ICS or lab environments where power shutoff has safety implications and must be engineered and trained.
Shared responsibility reality If a third party controls base building power or EPO, you still need to document the division of responsibilities, the access path during emergencies, and how you get assurance the capability exists and is maintained. PE-10 is frequently satisfied via a mix of your controls plus third-party contract/SLA and evidence collection. 2
What you actually need to do (step-by-step)
1) Define the shutoff scope (the missing parameter)
Because the control text includes a parameter placeholder, start by declaring what PE-10 covers in your environment. 1
Create a one-page “PE-10 Scope Statement” that lists:
- Facilities/rooms in scope (by site, floor, room ID).
- Power domains in scope (room-level EPO, rack PDU disconnects, UPS output disconnects, etc.).
- System tie: which information system(s) operate in those spaces.
Decision tip: If the room contains system components that support your boundary or critical workloads, include it. If you exclude a space, document why and where the system boundary truly resides.
2) Assign ownership and escalation paths
Name a control owner (often Facilities, Data Center Ops, or Corporate Security) and an IT service owner who can validate the technical impact. Then define who can authorize activation during an emergency (incident commander, facilities manager, security shift lead). 2
Deliverables:
- RACI for PE-10 operation and maintenance.
- Emergency contact list integrated into your incident response runbooks.
3) Implement the emergency shutoff capability
Choose the mechanism appropriate to the space and risk:
- Room-level EPO for data centers and dedicated server rooms.
- Local disconnects for specific equipment where selective shutoff is safer than room-wide shutdown.
- Breaker-level controls with lockout/tagout practices where applicable.
Your implementation must be:
- Accessible: responders can reach it without special tools.
- Identifiable: clear signage and labeling that survives stress.
- Safe: designed to avoid creating additional hazards (coordinate with safety and electrical engineering). 2
4) Prevent accidental or malicious activation (without blocking emergency use)
PE-10 does not explicitly require anti-tamper, but audits commonly probe whether the EPO could be triggered casually. Add pragmatic protections:
- Protective covers or guarded switches.
- Access controls to the room where the EPO is located.
- Clear “when to use” instructions posted nearby.
Document your rationale so assessors see you balanced emergency access with misuse prevention.
5) Write the operational procedure (make it runnable)
Create a short runbook that answers:
- Trigger criteria: what events justify shutoff (fire, electrical odor, flooding near live equipment, energized equipment hazard).
- Authorization: who can pull the shutoff, and when anyone can act for safety.
- Immediate actions: call sequence, evacuation, coordination with building management.
- Post-shutoff recovery: who resets, how you verify safe restoration, and how you record the event.
Tie this to incident response and facilities emergency procedures so it is not a standalone document nobody uses. 2
6) Train the people who might need to act
PE-10 fails in practice when only one person knows where the EPO is. Train:
- Facilities on-call staff.
- Security personnel with site response duties.
- Data center technicians and NOC staff for escalation and coordination.
Keep training tight: location, conditions for use, and who to notify.
7) Test and maintain (and keep the evidence)
Plan and execute periodic checks appropriate to your environment:
- Visual inspection of signage, access path, and labeling.
- Functional testing aligned with safety guidance and business impact constraints.
- Maintenance tickets for any issues found (stuck switch, missing label, blocked access).
Even if you cannot do live power-cut tests frequently, document your alternative assurance steps and engineering justification.
8) If a third party owns the EPO, operationalize assurance
For colocation or managed facilities:
- Add contract language: EPO capability exists, where it is, who can access it, maintenance responsibilities, and notification obligations.
- Obtain evidence: latest maintenance attestation, site diagrams, or provider statement of control.
- Confirm your access path during an emergency (badging, escort rules, after-hours entry).
Daydream can help here by mapping PE-10 to a recurring evidence request set for your colocation provider or facilities management third party, so audits do not depend on ad hoc email threads.
Required evidence and artifacts to retain
Assessors typically want evidence that is specific, current, and traceable to in-scope spaces.
Control design evidence
- PE-10 scope statement (parameter definition) and system boundary mapping. 1
- Facility one-line diagram or annotated floor plan showing EPO/disconnect locations.
- Photos of EPO/disconnect, signage, and labels (dated).
Operating effectiveness evidence
- Maintenance work orders / inspection checklists (showing dates, issues, remediation).
- Test records (functional test where feasible, or documented inspection regime).
- Training records and attendee lists for staff with emergency duties.
- Incident records if activation occurred, including post-event review.
Third-party evidence (if applicable)
- Contract/SOW clauses or responsibility matrix.
- Provider attestation or maintenance documentation for EPO capability.
Common exam/audit questions and hangups
Expect these questions, and prepare the exact artifact you will hand over.
-
“What is the ‘{{…}}’ scope for PE-10 in your environment?”
Provide the scope statement and tie it to rooms and systems. 1 -
“Show me where the emergency shutoff is for this room.”
Have a diagram and a photo, and be ready for a walkthrough. -
“Who can activate it and under what conditions?”
Provide the runbook excerpt plus role assignments. -
“How do you know it works?”
Show inspection/test logs and corrective actions. -
“Your systems are in a colo. How do you meet PE-10?”
Show the responsibility split, contract language, and evidence collected from the provider.
Frequent implementation mistakes (and how to avoid them)
| Mistake | Why it fails | Avoid it by |
|---|---|---|
| No defined scope for the parameter | Auditors see ambiguity; coverage gaps appear | Publish a PE-10 scope statement and map it to facilities and system boundary. 1 |
| EPO exists but is poorly labeled or blocked | Emergency responders cannot find or access it | Add signage, keep a clear access path, include it in housekeeping inspections. |
| “We rely on the colo” with no evidence | Shared responsibility becomes “no responsibility” | Collect provider artifacts and document escalation and access. |
| Testing is informal (“we checked once”) | Operating effectiveness cannot be shown | Use a repeatable inspection/test checklist and retain records. |
| Overly restrictive access | People hesitate or cannot act during a real emergency | Use guarded controls and training rather than hiding the shutoff. |
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for PE-10, so this page does not list enforcement actions.
Operationally, PE-10 is a safety and resilience control. The risk is not theoretical: inability to quickly de-energize equipment can worsen physical hazards, damage systems, and complicate incident response. For regulated environments, the compliance risk usually shows up as an assessment finding due to missing scope definition and weak evidence of ongoing maintenance. 2
Practical 30/60/90-day execution plan
First 30 days (stabilize scope and ownership)
- Publish PE-10 scope statement (rooms, equipment, systems). 1
- Assign control owner, alternates, and escalation contacts.
- Gather baseline evidence: diagrams, current photos, existing maintenance records.
- Identify gaps: missing signage, blocked access, unclear authorization.
By 60 days (implement runbooks and assurance)
- Finalize and train on the emergency shutoff runbook (trigger criteria, authorization, post-event steps).
- Fix physical gaps: signage, labels, protective covers, access path controls.
- If a third party is involved, update contracts/SOWs or create a responsibility matrix; start recurring evidence requests.
By 90 days (prove operating effectiveness)
- Run a tabletop exercise that includes a power shutoff decision and communications path; record outcomes and actions.
- Execute the first scheduled inspection/test cycle and close remediation tickets.
- Package an “audit-ready” PE-10 evidence set in your GRC system (or Daydream): scope, diagrams, photos, procedures, training, and latest inspection/test record. 2
Frequently Asked Questions
What counts as an “emergency shutoff” for PE-10?
A mechanism that can quickly remove electrical power from the defined in-scope equipment or area during an emergency. In practice, this is often an EPO for a room or a documented disconnect method for specific equipment. 2
We are fully cloud. Do we still need PE-10?
If you have no facilities or equipment under your control that support the system boundary, PE-10 may be out of scope for your environment. Document the rationale and your reliance on cloud provider facilities so assessors can follow the boundary decision. 2
Our systems are in a colocation site. Can the colo provider satisfy PE-10?
Yes, but you need written responsibility allocation and evidence that the capability exists and is maintained. Treat the colo as a third party and collect diagrams, attestations, and access procedures as recurring evidence.
Do we have to test the EPO by actually cutting power?
NIST SP 800-53 does not prescribe a specific test method in the excerpt provided, but assessors will expect a credible assurance approach. If live shutoff testing is unsafe or too disruptive, document your inspection regimen and engineering justification. 2
Who should own PE-10: Facilities or IT?
Facilities typically owns the physical mechanism and maintenance, while IT owns system impact and coordinates recovery. Make this explicit in a RACI so emergency actions are not delayed by ambiguity.
What evidence is the fastest win for audit readiness?
A clear scope statement for the parameter, a labeled diagram and photo of the shutoff location, and the most recent inspection/test record. Those three artifacts answer the most common audit questions. 1
Footnotes
Frequently Asked Questions
What counts as an “emergency shutoff” for PE-10?
A mechanism that can quickly remove electrical power from the defined in-scope equipment or area during an emergency. In practice, this is often an EPO for a room or a documented disconnect method for specific equipment. (Source: NIST SP 800-53 Rev. 5)
We are fully cloud. Do we still need PE-10?
If you have no facilities or equipment under your control that support the system boundary, PE-10 may be out of scope for your environment. Document the rationale and your reliance on cloud provider facilities so assessors can follow the boundary decision. (Source: NIST SP 800-53 Rev. 5)
Our systems are in a colocation site. Can the colo provider satisfy PE-10?
Yes, but you need written responsibility allocation and evidence that the capability exists and is maintained. Treat the colo as a third party and collect diagrams, attestations, and access procedures as recurring evidence.
Do we have to test the EPO by actually cutting power?
NIST SP 800-53 does not prescribe a specific test method in the excerpt provided, but assessors will expect a credible assurance approach. If live shutoff testing is unsafe or too disruptive, document your inspection regimen and engineering justification. (Source: NIST SP 800-53 Rev. 5)
Who should own PE-10: Facilities or IT?
Facilities typically owns the physical mechanism and maintenance, while IT owns system impact and coordinates recovery. Make this explicit in a RACI so emergency actions are not delayed by ambiguity.
What evidence is the fastest win for audit readiness?
A clear scope statement for the parameter, a labeled diagram and photo of the shutoff location, and the most recent inspection/test record. Those three artifacts answer the most common audit questions. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream