PE-2(3): Restrict Unescorted Access

PE-2(3): restrict unescorted access requirement means you must prevent anyone from entering the facility area(s) where the system resides unless they meet your defined authorization criteria, or they are escorted. Operationalize it by defining who qualifies, enforcing it with physical access controls and visitor procedures, and retaining access/visitor evidence for audits. ¹

Key takeaways:

• Define “authorized for unescorted access” as a documented, role-based criterion tied to need-to-access the facility zone(s).
• Enforce the restriction with badges/keys, zone controls, visitor escort rules, and rapid deprovisioning when roles change.
• Keep assessor-ready evidence: access rosters, approvals, logs, visitor records, and periodic reviews mapped to a control owner. ²

A common failure mode in physical security controls is ambiguity: teams control “building access” but cannot prove who is allowed to enter the specific facility space where the system resides, without an escort. PE-2(3): restrict unescorted access requirement closes that gap by forcing you to define a standard for “who may be unescorted” and to implement enforceable barriers and procedures that match that standard. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PE-2(3) as a scoped access authorization control: identify the facility zones that matter (data center room, network closet, secure cage, operations floor), define the authorization criteria, then configure physical access systems and visitor handling so that anyone outside the criteria is either blocked or escorted. Your audit posture depends less on having “a policy” and more on showing repeatable operations: approvals before granting unescorted access, logging, periodic review, and prompt removal. ²

This page gives requirement-level implementation guidance you can hand to facilities/security operations, and it tells you exactly what artifacts to retain so you can answer assessors without scrambling.

Regulatory text

Requirement (PE-2(3)): “Restrict unescorted access to the facility where the system resides to personnel with {{ insert: param, pe-02.03_odp.01 }}.” ¹

Operator translation: You must (1) define the organization-specific criteria represented by the parameter (your “who qualifies” rule), and (2) enforce that only those personnel can enter the facility area where the system is located without an escort. Everyone else must be denied entry or escorted under a defined process. ²

What the parameter typically represents in practice: a documented authorization basis such as “approved physical access based on role, need, background screening status, and management approval,” applied to specific zones rather than the whole building. Your criteria must be explicit enough that an assessor can test it against your access roster and logs.

Plain-English interpretation (what the control is trying to prevent)

PE-2(3) reduces the risk of unauthorized physical presence near systems that process, store, or transmit sensitive data. Physical proximity enables outcomes you cannot fully mitigate with cyber controls alone (device theft, console access, rogue hardware insertion, or tampering). The requirement focuses on unescorted access because escorts are a compensating control: they allow legitimate business visits while keeping accountability on a trained, authorized employee.

Who it applies to (entity and operational context)

Entities: Federal information systems and contractor systems handling federal data that align to NIST SP 800-53 control expectations. ²

Operational contexts where assessors expect PE-2(3) discipline:

• On-prem data centers, server rooms, cages, network closets, comms rooms.
• Offices with dedicated system infrastructure rooms or restricted operations areas.
• Co-location environments where you control a cage/suite (even if the landlord controls perimeter building access).
• Third-party hosted facilities, when your contract grants your staff access to the space where your system components reside (you still need to control your unescorted eligibility list and procedures).

Scoping rule you should document: Identify the “facility where the system resides” as named zones/areas, not vague “HQ.” If the system is distributed, scope the zones that contain system components (compute, storage, network) and any spaces with direct console/physical port access.

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

1) Define the authorization criteria (“who may be unescorted”)

Create a short standard that answers:

• Which roles may have unescorted access (examples: data center operations, network engineering on-call, facilities staff assigned to secure areas).
• Preconditions (examples: employment/contract status, training completion, background screening where applicable, manager approval).
• How exceptions work (temporary unescorted access should be rare; prefer escorting for visitors and short-term work).

Deliverable: Unescorted Physical Access Standard that includes the criteria, approval authority, and revocation triggers. Keep it terse and testable.

2) Map and label the controlled zones

Build a zone inventory for the spaces that qualify as “facility where the system resides,” for example:

• Zone A: Data center room (badge + mantrap)
• Zone B: Network closet (badge)
• Zone C: Secure cage at colo provider (keycard managed by provider, authorized list maintained by you)

Deliverable: Physical Security Zone Register tied to the system boundary description you use for your authorization package / SSP.

3) Implement technical enforcement for unescorted access

Coordinate with physical security/facilities to ensure access control mechanisms align to your criteria:

• Badge access groups mapped to the zones.
• Unique credentials per person (no shared badges/keys for unescorted eligibility).
• Anti-passback/mantrap controls where risk warrants (if available).
• Alarm/monitoring integration for forced-door or after-hours access (as feasible).

Minimum expectation: The access control system must prevent unapproved personnel from entering the restricted zone unescorted.

4) Establish an escort/visitor process for everyone else

Write a simple operational procedure:

• Visitor identity verification and sign-in.
• Visitor badge type that cannot open restricted doors.
• Escort eligibility (who can escort; usually personnel already authorized for unescorted access to that zone).
• Escort ratio and line-of-sight rules appropriate to your environment.
• Visitor sign-out and badge return.

Make one person accountable for visitor log retention.

5) Add joiner/mover/leaver (JML) triggers for physical access

Most PE-2(3) findings come from stale access lists. Tie physical access changes to HR/IT workflows:

• Grant: requires documented request + approval against criteria.
• Modify: role change triggers re-evaluation of zone access.
• Remove: termination/contract end triggers same-day deactivation where feasible.

Practical control: run a recurring reconciliation between HR roster and badge system active users for restricted zones.

6) Run periodic access reviews and document them

Do recurring reviews of:

