Security Policies and Procedures for Physical Access

PCI DSS 4.0.1 Requirement 9.1.1 requires you to have documented physical access security policies and operational procedures, keep them current, actively follow them, and ensure everyone affected actually knows them. To operationalize it fast, inventory all Requirement 9 physical controls, map each to a written procedure, assign owners, train affected staff and third parties, then collect proof that the procedures run in real life. (PCI DSS v4.0.1 Requirement 9.1.1)

Key takeaways:

• Your “physical security” policy must cover every physical access control referenced across PCI Requirement 9, not just doors and badges. (PCI DSS v4.0.1 Requirement 9.1.1)
• Auditors test “in use” and “known” through interviews, samples, and evidence, not policy PDFs. (PCI DSS v4.0.1 Requirement 9.1.1)
• Treat this as a documentation-and-adoption requirement: ownership, training, and execution records are as important as the words on the page. (PCI DSS v4.0.1 Requirement 9.1.1)

This requirement is a forcing function: if your team cannot show consistent, written physical access practices around cardholder data, you will struggle to pass a PCI assessment even if the building has strong security. Requirement 9.1.1 is not asking for a specific lock type or camera model. It is asking for governance and operational discipline around the physical access controls you already rely on to protect cardholder data environments.

A practical way to read it: “Write down how you restrict physical access, keep the documents current, prove people follow them, and prove the right people know what they are supposed to do.” That includes employees, contractors, and relevant third parties who may enter facilities or handle media. It also includes cross-functional teams that implement parts of physical security (Facilities, Corporate Security, IT, Data Center Operations, HR for onboarding/offboarding, and Procurement/TPRM for third-party access).

If you want fast execution, focus on three deliverables: (1) a policy and a set of role-based procedures tied directly to Requirement 9, (2) training/acknowledgements for affected parties, and (3) operational evidence that the procedures are actually followed.

Regulatory text

Requirement statement (verbatim): “All security policies and operational procedures that are identified in Requirement 9 are documented, kept up to date, in use, and known to all affected parties.” (PCI DSS v4.0.1 Requirement 9.1.1)

What the operator must do:

• Document the physical access security policies and the day-to-day procedures referenced by PCI Requirement 9 (for example: granting badge access, escorting visitors, reviewing access lists, securing media, responding to lost badges). (PCI DSS v4.0.1 Requirement 9.1.1)
• Keep them up to date with real operations: org changes, site moves, new data center provider, badge system changes, and role changes must trigger updates. (PCI DSS v4.0.1 Requirement 9.1.1)
• Put them in use: auditors will expect to see records, tickets, logs, and forms that show the procedures are executed. (PCI DSS v4.0.1 Requirement 9.1.1)
• Make them known to all affected parties: staff and relevant third parties must be able to describe what they do and where the procedure lives. (PCI DSS v4.0.1 Requirement 9.1.1)

Plain-English interpretation (what this means in practice)

If your organization stores, processes, or transmits cardholder data, you must run physical access like a controlled process, not a set of informal habits. The policy sets the rules (who can enter, under what conditions, and what “restricted area” means). Procedures tell people exactly how to follow those rules (how to request access, how approvals work, how visitors are logged, how exceptions are handled, what to do when a badge is lost, how to revoke access promptly). (PCI DSS v4.0.1 Requirement 9.1.1)

Auditors commonly treat 9.1.1 as the “paper trail” requirement behind all other physical security testing. If your controls exist but you cannot show they are documented, current, used, and understood, you will spend the assessment arguing about intent instead of passing requirements. (PCI DSS v4.0.1 Requirement 9.1.1)

Who it applies to (entity and operational context)

Entity types in scope: merchants, service providers, and payment processors subject to PCI DSS. (PCI DSS v4.0.1 Requirement 9.1.1)

Operational contexts that trigger work under 9.1.1:

• Corporate offices with cardholder data environment (CDE) space, network closets, or secure rooms that support payment systems. (PCI DSS v4.0.1 Requirement 9.1.1)
• Data centers and colocation sites, including third-party hosted environments where your staff can access cages, racks, consoles, or media. (PCI DSS v4.0.1 Requirement 9.1.1)
• Retail locations that store payment-related equipment, paper records, or media. (PCI DSS v4.0.1 Requirement 9.1.1)
• Third-party access scenarios: facilities vendors, cleaning crews, maintenance, and any third party that could physically reach systems or media tied to cardholder data. (PCI DSS v4.0.1 Requirement 9.1.1)

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

Step 1: Define your “Requirement 9 surface area”

Create a simple inventory of where physical controls matter for PCI:

• Locations: offices, server rooms, network closets, storage rooms, receiving areas, offsite storage, colocation cages.
• Assets: payment systems, servers, backup media, paper records, portable media, endpoints in restricted zones.
• People categories: employees, contractors, guards, facilities staff, visitors, and third parties. (PCI DSS v4.0.1 Requirement 9.1.1)

Output: a scoped list of spaces and workflows that your policy/procedures must cover. (PCI DSS v4.0.1 Requirement 9.1.1)

