POI Device Protection

PCI DSS 4.0.1 Requirement 9.5.1 requires you to protect point-of-interaction (POI) devices from tampering and unauthorized substitution by (1) maintaining an accurate device list, (2) performing periodic physical inspections for tampering, and (3) training staff to spot and report suspicious behavior. Operationalize it with a tight inventory, a repeatable inspection routine, and auditable training and reporting records. (PCI DSS v4.0.1 Requirement 9.5.1)

Key takeaways:

• Maintain a current POI device inventory with enough detail to detect swaps. (PCI DSS v4.0.1 Requirement 9.5.1)
• Run documented, periodic POI inspections focused on device surfaces and attachment points. (PCI DSS v4.0.1 Requirement 9.5.1)
• Train frontline personnel and require prompt reporting of suspected tampering or substitution. (PCI DSS v4.0.1 Requirement 9.5.1)

“POI device protection requirement” work succeeds or fails on execution details: what counts as a POI device in your environment, who touches it, how you know it’s the same device tomorrow, and what evidence you can produce during an assessment without scrambling. Requirement 9.5.1 is a physical security control with operational dependencies on store operations, IT, security, and any third party that installs, maintains, or replaces payment terminals.

Assessors typically look for three things: (1) you can account for every in-scope POI device, (2) you can prove routine inspections actually happen and are effective at detecting tampering or swaps, and (3) your staff knows what “wrong” looks like and what to do next. This page gives you requirement-level implementation guidance you can assign, track, and audit.

If you want to run this as a program instead of a spreadsheet exercise, Daydream can help you standardize evidence collection (device inventories, inspection attestations, training completion, incident tickets) so your team is not rebuilding proof each assessment cycle.

Regulatory text

PCI DSS 4.0.1 Requirement 9.5.1 states: “POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including maintaining a list of POI devices, periodically inspecting POI device surfaces to detect tampering or unauthorized substitution, and training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.” (PCI DSS v4.0.1 Requirement 9.5.1)

Operator meaning: you must be able to (a) identify your POI devices, (b) detect if someone altered or swapped a device, and (c) show that staff is trained and reporting paths work. The control is not satisfied by policy text alone; it needs a recurring, evidenced operational loop. (PCI DSS v4.0.1 Requirement 9.5.1)

Plain-English interpretation

If a device takes card data by physical interaction (dip, tap, swipe, insert), you must prevent and detect physical compromise. The practical intent is to reduce risk from skimmers, look-alike terminal swaps, or “maintenance” activity that introduces malicious hardware.

This requirement expects both prevention and detection:

• Prevention through controlled installation, secure mounting, and limited access.
• Detection through routine inspections and trained staff reporting.

Who it applies to (entity + operational context)

Applies to:

• Merchants operating checkout lanes, kiosks, mobile checkout, or unattended terminals. (PCI DSS v4.0.1 Requirement 9.5.1)
• Service providers and payment processors that deploy, service, warehouse, refurbish, or manage POI devices on behalf of merchants or other customers. (PCI DSS v4.0.1 Requirement 9.5.1)

Operationally, this hits:

• Retail store operations, branch operations, call centers with card-present hardware, and field services.
• Any third party involved in delivery, installation, repair, replacement, key injection, or terminal swap logistics. Even if they “own” the terminal, you still need controls and evidence that your environment is protected from substitution.

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

1) Define “in-scope POI devices” and owners

• Identify every location and process where a card is physically presented.
• Enumerate device types: countertop terminals, pin pads, integrated POS peripherals, mobile readers, kiosks, and temporarily staged spare terminals.
• Assign an accountable owner for the control (often Store Ops + Security + IT).

Output: scope statement and RACI for inventory, inspections, and training.

2) Maintain a POI device list that can detect substitution

Your list must be detailed enough to prove a device wasn’t swapped with an identical-looking unit. At minimum, capture:

• Location (site, store/branch ID, lane/register, kiosk ID).
• Device make/model.
• Unique identifier(s): serial number and/or asset tag; include other immutable identifiers if available.
• Deployment status (in service, in storage, in transit, retired).
• Custodian (team or role responsible for the device at the location).

