POI Device Inspection

PCI DSS requires you to periodically inspect payment point-of-interaction (POI) device surfaces to spot tampering or unauthorized device swaps before card data is captured. To operationalize it, maintain an inventory of POI devices, define an inspection cadence and checklist, train staff to recognize tamper indicators, and retain inspection logs and escalation records. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Key takeaways:

• You need a repeatable inspection process for POI device surfaces, not ad hoc “looks fine” checks. (PCI DSS v4.0.1 Requirement 9.5.1.2)
• Evidence matters: inventory, checklists, completed logs, training records, and incident/escalation tickets are what assessors ask for.
• The control fails most often at the edges: third-party managed locations, staffing turnover, and device swaps without documentation.

“POI device inspection” is a practical, front-line PCI control: it’s about catching physical interference with payment devices where card data enters your environment. PCI DSS 4.0.1 Requirement 9.5.1.2 says POI device surfaces are periodically inspected to detect tampering and unauthorized substitution. (PCI DSS v4.0.1 Requirement 9.5.1.2)

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to treat this as an operational program with clear ownership and proof, not as a policy statement. You need three things working together: (1) a complete, accurate inventory of every in-scope POI device and where it is deployed, (2) a documented inspection procedure and cadence that store managers and frontline staff can execute consistently, and (3) an escalation workflow that triggers device quarantine and investigation when something looks off.

This page gives requirement-level implementation guidance: who this applies to, exactly what to do, what evidence to keep, common audit hangups, frequent mistakes, and a practical execution plan you can run without waiting for a major tooling project.

Regulatory text

Requirement (excerpt): “POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.” (PCI DSS v4.0.1 Requirement 9.5.1.2)

Operator interpretation: You must run routine, documented inspections of the physical surfaces of payment terminals and related POI devices to identify signs that someone has altered the device or swapped it with a malicious look-alike. “Periodically” must be defined by you as an enforceable cadence that matches your risk and operating environment, and you need evidence that the inspections happened and exceptions were handled.

Plain-English interpretation (what this requirement is really asking)

You are responsible for proving that people at the point of payment regularly check devices for visible signs of tampering or replacement, and that you react quickly when they find something suspicious. This includes:

• Knowing what devices you have and where they are.
• Knowing what “normal” looks like for each device model (seals, screws, casing fit, ports, overlays).
• Ensuring staff can identify red flags.
• Keeping records that stand up in an assessment.

Who it applies to

Entity types: Merchants, service providers, and payment processors handling card-present transactions with POI devices. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Operational contexts where this is typically in scope:

• Retail stores, hospitality, restaurants, clinics, and any attended checkout lane with a card-present terminal.
• Unattended payment devices (kiosks, self-checkout, vending) if they are part of your card acceptance environment.
• Field-service and mobile acceptance where devices move between locations (higher substitution risk).
• Third-party managed or franchised locations where your brand accepts payment but local operations control the floor.

Key scoping note: If the device can capture payment card data at the point of interaction, it belongs in the inspection program, even if it is “owned” or “managed” by a third party. You still need a control you can evidence.

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

Step 1: Establish ownership and boundaries

Assign an accountable owner for the POI inspection program (often Store Operations, Loss Prevention, or IT Asset Management), with Compliance setting requirements and evidence standards. Clarify:

• Which locations are in scope.
• Which device types are in scope (terminals, PIN pads, integrated POS peripherals that present a payment interface).
• Who performs inspections (role-based, not person-based).

Step 2: Build and maintain a POI device inventory

Create a single source of truth that includes, at minimum:

• Location identifier (store/site ID, address, lane/register number).
• Device make/model.
• Unique device identifier (serial number and/or asset tag).
• Deployment status (in service, spare, in repair, retired).
• Photos of the device “known-good” state (front, back, sides, cable connections) so inspectors can compare.

Practical tip: inventory accuracy is the foundation. If assessors can find a terminal on the floor that is not in your inventory, your inspection logs become less credible.

Step 3: Define the inspection cadence and triggers