Step 2: Write (or refresh) the policy once, then drive procedures by workflow

A workable documentation set usually includes:

• Physical Access Security Policy (high-level rules): definitions (restricted area/CDE-adjacent areas), access principles, accountability, acceptable authentication methods (badge, key, biometrics), and exception handling. (PCI DSS v4.0.1 Requirement 9.1.1)
• Operational procedures (task-level runbooks), at minimum:
  • Access provisioning and approval (new access, changes, temporary access).
  • Visitor management (sign-in/out, identity check, badges, escort rules, log retention).
  • Access review (who reviews, what they compare against, how exceptions are remediated).
  • Access termination (role change, termination, contractor end date).
  • Lost/stolen badge response.
  • Physical media handling and storage (if applicable to your Requirement 9 controls). (PCI DSS v4.0.1 Requirement 9.1.1)

Practical tip: Write procedures in the format “Trigger → Steps → Required record → Owner → Escalations.” Auditors can test that structure quickly. (PCI DSS v4.0.1 Requirement 9.1.1)

Step 3: Assign owners and RACI for each procedure

If Corporate Security “owns” the badge system but IT approves access to the server room, spell that out. 9.1.1 fails most often due to unclear ownership, which leads to inconsistent execution evidence. (PCI DSS v4.0.1 Requirement 9.1.1)

Output: each document has a named owner, a backup, and an approval authority. (PCI DSS v4.0.1 Requirement 9.1.1)

Step 4: Make “kept up to date” real with change triggers

Define a small set of triggers that require review/update:

• New site, remodel, or relocation of restricted areas
• Change to access control system (new badge vendor, new logging)
• New third party with physical access
• CDE scoping change (systems moved, segmentation changes affecting spaces)
• Post-incident corrective action (tailgating event, lost keys, break-in) (PCI DSS v4.0.1 Requirement 9.1.1)

Keep a revision history and approvals so you can show currency without debating. (PCI DSS v4.0.1 Requirement 9.1.1)

Step 5: Roll out awareness so procedures are “known to all affected parties”

You need targeted enablement, not a one-size annual training slide:

• Role-based training for reception/front desk, security guards, facilities, IT admins, and site leads.
• Third-party onboarding: incorporate physical access rules into third-party access requests and onsite requirements (badging, escorting, permitted work areas).
• Quick-reference job aids at points of use (visitor desk checklist, lost badge steps). (PCI DSS v4.0.1 Requirement 9.1.1)

Evidence hook: require acknowledgements in your LMS, HR system, or a lightweight attestation workflow. (PCI DSS v4.0.1 Requirement 9.1.1)

Step 6: Prove the procedures are “in use”

Auditors will sample. Build an evidence bundle that matches your procedures:

• Recent access requests with approvals
• Visitor logs and escort records
• Termination/offboarding tickets tied to badge revocation
• Exception approvals (temporary badges, after-hours access)
• Physical access review outputs and follow-up actions (PCI DSS v4.0.1 Requirement 9.1.1)

If you use Daydream for compliance operations, this is where it pays off: store each procedure with its required evidence list, schedule recurring access reviews, and attach sampled artifacts in one place so your assessor doesn’t have to chase Facilities, HR, and Security across multiple systems.

Required evidence and artifacts to retain

Use this as your minimum evidence checklist mapped to 9.1.1’s four tests (documented, current, in use, known):

Requirement 9.1.1 test	Artifacts to retain
Documented	Physical Access Security Policy; procedure runbooks; forms/templates (visitor log, access request form); RACI/ownership list (PCI DSS v4.0.1 Requirement 9.1.1)
Kept up to date	Version history; last review/approval records; change log tied to triggers; deprecation notes for replaced procedures (PCI DSS v4.0.1 Requirement 9.1.1)
In use	Completed access requests; visitor logs; badge audit logs; access review results; offboarding tickets; incident tickets tied to physical events (PCI DSS v4.0.1 Requirement 9.1.1)
Known	Training assignments and completion records; attestations; onboarding checklists for affected roles and third parties; interview prep notes for control owners (PCI DSS v4.0.1 Requirement 9.1.1)

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me the written procedures for granting access to the CDE areas. Who approves and what is the record?” (PCI DSS v4.0.1 Requirement 9.1.1)
• “How do you ensure contractors and third parties know the physical access rules?” (PCI DSS v4.0.1 Requirement 9.1.1)
• “How do you know the policy is current? What triggers an update?” (PCI DSS v4.0.1 Requirement 9.1.1)
• “Pick a terminated employee. Show badge removal evidence and when it happened.” (PCI DSS v4.0.1 Requirement 9.1.1)
• “Walk me through visitor handling at Site A versus Site B. Why is it consistent?” (PCI DSS v4.0.1 Requirement 9.1.1)

Hangup pattern: teams show a strong corporate security policy but no operational procedures, or procedures exist informally in emails and tribal knowledge. 9.1.1 is explicit that procedures must be documented and known. (PCI DSS v4.0.1 Requirement 9.1.1)