Practical control design:

• Tag devices physically (tamper-evident asset label or engraved tag) and record it in the inventory.
• Control spares. A spare device sitting in a drawer is a substitution risk if you cannot track chain-of-custody.

Evidence tip: Keep an “inventory change log” that records swaps, repairs, and decommissions with a ticket reference.

3) Establish a periodic inspection procedure that staff can follow

Your inspection needs to focus on device surfaces and anything that could conceal a skimmer or indicate forced access. Build a checklist that includes:

• Signs of overlay/added components, unusual attachments, or misaligned seams.
• Evidence of prying, broken seals, missing screws, or new adhesive residue.
• Cable integrity and routing (unexpected splitters, couplers, or new cable paths).
• Mounting integrity (device moved, rotated, or loosened from bracket).

Make the checklist observable. Frontline staff should not need special tools or technical judgment to complete a basic inspection.

Operational detail that prevents audit pain:

• Define who inspects (role), where they record results, and what triggers escalation.
• Define what “pass” and “fail” looks like, with photos of “known good” devices per model.
• Include an out-of-band verification step for any “service call” (for example, verify the technician work order through your internal help desk before allowing access).

4) Create a “suspected tampering” response path

Train staff to treat suspected tampering as an incident with containment steps. Your runbook should cover:

• Stop using the device immediately.
• Preserve the device; do not power-cycle or disassemble unless your security procedure requires it.
• Notify the help desk/security contact and store/branch manager.
• Swap to a known-good device using controlled spares, if business continuity requires it.
• Open an incident ticket and record the device identifier, location, and observations.

Assessors often ask for proof that this path is real: tickets, emails, or hotline logs tied to device IDs.

5) Train personnel and make it role-specific

Requirement 9.5.1 explicitly calls for training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution. (PCI DSS v4.0.1 Requirement 9.5.1)

Training should be tailored:

• Cashiers/front desk: how to inspect, what to look for, how to escalate, what not to do.
• Managers: how to quarantine devices, approve technician access, and ensure inspections are completed.
• IT/field services: chain-of-custody, secure installation, and documentation expectations.
• Receiving/warehouse: verify shipments, track serials, secure storage, and log device movement.

6) Manage third-party touchpoints (installation, repair, replacement)

Most substitution risk appears during legitimate maintenance. Put controls around:

• Pre-approval of service visits and identity verification at arrival.
• Device swap documentation (old serial removed, new serial installed, tickets, and sign-off).
• Shipping controls for device returns and replacements, with tracking and receipt confirmation.

If a third party provides or services the terminals, your due diligence should still confirm how they prevent substitution and how you receive notice of swaps. Store their procedures and your oversight records.

Required evidence and artifacts to retain

Keep evidence aligned to the three explicit requirement components. (PCI DSS v4.0.1 Requirement 9.5.1)

Device list evidence

• Current POI inventory export (with device identifiers and locations).
• Inventory change log (swap/repair/retire) mapped to tickets.
• Photos of asset tags or “known good” reference photos per device model (recommended).

Inspection evidence

• Written inspection procedure and checklist.
• Completed inspection logs (paper forms or digital attestations) tied to location and device ID.
• Exception records: failed inspections, quarantines, device removals, follow-up actions.

Training evidence

• Training content (slides, job aids, photos of tampering indicators).
• Training completion records by role/location.
• Reporting mechanism proof (help desk queue, hotline SOP, incident response runbook).

Daydream note (practical fit): teams often lose time reconciling device IDs across spreadsheets, tickets, and training rosters. Daydream can centralize artifacts and map them directly to 9.5.1 so you can produce evidence sets by site or assessor request without rebuilding them each time.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your list of POI devices and how you know it’s complete.”
• “How do you detect if a device has been swapped with an identical unit?”
• “Walk me through your inspection process. Who does it, and where is it recorded?”
• “Show inspection records for a sample of locations and devices.”
• “How are employees trained, and what do they do if they suspect tampering?”
• “How do you control third-party technicians and document device replacements?”

