PE-2: Physical Access Authorizations

PE-2 requires you to develop, approve, and maintain an accurate list of people authorized for physical access to the facility where your system resides, and to operate that list as a real access-control mechanism (not a static spreadsheet). To operationalize it quickly, define the facility scope, assign an owner, tie authorization to HR/contractor lifecycle events, and produce repeatable review and removal evidence. ¹

Key takeaways:

• You need an approved, maintained “authorized physical access” roster for each in-scope facility, with clear joiner/mover/leaver controls. ¹
• Auditors look for operational proof: approvals, reviews, and timely removals aligned to personnel changes, not just a policy.
• Map PE-2 to an accountable owner, procedure, and recurring evidence set so you can pass assessments without scrambling.

The pe-2: physical access authorizations requirement is one of those controls that sounds simple and still fails in audits because it gets treated as “Facilities handles badges” instead of a security control with defined scope, approvals, and evidence. PE-2 is narrowly worded: you must “develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides.” ¹ That means you need a living authorization list tied to your system’s hosting location(s), whether that’s your own office suite, a cage in a colocation site, a data center floor managed by a third party, or a mixed model.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat the authorization list like an access system of record: define what “facility” means for your environment, specify who can approve access, integrate requests and terminations with HR and third-party onboarding/offboarding, and retain evidence that the list is current. If you do that, PE-2 becomes routine: a small set of repeatable artifacts, a cadence for review, and a clean story for auditors about how physical access to system locations is controlled and monitored.

Regulatory text

Requirement (verbatim excerpt): “Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides;” ¹

What the operator must do:

• Develop an authorization list that covers all individuals who can physically access the facility where the system resides. ¹
• Approve that list (or entries on it) through an identified, documented approver workflow. ¹
• Maintain the list so it stays accurate as people join, change roles, or leave. ¹

This is not a policy-writing exercise. Your list has to match real badge/access rights and be kept current through operational processes.

Plain-English interpretation (what PE-2 is really asking)

PE-2 expects you to answer one question reliably: “Who is allowed to enter the place where this system lives?” Then it expects you to prove that answer is (1) authorized, (2) current, and (3) controlled.

In practice, auditors want to see:

• A defined facility scope for each in-scope system (headquarters, lab, data center room, colo cage, wiring closet, etc.).
• A named control owner accountable for the roster.
• A workflow that prevents ad hoc access grants and ensures timely removal.
• Evidence that the authorization list is reviewed and corrected, not abandoned.

Who it applies to (entity and operational context)

Entities:

• Federal information systems and contractor systems handling federal data commonly implement NIST SP 800-53 controls, including PE-2. ²

Operational contexts where PE-2 shows up:

• On-prem facilities: offices with server rooms, labs, network closets, production floors with OT/IoT.
• Colocation: cages/suites where your hardware is installed; your staff and third-party technicians may have access.
• Hybrid hosting: some systems in cloud, but supporting systems (network edge, HSMs, backups, build rooms) remain in physical facilities.
• Third-party managed facilities: you may not manage the building access system, but you still need an authorization list for who is permitted to access the relevant spaces, plus governance over the third party process.

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

Step 1: Define “facility where the system resides”

Create a short scoping statement per system (or per boundary) that lists:

• Facility name and address (or colo identifier).
• Spaces that matter (data center floor, cage number, server room, MDF/IDF, records room).
• Who controls access (you vs. landlord/colo vs. managed service provider).

Deliverable: Facility scope register linked to your system inventory.

Step 2: Choose the system of record for the authorization list

Pick one place where the authoritative list lives:

• Physical access control system exports (badge system).
• Colo portal access roster.
• A controlled GRC register if you cannot get reliable exports, but only if you can reconcile it to actual badge grants.

Deliverable: PE-2 authorized access roster per facility.

Minimum fields to include:

• Legal name
• Employer (employee or third party)
• Unique identifier (badge ID, ticket ID, or portal user ID)
• Facility/space authorized
• Access level (if applicable)
• Approval reference (ticket/workflow ID)
• Start date and end date (or “until revoked” with review trigger)
• Sponsoring manager / business owner

Step 3: Define who can approve physical access

Write down approval rules that match your risk posture:

• Who can request access (manager, project lead, Facilities, Security).
• Who approves (Facilities + Security, or Security alone for restricted spaces).
• When additional checks apply (background screening requirements may exist in your program, but keep PE-2 focused on authorization mechanics).

Deliverable: Physical Access Authorization SOP (one to two pages) that states roles and approval steps.

Step 4: Integrate joiner/mover/leaver events

This is where PE-2 usually breaks.

Operational requirements to implement:

• Joiners: no badge/portal access without an approved request and documented facility scope.
• Movers: role/location changes trigger access review (e.g., moving teams should not retain old server room access by default).
• Leavers: terminations and contract end dates trigger removal from the access roster and badge deactivation.

Deliverables:

• Workflow/ticket type for physical access requests and removals
• HR/Identity triggers (HR termination feed, contractor end date report, or weekly reconciliation)

Step 5: Run a recurring reconciliation and review

Set a review cadence that your team can sustain and defend in an audit. The control text requires the list be maintained; the cleanest way to prove “maintained” is a repeatable review record. ¹

Practical review checks:

• Compare badge system/colo roster to the PE-2 list (or confirm the badge system export is the list).
• Confirm each individual has an active business need and a current sponsor.
• Remove entries that are stale, duplicated, or not tied to a current ticket/approval.

