POI Device Tampering Training

PCI DSS v4.0.1 Requirement 9.5.1.3 requires you to train all personnel who work around payment point-of-interaction (POI) devices to spot tampering or substitution, verify the identity of third-party repair/maintenance personnel, ensure devices aren’t installed/replaced/returned without verification, and report suspicious behavior through a defined channel. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Key takeaways:

• Train the people physically near POI devices, not just security staff. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Your training must explicitly cover third-party identity verification and “no device swap without verification.” (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Auditors will look for proof of completion, role coverage, and an operational reporting path that staff can explain. (PCI DSS v4.0.1 Requirement 9.5.1.3)

“POI device tampering training” is a practical, front-line control. It exists because payment terminals and other POI devices sit in semi-public spaces and can be physically handled, observed, or targeted by criminals or dishonest insiders. PCI DSS doesn’t treat this as a purely technical problem; it treats it as a people-and-process requirement.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize PCI DSS v4.0.1 Requirement 9.5.1.3 is to treat it like a role-based training and accountability program tied directly to your POI inventory and your service/repair workflow. Your goal is simple: personnel in POI environments must know what “normal” looks like for your devices, what “suspicious” looks like, how to validate a person who claims they’re there to work on a device, and what to do if something feels off. (PCI DSS v4.0.1 Requirement 9.5.1.3)

This page gives you requirement-level implementation guidance: who needs training, what to include, how to run it operationally, what evidence to keep, and what auditors commonly challenge.

Regulatory text

PCI DSS v4.0.1 Requirement 9.5.1.3 states that training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices. It must include: verifying the identity of any third party claiming to be repair or maintenance personnel before granting access to modify or troubleshoot devices; procedures to ensure devices are not installed, replaced, or returned without verification; being aware of suspicious behavior around devices; and reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel. (PCI DSS v4.0.1 Requirement 9.5.1.3)

What the operator must do: implement training that is specific to POI tampering and substitution risks, mapped to the real workflows in your environment (stores, branches, kiosks, event terminals, or serviced locations). The training must teach identity verification for third-party technicians, device verification at install/return/replacement, and reporting expectations. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Plain-English interpretation (what this requirement really means)

You must ensure that people who can physically access POI devices can:

1. recognize signs that a device might be altered or swapped,
2. stop unverified third parties from touching devices,
3. follow a controlled process so devices are not installed/replaced/returned without checks, and
4. escalate concerns through a known reporting channel. (PCI DSS v4.0.1 Requirement 9.5.1.3)

This is not “annual security awareness training.” It’s targeted training for personnel who operate around payment devices and can realistically notice tampering first.

Who it applies to (entity and operational context)

This requirement applies to merchants, service providers, and payment processors with POI environments. (PCI DSS v4.0.1 Requirement 9.5.1.3)

In scope personnel typically include:

• Store/branch staff who open/close lanes or handle terminals.
• Supervisors and managers with oversight of registers or service desks.
• Field technicians employed by you.
• Help desk staff receiving incident reports about terminals.
• Receiving/warehouse staff handling shipped POI devices (where relevant to your workflow).
• Anyone who escorts or approves access for third-party maintenance personnel. (PCI DSS v4.0.1 Requirement 9.5.1.3)

“In POI environments” is the key phrase. If a role is routinely near POI devices, treat it as in scope, even if that person never processes a payment.

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

1) Define your POI environment and roles

• Create or validate a list of locations and contexts where POI devices exist (stores, pop-up events, customer service counters, cages, kiosks).
• Identify the roles that can observe, handle, store, install, disconnect, ship, or approve work on POI devices.
• Assign training ownership (usually Compliance/GRC plus Store Ops or IT Asset/Endpoint). (PCI DSS v4.0.1 Requirement 9.5.1.3)

Exam reality: if your role scoping is fuzzy, auditors will assume coverage gaps.

2) Write the minimum required training content (don’t overdesign it)

Your training content must directly cover the items called out in the requirement: (PCI DSS v4.0.1 Requirement 9.5.1.3)

A. Identity verification of third-party repair/maintenance personnel

