What PCI DSS 9.2 facility entry controls require in practice
Requirement 9.2 asks you to control who can physically enter the places where cardholder data is stored, processed or transmitted, and to watch and limit physical access to the equipment inside them. If an assessor or a remediation plan is due, expect the requirement to span five sub-requirements: entry controls for facilities and systems, monitoring of sensitive areas, handling of publicly accessible network jacks, physical protection of wireless and network hardware, and locking consoles in sensitive areas. The underlying risk is simple. Someone who can walk up to a server, plug a laptop into a wall jack or reach a console can bypass logical controls that took months to build. A card number is useless to an attacker who cannot touch the system that holds it, so physical access is part of the same chain of trust as passwords and firewalls.
The two sub-requirements that cause the most difficulty are monitoring and scope. Requirement 9.2.1.1 expects individual physical access to sensitive areas within the cardholder data environment to be monitored with video or access control mechanisms, with the data reviewed, correlated and stored for at least three months unless local law restricts retention. Teams often discover that their camera system overwrites footage after a few weeks, or that badge logs are not tied to the individuals who used them. Confirm your retention settings with your camera or access control vendor and test a retrieval from three months back before the assessment. The term "sensitive area" is equally slippery. PCI SSC FAQ 1494 describes it as typically a subset of the cardholder data environment that houses critical systems, such as data centers, server rooms and retail back offices. Decide and document which rooms, cabinets and network closets meet that description, because the assessor will test the boundary you set.
A practical first step is to build a table that maps each physical location to its systems, its entry method, its monitoring device, its retention period and its owner, then check it against the network and data-flow diagrams. Ask your facilities team which jacks in public areas are active, which wireless access points sit in reachable spaces and which consoles remain logged in or unlocked. Verify the findings with the PCI DSS standard page and the SAQ D sub-requirement wording for your assessment type. Where an organization cannot physically restrict an item, such as a shared lobby jack, document the alternative approach with your assessor before you rely on it.
Which facilities, areas and teams fall under 9.2
Requirement 9.2 applies wherever cardholder data environment (CDE) systems sit physically, so the first job is deciding which sites, rooms and occupants count. Each decision below changes how many doors, cameras and third parties your entry controls must cover, and who must be able to show evidence for them.
Sites that host CDE systems
Start with an inventory of every physical location where a CDE system is installed, stored, powered or administered, including headquarters racks, branch closets, warehouses and disaster recovery sites. A single server in a branch office pulls that office into 9.2 just as a primary data center does. Check the network and data-flow diagrams against the site list, because systems that were moved or added during a project often leave a location off the register. Ask your assessor early which locations they expect to sample.
Sensitive areas inside a site
PCI SSC FAQ 1494 describes a sensitive area as typically a subset of the CDE that houses critical systems, such as data centers, server rooms and retail back offices. Each one needs its own entry controls, monitoring and access list, which means a whole building is rarely the right unit of scope. Mark each room on the floor plan and record who holds a badge for it. Retail back offices are a common gap because they are often shared with stock and staff areas.
Colocation and cloud facilities
When a colocation provider or cloud platform owns the building, the provider usually operates the physical controls, but your organization still owns the outcome for its own cages, racks and cabinets. Obtain the provider's current PCI DSS responsibility documentation and confirm which 9.2 controls it performs and which you must perform, such as your own badge issuance or your own camera review. Request the provider's evidence on request, and make sure it covers the period you are being assessed for.
Shared office and multi-tenant space
In shared buildings, the CDE room may open onto corridors, lobbies or floors used by other tenants or departments. Entry controls must prevent unauthorized people from reaching the sensitive area, even when they are inside the building. Map the paths from the building entrance to each sensitive area and identify every door, lift lobby and shared corridor along the way. Agree in writing with the landlord or building operator who manages those shared points, and confirm what access logs they can supply.
Third parties with physical access
Cleaners, facilities contractors, HVAC and electrical engineers, hardware vendors and auditors may enter sensitive areas without holding a company badge. Each group expands the 9.2 work because you must know who entered, when and under whose escort. Build a register of third parties with physical access, list the contract that governs each one, and decide how their visits will be logged and escorted. Confirm that your contracts require them to follow your entry procedures.
Teams that own each control
Physical security, IT operations, facilities management and the payment team often each hold part of the 9.2 evidence, such as badge systems, camera feeds, network wall jacks and console locks. Without a named owner for each control, reviews stop and evidence goes missing. Assign one accountable owner per sensitive area, document who maintains the access list, and confirm who reviews camera or access logs each period. Clear ownership also makes it easier to brief any outside consultant on who can answer questions during preparation.
How sensitive areas differ between data centers, retail and offices
When the organization owns the building, the whole facility is its responsibility, so the sensitive areas are usually the rooms and racks that hold cardholder data systems: server rooms, network closets, and any cage or suite inside a larger site. Controls are typically designed by the organization itself, including badge readers on sensitive doors, cameras covering entry points and racks, and a documented process for who may enter. Because no landlord shares the space, the organization must show that every control operates and that its logs and footage are kept and reviewed.
- Sensitive area boundaries: Map each server room, cage and wiring closet that houses CDE systems, and record the boundary in the scope documentation.
- Camera and badge coverage: Confirm that cameras or access control logs cover every individual entry point to those rooms, not just the main door.
- Retention: Check that footage or access records are stored for at least three months, unless local law restricts retention.
- Shared building areas: Identify loading docks, shared corridors and common facilities that may still lead to sensitive rooms.
- Review cadence: Show who reviews access logs and footage, and how reviews are correlated with other events.
Confirm that the boundary of each sensitive area matches the current network and system diagrams.
In a colocation facility, the provider operates the building and typically controls the perimeter, the common areas and much of the physical access infrastructure. The customer usually controls its own cage, cabinet or suite, along with the locks, keys or badges that the provider allows it to manage. Responsibility is therefore split, and the split is set by the contract and the provider's service description rather than by the standard alone. Organizations must confirm in writing which facility controls the provider runs, which they run, and what evidence the provider will share.
- Provider-run controls: Confirm the provider's entry controls, visitor handling, camera coverage and log retention for the building and common areas.
- Customer-run controls: Identify which locks, badges or cabinet keys the organization administers and how it logs access to its own cage.
- Evidence sharing: Ask whether the provider will supply access logs, footage or audit reports covering the organization's space, and on what schedule.
- Escort and contractor access: Clarify whether the provider escorts vendors into the customer's area and whether that escort is recorded.
- Termination of access: Agree how quickly the provider deactivates badges belonging to departed staff.
Request the provider's facility description and its current assurance documentation, then confirm the customer-controlled responsibilities in the agreement.
In a retail environment, the sales floor is usually public and is not a sensitive area. The back office, stockroom or manager's room where a payment system, network equipment or a console sits is usually the sensitive area, because it houses systems that can affect the cardholder data environment. The store owner or franchise operator controls the room, but many stores share space with landlords, mall operators or franchisors who may hold keys or run cameras. Controls tend to be simpler than in a data center, so the question is whether they are consistently applied across every location.
- Back office definition: Mark which rooms contain payment terminals' supporting equipment, network hardware or consoles, and treat them as sensitive.
- Locking and keys: Record who holds keys to back offices, including store staff, managers and any landlord or cleaning contractor.
- Camera placement: Check whether a camera or access log covers the back office door, and whether footage is retained for at least three months.
- Landlord arrangements: Confirm in the lease or service agreement whether the landlord has access to the room and whether it provides any footage.
- Store consistency: Verify that every location follows the same procedure, because gaps usually appear at smaller or franchised sites.
Confirm the back office layout for each location in writing, and keep a current floor plan with the sensitive rooms marked.
A corporate office that houses payment operations staff is usually not a sensitive area in its own right, but a room within it may be. If the office contains a server closet, a network room or a shared console that can reach the cardholder data environment, that room becomes sensitive. Many offices are leased from a landlord who runs the building's access system, cameras and visitor desk. The organization controls its internal suite but depends on building services for the perimeter. Where payment systems are reachable from a general office, the scope and the access controls need careful review.
- Sensitive room identification: Find any server closet, network cabinet or console inside the office that connects to CDE systems.
- Building access: Document whether the landlord's badge system is used to reach the floor, and whether it logs individual entry.
- Visitor handling: Confirm that visitors to the payment team's floor are escorted and that their entry is recorded.
- Remote consoles: Check that any console or jack in a shared area is secured and cannot be used by unauthorized people.
- Landlord responsibilities: Confirm in the lease which building controls the landlord operates and which it does not.
Write down which controls the building provides, which the organization provides, and confirm both in the lease or facilities agreement.
How an assessor tests 9.2 and what they ask to see
This table maps each part of Requirement 9.2 to the test steps an assessor typically performs, the evidence they request and the findings that come up most often. Use it as a pre-assessment checklist: if your team cannot produce the evidence in the right column for a row, that row is where a gap is most likely to appear.
| Sub-requirement | Typical assessor test steps | Evidence requested | Common findings |
|---|---|---|---|
| 9.2.1 Entry controls for facilities and systems | Observe entry points to sensitive areas during the visit. Interview staff on how access is granted and removed. Confirm the controls apply to both facilities and systems. | Access control configuration, lists of entry methods, door and badge reader inventory, documented procedure for granting access. | Entry points that were not included in the control design, such as secondary doors or loading bays. |
| 9.2.1.1 Monitoring of individual physical access to sensitive areas | Identify sensitive areas within the CDE using the organization's definition. Inspect camera or badge monitoring coverage of each entry point. Sample recordings or access logs and check that they are reviewed. | Camera placement diagram, floor plans marked with coverage, sample footage or access logs, records showing review or correlation. | Cameras that do not cover every entry point or sensitive area. Logs collected but never reviewed. |
| 9.2.1.1 Retention period | Check the configured retention setting on the recording or access system. Ask whether any legal restriction shortens retention and request the documented basis. | Retention configuration screenshots or exports, storage capacity records, legal justification if retention is shorter than three months. | Retention set below three months, or recordings overwritten before the period ends. |
| 9.2.2 Publicly accessible network jacks | Walk the sensitive areas and check for network jacks reachable by visitors or staff who should not connect devices. Confirm controls exist for unused jacks. | Inventory of network jacks in sensitive areas, port disablement or authorization procedure, sample of access restrictions. | Active jacks in lobbies, meeting rooms or shared spaces that connect into the CDE network. |
| 9.2.3 Physical access to wireless access points, gateways and handheld devices | Inspect wireless hardware and gateways in the sensitive areas. Check how physical access to them is restricted and whether handheld devices are controlled. | Asset list of wireless and network hardware with locations, lock or cabinet records, handheld device custody log. | Access points or gateways in unlocked closets or open ceiling spaces accessible to unauthorized people. |
| 9.2.4 Consoles in sensitive areas | Observe consoles and workstations inside sensitive areas. Check whether they are locked or logged off when unattended and whether screens are shielded from visitors. | Console inventory, screen lock or logoff settings, staff procedure for unattended consoles. | Consoles left logged in, or no written expectation for staff when they leave a station. |
| Staff interviews across 9.2 | Ask data center, server room or back office staff how they recognize unauthorized entry, how they report a failed camera or reader, and how they respond to tailgating. | Staff briefing records, incident or fault tickets for cameras and readers, training attendance. | Staff unaware of the monitoring or unsure who reviews the footage. |
How to implement 9.2 from site inventory to evidence
This sequence turns 9.2 from a list of physical controls into a documented set of facility layouts, access rules, camera or badge coverage, retention settings and hardening records that an assessor can sample. Each step produces an artifact that the next step depends on, so gaps surface early rather than during the assessment.
Inventory facilities and sensitive areas
Start by listing every facility, room and rack location where cardholder data or systems that affect its security can be found. Mark the sensitive areas within the cardholder data environment, which PCI SSC FAQ 1494 describes as typically housing critical systems such as data centers, server rooms and retail back offices. Facilities, facility managers and the security team usually own this work, with the QSA reviewing the result later. The output is annotated floor plans showing each sensitive area, its boundaries and the entry points into it. The step is done when someone outside the project can walk the plans and find every door, wall opening and network jack in each area.
Define entry methods for each sensitive area
For each sensitive area, record how people enter and leave: badge readers, keypads, mechanical keys, staffed reception or escorted access. Decide who may enter, who approves access and how entry is revoked. Pair this with your access policy so that physical access follows the same need-to-know logic used for logical access. The output is an entry method register that lists each door, its control type, the owner of the control and the approval path. The step is complete when every entry point on the floor plans appears in the register with a named control.
Deploy badge and camera coverage
Install or confirm access control readers and video cameras so that individual physical access to each sensitive area is monitored. Camera placement should cover entry points and the paths to critical systems, and the facilities team should confirm field of view and lighting in the actual space. Ask vendors to confirm the recording and export features you need, because capabilities differ by product. The output is a camera coverage map and a badge reader list tied to the floor plans. The step is done when a tour of each sensitive area shows that every entry point is either covered by a camera or enforced by a reader.
Set three-month retention and review process
Configure storage for camera footage and access logs so that data is kept for at least three months, unless applicable law restricts retention. Assign someone to review the data, correlate badge events with camera footage where needed and record the review. If you use a metrics or alerting stack to ingest access or sensor events, a tool such as Grafana Alerting can build alert rules across data sources, and Prometheus can store time series, but confirm with each vendor which access and video events they can ingest natively. The output is a retention configuration record and a review log. The step is complete when a sample of recent data can be retrieved for a past date range and the review entries are dated and signed.
Restrict publicly accessible network jacks
Walk every area accessible to visitors or the public and identify network jacks that could connect a device to the network. Disable unused ports, or move them to a secured state, and require that any activated port is in a controlled location. Coordinate with the network team so that port changes are authorized and recorded. The output is a jack inventory showing each port, its location, its status and the control that restricts it. The step is done when the inventory matches the physical ports and the network team can show the change record for each one.
Control physical access to wireless and network hardware
Identify wireless access points, switches, routers, firewalls and similar devices in or near the cardholder data environment, and confirm that people cannot tamper with them. Locate them in locked racks or cabinets, and limit who holds keys or badge access to those spaces. Coordinate with the team that manages wireless configuration, because physical controls alone do not satisfy the rest of the standard. The output is a hardware location register with cabinet or room assignments and the access list for each. The step is done when every device in the register sits behind a physical control that matches the entry register from earlier.
Lock consoles and document the hardening record
Lock or log off consoles in sensitive areas when they are not attended, and set screen-lock and session settings where the platform supports them. Compile the hardening record that ties everything together: the floor plans, entry register, camera map, retention configuration, jack inventory and hardware register, each dated and tied to an owner. Store the record with your PCI DSS evidence and set a review cycle so it stays current as the facility changes. Ask your QSA which evidence formats they accept. The output is a consolidated 9.2 evidence pack. The step is done when an internal reviewer who did not build the controls can trace each sub-requirement to a document and a sample.
Evidence that passes 9.2 and how to keep it current
Requirement 9.2 is tested largely through records: who was granted entry, what cameras saw, who reviewed it, and how devices were hardened. An assessor will want each record to show the control operated over the assessment period, not only that it existed on the day of the walkthrough. The cards below cover each evidence type and the routine that keeps it current between assessments.
Badge access logs and access lists
Badge system exports show who entered sensitive areas in the CDE, when, and through which door. Pair the logs with a current access list of authorized individuals, and reconcile the two each month so that any badge holder absent from the list stands out. Check that access revocations from HR or termination workflows appear in the logs as deactivated credentials. Ask your vendor how long the system retains logs by default, and confirm that retention meets at least three months.
Camera footage index and retention settings
An index of camera locations, the sensitive areas each one covers, and the retention period configured on the recorder shows an assessor that footage is stored for at least three months unless law restricts it. Export the retention configuration as evidence and sample footage from several dates to confirm it is actually retrievable. Review the index whenever a camera is moved, added or retired, because stale entries are a common finding.
Review sign-offs
Requirement 9.2.1.1 expects the monitoring data to be reviewed and correlated, so keep dated sign-offs showing who reviewed badge and camera records and what they found. Each review should record exceptions and the follow-up taken. Set a recurring review calendar, assign a named reviewer and a backup, and retain the signed records with the access logs they cover.
Floor plans marking sensitive areas
A current floor plan that marks data centers, server rooms and back offices, along with entry points, camera fields of view and badge readers, lets an assessor test coverage without walking every room. Use the definition of a sensitive area in PCI SSC FAQ 1494 as your reference point. Update the plan after any facility change and date each version so the assessor can see which layout applied during the review period.
Jack and console hardening records
Records of publicly accessible network jacks, locked consoles and disabled unused ports show how 9.2.2 through 9.2.4 were met. Keep a list of wall jacks in public areas with their status, the configuration or port-disable settings applied, and photographs or inspection notes for locked consoles. Repeat the inspection on a schedule and after any office fit-out, since new jacks often appear during moves.
Wireless hardware inventories
An inventory of wireless access points, network switches and other hardware in sensitive areas, with locations and physical access controls, shows that devices cannot be tampered with or substituted without detection. Record each device's location, owner and the access controls that protect it. Reconcile the inventory against asset discovery output at each review cycle, and record any device found outside the list as an exception with its disposition.
Why the three-month retention and review matter to an assessor
Requirement 9.2.1.1 is tested on two things at once: that individual physical access to sensitive areas inside the cardholder data environment is monitored with video cameras or access control mechanisms, and that the resulting data is reviewed, correlated and stored for at least three months unless law restricts it. An assessor will not accept a camera that records to a drive nobody opens. They will ask who reviews the footage or badge events, how often, what they look for, and what happens when something unusual appears. For a server room or data center, that usually means a named role, a documented review cadence, and records showing the review took place, such as sign-off entries, ticket references for anomalies, or correlation notes that link a badge event to a camera clip and to the visitor or personnel records covered by 9.3.
The three-month figure is a minimum for retention, and the assessor will check the storage configuration against it. Confirm the retention setting on each recorder or access control system, and confirm that backups or exports follow the same period. Where your sensitive areas are cameras feeding a monitoring platform, a tool such as Grafana Alerting can help show that access events and alerts are being acted on, but it does not replace documented human review. Decide early who owns the review, how correlation is recorded, and where the evidence lives. Any shortening of retention for a specific site must rest on a legal restriction that counsel has confirmed in writing. Do not assume a local privacy rule applies to your footage without that advice, because a justification you cannot evidence will be treated as no justification at all.
What meeting 9.2 costs in money and effort
This table breaks down the cost components behind Requirement 9.2, showing who is paid for each, whether it is one-time or recurring, what drives it up, and how to keep it down. Use it to build a quote request and to see where open-source log tooling removes license spend but not labor.
| Cost component | One-time or recurring | Cost drivers | How to reduce it |
|---|---|---|---|
| Badge readers and access control hardware | One-time, with replacement cycles | Number of entry points to sensitive areas, door hardware condition, and whether readers must integrate with existing badge systems | Limit sensitive areas to the rooms that hold CDE systems, and confirm which existing readers the scope can reuse |
| Camera hardware and installation | One-time, with recurring maintenance | Number of cameras needed to cover each entry point and rack row, lighting, cabling, and mounting in restricted areas | Map camera coverage to sensitive area boundaries first, then buy only for uncovered entrances |
| Access control software or licenses | Usually recurring | Per-door or per-user licensing, vendor support tier, and integration with the identity system | Compare per-user and per-door terms in writing and ask whether the vendor licenses fees on a multi-year basis |
| Open-source log and alert tooling | Platform setup one-time, operation recurring | License spend is generally zero for the core software, so cost moves to engineering hours and hosting | Remove license spend, but budget for integration, dashboards and maintenance labor, which the open-source license does not cover |
| Engineering time to integrate camera and badge logs | One-time, with ongoing upkeep | Number of source systems, log format variety, and whether events are correlated across access control and video | Standardize event fields early and reuse one collector for all entry systems |
| Retention storage for at least three months of data | Recurring | Camera resolution, frame rate, number of cameras, and whether law restricts retention periods | Confirm the retention period with counsel and set storage tiers to match, rather than keeping all footage at full resolution |
| Review labor for monitored data | Recurring | Frequency of review, number of sensitive areas, and how much correlation is automated | Automate alerts for unusual access and document a review schedule that the assessor can sample |
| Physical hardening work | One-time, with periodic repairs | Condition of walls, ceilings and doors around sensitive areas, and need for locks on consoles and network jacks | Address the most exposed points first and record the work so it is repeatable |
| External review and assessor sampling | Recurring, per assessment cycle | Size of the sample the assessor selects, quality of evidence on hand, and number of sites in scope | Keep evidence organized by area and date so sampling does not trigger rework. Ask a QSA to state the expected sample in the scoping discussion |
How Grafana and Prometheus can support 9.2 monitoring evidence
Requirement 9.2.1.1 expects video or access-control monitoring of sensitive areas with records kept for at least three months. Grafana and Prometheus do not record physical access, but they can watch the systems that do, show gaps in that evidence, and alert the team before a gap becomes a finding.
Alerting across metrics and logs
Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so metrics from an access-control platform and logs from a camera recorder can be evaluated in one place. Define a rule that fires when a monitored door controller or camera stops reporting, and another that fires when the retention store falls short of the three-month window. Check that alert notifications reach a staffed channel, because a rule that fires to an unwatched mailbox does not protect the sensitive area.
Single view for alert management
Teams can create, manage and act on alerts from one view, which keeps alert ownership, silences and acknowledgements in a single record. For 9.2 this matters because an assessor will ask who responded to a camera outage and when. Confirm that your alert history is exported or retained for the period your assessor will review, and that acknowledgements name the responder.
Pull-based metric collection over HTTP
Prometheus collects metrics from instrumented jobs through a pull model over HTTP, so it checks each target on a schedule and records when a target stops responding. A scrape that fails is itself a signal. Use this to watch exporters on badge readers, controllers or recorders, and treat a flat or missing series as a possible monitoring failure rather than an assumption that all is well.
Local time series storage
Prometheus stores metrics as time series identified by metric name and labels on autonomous local storage. The retention period is a configuration decision you own, so set it deliberately to cover the three-month review window in 9.2.1.1 with margin, and document it. Local storage also means the monitoring host needs its own protection, backup and time synchronization, or its history may not stand up to review.
PromQL queries for gap detection
PromQL queries time series by metric name and labels, which lets you ask whether a camera or controller reported within an expected interval. A query that counts reporting devices per site against the device inventory can reveal a sensitive area with no current coverage. Save these queries as versioned files and attach their output to quarterly review records, since they show the monitoring was operating, not just configured.
Licensing and scope caveats
Grafana is licensed under AGPL-3.0-only, which carries source disclosure obligations if you modify and distribute it or offer it over a network, so have counsel review the approach before customizing it. Prometheus is licensed under Apache-2.0. Neither tool replaces the camera or badge system, and neither can prove that a person was monitored. Confirm the license obligations with your legal team and confirm the tools meet your assessor's expectations for evidence.
Who owns 9.2 in-house, with a partner and with the assessor
Your organization owns the controls in Requirement 9.2. Site access decisions, the definition of sensitive areas within the cardholder data environment, and the choice of camera or badge monitoring all sit with your security and facilities leadership. Your team also reviews the monitoring data, decides who keeps access, and signs off on the policies and records that show the controls operate. An assessor will ask for these decisions and sign-offs directly, so they cannot be delegated away.
- Sensitive area definitions: Decide which rooms, racks and consoles count as sensitive areas, using the guidance in PCI SSC FAQ 1494 as a starting point.
- Access authorization: Approve who enters each sensitive area and remove access when roles change.
- Monitoring review: Review and correlate camera or badge data on a documented schedule, and act on anomalies.
- Retention decisions: Confirm the retention period for monitoring data, which must be at least three months unless law restricts it.
- Sign-offs: Own the policies, asset lists and approval records that the assessor samples.
Check that each control has a named owner, a review cadence and an example record from the last reporting period.
An implementation partner can prepare the technical side of 9.2 so your team has accurate inventories and usable evidence. DeployOpen plans, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure. For 9.2 that work usually covers inventories of entry points, network jacks and consoles, and pipelines that gather access and monitoring data into a place your team can review. The partner prepares systems and evidence. It does not decide access policy, and it does not attest that the controls meet the standard.
- Inventories: Build and maintain lists of sensitive areas, network jacks, wireless hardware and consoles, which assessors use to test coverage.
- Evidence pipelines: Integrate access-control, camera and alerting data into a monitoring stack such as Grafana Alerting, with Prometheus collecting time-series metrics where they apply.
- Retention configuration: Configure storage so monitoring records survive for the required period.
- Hardening and documentation: Lock down consoles and network hardware configurations and write runbooks your team can operate.
- Scope of work: Agree deliverables and timelines in a written, fixed-scope statement before work starts.
Check that the partner's written scope names each system, record type and deliverable, and that your team keeps administrative ownership afterward.
The Qualified Security Assessor or other assessor tests whether the controls in 9.2 operate as described, then documents the result in the Report on Compliance or the relevant questionnaire. Assessors sample monitoring records, observe entry controls, check inventories against the physical environment and interview staff. Only an independent assessor can issue these results. Organizations often bring in an assessor early for a readiness review, but the assessor who validates the environment should keep independence from the team that designed the controls.
- Testing: Sample camera or badge records, confirm the three-month retention and check that reviews happened.
- Observation: Walk the facility to confirm sensitive areas, locked consoles and restricted jacks match the documentation.
- Reporting: Record findings in the ROC or SAQ and the Attestation of Compliance, which the assessor or your organization signs as the template requires.
- Independence: Keep design and assessment roles separate so the assessor can test work that others prepared.
- Evidence requests: Expect requests for dated samples rather than summaries.
Before engaging an assessor, confirm which PCI SSC template applies to your environment and what evidence the assessor expects in advance.
Where 9.2 programs usually fall short and how to close the gap
Most 9.2 findings are not missing locks or cameras. They come from sensitive areas nobody has defined, coverage that stops at the main door, and evidence that exists only in someone's memory. The cards below pair each common gap with the action that closes it before an assessor asks.
Undefined sensitive areas
Requirement 9.2.1.1 applies to sensitive areas within the cardholder data environment, and PCI SSC FAQ 1494 describes these as typically a subset of the CDE that houses critical systems, such as data centers, server rooms and retail back offices. If the list is informal or missing, monitoring coverage cannot be proven. Build a written register of sensitive areas, tie each entry to the CDE data-flow diagram, and review it when the environment changes. Illustrative example: a store back office that houses a payment server but is absent from the register.
Camera blind spots at secondary doors
Teams often monitor the main server room door and overlook loading docks, rear corridors, cable risers and maintenance hatches that also reach sensitive areas. Walk every route into each sensitive area, including emergency exits, and confirm that individual access is captured on video or by an access control log. Check field of view, lighting and camera uptime at night, because an assessor will test the footage you cannot produce.
Retention set below three months
Requirement 9.2.1.1 expects monitoring data to be stored for at least three months unless law restricts retention. Video recorders often overwrite on a fixed loop sized by disk capacity, so a busy site can silently fall short. Confirm the retention setting on every recorder or log store, test it by pulling footage from a date about three months back, and alert when storage is near capacity.
Reviews that are not recorded
Requirement 9.2.1.1 requires that monitoring data be reviewed and correlated, and an assessor will ask for proof that it happened. Reviews done by memory or by an operator glancing at a screen leave no evidence. Assign a named reviewer and a recurring cadence, record each review with the date, the reviewer, the areas covered and any exceptions raised, and keep those records with the footage. Access control alerts can feed the same workflow.
Unlocked wall jacks in meeting rooms
Requirement 9.2.2 covers network jacks in publicly accessible areas. Conference rooms, lobbies and shared offices with live wall ports let a visitor plug a device into a network that reaches the CDE. Map every jack that is reachable by the public, disable unused ports at the switch, and assign active ports to a documented VLAN with access restricted by policy. Record the mapping so the assessor can see that the controls match the plan.
Unmanaged wireless hardware
Requirement 9.2.3 addresses physical access to wireless access points, gateways and network hardware. Access points installed by facilities staff or a vendor are often absent from the asset inventory and sit in unlocked ceiling spaces or comms closets. Inventory each device by location, lock the enclosures, and check the inventory against what is physically present during scheduled walkthroughs. Unknown devices should trigger an investigation, not a silent update to the list.
Consoles left logged in
Requirement 9.2.4 expects consoles in sensitive areas to be locked when not in use, so that a person who walks into the room cannot use an active session. Shared terminals in data centers and back offices often stay signed in for convenience. Configure automatic screen locks with a short idle timeout, prohibit shared generic sessions, and include console checks in the walkthrough so that gaps appear on a checklist rather than in an incident report.
Questions buyers ask about 9.2 cost, effort and outsourcing
How much effort does requirement 9.2 take to meet?
Effort depends mainly on how many facilities and sensitive areas hold systems in the cardholder data environment, and how much of the physical access control is already in place. Requirement 9.2 has five sub-requirements, so the work usually falls into three parts: confirming entry controls on each facility, setting up camera or badge monitoring for sensitive areas such as data centers and server rooms, and documenting restrictions on network jacks, wireless hardware and consoles. A single small office with one locked server cabinet is far less work than several colocation cages with separate access systems. Ask your team to inventory every location that houses CDE components before estimating anything.
Can a hosting or colocation provider cover requirement 9.2 for us?
A provider can cover part of 9.2, but not all of it, and the split must be written down. Data center operators often run the building's entry controls, guard desks and camera systems, so their attestation may cover those controls. Your organization still owns the requirement for any sensitive area it controls, such as a locked cage, a rack, or a network closet inside a shared facility. Request the provider's current responsibility matrix and its own PCI DSS attestation, then check each sub-requirement against it. Anything the provider does not cover becomes your evidence to produce.
What does the work need from our team?
The work needs facilities staff, a systems owner for the CDE, and someone who can review camera or access logs. Facilities staff know where doors, badge readers and cameras are installed and who holds keys. Systems owners know which racks, consoles and network jacks matter. A reviewer must check that logs are retained for at least three months and that footage or access records can be correlated with events, such as a badge swap or a cabinet opening. Plan for named owners and a regular review cadence, because assessors test whether the process runs, not only whether the hardware exists.
Can we do requirement 9.2 ourselves without outside help?
Most organizations with an in-house facilities and security team can meet 9.2 without outside help, provided they have the skills to document the environment and keep evidence current. The main gap is usually evidence discipline: retained video or access logs, dated photos of locks and consoles, and records showing who reviewed them. Outside help makes sense when no one owns the physical layer, when several sites need consistent configuration, or when the team wants an independent view before the assessor arrives. Any engagement should keep the organization in charge of its own controls.
What should we include when briefing a partner on 9.2?
A useful brief lists every facility and sensitive area that touches the CDE, the access control and camera systems in use, who manages them, and which provider covers which part. Include your current network and data-flow diagrams, any existing responsibility matrix, and recent logs or footage samples. State how long monitoring data is retained today and whether local law limits retention. Ask the partner to name the deliverables in writing, such as a gap list, configuration changes, and an evidence index, before work starts. Most engagements are fixed-scope, so a clear brief produces a clearer quote.
What drives the cost of meeting requirement 9.2?
The main cost drivers are the number of sites, the number of sensitive areas, whether cameras and access control already exist, and how much integration work is needed. Hardware and licenses are typically one-time or recurring purchases, while staff time, monitoring, log storage and periodic review recur each year. Retention can add cost if the storage has to hold footage for the required period across many cameras. Ask any provider to split the quote into one-time setup, recurring operations, and optional support, so you can compare options fairly.
What will an assessor accept as evidence for 9.2?
An assessor usually accepts evidence that is current, dated, complete and traceable to a specific sub-requirement. For 9.2.1.1, that means camera or access records covering sensitive areas, a record showing the data was reviewed, and proof it is retained for at least three months unless law restricts that. For the other sub-requirements, expect configuration records for public network jacks, inventories of wireless and network hardware, and proof that consoles in sensitive areas are locked. Your independent assessor decides what is sufficient. Confirm the expected format with your assessor before you collect evidence, and keep the reviewed records in a single index.
How DeployOpen prepares 9.2 systems and evidence
DeployOpen helps organizations prepare the monitoring, access and hardening evidence that Requirement 9.2 asks for in facilities that house cardholder data. We work inside your own data centers, cloud accounts or network, and the organization keeps ownership of its controls and its assessor relationship.
How we scope
- Agree in writing which sensitive areas, such as data centers and server rooms, fall inside the 9.2 scope.
- Map every camera, badge reader and access control point that covers those areas to a named owner.
- Confirm with your QSA how sensitive areas are defined for your environment before build work starts.
How we build
- Deploy self-hosted monitoring so camera and access events feed a central, time-synchronized record.
- Configure alert rules, for example in Grafana Alerting, for door events, badge failures and camera outages in sensitive areas.
- Lock down publicly accessible network jacks, wireless hardware and consoles according to the agreed design.
How we hand over
- Deliver configuration records, alert rule exports and retention settings showing data is kept for at least three months.
- Provide review procedures and sample reports that show how monitoring data is reviewed and correlated.
- Document the design, owners and open items so your team can run the controls after handover.
How we support
- Fixed-scope engagements have deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Your assessor, a Qualified Security Assessor, reviews the evidence. DeployOpen prepares it but does not issue reports or attestations.