Hangups that trigger follow-ups:

• Inventory exists but is missing serial numbers or accurate locations.
• Inspection logs exist but do not tie to device IDs, only to “Store #123.”
• Training is generic security awareness and does not cover POI-specific tampering cues.
• No evidence of exceptions, escalations, or incident handling, even though the process claims it exists.

Frequent implementation mistakes (and how to avoid them)

1. Inventory that cannot detect substitution.
   Fix: record unique identifiers and physically tag devices; require ticketed updates on every move/swap.

2. Inspections that are checkbox theater.
   Fix: use model-specific “known good” photos, require observation notes for anomalies, and spot-check by managers or security.

3. Uncontrolled spares.
   Fix: treat spares as in-scope assets with storage controls and chain-of-custody logging.

4. Third-party maintenance without verification.
   Fix: require pre-approved work orders, identity checks, and documented device swaps with serials.

5. Training without a reporting channel.
   Fix: publish a single reporting path, test it (tabletop), and retain the test record.

Risk implications (why assessors care)

A compromised POI device can capture card data at the point of interaction. The operational risk is concentrated at distributed sites where physical access is hard to supervise and staff turnover is high. Your control set needs to assume that an attacker will try to blend in as a technician or rely on staff not knowing what “normal” looks like.

Practical 30/60/90-day execution plan

First 30 days (stabilize and get auditable)

• Name control owners and publish scope: which POI devices and sites are in scope.
• Build the initial POI inventory with identifiers and locations; reconcile with procurement and store lists.
• Draft inspection checklist and “known good” photo job aid for each device model.
• Define the escalation process and route (help desk queue, security mailbox, incident ticket type).

By 60 days (operate consistently)

• Roll out inspections across sites with a standard logging method.
• Train frontline roles and managers on inspection + reporting; capture completion records.
• Implement chain-of-custody steps for spares, shipments, and swaps.
• Run a small internal sampling review: pick sites, trace inventory to device, match inspection logs.

By 90 days (prove effectiveness and close gaps)

• Tune inspection checklist based on real findings and staff feedback.
• Add manager spot-checks and exception tracking.
• Formalize third-party procedures for technician visits and device replacements; store their documentation and your oversight records.
• Prepare an assessor-ready evidence pack: inventory export, inspection logs, training roster, and a few closed escalation tickets.

Frequently Asked Questions

What counts as a “POI device” for Requirement 9.5.1?

Any device that captures payment card data through direct physical interaction with the card form factor is in scope, such as terminals, pin pads, and kiosks. Apply your scope consistently across owned devices and devices provided or serviced by third parties. (PCI DSS v4.0.1 Requirement 9.5.1)

Do we need serial numbers in the POI device list?

The requirement calls for maintaining a list of POI devices and protecting against substitution, so your list must include identifiers that let you detect swaps. In practice, serial numbers and asset tags make substitution detection and audit sampling much easier. (PCI DSS v4.0.1 Requirement 9.5.1)

What should a “periodic inspection” look like?

It should be a documented, repeatable check of device surfaces and attachment points for signs of tampering or substitution, recorded in an inspection log. The checklist should be simple enough for frontline staff to execute and consistent enough to audit. (PCI DSS v4.0.1 Requirement 9.5.1)

How do we handle third-party technicians who service payment terminals?

Treat technician access as a controlled event: verify the work order, verify identity, supervise access when feasible, and document any device swap by serial number and location in a ticket. Retain those records as evidence of substitution control. (PCI DSS v4.0.1 Requirement 9.5.1)

Are mobile readers and “pop-up” checkout devices in scope?

If they capture card data via direct physical interaction, they fall under the POI protection expectation. Track them in inventory and define how inspections and custody work when devices move between staff and locations. (PCI DSS v4.0.1 Requirement 9.5.1)

What evidence is most likely to be requested by an assessor?

Expect requests for the POI device list, inspection procedure and logs, and role-based training records, plus examples of how suspected tampering would be reported and handled. Tie logs and tickets to device identifiers to avoid sampling failures. (PCI DSS v4.0.1 Requirement 9.5.1)