Roles and Responsibilities for Physical Access

To meet the roles and responsibilities for physical access requirement, you must document who performs each Physical Security control in PCI DSS Requirement 9, assign ownership with backup coverage, and prove those people understand their duties. Operationally, this means a clear RACI, written procedures tied to job roles, and repeatable evidence that access tasks are executed and reviewed. (PCI DSS v4.0.1 Requirement 9.1.2)

Key takeaways:

• Create a Requirement 9 RACI that names accountable owners for every physical access activity in scope. (PCI DSS v4.0.1 Requirement 9.1.2)
• Tie procedures to roles (Facilities, IT, Security, HR, third parties) and keep proof of task execution and periodic review.
• Auditors look for “assigned and understood,” so training/attestations and management oversight matter as much as the document.

PCI DSS physical access controls often fail audits for a simple reason: the organization has controls on paper, but nobody can show who actually owns the day-to-day work. Requirement 9.1.2 fixes that by forcing clarity. It expects documented roles and responsibilities, explicit assignment, and evidence that the people performing physical security activities understand what they must do. (PCI DSS v4.0.1 Requirement 9.1.2)

For a CCO, GRC lead, or Compliance Officer, the fastest path is to treat this as an operating model deliverable: one RACI, a set of mapped procedures, and an evidence system that proves execution. This requirement applies to the physical locations, people, and processes that protect the cardholder data environment (CDE) and any in-scope system components, including where third parties have physical access (for example, colocation staff or building security). (PCI DSS v4.0.1 Requirement 9.1.2)

The guidance below is built to get you audit-ready quickly: who should own what, how to write the minimum documentation that passes scrutiny, what evidence to retain, and where teams commonly break down during assessments.

Regulatory text

Requirement: “Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.” (PCI DSS v4.0.1 Requirement 9.1.2)

Operator meaning (what you must do):

1. Document the roles/responsibilities for every physical access activity you perform to satisfy PCI DSS Requirement 9. (PCI DSS v4.0.1 Requirement 9.1.2)
2. Assign those responsibilities to specific roles (and, in practice, named owners/teams) so there is accountable ownership and backup coverage. (PCI DSS v4.0.1 Requirement 9.1.2)
3. Prove they are understood through onboarding, training, role acknowledgments, and manager oversight that ties people to the procedures they execute. (PCI DSS v4.0.1 Requirement 9.1.2)

Plain-English interpretation

You need a defensible answer to: “Who does physical access control work, what exactly do they do, and how do you know they know?” If Facilities issues badges, Security reviews CCTV, IT manages data center racks, HR triggers terminations, and a third party guards the lobby, you must show how those responsibilities fit together without gaps.

Assessors typically test this requirement indirectly: they sample physical access requests, visitor logs, badge changes, and periodic reviews. If any sample has unclear ownership (or the doer cannot explain the procedure), Requirement 9.1.2 becomes the root cause even if you have other physical controls written down.

Who it applies to

Entity types: merchants, service providers, and payment processors that must comply with PCI DSS. (PCI DSS v4.0.1 Requirement 9.1.2)

Operational context (scope):

• All locations with physical access to the CDE or in-scope system components (office suites, data centers, server rooms, network closets, storage areas).
• All people who can grant, approve, administer, or audit physical access: employees, contractors, and other third parties (guards, building management, colocation staff).
• All activities under PCI Requirement 9 that your environment relies on: badge provisioning, key control, visitor handling, escorting, media storage access, monitoring, log retention, and periodic access reviews. (PCI DSS v4.0.1 Requirement 9.1.2)

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

1) Define your physical access control boundary

• List the in-scope spaces (rooms, cages, closets) and the physical control mechanisms (badges, keys, biometrics, mantraps, visitor process, cameras).
• Identify which teams touch each mechanism (Facilities, Corporate Security, IT, Data Center Ops, HR, Workplace, third-party building security).

Deliverable: “Physical Access Scope & Control Points” register (simple table is fine).

2) Build a Requirement 9 RACI that covers the full lifecycle

