PE — Physical and Environmental Protection
Physical and Environmental Protection is the control family that protects the room the system lives in rather than the system itself. PE governs who can walk up to the hardware, what stops them when they shouldn’t, and what keeps the boxes powered, cooled, dry, and not on fire. It is also the family most often signed away in a single sentence: “inherited from [datacenter / colo / CSP].” That sentence is usually true and almost never backed by anything an assessor can read. PE is where the gap between a claimed control and a validated one is widest, and that gap is the whole reason this page is worth more than a restatement of the catalog.

PE is a catalog family from SP 800-53, not a step in the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. PE controls get pulled in at Select off your 800-53B baseline, get documented and stood up (or inherited) at Implement, and get graded at Assess. For most systems the Assess step on PE is short, because the answer is “the facility handles it.” Whether that short answer survives is the interesting part.
What’s in the family
In Rev 5 the family runs PE-1 through PE-23, but that span is not a flat list of live controls, and several common SSPs are quoting Rev 4 here without knowing it.
The load-bearing ones:
- PE-1, Policy and Procedures. The family’s documented org policy. Same role the -1 plays everywhere. Pulled first, inherited from existence by everything below it.
- PE-2, Physical Access Authorizations. The authorized-personnel roster. Who is allowed in, approved by whom, reviewed on what cycle, and removed when they leave. This is the list the badge system is supposed to enforce.
- PE-3, Physical Access Control. The enforcement layer. Badge readers, mantraps, guards, locked cages, the cage key log. PE-2 says who should get in; PE-3 is the door that says no.
- PE-6, Monitoring Physical Access. Cameras, intrusion alarms, access-log review. The control that turns a badge swipe into evidence, which is why it feeds AU and IR more than people expect.
- PE-8, Visitor Access Records. The visitor log and escort record. Note the renumbering: old PE-7 (Visitor Control) is withdrawn in Rev 5, folded back into PE-2 and PE-3 because the distinction between “controlling visitors” and “controlling physical access” was never real. If your SSP still cites PE-7 as a live control, that line is a Rev 4 fossil.
- PE-9 through PE-12, the power-and-light cluster. PE-9 power equipment and cabling, PE-10 emergency shutoff, PE-11 emergency power (UPS plus generator), PE-12 emergency lighting. This is the stuff colos sell as a feature, and the stuff they have actual test records for.
- PE-13, Fire Protection. Detection and suppression. Pre-action sprinkler versus a clean-agent system (FM-200, Novec 1230, inert gas) matters here, and an assessor who knows the difference will ask which one you have.
- PE-14, Environmental Controls. Rev 4 called this “Temperature and Humidity Controls.” Rev 5 renamed and broadened it to cover temperature, humidity, pressure, and similar environmental factors. An SSP that still says “Temperature and Humidity Controls” is, again, quoting the old catalog.
- PE-15, Water Damage Protection. Leak detection, shutoff valves, not putting the racks under the bathroom on floor three.
- PE-16, Delivery and Removal. Controlling hardware in and out of the facility. The seam where a removed drive becomes an MP (media protection) problem.
- PE-17, Alternate Work Site. Telework and remote-work physical security. Quiet for years, then 2020 made it live on a lot of systems that used to mark it not-applicable. More on that below.
- PE-18, Location of System Components. Rev 5 title is “Location of System Components” (Rev 4 said “Information System Components”). Positioning the hardware to reduce physical and environmental risk.
Then the tail. PE-19 (Information Leakage), PE-20 (Asset Monitoring and Tracking), PE-21 (Electromagnetic Pulse Protection), PE-22 (Component Marking), and PE-23 (Facility Location) are real Rev 5 controls, but none of them sit in any 800-53B baseline. They enter a system only through an overlay or a deliberate tailoring-in decision. PE-19 and PE-21 in particular are TEMPEST-and-EMP territory that you will see on national-security systems under CNSSI 1253 and basically nowhere else. If one of these shows up in a Moderate commercial SSP with no overlay justification, someone copied a template.
Baselines and where the controls come from
The baselines live in SP 800-53B, not in the catalog. FIPS 199 sets your categorization, FIPS 200 sets the security floor, and 800-53B turns the impact level into a starting control set. For national-security systems CNSSI 1253 overlays it; FedRAMP and DoD (DoDI 8510.01) layer their own on top.
PE is heavily baseline-allocated at the base-control level, which makes it look easy. PE-1, PE-2, PE-3, PE-6, PE-8, PE-12, PE-13, PE-14, PE-15, and PE-16 are in the Low baseline and carry up through Moderate and High. The work that separates a Moderate system from a High one is mostly in the enhancements and in PE-9 through PE-11 (which arrive at Moderate), not in adding whole new base controls. So the trap is real: the control count barely moves between impact levels, which lulls people into thinking the implementation depth doesn’t move either. It does.
Deeper: inheritance is not the same as a satisfied control.
When you authorize a system on AWS GovCloud, Azure Government, or a FedRAMP-authorized colo, the provider’s physical controls are authorized for their facility. That authorization is real and you can lean on it, but it transfers to your SSP only through the customer-responsibility matrix (CRM) and the provider’s attestation (a SOC 2 Type II report, a FedRAMP package, a written letter). “Inherited from [provider]” with nothing behind it is a control narrative pointing at a document the assessor can’t see. The clean version names the artifact: which CRM line marks PE-3 as provider-responsibility, which SOC 2 report and which reporting period covers it, and which controls the CRM hands back to you. Because some always come back. PE-17 (your teleworkers’ homes) is yours no matter who runs the datacenter. So is PE-2 for any of your own staff who badge into a shared cage. The shared-responsibility line is the deliverable, not the inheritance claim by itself.
| Control | Typical first live at | What an assessor actually checks |
|---|---|---|
| PE-2 | Low | Pull the authorized-personnel roster; sample it against the badge-system access list. Names on the badge system that aren’t on the roster, or terminated staff still active, is a finding. |
| PE-3 | Low | Walk the floor. Confirm the door actually requires a badge, the cage is locked, and the key/PIN log is real and current. |
| PE-6 | Low | Camera coverage of entry points and review cadence; pull a week of access logs and check someone looked at them. |
| PE-8 | Low | Visitor log plus escort attestation. Sample entries: who escorted, in and out times present, gaps explained. |
| PE-11 | Moderate | UPS and generator load-test records, fuel contract or fuel-level logs, last transfer-switch test date. |
| PE-13 | Low | Suppression-system inspection tags, the agent type, last inspection date. Expired tag = finding. |
| PE-14 | Low | Temp/humidity sensor logs against the ranges the SSP states. If the SSP says 64–80°F and the logs show excursions with no record of action, that’s the gap. |
Treat “first live at” as directional. Your overlay moves it, and inheritance changes who answers the question, not whether it gets asked.
Where it actually goes wrong
The single most brittle spot in this family is the inheritance claim with nothing behind it. An SSP writes “PE-2, PE-3, PE-6, PE-13, PE-14 inherited from [colo],” the assessor asks for the CRM line and the attestation, and the answer is a vendor marketing PDF about their “world-class facilities.” That’s not an attestation. A SOC 2 Type II from a period that overlaps your authorization is. The fix is boring: get the bridge letter if the report period has lapsed, cite the report and period in the narrative, and reconcile every CRM line that comes back to you. The ones that come back are the ones that bite.
PE-2 versus the badge system. The roster and the access list drift apart the same way AC-2 accounts do, and for the same reason: provisioning is eager, deprovisioning is nobody’s Friday-afternoon job. Someone transfers teams, keeps the cage badge, and nine months later still has 0300 floor access they have no reason to hold. This is a PE+PS+AC seam: termination should trip PS-4, which should kill the AC-2 account and the PE-2 physical authorization in the same workflow. When those three live in three different systems owned by three different people, the badge is the one that survives. Sample five terminated employees against the badge access list. If any are still active, the deprovisioning process is theater.
PE-8 visitor logs as IR evidence. Nobody cares about the visitor log until there’s an incident, and then it’s the first thing pulled. A log with sign-in times but no sign-out, or escort fields left blank, is worse than no log because it documents that the control wasn’t really running. Escort attestation is the part that rots: the badge says a visitor entered, but who walked them, and were they actually escorted the whole time or handed a badge and pointed at the cage?
PE-17 went live when the office emptied. Pre-2020, plenty of systems marked PE-17 not-applicable because there was no alternate work site. Then everyone’s dining room became one. PE-17 now ties into AC-17 (remote access) and the CP family, and “N/A” on a system with a remote workforce is a stance you defend, not a default. The honest version states the physical posture you require of teleworkers (screen positioning, locked-when-away, no shared-household printing of CUI) and admits you can’t enforce most of it, which is itself the risk you’re documenting.
Here’s the flag I’ll plant: PE is the family where inherited-control claims are weakest across the whole catalog, and assessors who skip the floor walk and the attestation review are signing off on the least-validated controls in the package. A remote SOC 2 review plus a thirty-minute walk-through catches most of the rot, and a surprising number of assessments do neither. If you own a PE control, assume the floor walk is coming and make the roster match the badge list before someone else finds out it doesn’t.
Artifacts
PE lands in the usual three places. The SSP narrative has to name the inheritance source and the artifact behind it, not just assert inheritance. The SAR records whether the floor walk and the attestation review backed the claim. The POA&M holds the gap, which for PE is most often a lapsed SOC 2 period, a roster that doesn’t match the badge list, or a visitor log missing escort fields. The assessor has read PE-13. They want to know which suppression agent is in your room and when the tag was last signed.
Sources
- SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (NIST)
- SP 800-53B, Control Baselines for Information Systems and Organizations (NIST)
- SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations (NIST)
- FIPS 199, Standards for Security Categorization of Federal Information and Information Systems (NIST)
- FIPS 200, Minimum Security Requirements for Federal Information and Information Systems (NIST)
- CNSSI 1253, Security Categorization and Control Selection for National Security Systems (CNSS)
- DoDI 8510.01, Risk Management Framework for DoD Systems (DoD)
Adjacent material on this site
- PS, Personnel Security (where PE-2 deprovisioning ties to PS-4 termination)
- CP, Contingency Planning (power, environment, and alternate-site overlap with PE-9 through PE-17)
- AC, Access Control (PE-17 alternate work site meets AC-17 remote access)
- MA, Maintenance (vendor physical access to the facility)
- RMF control families overview
- RMF roadmap