Deliverables:

• Access roster review log (date, reviewer, exceptions found, removals completed)
• Exception tickets for anything that cannot be remediated immediately

Step 6: Handle third-party access explicitly

Physical access often includes third parties (facility staff, ISP techs, hardware vendors, consultants). Treat them like named individuals, not company names.

Required mechanics:

• Each third-party person has an entry on the authorized list.
• Access is sponsored by an internal owner.
• Access ends when the engagement ends (or is periodically re-approved).

If your colo provider controls access, require:

• Evidence exports or screenshots from the provider portal showing the current authorized user list.
• A documented process for requesting removals.

Step 7: Map ownership, procedure, and recurring evidence (assessment readiness)

Make PE-2 easy to audit by explicitly mapping:

• Control owner
• Procedure/SOP link
• Evidence set and where stored
• Review cadence and responsible role

If you use Daydream, set PE-2 as a control with assigned owner and recurring evidence tasks so the roster review, approvals, and exports land in one place throughout the year, not the week before an assessment.

Required evidence and artifacts to retain

Keep artifacts that prove developed, approved, maintained:

Core artifacts

• Authorized access roster export(s) per facility (current state)
• Physical access request/approval tickets (sample set across the period)
• Termination/offboarding removal tickets (sample set)
• Recurring roster review log + remediation records

Supporting artifacts

• Facility scope register tied to the system boundary
• Role/approval matrix (who can approve what spaces)
• Third-party access sponsorship list (if not already in the roster)

Auditor-friendly packaging: one folder per facility per review period containing the roster, review log, and the exceptions closed.

Common exam/audit questions and hangups

Expect these questions:

• “Show me the list of individuals with authorized access to the facility where System X resides.” ¹
• “Who approves additions to this list, and how do you document approval?”
• “How do you ensure terminated employees and ended contractors are removed?”
• “How do you handle access for third-party technicians at a colocation site?”
• “Prove the list is maintained. Where is your review evidence?”

Common hangups:

• Multiple facilities but one generic list.
• A list that exists but cannot be reconciled to badge access.
• Approvals done via informal email with no retention.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails PE-2	Fix
Treating the badge system as “Facilities-only” and not part of compliance	You cannot show an approved, maintained authorization list for the system facility	Make the badge export (or colo roster) the system of record and govern it with Security/GRC oversight
Listing companies instead of people (“ACME Cabling”)	PE-2 requires individuals with authorized access	Record named individuals and their sponsor
No removal proof	“Maintain” implies timely updates	Tie removals to HR/contractor offboarding triggers and keep tickets
One-time cleanup with no cadence	Auditors test operating effectiveness over time	Run recurring reviews and store review logs

Risk implications (why operators care)

If an unauthorized person can enter the system facility, they can bypass logical controls through device theft, tampering, rogue hardware insertion, or direct console access. PE-2 is also a dependency control: incident response, asset management, and media protection all assume you can restrict who gets near the systems.

The most common PE-2 risk in assessments is not “no locks,” it is no proof the authorization list is current. Missing evidence turns a potentially strong physical security posture into an audit finding.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Confirm in-scope systems and list the facilities/spaces where they reside.
• Assign a PE-2 control owner (Security, Facilities, or IT, but named).
• Select the system of record for the authorized access roster per facility.
• Stand up a basic approval workflow (ticket type + required fields).

Days 31–60 (operationalize lifecycle controls)

• Integrate joiner/mover/leaver events with physical access requests and removals.
• Build a third-party access sponsorship process and require named individuals.
• Perform the first reconciliation: roster vs. badge/colo records; remediate gaps.
• Define and document the review cadence and reviewer responsibilities.

Days 61–90 (evidence hardening and audit readiness)

• Run at least one full recurring roster review and capture the full evidence set.
• Create an “audit packet” template per facility (scope, roster, approvals, review log, exceptions).
• Test a termination sample: pick recent leavers and verify badge/portal access removal evidence exists.
• In Daydream (or your GRC system), schedule recurring evidence tasks so PE-2 stays current year-round.

Frequently Asked Questions

Does PE-2 require a physical access policy, or just a list?

The control text is explicit about the list: develop, approve, and maintain it. ¹ A short SOP helps prove how approvals and maintenance happen, but the list and its operating evidence are what you will be asked to produce.

What counts as the “facility where the system resides” in cloud-first environments?

If the system is fully hosted in a public cloud, the “facility” may be the provider’s data centers, which you do not control directly. In practice, focus PE-2 on the facilities you control that support the system boundary (offices, labs, network rooms, build rooms, or locations housing dedicated hardware).

Can the badge system be the authorization list?

Yes, if you can export it and show it is approved and maintained through your workflow. The failure mode is having badge access granted outside governance with no retained approvals.

How do we handle third-party data center or colocation access?

Require a named-user roster from the provider portal or access reports, and reconcile it to your internal sponsorship/approval records. Ensure you can show removals when the third party engagement ends.

We have one office and many systems. Do we need separate lists per system?

PE-2 is facility-based, so one facility list can cover multiple systems if they reside in the same controlled space. Document the mapping from systems to facilities so the shared roster clearly satisfies each system’s PE-2 expectation.

What evidence is usually missing during audits?

Review and removal proof. Teams can often produce a current roster, but cannot show recurring maintenance (review logs, exception remediation) or timely deprovisioning tied to terminations.

Footnotes

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

2. NIST SP 800-53 Rev. 5