Create a RACI that maps each Requirement 9 activity to roles. You do not need a novel; you need full coverage without ambiguity.

Example RACI rows (adapt to your environment):

Activity (Req. 9)	Responsible	Accountable	Consulted	Informed
Approve new badge access to CDE room	Corporate Security	CISO / Security Director	IT System Owner, Compliance	Facilities
Create/modify badge in access system	Facilities or Security Admin	Security Manager	HR (employment status)	Requestor manager
Visitor sign-in, ID check, issue temporary badge	Reception / Security Guard (incl. third party)	Facilities Lead	Compliance	Site leadership
Escort visitors in CDE areas	Host employee	Host manager	Security	Reception
Periodic physical access review	Compliance + Security	CCO / Security Director	IT owners	Internal Audit

Deliverable: Requirement 9 RACI (version-controlled).

3) Translate the RACI into role-based procedures people can follow

For each activity in your RACI, create or update a procedure with:

• Trigger (e.g., “new hire needing server room access”)
• Required approvals
• How to validate identity and authorization
• Steps in the badge/key system
• Logs generated and where stored
• Exception handling (lost badge, emergency access, system outage)
• Required reviewer and review frequency (define your cadence as a control objective)

Keep procedures short and operational. If it reads like a policy statement, rewrite it as a runbook.

Deliverables: Physical Access Procedures (runbooks) mapped to RACI lines.

4) Assign ownership to named roles, then attach to HR constructs

Auditors accept role-based assignment, but your operations need named ownership.

• Put each RACI “Accountable” role into a control owner list with a primary and delegate.
• Tie responsibilities to job descriptions or team charters where possible.
• Confirm third-party responsibilities in contracts/SOWs if guards, building management, or colocation providers execute parts of your control.

Deliverables: Control Owner Register; third-party responsibility clauses or addenda (where applicable). (PCI DSS v4.0.1 Requirement 9.1.2)

5) Prove the roles “are understood”

This is where many programs fail because they stop at documentation. Use at least two of these mechanisms:

• Role-based training for Facilities/Security/Reception/IT staff handling physical access
• Annual (or defined-cadence) acknowledgments that staff read the procedures
• Tabletop walkthroughs for edge cases (visitor exceptions, badge system outage)
• Manager attestations during performance or compliance cycles

Deliverables: training completion records; signed acknowledgments; walkthrough notes; manager attestations. (PCI DSS v4.0.1 Requirement 9.1.2)

6) Stand up an evidence routine that matches audit sampling

Build an evidence map that shows, for each Requirement 9 activity:

• What artifact is generated
• Who generates it
• Where it is stored
• How long it is retained (set a retention standard that meets your internal and PCI program needs)

If you use Daydream, treat this as a control-to-evidence workflow: RACI owners get tasks, upload artifacts, and approvals are tracked in one place so you can answer “assigned and understood” without chasing email threads.

Required evidence and artifacts to retain

Keep evidence that proves documentation, assignment, understanding, and execution:

Governance

• Requirement 9 RACI with owner names/roles and version history
• Physical Access Policy and supporting procedures/runbooks
• Control owner register (primary/delegate)

Operational records (samples)

• Badge/access requests and approvals for CDE areas
• Badge provisioning/change logs from the access control system
• Visitor logs for in-scope areas (including escort records)
• Key inventory logs (if keys are used) and issuance/return records
• Exception records (lost badge, emergency access)

“Understood” proof

• Training materials + attendance/completion logs
• Acknowledgments/attestations tied to roles that perform Requirement 9 activities (PCI DSS v4.0.1 Requirement 9.1.2)

Common exam/audit questions and hangups

• “Show me where Requirement 9 responsibilities are documented, and who owns each activity.”
  Hangup: you provide a policy but no RACI or ownership mapping.
• “Who can approve access to the server room, and what is the approval path?”
  Hangup: approval is informal (chat/email) and not consistently retained.
• “How do you ensure third-party guards follow your visitor process?”
  Hangup: contract lacks procedural obligations; no training or oversight evidence.