“Periodically” must become a defined operational rule. Pick a cadence that matches your environment and can be executed reliably. Then add event-based triggers that force an inspection outside the normal cadence, such as:

• Device installation, replacement, or relocation.
• After maintenance by internal teams or a third party.
• After a physical security incident at the site (break-in, suspicious activity).
• After a device is found unattended or stored improperly.

Write the cadence and triggers into your procedure so the business can execute without guesswork. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Step 4: Create a model-specific inspection checklist

Your checklist must focus on device surfaces and substitution indicators. Include items such as:

• Evidence of broken or missing tamper-evident seals (if present).
• Cracks, gaps, or ill-fitting casing seams.
• Unusual adhesives, overlays, or “new” labels on the keypad/display.
• Scratches near screws or panels that suggest opening.
• Unexpected attachments, adapters, or cable routing changes.
• Added components around card insert/tap areas.
• Ports that are exposed when they should not be.

Maintain separate checklists (or sections) for each device model family so the steps match what staff sees in the field.

Step 5: Train staff and validate competence

Training must be practical: staff should be able to identify what “good” looks like and what triggers escalation. Cover:

• Why devices are inspected (tampering/substitution risk).
• How to compare serial numbers/asset tags to the inventory.
• How to use the checklist and capture evidence (photos, notes).
• What to do if suspicious signs exist (stop use, quarantine, notify).

Include a lightweight knowledge check or sign-off so you can prove the training wasn’t just assigned.

Step 6: Run inspections and capture evidence

Have inspectors complete:

• Date/time of inspection.
• Inspector name/role.
• Device identifier (serial/asset tag) and location.
• Checklist results (pass/fail per item).
• Photos where your process requires them (commonly for exceptions or spot checks).
• Any anomalies and immediate actions taken.

Avoid “all good” free-text logs. Use structured fields. Structured logs reduce assessor skepticism.

Step 7: Escalation, quarantine, and investigation workflow

Define a clear “stop-the-line” process:

• Remove device from service if tampering/substitution is suspected.
• Preserve the device (do not attempt to open it).
• Notify the right teams (operations, security, IT, compliance).
• Document actions in an incident or ticketing system.
• Replace with a known-good device from controlled inventory.

Your goal is fast containment and clean evidence trails.

Step 8: Oversight, monitoring, and program assurance

Add second-line checks so you can prove the program works:

• Spot audits by regional managers or security teams.
• Inventory-to-floor reconciliations (does every deployed device appear in inventory, and do serial numbers match?).
• Exception trend review (missed inspections, repeat anomalies at a site, high turnover sites).

If you manage this in a GRC tool like Daydream, treat POI inspections like any other control: map owners, tasks, due dates, evidence requests, and exception handling to a single system of record.

Required evidence and artifacts to retain

Assessors typically want to see that the control is defined, performed, and governed. Retain:

• POI device inventory with serial numbers/asset tags and locations.
• Inspection procedure defining cadence, triggers, and responsibilities. (PCI DSS v4.0.1 Requirement 9.5.1.2)
• Inspection checklists (blank templates and completed records).
• Completed inspection logs ¹ with dates and inspector attribution.
• Training materials and completion records for staff performing inspections.
• Exception/escalation records (tickets/incidents) for suspicious devices, including removal from service and disposition.
• Change/maintenance records for device swaps, repairs, or third-party servicing (to show controlled substitution, not unauthorized substitution).

Common exam/audit questions and hangups

Expect these from QSAs/internal audit:

1. Show me your POI inventory. How do you know it’s complete and current?
2. What does “periodically” mean here? Where is your cadence defined, and how do you enforce it? (PCI DSS v4.0.1 Requirement 9.5.1.2)
3. How do you detect unauthorized substitution? Do inspectors verify serial numbers against the inventory?
4. Prove inspections occurred. Can you produce logs for a sample of locations and devices?
5. What happens when something is suspicious? Show quarantine steps and incident records.
6. How do you manage third-party involvement? If a third party services devices, how do you control and document swaps?