• What staff must do before allowing access: check ID, confirm work order/ticket, confirm approved third party, confirm escort requirements, and confirm scope of work matches the request.
• What staff must never do: allow “walk-in” service, accept “I’m here for maintenance” without verification, or let a technician work unobserved if your procedure requires supervision. (PCI DSS v4.0.1 Requirement 9.5.1.3)

B. Device installation/replacement/return verification

• Steps for verifying a device before it goes into service (and after it returns from repair or storage).
• How to confirm a device is the expected one (example: match asset tag/serial number to inventory record; confirm location assignment; confirm any tamper indicators are intact if you use them).
• What to do if verification fails: quarantine the device, stop use, escalate. (PCI DSS v4.0.1 Requirement 9.5.1.3)

C. Suspicious behavior awareness

• Provide concrete examples relevant to your setting: someone loitering near terminals; attempts to distract staff while another person handles a device; a person requesting access outside normal hours; pressure to “just swap it quickly.” (PCI DSS v4.0.1 Requirement 9.5.1.3)

D. Reporting

• Exactly where to report (ticketing queue, hotline, manager-on-duty, security contact).
• What details to report (location, device identifier, what was observed, who was present, whether the device is still in service).
• Emphasize that staff should report even if unsure. (PCI DSS v4.0.1 Requirement 9.5.1.3)

3) Turn training into an operational workflow

Training fails when it’s detached from how work happens. Build simple “do this every time” hooks:

• Third-party access gate: no technician touches a POI device without a verified ticket/work order and identity check. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Device change control: swaps, replacements, and returns require verification before re-deployment. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Quarantine path: a known place/process to hold suspicious devices and prevent accidental reuse.
• Escalation path: a fast reporting route to “appropriate personnel” (name the team, not a vague mailbox). (PCI DSS v4.0.1 Requirement 9.5.1.3)

4) Deliver the training in a way your workforce will retain

Pick formats that fit your environment:

• Short module for all in-scope personnel.
• Job aid at the point of use (register binder card, back-office poster, intranet page).
• Supervisor talk-track for new hires and shift refreshers. (PCI DSS v4.0.1 Requirement 9.5.1.3)

If you run many distributed locations, centralize assignment tracking. Daydream can help you map roles to POI locations, assign training, and collect evidence in one place so audits don’t become a manual scavenger hunt.

5) Validate effectiveness (lightweight but real)

PCI DSS 9.5.1.3 is a training requirement, but auditors often test whether staff can explain the process.

• Ask managers to perform spot knowledge checks (“What do you do if a technician shows up without a ticket?”).
• Run a tabletop scenario: suspected swap at Lane 3; what happens next?
• Confirm reporting produces an actionable ticket and not dead-end email. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Required evidence and artifacts to retain

Keep evidence that proves: (a) the training content covers required topics, (b) the right people took it, and (c) reporting/verification is operational.

Minimum artifacts:

• Training material (slides, script, LMS module text) explicitly addressing all required topics. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Training assignment matrix mapping POI roles/locations to required training.
• Completion records (LMS export or signed attendance logs) showing learner, role/location, completion date, and version of content.
• Job aids or SOP excerpts for: third-party identity verification, device install/replace/return verification, reporting steps. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Incident/reporting tickets or logs showing that reports are captured and routed to appropriate personnel (sanitize if needed).
• Third-party maintenance process evidence: work order templates, technician verification checklist, escort policy/procedure. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Common exam/audit questions and hangups

Expect questions like:

• “Who do you consider ‘personnel in POI environments,’ and how did you determine coverage?” (PCI DSS v4.0.1 Requirement 9.5.1.3)
• “Show me where training teaches staff to verify third-party repair identity before granting access.” (PCI DSS v4.0.1 Requirement 9.5.1.3)
• “How do you ensure devices are not installed or replaced without verification?” (PCI DSS v4.0.1 Requirement 9.5.1.3)
• “What is the reporting path, and can a cashier explain it?”
• “Provide evidence of completion for a sample of locations/roles.”
• “What happens to a suspicious terminal right now, operationally?” (PCI DSS v4.0.1 Requirement 9.5.1.3)

Hangups that trigger follow-ups:

• Training is generic security awareness with no POI-specific content.
• Training exists, but contractors/seasonal staff are not covered.
• “Appropriate personnel” is undefined, or staff don’t know who that is. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Training only IT/security.
   Fix: include store ops, cashiers, supervisors, receiving, and anyone who escorts technicians. (PCI DSS v4.0.1 Requirement 9.5.1.3)

2. Mistake: No explicit third-party identity verification step.
   Fix: require a ticket/work order + ID check, and train staff to deny access when either is missing. (PCI DSS v4.0.1 Requirement 9.5.1.3)

3. Mistake: Device swaps handled informally (“just plug the new one in”).
   Fix: create a short verification checklist tied to inventory identifiers before a device returns to service. (PCI DSS v4.0.1 Requirement 9.5.1.3)

4. Mistake: Reporting channel exists but is not usable.
   Fix: give a single, simple reporting method for front-line staff and test it with real tickets. (PCI DSS v4.0.1 Requirement 9.5.1.3)

5. Mistake: Evidence is scattered.
   Fix: centralize training versions, assignments, and completion data. Daydream is a practical place to keep the control narrative and artifacts aligned to PCI DSS evidence asks.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, the risk is straightforward: a tampered or substituted POI device can compromise payment data and create downstream incident response, card brand, and reputational impacts. PCI DSS treats this as a people-and-process line of defense in physical payment environments. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Practical 30/60/90-day execution plan

First 30 days (establish control design)

• Identify in-scope POI environments and roles; document your coverage logic. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Draft training content covering all four required areas: identity verification, install/replace/return verification, suspicious behavior, reporting. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Define the reporting channel and escalation owner (“appropriate personnel”) and confirm it is staffed.
• Create a one-page job aid for front-line staff.

Next 60 days (rollout + evidence)

• Assign training to all in-scope personnel; track completion centrally.
• Train managers on how to enforce “no ticket, no touch” for third-party maintenance. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Implement (or tighten) the device verification checklist for install/replace/return.
• Start retaining proof: training version, completions, SOPs, and sample tickets.

By 90 days (prove it works)

• Run spot checks: ask staff to explain what to do if a device looks different or a technician appears unannounced. (PCI DSS v4.0.1 Requirement 9.5.1.3)
• Test the reporting channel end-to-end and confirm incidents route to the correct team.
• Perform a mini-audit: pick several locations, sample personnel completion, and verify job aids are present and current.
• If you use Daydream, map the requirement to artifacts and assign an evidence owner so future audits are a refresh, not a rebuild.

Frequently Asked Questions

Does PCI DSS require this training for corporate security staff too?

The requirement targets “personnel in POI environments,” so prioritize people with physical proximity to POI devices. Train corporate teams who approve third-party access or handle POI inventory workflows if they influence install/replace/return decisions. (PCI DSS v4.0.1 Requirement 9.5.1.3)

What counts as “verifying identity” for a third-party technician?

The requirement expects a real identity verification step before access is granted. In practice, that means checking ID and confirming the person is authorized for a specific work order/ticket tied to your approved third party. (PCI DSS v4.0.1 Requirement 9.5.1.3)

We outsource terminal maintenance. Are we still responsible for training?

Yes. The requirement is about training your personnel in POI environments, including how they interact with third-party maintenance personnel and device replacements. Outsourcing maintenance does not remove the need for your staff to verify identity and follow verification procedures. (PCI DSS v4.0.1 Requirement 9.5.1.3)

Do we need to include procedures for devices being “returned”?

Yes. The regulatory text explicitly includes procedures to ensure devices are not installed, replaced, or returned without verification, so your workflow must cover devices coming back from repair, storage, or shipment. (PCI DSS v4.0.1 Requirement 9.5.1.3)

What will an auditor ask to see as evidence?

Expect requests for training content, completion records for in-scope roles, and written procedures/job aids covering identity verification, device verification at install/replace/return, and reporting. Auditors may also interview staff to confirm they can explain the process. (PCI DSS v4.0.1 Requirement 9.5.1.3)

How do we keep this program current as locations and devices change?

Tie training assignment to your POI inventory and role onboarding/offboarding so coverage updates automatically when devices or staff change. Keep versioned training content and reissue updates when procedures or third-party maintenance processes change. (PCI DSS v4.0.1 Requirement 9.5.1.3)