PE-2(1): Access by Position or Role

PE-2(1) requires you to grant physical access to the facility where a system resides based on a person’s position or role, not ad hoc exceptions or informal approvals. To operationalize it quickly, define role-based physical access groups, map them to specific areas, enforce approvals through your access control system, and retain evidence that access aligns to current job roles. ¹

Key takeaways:

• Define role-based facility access profiles (by position/role) and map each profile to specific physical zones.
• Enforce access assignments through a controlled workflow tied to HR/identity data, with periodic review and rapid removal on role changes.
• Keep assessor-ready evidence: role-to-zone matrix, approvals, badge/credential rosters, and physical access logs.

For most programs, physical security controls get assessed only when something goes wrong: a tailgating incident, a lost badge, or a contractor who “just needed to get in for a minute.” PE-2(1) is the control that prevents that drift by forcing an explicit rule: facility access follows position or role. ²

If you are a CCO, Compliance Officer, or GRC lead supporting NIST SP 800-53 assessments (including federal systems and contractors handling federal data), treat PE-2(1) as a design-and-evidence control. You need (1) a defensible authorization model (roles → zones), (2) an operational process that keeps assignments accurate as people join, move, and leave, and (3) artifacts that prove it ran as intended.

This page focuses on fast execution: how to define roles without boiling the ocean, how to integrate Facilities/Security with HR and IAM, what auditors ask for, and what breaks in practice. The goal is simple: nobody has physical access to system-resident facilities unless their role requires it, and you can prove it on demand. ¹

Regulatory text

Requirement (verbatim): “Authorize physical access to the facility where the system resides based on position or role.” ¹

What the operator must do:

• Define which positions or roles warrant physical access to the facility (and to which areas within it).
• Grant, modify, and revoke physical access only through those role definitions, with approvals and traceability.
• Prevent “special” access that bypasses the role model, or treat it as a time-bound exception with documented approval and review.

This is not a policy-only control. Assessors typically want to see the access control system configuration (badge groups, door groups), the workflow that assigns people to those groups, and proof the workflow reflects current roles. ²

Plain-English interpretation (what PE-2(1) really means)

PE-2(1) means you run your facility access like you run logical access: role-based access control (RBAC), but for doors. If your system is in a data center, server room, wiring closet, or controlled office suite, access to that facility must be tied to job function.

A clean way to phrase it operationally:

• “If your job role needs it, you get access.”
• “If your job role does not need it, you don’t.”
• “If you need one-time access, it’s approved, time-bound, logged, and reviewed.”

Who it applies to

Entity scope

• Federal information systems and programs assessed against NIST SP 800-53. ²
• Contractors and other organizations handling federal data where NIST SP 800-53 controls are flowed down contractually. ²

Operational scope (where it bites)

• Facilities where systems reside: data centers (owned or colocation), MDF/IDF closets, server rooms, security operations spaces, labs with controlled equipment, and offices with sensitive systems. ¹
• Hybrid environments: even if most workloads are cloud, you may still have network gear, endpoints, backups, or token/HSM infrastructure on-prem.

Third-party scope

• Third parties who need access (cleaning crews, ISP techs, hardware maintenance, auditors) must be handled through role-based models (for recurring roles) or controlled visitor/escort processes (for non-recurring needs). The control language is about “position or role,” not employment type. ¹

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

1) Identify the “system-resident facility” boundaries

Create a simple facility/zone inventory:

• Facility name and address (or site identifier)
• Zones inside it (e.g., Lobby, Office Suite, Server Room, MDF, Cage A)
• Which zone(s) contain system components in scope

Output artifact: Facility/zone register with in-scope markings.

2) Define physical access roles (keep it small, tied to job function)

Start with a handful of roles that map to reality:

• Data Center Operations
• Network Engineering
• Facilities Maintenance (restricted)
• Security/Guard force
• Authorized IT Admin (if you have small teams)
• Approved Third-Party Technician (recurring contract role)

Avoid copying your entire HR job code list. Assessors want a workable role model that controls doors. ²

Output artifact: Role catalog for physical access.

3) Build a role-to-zone access matrix (the “who can open what” truth source)

Create a matrix with:

• Role
• Zones granted
• Access conditions (business hours only, escort required, dual authorization if your program requires it)
• Approver(s) by role (Facilities, Security, System Owner)
• Rationale (“needed to perform duties”)

Operator tip: Tie approvers to accountability. For high-sensitivity zones, include the System Owner or Information System Security Officer (ISSO) as an approver.

Output artifact: Physical Access Authorization Matrix (PAAM).

4) Configure the physical access control system (PACS) to match roles

In the PACS (badge system):

• Create access groups that correspond to your roles.
• Map groups to door schedules and door controllers for the specified zones.
• Disable “miscellaneous” groups that become junk drawers.

If you cannot create role groups (limitations or outsourced PACS), maintain a compensating control: a controlled spreadsheet plus weekly reconciliation against PACS assignments, with documented approvals and change tickets. Keep the goal intact: authorization follows role, with traceability. ¹

Output artifacts: Screenshots/export of PACS access groups and memberships.

5) Implement an approval workflow that starts from role/position data

Your workflow should answer: “Why does this person have access?”

• Trigger: New hire, role change, transfer, contractor onboarding
• Input: HR role/department, manager, work location, system/team assignment
• Control: Request must select a role-based access profile (not free-text)
• Approval: Manager + Facilities/Security + System Owner (as needed)
• Provisioning: PACS assignment to the correct role group
• Deprovisioning: automatic on termination; expedited removal on transfer out of role

Output artifacts: Access request tickets, approval records, onboarding/offboarding checklists.

6) Run periodic access reviews focused on role drift

Perform a review where you reconcile:

• HR roster vs PACS active badgeholders
• Current job role vs assigned physical access role group(s)
• Terminated/expired contractors vs active badges
• High-risk zones: validate “who has access and why” with named approvers

Output artifacts: Access review report, exceptions list, remediation tickets, sign-off.

7) Handle exceptions and visitors without breaking the model

Common “pressure points”:

• Emergency repairs after hours
• One-off third-party access
• Temporary project teams

Control approach:

• Use time-bound access credentials (start/end date)
• Require escort for non-recurring roles
• Document the exception, approver, and scope (zones, hours)
• Review exceptions in the next access review cycle

Output artifacts: Visitor logs, temporary badge logs, exception approvals.

Required evidence and artifacts to retain (assessor-ready)

Use this as your evidence checklist:

• Physical access policy/procedure that states access is authorized by position/role. ¹
• Facility/zone inventory identifying where the system resides.
• Role catalog for physical access.
• Role-to-zone access matrix with approver and rationale.
• PACS configuration evidence: access group definitions, door mappings, membership exports.
• Access requests and approvals: tickets or forms showing role selection and approvals.
• Provisioning/deprovisioning records: onboarding/offboarding steps; termination removals.
• Periodic access review package: roster, findings, remediation actions, sign-off.
• Logs: badge access logs (especially for sensitive zones) and visitor/escort logs.

If you use Daydream to manage control ownership and evidence cadence, map PE-2(1) to a single control owner (often Facilities Security or Corporate Security) plus a GRC co-owner, then schedule recurring evidence pulls (PACS group export, quarterly review sign-off) so you are not rebuilding proof during the audit window. ²

Common exam/audit questions and hangups

Expect these questions:

1. “Show me how physical access is authorized by role.” Provide the role-to-zone matrix plus a recent access request showing role selection and approval trail. ¹
2. “Who has access to the server room/data center right now?” Provide a PACS export for that door group and tie each person to a current role.
3. “How do you remove access when someone changes jobs or leaves?” Show offboarding evidence and HR-triggered workflow.
4. “How do contractors get access?” Show contractor roles or visitor/escort processes with time bounds.
5. “How do you detect access drift?” Show periodic review methodology and remediation tickets.

Hangup pattern: teams show a policy but cannot show how PACS groups map to roles, or they cannot show the last review and who signed it.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Everyone in IT” gets access to sensitive zones.
  Fix: split IT into roles based on actual need (network, data center ops, endpoint support). Keep the smallest set with server room access.

• Mistake: Role definitions exist, but PACS assignments are manual and inconsistent.
  Fix: require a role-based profile selection in every request and run reconciliations against HR role data.

• Mistake: Contractors accumulate access across engagements.
  Fix: enforce end dates on contractor badges and require renewal with re-approval.

• Mistake: Exceptions become permanent.
  Fix: time-box exceptions and track them as a queue item for the next access review.

• Mistake: Evidence is scattered across Facilities, Security, and IT.
  Fix: assign one control owner and one evidence coordinator; store artifacts in a single audit repository with consistent naming.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk still maps cleanly to operational impact:

• Unauthorized facility access can bypass logical controls (console access, removable media, network taps).
• Poor role alignment increases insider threat exposure and makes incident investigations harder because “who should have had access” is unclear.
• Weak evidence creates assessment risk even if operations are decent. Assessors grade what they can verify. ²

Practical 30/60/90-day execution plan

Use these phases as an execution plan (adjust to your environment size and whether PACS is outsourced):

First 30 days (stabilize and define)

• Assign a control owner and backups; define RACI across Security, Facilities, IT, and HR.
• Inventory in-scope facilities and define zones.
• Draft the role catalog (start small) and the role-to-zone access matrix.
• Export current PACS access lists for sensitive zones and identify obvious misalignments for cleanup.

Days 31–60 (implement and align to systems)

• Configure PACS groups to match roles (or document compensating reconciliation controls).
• Implement an access request workflow that requires selecting a role-based access profile.
• Formalize exception handling for temporary access, including required approvals and end dates.
• Run your first access review focused on the highest-risk zones; open remediation tickets.

Days 61–90 (prove operation and make it repeatable)

• Complete remediation from the initial review (removals, role corrections, contractor expirations).
• Run a second review to prove the process is operating, not a one-time cleanup.
• Package evidence in an assessor-ready folder: matrix, PACS exports, review sign-offs, sample tickets, visitor logs.
• In Daydream, set recurring tasks for evidence pulls and access reviews so PE-2(1) stays continuously testable. ²

Frequently Asked Questions

Does PE-2(1) require RBAC in the badge system itself?

The requirement is outcome-based: access must be authorized by position or role. The simplest way is PACS role-based groups, but a documented compensating process can work if it reliably enforces role-based approvals and you can prove it. ¹

Our systems are in the cloud. Do we still need this control?

If you have any facility where in-scope system components reside (network gear, endpoints, backup media, HSMs), PE-2(1) applies to that facility. If you truly have no such facility in scope, document the rationale and boundary. ¹

How should we handle occasional third-party technicians?

Treat non-recurring third-party access as time-bound and approved for specific zones, often with escort requirements. Keep visitor logs and the approval record tied to the work order. ²

What evidence is most persuasive to an assessor?

A role-to-zone matrix plus a PACS export showing group membership, then a few sampled access requests that show approvals and role alignment. Add the latest access review report with sign-off and remediation tracking. ²

Who should own PE-2(1): IT or Facilities?

Ownership usually sits with Corporate Security or Facilities Security because they administer PACS, with IT/System Owners as required approvers for sensitive zones. What matters is clear accountability and evidence coordination. ²

How do we handle employees with multiple roles?

Allow multiple access profiles only when each is justified, approved, and recorded. Document the rationale in the access request and ensure the combined access still matches job duties. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5