• “How do staff learn the procedure?”
  Hangup: you claim training exists but cannot show records. (PCI DSS v4.0.1 Requirement 9.1.2)

Frequent implementation mistakes and how to avoid them

1. RACI exists but doesn’t match reality. Fix by validating with Facilities/Security/IT in a working session and testing against real tickets and visitor flows.
2. No accountable owner for periodic reviews. Assign a single accountable role and define what “review complete” means in evidence terms.
3. Third parties treated as “out of scope.” If they perform an in-scope activity (like visitor check-in), you still need documented responsibilities and proof of understanding. (PCI DSS v4.0.1 Requirement 9.1.2)
4. Procedures written at policy level. Rewrite into steps with system-of-record references (badge system, ticketing, log repository).
5. Understanding is assumed. Add attestations and short role-based training tied to the RACI. (PCI DSS v4.0.1 Requirement 9.1.2)

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, so treat this as an audit and breach-exposure control rather than a penalty-driven one.

Risk-wise, unclear ownership causes control gaps: terminated employees keep access, visitors are not escorted, badge exceptions become the norm, and physical entry becomes an easy path to system compromise. Requirement 9.1.2 is a “program glue” control: it makes the rest of Requirement 9 auditable because humans, not documents, run physical security.

Practical 30/60/90-day execution plan

First 30 days (stabilize ownership)

• Confirm in-scope physical areas and control points.
• Draft the Requirement 9 RACI and name accountable owners with delegates.
• Inventory existing procedures and identify gaps tied to RACI rows.
• Decide your evidence repository and ownership (GRC tool, ticketing, controlled folder).

By 60 days (make it executable)

• Publish updated runbooks for the highest-risk flows: badge issuance to CDE, visitor entry, access removal, exceptions.
• Implement training/acknowledgment for the roles in the RACI.
• Update third-party agreements/SOWs or operating procedures for guards/building staff where they execute steps.

By 90 days (make it auditable)

• Run an internal “mini-assessment”: sample recent access requests, visitor logs, and terminations, then trace to RACI owner and procedure.
• Fix evidence gaps (missing approvals, inconsistent logs, unclear retention).
• Schedule recurring reviews (access reviews, procedure review, training refresh) with calendar ownership and a defined output artifact.

Frequently Asked Questions

Do we need a separate policy just for “roles and responsibilities for physical access”?

No. You need documented roles and responsibilities for Requirement 9 activities, which can live in a RACI plus procedures and a policy structure. The key is that it’s assigned and understood, with proof. (PCI DSS v4.0.1 Requirement 9.1.2)

Is a RACI mandatory, or can we describe responsibilities in a narrative?

PCI DSS doesn’t prescribe a RACI format, but you must document, assign, and show understanding. A RACI is the fastest way to show complete coverage and avoid ambiguity during sampling. (PCI DSS v4.0.1 Requirement 9.1.2)

How do we handle shared responsibility between Facilities and IT for server rooms?

Split responsibilities by lifecycle step (approval, provisioning, monitoring, review) and make one role accountable per step. Shared accountability is where audits get messy; keep “Accountable” singular.

What counts as evidence that people “understand” their responsibilities?

Training completion records, role-based attestations, and walkthroughs tied to the specific procedures are strong evidence. Pair that with interviews: staff should be able to explain the steps they perform. (PCI DSS v4.0.1 Requirement 9.1.2)

Our building security is a third party. Are they included?

Yes if they perform any in-scope Requirement 9 activities (visitor check-in, badge issuance, escorting, monitoring). Document their responsibilities, ensure they are trained or briefed on your procedures, and retain oversight evidence. (PCI DSS v4.0.1 Requirement 9.1.2)

How should we store evidence so audits don’t turn into a fire drill?

Store artifacts by Requirement 9 activity with clear ownership and a repeatable naming convention, and keep a simple evidence map that shows where each artifact lives. Many teams centralize this in Daydream so RACI owners can upload proof as work happens and approvals are preserved.