Frequent implementation mistakes (and how to avoid them)

1. Policy exists, procedures don’t. Fix: publish task-level runbooks for each physical workflow you expect to be audited on. (PCI DSS v4.0.1 Requirement 9.1.1)
2. Facilities/security run the process, compliance owns the document. Fix: document ownership where the work happens; compliance can govern review cadence and evidence collection. (PCI DSS v4.0.1 Requirement 9.1.1)
3. “Known to all affected parties” treated as annual security awareness. Fix: role-based training and site-specific job aids for staff who execute physical controls daily. (PCI DSS v4.0.1 Requirement 9.1.1)
4. Third-party physical access ignored. Fix: require third-party badging/escort rules in contracts or work orders, and keep logs showing compliance. (PCI DSS v4.0.1 Requirement 9.1.1)
5. Documents updated, but old versions still circulating. Fix: single source of truth, remove obsolete copies, and link procedures from access request workflows. (PCI DSS v4.0.1 Requirement 9.1.1)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement context as assessment-driven: PCI outcomes typically turn on whether controls are demonstrable, repeatable, and supported by evidence. Weak physical access documentation increases the chance of inconsistent site practices, untracked visitor access, and delayed access revocation, all of which increase the likelihood of unauthorized physical access to systems or media tied to cardholder data. (PCI DSS v4.0.1 Requirement 9.1.1)

Practical execution plan (30/60/90-day)

Use this as an operator’s rollout sequence; adjust to your environment and assessment timeline.

First 30 days: establish the minimum compliant set

• Scope the locations, spaces, and roles that fall under Requirement 9 physical access expectations. (PCI DSS v4.0.1 Requirement 9.1.1)
• Publish or refresh the Physical Access Security Policy and the core procedures for access provisioning, visitors, and offboarding. (PCI DSS v4.0.1 Requirement 9.1.1)
• Assign owners and set a single repository where staff can find the current version. (PCI DSS v4.0.1 Requirement 9.1.1)
• Start collecting “in use” evidence from live workflows immediately (tickets, logs, sign-in sheets). (PCI DSS v4.0.1 Requirement 9.1.1)

Next 60 days: operationalize and prove “known”

• Deliver role-based training for all affected internal roles; capture completion/attestations. (PCI DSS v4.0.1 Requirement 9.1.1)
• Integrate third-party physical access requirements into the access request process and onsite check-in. (PCI DSS v4.0.1 Requirement 9.1.1)
• Define change triggers and revision workflow so “kept up to date” becomes routine. (PCI DSS v4.0.1 Requirement 9.1.1)
• Run an internal evidence test: pick samples and confirm you can produce artifacts on demand. (PCI DSS v4.0.1 Requirement 9.1.1)

By 90 days: stabilize and prepare for assessment sampling

• Standardize between sites (common forms, minimum visitor handling steps, consistent access approval rules). (PCI DSS v4.0.1 Requirement 9.1.1)
• Perform a documented check that procedures are followed, then open remediation items for gaps. (PCI DSS v4.0.1 Requirement 9.1.1)
• Package an assessor-ready evidence binder by procedure, with samples and interview contacts. (PCI DSS v4.0.1 Requirement 9.1.1)

Frequently Asked Questions

Do we need a separate physical security policy for PCI, or can we extend our corporate policy?

You can extend your corporate policy if it clearly covers the physical access controls in PCI Requirement 9 and you can show it is in use and known to affected parties. If the corporate policy is too generic, add PCI-specific procedures as attachments or runbooks. (PCI DSS v4.0.1 Requirement 9.1.1)

Who counts as “affected parties”?

Anyone who designs, approves, executes, or is constrained by the physical access procedures. That usually includes Facilities, Corporate Security, IT/data center ops, HR (offboarding), reception/front desk, and third parties with onsite access. (PCI DSS v4.0.1 Requirement 9.1.1)

What evidence is most persuasive for “in use”?

Records generated by the process: approved access requests, visitor logs, badge deprovisioning tickets, and access review outputs with remediation actions. Auditors prefer system records over screenshots without context. (PCI DSS v4.0.1 Requirement 9.1.1)

We use a colocation provider. Do we still need procedures?

Yes. Document your side of the process (requesting access, who is authorized, how you review and remove access) and retain evidence. Also document how the third party’s onsite controls fit into your operating procedures. (PCI DSS v4.0.1 Requirement 9.1.1)

How do we show procedures are “known” without overtraining everyone?

Train by role and location. Focus on staff who grant access, manage visitors, escort, or maintain restricted areas, then keep completion records and job aids at points of use. (PCI DSS v4.0.1 Requirement 9.1.1)

What’s the fastest way to get assessor-ready for 9.1.1?

Map each Requirement 9 physical control to a written procedure, assign an owner, then build an evidence index that lists exactly what artifacts you will provide per procedure. A system like Daydream helps keep procedures, owners, review cycles, and evidence in one workflow. (PCI DSS v4.0.1 Requirement 9.1.1)