Common hangup: organizations have a policy statement but no reliable way to show consistent execution across every store and shift.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Inventory exists, but it’s stale.
  Fix: tie inventory updates to procurement, deployment, and repair workflows so changes create an update task automatically.

• Mistake: Inspections are informal (“manager eyeballs it”).
  Fix: require a checklist with serial number verification and recorded outcomes.

• Mistake: No baseline for what “normal” looks like.
  Fix: store model-specific photos and “known-good” examples; include them in training and job aids.

• Mistake: Shared devices/spares aren’t controlled.
  Fix: track spares in inventory and require an inspection and documented swap event before deployment.

• Mistake: Third-party serviced devices come back without evidence.
  Fix: require service documentation and a post-service inspection before returning to use; bake it into the third-party process and acceptance criteria.

Risk implications (why auditors care)

POI tampering and substitution are direct paths to card data compromise at capture. If a malicious actor alters a terminal or swaps it with a look-alike, downstream controls (logging, network segmentation, monitoring) may not prevent exposure at the device itself. Requirement 9.5.1.2 pushes detection to the physical edge, where technical controls are weakest. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Practical execution plan (30/60/90)

Immediate (first 30 days): stabilize the basics

• Assign owner(s) and publish the inspection procedure draft with cadence and triggers. (PCI DSS v4.0.1 Requirement 9.5.1.2)
• Build or reconcile the POI inventory for a pilot region or representative set of sites.
• Create the first inspection checklist for the top device model(s).
• Stand up a simple evidence capture method (forms + ticketing for exceptions).

Near-term (next 60 days): expand and make it repeatable

• Roll inventory standard and checklist coverage across all locations/device models.
• Train staff and store managers; document completion.
• Start routine inspection logging and implement escalation runbooks.
• Add management oversight: spot checks and inventory-to-floor reconciliations.

Ongoing (next 90 days and beyond): govern and harden

• Review missed inspections and recurring exceptions; adjust staffing/process.
• Test escalation flow with tabletop exercises (what happens if a device looks tampered?).
• Tighten third-party service acceptance: no device returns to service without documented inspection.
• Centralize evidence for assessments (Daydream or your existing GRC repository) so samples are easy to produce.

Frequently Asked Questions

What counts as a “POI device surface” for inspection?

Treat any external casing, seams, screws, ports, cable connections, keypad overlays, and card insert/tap areas as in scope. The requirement is to inspect what could show tampering or indicate the device was swapped. (PCI DSS v4.0.1 Requirement 9.5.1.2)

How often is “periodically” for POI device inspections?

PCI DSS requires periodic inspection but does not specify a single universal frequency in the excerpt provided. Define a cadence you can execute consistently, document it, and add event-based triggers like post-maintenance or relocation. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Do I need to record photos for every inspection?

The requirement mandates inspections and detection, not a specific evidence format in the excerpt provided. Photos are a strong practice for exceptions, new deployments, or spot checks, and they reduce disputes during audits. (PCI DSS v4.0.1 Requirement 9.5.1.2)

We use a third party to service or supply terminals. Are we still responsible?

Yes. You still need an inspection process you control and can evidence for devices operating in your environment, including documenting controlled swaps versus unauthorized substitution. (PCI DSS v4.0.1 Requirement 9.5.1.2)

What should staff do if they suspect a device was tampered with?

Remove it from service, preserve it as-is, and escalate through an incident/ticket workflow so you can investigate and document containment. Put a known-good replacement into service through a controlled swap process. (PCI DSS v4.0.1 Requirement 9.5.1.2)

What’s the fastest way to fail this requirement during an assessment?

Having terminals on the floor that are missing from inventory, inspection logs that don’t tie to device serial numbers, or gaps where inspections were “supposed to happen” but there’s no evidence. Those issues undermine your ability to show periodic inspection in practice. (PCI DSS v4.0.1 Requirement 9.5.1.2)

Footnotes

1. PCI DSS v4.0.1 Requirement 9.5.1.2