• The unescorted access roster per zone.
• Exceptions/temporary grants.
• Visitor logs for anomalies (after-hours, repeated visits, missing sign-outs).

Document reviewer, date, changes made, and follow-ups. Assessors test that you don’t just “set it once.”

7) Assign control ownership and evidence cadence

Put PE-2(3) under a named owner (Facilities Security, Corporate Security, or Data Center Ops) with GRC oversight. Map it to procedures and evidence artifacts. Daydream can help you map PE-2(3) to a control owner, implementation procedure, and recurring evidence artifacts so audits don’t turn into a document hunt. ²

Required evidence and artifacts to retain

Keep artifacts that prove design (what you said you do) and operation (what you did):

Design evidence

• Unescorted Physical Access Standard (criteria + approval authority).
• Zone Register / facility diagram excerpts showing restricted areas in scope.
• Visitor/Escort Procedure.

Operating evidence

• Access control group membership export for each restricted zone (roster of unescorted personnel).
• Access request/approval tickets (sample set that shows criteria checks).
• Badge system logs or door event logs for restricted zones (sampled period).
• Visitor logs for restricted zones + escort assignments.
• JML deprovisioning records for terminated/role-changed personnel.
• Periodic access review records (sign-off + remediation actions).

Retention period: follow your internal retention schedule; ensure it covers the audit window and allows sampling across time.

Common exam/audit questions and hangups

Assessors and internal audit teams tend to focus on these:

1. “Define ‘facility where the system resides.’ Which doors and rooms are in scope?”
   Hangup: teams only show building lobby controls, not the actual system room.

2. “Show me the criteria for unescorted access and prove each person on the roster meets it.”
   Hangup: criteria exists, but approvals don’t reference it.

3. “How do you prevent piggybacking/tailgating?”
   Hangup: policy says “no tailgating,” but there’s no training, signage, monitoring, or enforcement story.

4. “How fast is access removed after termination or transfer?”
   Hangup: cyber accounts are offboarded, badges remain active.

5. “Do visitors ever enter restricted areas unescorted?”
   Hangup: contractors are treated as “known,” but they are not authorized per criteria.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating all employees as eligible for unescorted access.
  Fix: restrict to roles with a documented need; everyone else uses escort.

• Mistake: Managing keys/badges informally (shared keys, spare badges).
  Fix: unique assignment, inventory checks, documented issuance/return, and rapid disablement.

• Mistake: No zone-level scoping.
  Fix: define the rooms/doors where system components reside; map badge groups to those zones.

• Mistake: Reviews happen but aren’t recorded.
  Fix: use a standard access review checklist and save exports, sign-off, and evidence of removals.

• Mistake: Third-party facilities are “out of sight, out of mind.”
  Fix: contractually require logs/controls where possible, and maintain your own authorized unescorted list and escort rules for your staff and visitors.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so you should treat PE-2(3) as an assessment-driven control under NIST SP 800-53 rather than a control with specific cited penalties here. ²

Operationally, the risk is straightforward: untracked physical access undermines incident investigation, increases insider threat exposure, and makes it hard to assert system integrity if tampering is suspected. From a governance standpoint, the most common “real” failure is inability to produce evidence quickly. Missing implementation evidence is itself a risk factor called out for PE-2(3). ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + rules)

• Name the PE-2(3) control owner and backups.
• Define the in-scope facility zones and list the controlled doors.
• Publish unescorted access criteria and approval workflow (ticket template).
• Export current badge/group rosters for in-scope zones and run a first-pass cleanup of obvious overprovisioning.

Days 31–60 (enforce + make it auditable)

• Align badge groups to zones; remove shared credentials where found.
• Implement/refresh visitor escort procedures and visitor badge restrictions.
• Add JML triggers for badge provisioning and deprovisioning (HR + security ops handshake).
• Stand up an evidence pack: where logs live, who pulls them, and how they are stored.

Days 61–90 (operate + prove repeatability)

• Run the first formal access review and document actions taken.
• Test an audit-style sample: pick a few badge holders and show end-to-end approval, eligibility, and door logs.
• Tabletop a “lost badge” and a “terminated employee” scenario to verify disablement steps and evidence capture.
• If you use Daydream, configure PE-2(3) with the mapped owner, procedure, and recurring artifacts so evidence collection becomes routine rather than episodic. ²

Frequently Asked Questions

What counts as “unescorted access” for PE-2(3)?

Unescorted access means a person can enter the facility zone where the system resides without a qualified escort present. If a visitor can badge into the server room alone, that is unescorted access and must be restricted to your defined criteria. ¹

Do contractors qualify as “personnel” who can have unescorted access?

They can, but only if your criteria explicitly allows it and you can prove they meet the criteria and were approved. In many environments, contractors should default to escorted access unless there is a documented operational need.

We’re in a co-location data center. The provider controls the building. Are we still on the hook?

Yes for what you can control: define who on your side is authorized for unescorted access to your cage/suite and maintain that approved list and supporting approvals. Also ensure your visitor/escort process covers anyone you bring into the space. ²

What evidence do auditors usually ask for first?

They usually start with (1) the unescorted access roster for the restricted zone and (2) proof of approval/eligibility for a sample of names. Door logs and visitor logs come next when they test operation.

Can cameras replace escorting for visitors?

Cameras can support detection and investigation, but they do not automatically meet the “restrict unescorted access” expectation. If a person can enter the restricted zone alone, you need to justify that they meet your criteria for unescorted access. ¹

How should we handle emergency access (fire alarm, facilities incident)?

Write an emergency access clause: safety first, then document the event, who entered, why, and any post-event checks. After-action evidence matters because PE-2(3) is assessed on both policy and operation.

Footnotes

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

2. NIST SP 800-53 Rev. 5