PE-3(2): Facility and Systems
PE-3(2): Facility and Systems requires you to run security checks at the physical perimeter of a facility or system to detect and prevent information exfiltration or unauthorized removal of system components. Operationalize it by defining what gets checked, where checks occur, who performs them, what triggers them, and what evidence proves consistent execution. 1
Key takeaways:
- Define perimeter “security checks” for both people and items leaving controlled areas, with explicit triggers and scope.
- Make the control auditable: assign an owner, write an SOP, and retain repeatable evidence of each check.
- Align physical security, IT asset management, and incident response so discoveries at egress become tracked events.
Footnotes
The pe-3(2): facility and systems requirement shows up when your environment has a real risk of data leaving in physical form (printed materials, removable media) or systems/components leaving as assets (laptops, drives, network gear, spare parts). The control is narrow but operationally tricky because teams confuse “access control at the door” with “egress screening for exfiltration.” PE-3(2) expects the latter: a security check at the physical perimeter focused on detecting information being taken out or components being removed without authorization. 1
For a Compliance Officer, CCO, or GRC lead, the fastest path is to: (1) pick the perimeter locations that matter, (2) define what constitutes a “security check” for your risk profile, (3) document triggers (every exit vs. conditional), and (4) build an evidence stream that stands up in an assessment. You do not need a perfect airport-style screening program everywhere. You do need a defensible, documented, consistently executed set of checks matched to where federal data or sensitive system components could walk out. 2
Regulatory text
Requirement (quoted): “Perform security checks {{ insert: param, pe-03.02_odp }} at the physical perimeter of the facility or system for exfiltration of information or removal of system components.” 1
Operator interpretation of what you must do:
- Perform security checks: You must carry out an actual, observable procedure (not only a policy) that is intended to detect outbound information or hardware. 1
- At the physical perimeter of the facility or system: Checks happen at egress points (doors, loading docks, shipping/receiving, cage exits, mantraps, badged turnstiles) or at the boundary of a specific controlled system area (data center suite, lab, secure room). 1
- For exfiltration of information or removal of system components: The check’s purpose must explicitly cover both data leaving (paper, media, devices with data) and components leaving (servers, drives, networking parts, laptops, mobile devices, spares). 1
Plain-English interpretation (what this means in practice)
You need a defined way to stop people from walking out with sensitive information or equipment. That can include bag checks by security staff, controlled packaging and escort procedures at loading docks, asset pass systems for equipment removal, tamper-evident seals for shipments, or outbound media controls. The key is that outbound movement gets checked at the perimeter, and exceptions are documented.
A good internal test: if an assessor asks, “Show me how you would detect an employee leaving with a hard drive,” you can point to a written procedure, training, logs, and recent examples.
Who it applies to
This applies most directly to:
- Federal information systems and environments assessed against NIST SP 800-53. 2
- Contractor systems handling federal data where the organization has facilities or controlled spaces and physical assets that could be removed. 2
Operational contexts where PE-3(2) is commonly relevant:
- Data centers (owned or co-located), server rooms, network closets with controlled access.
- R&D labs, manufacturing floors with test systems, repair depots handling customer or government devices.
- Secure print/mail rooms, records storage, or any area with bulk sensitive paper output.
- Shipping/receiving where equipment is staged for repair, return, or disposal.
If you are “cloud-only” with no controlled facility footprint, the control may still apply at the “system perimeter” for physical assets you manage (corporate endpoints, removable media storage, secure storage cabinets). Scope it carefully and document your rationale.
What you actually need to do (step-by-step)
1) Define scope: the perimeters and the assets/data at risk
Create a short scope statement that answers:
- Which facilities/areas are “controlled” (data center suite, secure lab, records room).
- Which exit points are in scope (primary doors, emergency exits with alarms, loading docks).
- What you are preventing from leaving (categories of information and component types).
Keep it concrete: “removable storage,” “printed controlled unclassified information,” “server drives,” “network appliances,” “developer laptops.”
2) Choose the “security check” pattern(s) you will use
Pick one or more check types and tie each to the perimeter location:
| Egress point | Primary risk | Example security check | Typical owner |
|---|---|---|---|
| Main employee exit | Small-item removal (media, paper) | Random or triggered bag checks; visual inspection of packages | Physical security |
| Data center exit | Component removal | Asset pass required; inventory verification; escort sign-out | Data center ops + security |
| Loading dock | Bulk shipment | Shipping authorization review; seal logs; camera review on exceptions | Facilities + logistics |
| Secure room/cage door | High-value assets | Two-person integrity; sign-out log; badge + escort | System owner |
Your “security check” must be more than CCTV exists. Cameras can support the process, but PE-3(2) calls for performing checks at the perimeter for these purposes. 1
3) Define triggers and decision rules
Write simple, testable rules such as:
- Always: all equipment removals require an approved asset pass and inventory verification.
- Conditional: bags/packages are subject to screening based on alert conditions (after-hours exits, badge anomalies, termination processing, high-risk areas).
- Exception handling: medical/privacy accommodations, union rules, or safety constraints, with compensating controls (escort, camera review, secondary verification).
Avoid vague text like “security may check items.” Examiners look for when checks occur and how you ensure consistency.
4) Build the workflow for authorized removals
Most findings happen because authorized removals look the same as unauthorized removals. Build a clean “allowed path”:
- Request (ticket) for equipment/media removal.
- Approval by asset owner and data owner (when data-bearing).
- Serialization/asset tag validation.
- Documentation provided to security (asset pass or shipping manifest).
- Check performed at perimeter.
- Inventory updated (chain of custody, disposition, or transfer).
5) Train the people who perform checks
Training must cover:
- What items are in scope (common devices, removable media types, printed records).
- How to handle refusals, escalations, and after-hours events.
- How to document outcomes without collecting unnecessary personal data.
6) Instrument evidence capture (make it assessor-ready)
Decide what constitutes “proof of performance”:
- Logs of checks (manual logbook, access control system annotations, digital forms).
- Asset pass records linked to tickets.
- Shipping/receiving records with authorization and seal numbers.
- Exception records and follow-up actions.
- Periodic supervisor review attestations.
Daydream fits naturally here as the system of record that maps PE-3(2) to a control owner, the operating procedure, and the recurring evidence artifacts, so you do not rebuild the same evidence package each assessment cycle. 1
7) Test the control and close gaps
Run a tabletop or walk-through:
- Pick a scenario: “remove a failed drive,” “ship a server to repair,” “employee exits with printed records.”
- Confirm the check triggers and the documentation path.
- Verify the log exists and is retrievable.
Then set a cadence for spot checks by compliance or physical security leadership.
Required evidence and artifacts to retain
Keep artifacts that show design + operation:
Design (what you planned)
- PE-3(2) control statement and scope (in your SSP/control catalog or equivalent).
- SOP for perimeter checks (who/what/when/how).
- Roles and responsibilities (RACI) for security, facilities, IT, logistics.
- Training materials and training completion records for screeners.
Operating evidence (what actually happened)
- Asset pass approvals (tickets) and sign-out/sign-in records.
- Egress screening logs (date/time, screener, outcome, exception notes).
- Shipping manifests with authorization and verification steps.
- Inventory updates demonstrating component custody changes.
- Incident/exception follow-ups when a check flags an issue.
Retention period is program-specific; document your retention rule and ensure it is consistent across evidence types.
Common exam/audit questions and hangups
Expect these questions and prepare answers with artifacts:
- “Where is your physical perimeter, and which exits are covered?” Provide a facility diagram and list of egress points with associated check type.
- “What exactly is a ‘security check’ here?” Show the SOP and a sample completed log/record.
- “How do you control removal of data-bearing components?” Show asset pass + chain of custody + inventory linkage.
- “How do you prevent bypass (after-hours, emergency exits, loading dock)?” Show triggers, alarms/cameras, and exception workflows.
- “Show evidence from recent operations.” Provide a small sample set across different scenarios (equipment removal, shipment, visitor/contractor exit).
Hangup to avoid: presenting only badge access controls. PE-3(2) is about outbound checking for exfiltration/removal. 1
Frequent implementation mistakes and how to avoid them
- Mistake: Policy-only control. Fix: require logs or tickets for each check event and review them periodically.
- Mistake: No link to asset management. Fix: require serial/asset tag validation and inventory updates for removals.
- Mistake: Loading dock is ignored. Fix: treat shipping/receiving as a primary perimeter with explicit authorization checks.
- Mistake: Checks are ad hoc and discretionary. Fix: define triggers and minimum steps; document exceptions.
- Mistake: Evidence is scattered. Fix: centralize mapping of PE-3(2) to owner, procedure, and recurring evidence (Daydream can hold this control-to-evidence map). 1
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for this requirement, so treat “enforcement” here as assessment risk: PE-3(2) failures commonly show up as audit findings because the organization cannot demonstrate that checks occur consistently, or cannot prove who approved removals.
Risk implications are straightforward:
- Physical exfiltration bypasses many technical controls.
- Unauthorized component removal creates both data exposure risk (data-bearing devices) and availability risk (critical hardware disappears).
Practical 30/60/90-day execution plan
First 30 days (establish the control)
- Assign a control owner and back-up owner.
- Define scope: in-scope areas, egress points, asset/data categories.
- Draft the SOP and asset pass workflow.
- Decide what evidence you will retain and where it will live.
Days 31–60 (operate it and generate evidence)
- Train screeners and stakeholders (security, IT, facilities, logistics).
- Start performing checks at selected perimeters.
- Begin collecting artifacts: logs, tickets, shipping authorizations, inventory updates.
- Run one walk-through test and document results and fixes.
Days 61–90 (make it resilient and audit-ready)
- Expand to remaining perimeters or add compensating controls where screening is constrained.
- Add supervisory review and sampling of logs.
- Build an assessment packet: scope, SOP, training, and representative operational evidence.
- In Daydream, maintain the mapping between PE-3(2), the procedure, and recurring evidence artifacts so the next audit pull is repeatable. 1
Frequently Asked Questions
Do we have to screen every person leaving the building to meet PE-3(2)?
The control requires you to “perform security checks” at the physical perimeter for exfiltration/removal, but it does not prescribe a single method. Define risk-based triggers and document them, then show evidence that checks occur as designed. 1
What counts as “system components” for PE-3(2)?
Treat any hardware that is part of, or supports, the system as in scope, especially data-bearing parts like drives and removable media. Document your component categories and tie authorized removals to asset management and approvals. 1
We’re in a co-location data center. Who owns the perimeter checks?
Split responsibility by boundary: the co-lo provider may control building perimeter access, but you still need controls for your cage/suite perimeter and for equipment leaving your custody. Document shared responsibilities and retain evidence for the portions you control. 2
Are cameras enough to satisfy the “security checks” requirement?
Cameras support detection and investigation, but PE-3(2) calls for performing checks at the perimeter for the stated purpose. Pair cameras with an explicit check process such as asset pass verification, escort sign-out, or shipping authorization review. 1
How should we handle privacy concerns with bag checks?
Write the SOP to minimize personal data collection, focus on corporate assets and authorized removals, and define an escalation path when a person refuses a check. If bag checks are constrained, adopt alternative controls like asset pass enforcement, escorts, and shipping verification with documented rationale. 1
What is the minimum evidence an auditor will accept?
Provide a documented procedure, identified roles, training records for performers, and recent operational records showing checks or approvals occurred. Make the evidence easy to retrieve by mapping PE-3(2) to the evidence set in a single system of record. 1
Footnotes
Frequently Asked Questions
Do we have to screen every person leaving the building to meet PE-3(2)?
The control requires you to “perform security checks” at the physical perimeter for exfiltration/removal, but it does not prescribe a single method. Define risk-based triggers and document them, then show evidence that checks occur as designed. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
What counts as “system components” for PE-3(2)?
Treat any hardware that is part of, or supports, the system as in scope, especially data-bearing parts like drives and removable media. Document your component categories and tie authorized removals to asset management and approvals. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
We’re in a co-location data center. Who owns the perimeter checks?
Split responsibility by boundary: the co-lo provider may control building perimeter access, but you still need controls for your cage/suite perimeter and for equipment leaving your custody. Document shared responsibilities and retain evidence for the portions you control. (Source: NIST SP 800-53 Rev. 5)
Are cameras enough to satisfy the “security checks” requirement?
Cameras support detection and investigation, but PE-3(2) calls for performing checks at the perimeter for the stated purpose. Pair cameras with an explicit check process such as asset pass verification, escort sign-out, or shipping authorization review. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
How should we handle privacy concerns with bag checks?
Write the SOP to minimize personal data collection, focus on corporate assets and authorized removals, and define an escalation path when a person refuses a check. If bag checks are constrained, adopt alternative controls like asset pass enforcement, escorts, and shipping verification with documented rationale. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
What is the minimum evidence an auditor will accept?
Provide a documented procedure, identified roles, training records for performers, and recent operational records showing checks or approvals occurred. Make the evidence easy to retrieve by mapping PE-3(2) to the evidence set in a single system of record. (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