9.5 Point-of-interaction device protection: requirements and evidence

What PCI DSS 9.5 asks for POI device protection

If you are a compliance lead or engineer, the question you must answer is simple: could someone swap or tamper with a card-present terminal and nobody would notice? Requirement 9.5 exists to make that answer a documented no. It asks you to protect point-of-interaction (POI) devices that capture card data through physical interaction, such as swiped, tapped or dipped cards, from tampering and substitution. Tampering means someone alters the device, for example by fitting a skimming overlay or modifying its firmware. Substitution means a genuine-looking device is replaced with a fraudulent one. The requirement, numbered 9.5.1, rests on three parts: a device list that records each POI device with its location and serial number, periodic inspections of the devices, and training so that staff recognize suspicious behavior around them.

The inspection part is where most teams struggle. Under 9.5.1.2.1, which became mandatory on 31 March 2025, the frequency and type of inspections must be defined in a targeted risk analysis performed under Requirement 12.3.1. A fixed calendar check that never changes is no longer enough by itself. You must document why a given fleet, in a given location, is inspected at a given frequency, and the rationale must reflect real exposure, such as high-traffic outlets, unattended kiosks or devices that have been moved. Confirm with your assessor which risk factors they expect to see in the analysis and how they want the inspection results recorded. Your device list also has to stay current, because an inspection cannot catch a substitution if no one knows what the correct device looks like.

The scope of 9.5 is narrower than many readers expect. PCI SSC FAQ 1281 states that Requirement 9.5 does not require POI devices to be fixed in place or tethered, so mobile terminals can remain in scope if they are managed under the same list, inspection and training controls. The SAQ D notes also state that 9.5.1 does not apply to commercial off-the-shelf devices such as merchant-owned smartphones or tablets, and that it is only recommended for manual key-entry components such as keyboards. Before you build a device list, classify each device: dedicated payment terminals fall under 9.5.1, while off-the-shelf devices with a payment app may need a different justification. Record that classification, because an assessor will ask how you reached it.

Which POI devices and teams fall under PCI DSS 9.5

Requirement 9.5 applies to a narrower set of devices than many teams assume, and the list depends on who owns each terminal and where it sits. The cards below cover the device types that drive the work, the ones that fall outside 9.5.1, and the teams that must keep the device list accurate.

Card-present devices inside the CDE

Terminals that capture card data when a card is swiped, tapped or dipped are the core of Requirement 9.5.1. Each one that sits in or connects to the cardholder data environment belongs on the device list. Check the point-of-sale lanes, mobile kiosks, unattended payment units and any spare terminals kept in stockrooms, because assessors often find devices that operations never recorded.

Manual key-entry components

Keypads and keyboards used only to type card numbers are recommended for protection under 9.5 but are not mandated by the SAQ D notes. Decide early whether these components are in scope for your device list, document that decision, and apply the same inspection and training steps if you include them. Inconsistent treatment across lanes is what assessors question.

Commercial smartphones and tablets

Merchant-owned smartphones or tablets that accept payments through a commercial off-the-shelf application are not covered by Requirement 9.5.1, according to the SAQ D notes. They still fall under other requirements, such as access control, malware protection and configuration. Confirm with your assessor whether the payment application or any attached card reader changes that conclusion.

Leased and third-party terminals

Terminals supplied by a processor, acquirer or leasing company may still sit in your stores, so ownership alone does not settle whether they belong on your list. Ask each provider in writing which devices it owns, which it maintains, and whether it performs the inspections and training that 9.5 expects. Record the answers in the device list and in the contract with the provider.

Store operations and field service

Store managers run daily lanes and usually spot a swapped or damaged terminal first, so they need written inspection steps and a clear escalation path. Field service technicians move, replace and repair devices, which creates the most common gaps in location and serial number records. Both teams should update the device list at each change.

Procurement and the device list owner

Procurement introduces new terminals, and the device list owner must receive that record before the device is deployed. The owner keeps locations and serial numbers current, reviews inspection results and confirms that staff training has been delivered. Name one accountable person and a backup, and tie the list to the targeted risk analysis under 12.3.1 that sets inspection frequency.

How a QSA tests the POI device controls

This table compares what a Qualified Security Assessor typically samples for each part of Requirement 9.5, the evidence they ask to see and the findings that recur. Read each row as a test the assessor will run against your own device estate, and use the last column to decide what to prepare before fieldwork starts.

Requirement	What the assessor samples	Evidence requested	Findings that recur
9.5.1 Protection from tampering and substitution	Interviews with staff who handle devices, then a walkthrough of a sample of payment locations and their devices	Written procedures for protecting POI devices and the processes that run them	Procedures that exist on paper but are not followed at the sampled locations
9.5.1.1 Device list elements	The complete device list, cross-checked against devices physically observed at sampled locations	A list showing make, model, location, and the device or serial number for each POI device	Lists missing serial numbers, or devices in service that do not appear on the list
9.5.1.2 Periodic inspections	Inspection records for a sample of devices and locations over the review period	Completed inspection logs showing who inspected, when, and what was checked	Inspection records that are blank, templated or dated for locations the assessor did not confirm
9.5.1.2.1 Inspection frequency and type from the targeted risk analysis	The targeted risk analysis under 12.3.1 and the inspection schedule derived from it	A documented risk analysis that sets frequency and inspection type, plus proof the schedule follows it	Inspection frequency with no documented rationale, or a risk analysis that was never updated after devices or locations changed
9.5.1.3 Personnel training	Training records for staff who handle or inspect devices, and their awareness of tampering signs	Training content, attendance or completion records, and evidence the training covers the inspection process	Training completed once at onboarding and never refreshed, or staff who cannot describe what to look for
Device movement and replacement	Recent device additions, swaps or returns, traced through the list and inspection records	Change records showing the list was updated and the device was inspected before use	Replacement devices added to service before they were recorded or inspected

Implementing POI device protection in sequence

This sequence turns Requirement 9.5 into working records: an inventory of every card-present device, a documented risk analysis that sets how often and how each device is inspected, tested procedures, recorded inspections, trained staff and a list that stays current as devices move. Each step ends with an artifact an assessor can sample.

Build the device inventory
Start by listing every card-present point-of-interaction device in scope, including terminals that are swiped, tapped or dipped. For each device, record its make and model, serial number, device identifier, the location where it is used or stored, and the person or team responsible for it. Pull candidate devices from the payment provider's terminal records, purchase orders and site walkthroughs, then reconcile the two lists. The output is a single device list that every later step refers back to. Confirm with your acquirer or processor which device identifiers they use so your records match theirs.
Run the targeted risk analysis
Under the risk analysis process required by Requirement 12.3.1, document how device type, location, traffic volume, public access and past tampering attempts affect how often each device must be inspected and which inspection methods apply. The risk analysis is owned by the organization, usually the security or compliance lead with input from store or site operations. The output is a signed, dated analysis that states the chosen inspection frequency and type for each device group. Because the requirement makes this analysis mandatory for inspection frequency, an assessor will expect it to exist before inspections begin.
Define inspection and tamper-detection procedures
Write a short procedure that tells staff what to check on each inspection: the device's physical condition, seals and casing, cable connections, unexpected attachments or overlays, unexplained changes in the device's serial number or model, and any sign that the device was swapped. The procedure should also say what to do when something looks wrong, including who to notify, how to take the device out of service and how to record the event. The output is an approved procedure that matches the frequency and type set in the risk analysis.
Run and record each inspection
Carry out inspections at the frequency set in the risk analysis, and log each one against the device list. Each entry should record the device identifier, the date, the inspector, the checks performed, the result and any action taken. Where a device fails an inspection, record the finding, the containment step and the follow-up, and update the device list if the device is replaced. The output is an inspection log an assessor can sample across devices and time periods, showing that inspections happened as scheduled and that exceptions were handled.
Deliver role-based training and keep attendance
Train each group that handles or supervises devices, such as cashiers, store managers, field technicians and help desk staff, on the inspection procedure and the tamper signs most relevant to their role. Training should cover what to do when a device looks altered or when an unknown person asks to service or replace one. Keep attendance records, training materials and dates, and refresh the training when the procedure changes. The output is a training record that links each trained person to the procedure version they were taught.
Review the device list when devices move
Whenever a device is installed, moved, repaired, returned or retired, update the device list before the device is used or shipped. Compare the list against the inventory reconciliation and the inspection log, and confirm that the new location has the right inspection coverage and trained staff. Periodic reconciliation should catch any device that appears on the floor without a record. The output is a current device list with a change history that matches the physical estate, so that the next inspection cycle starts from accurate records.

Which evidence passes a 9.5 assessment

A QSA testing Requirement 9.5 looks for records that show each card-present device is known, inspected at a justified frequency, and handled by trained staff. The cards below cover the artifacts that connect those three checks, and each one needs upkeep between assessments, not just a clean snapshot on audit day.

Device list with locations and serials

This is the inventory of every card-present point-of-interaction device, recording make, model, serial number, location and the person or site responsible. Assessors compare it against devices they observe on site, so a missing serial or an unlisted terminal is the most common gap they find. Reconcile the list against the physical devices on a schedule your risk analysis sets, and after every move, swap or addition. Ask your team to confirm who owns the reconciliation and where the list is kept under version control.

Targeted risk analysis for inspections

Requirement 9.5.1.2.1 requires the inspection frequency and type to come from a targeted risk analysis under 12.3.1, and that requirement has been mandatory since 31 March 2025. The analysis should explain why each environment gets its inspection cadence, such as device exposure, staff turnover and how easily devices can be reached by the public. Review it when the environment changes and keep prior versions so the assessor can see the reasoning over time.

Inspection logs

Each inspection should record the device identifier, date, inspector, the type of inspection performed and the result, including any device found missing, altered or with unexpected attachments. Logs show the defined frequency is actually being followed. Gaps in the sequence are what assessors question first. Confirm that findings lead to a documented response, such as removing the device from service, and that the response is also recorded.

Training materials and completion records

Requirement 9.5 expects personnel to be trained to recognize tampering and substitution attempts, including suspicious contact from people claiming to be repair staff, unexpected device swaps and unauthorized inspections. Keep the current training content, the audience it was delivered to and a completion record for each person. Refresh the material when the risk analysis or device types change, and check that new hires and temporary staff are covered before they handle payments.

Device replacement change records

When a terminal is repaired, replaced or retired, the change record should link the old and new serial numbers, the reason, the approver, the date and the verification performed on the replacement before it took payments. These records prove the device list stayed accurate through the lifecycle. Pair them with the change control process used for the rest of the cardholder data environment so that a substituted device cannot enter service without an entry in the list.

Keeping the evidence current

Between assessments, the device list, inspection logs and training records drift unless someone owns a recurring check. Use a fixed reconciliation interval set in the risk analysis, and verify that inspection records match the defined frequency each period. An asset inventory tool can hold the device data, but it still needs manual confirmation against the physical devices, and it does not replace the inspections themselves. Ask your assessor early which format they will accept.

What meeting 9.5 costs in money and effort

This table breaks down the cost and effort components of meeting Requirement 9.5, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to decide which parts your own staff can absorb. No prices are given because none were supplied; confirm volumes and rates in your own environment.

Cost component	One-time or recurring, and who is paid	What drives it
Device inventory build	One-time build, then recurring upkeep. Internal staff or a partner compiles the list of POI devices with locations and serial numbers.	Number of locations, number of terminals per site, and how well existing asset records already match physical devices.
Device churn tracking	Recurring. Staff time to add, move, retire and replace devices in the list as they change.	Replacement rate, pilot programs, seasonal staffing, and whether devices are moved between stores.
Risk analysis under 12.3.1	Recurring when reviewed. Internal risk owner time, sometimes with an outside advisor.	Number of device types and locations, threat profile of each site, and how often the analysis is repeated.
Inspection tooling and labor	Recurring. Staff or contracted technicians perform inspections at the frequency set by the targeted risk analysis.	Inspection frequency, number of sites, travel between locations, and whether inspections are scripted or ad hoc.
Staff training development and delivery	One-time course build, then recurring delivery and records. Internal training team or an external provider.	Staff turnover, number of roles that touch devices, and whether training is delivered in person or through an online learning platform.
Evidence upkeep	Recurring. Staff time to keep inventory, inspection logs and training records current for assessors.	Retention rules, audit trail depth, and whether records live in one system or many spreadsheets.
Assessor sampling	Recurring at each assessment. Fees are paid to the QSA, and sampling depends on the records you can produce.	Number of locations sampled, quality of records, and the number of follow-up questions raised.
License spend for inventory tools	Recurring for commercial tools. Open-source inventory such as GLPI can reduce this line, but hosting and administration remain your cost.	Whether you already run an asset platform, hosting footprint, and internal administration capacity.

Open-source tools that support the device list and evidence

GLPI's Assets module is the most direct fit for the device list that requirement 9.5.1 expects, because it holds structured records for computers, peripherals, network equipment, phones and racks. Entries can be created by hand or pushed automatically by the GLPI Agent, which uses native inventory built into GLPI since version 10. Automated discovery captures what the agent can read from a host, so a card-reading terminal that does not run an agent or expose itself to the network will not appear on its own.

Manual entries: Staff record each terminal with its location, make, model and serial number, which gives you a device list that can be reviewed during an assessment.
Agent-pushed entries: Hosts that run the GLPI Agent report hardware and software details automatically, which helps keep records current when devices are added to a workstation or cash point.
Location and ownership fields: Use the standard asset fields to tie each device to a site, a cost center or a responsible owner, so inspection tasks can be assigned.
Status tracking: Record when a device is retired, replaced or moved, so the list reflects the environment on the day of the inspection.
Limit to confirm: Native inventory does not identify payment terminals by default. Confirm with your terminal vendor whether any device exposes data the agent can read, and otherwise plan manual or imported records.

Before relying on GLPI, test whether it records the specific serial numbers and locations your acquirer or assessor will ask for, using one terminal from each model in your estate.

Where organizations fail 9.5 and how to close each gap

Most 9.5 findings trace back to a device list that drifts away from reality. The gaps below cover the list itself, the inspection schedule, what staff know, and what happens when vendors swap hardware. Each card ends with a closing action you can assign and check.

Device lists without serial numbers

A list that records only model and store name cannot show whether a terminal was replaced, moved or substituted. Requirement 9.5.1 expects each device to be identifiable, so the list should carry a make, model, serial number and a location that is specific enough to find the device on the floor. Assessors often ask a sample of entries to be matched to physical units. Close it by capturing serial numbers at receipt, before any device is deployed, and reconciling the list against the terminal management system each quarter.

Fixed-schedule inspections with no risk analysis

Inspecting every terminal on the same calendar date, regardless of location risk or device type, does not show that the frequency was chosen deliberately. Requirement 9.5.1.2.1 asks that inspection frequency and type come from a targeted risk analysis under Requirement 12.3.1, and that mandate has applied since 31 March 2025. An unexplained interval is hard to defend when a tampering incident occurs at an unattended site. Close it by writing a risk analysis that ranks locations by exposure, sets the inspection interval and method for each tier, and recording who approved it.

List that does not match devices on site

The most common finding is a mismatch: the list shows terminals that no longer exist, and the terminals in the store are missing from the list. Each mismatch is a place where an unrecorded device could be swapped in without detection. Reconciliation should compare physical counts and serial numbers against the list, not just confirm that the list is complete on paper. Close it by running a physical walk-through against the list at each site, logging every discrepancy, and holding a named owner accountable for resolving it before the next cycle.

Untrained staff at satellite locations

Head-office teams often deliver training, but staff at kiosks, pop-up counters and franchise outlets may never receive it. Requirement 9.5.1 expects personnel to be trained to recognize tampering and substitution, including suspicious contact from someone claiming to be a technician. Without that training, an inspection can pass on paper while the people closest to the device cannot spot an attack. Close it by issuing short role-specific training to every location, keeping attendance records by site, and testing recognition with a brief quiz or spot check.

Vendor swaps without list updates

When a payment provider or hardware vendor replaces a terminal during a repair, upgrade or software change, the replacement often never reaches the device list. The organization then holds a list that describes hardware it no longer has, and it cannot confirm that the new unit came from a trusted source. Contracts with vendors should require notice of every swap and the serial numbers involved. Close it by adding a change step to the vendor process that requires a list update and an inspection of the replacement before it goes live, and confirming the requirement in writing with each vendor.

Questions buyers ask about 9.5 cost, effort and outside help

Does requirement 9.5 apply to smartphones and tablets?

Generally no, when the devices are commercial off-the-shelf products such as merchant-owned smartphones or tablets. The SAQ D notes say Requirement 9.5.1 does not apply to these devices. Requirement 9.5.1 is only recommended for manual key-entry components such as keyboards. The test is whether the device is a dedicated point-of-interaction device that captures card data through physical interaction with the card. Confirm with your acquirer or assessor how your specific devices and any payment app on them are classified, because the answer depends on how the card data is captured and what the device does. Also check the PCI SSC FAQ on physically securing POI devices for the position on fixed installation, which the standard does not require.

How much effort does the POI device list take to build and maintain?

The first build is mostly collection work, and the ongoing effort is change handling. Someone must record each device with its make, model, serial number, location and status, then reconcile that list against what is physically present. Effort rises with the number of sites, the number of terminals per site, and how often devices are moved, repaired, swapped or retired. Requirement 9.5.1 does not require devices to be fixed in place or tethered, so mobile devices add more movement events to track. Ask for a quote that separates the initial inventory, the data model or tool setup, and the recurring reconciliation work. Inventory tools can reduce manual effort: the GLPI Assets module can record peripherals and be filled by its agent, and Wazuh Syscollector collects endpoint hardware data, but neither is known to capture POI terminals automatically, so confirm what each can read in your environment before relying on them.

Can inspections of POI devices be outsourced, or must our staff do them?

Requirement 9.5 does not say who performs the inspections, so an outside provider can carry them out if your procedures and evidence meet the requirement. Your organization still owns the control: the inspection frequency and type must be set by you, the results must be recorded, and anomalies must be acted on. Outsourcing usually covers the labor of visiting sites and checking devices against the list, while your team keeps the device list, approves the inspection plan, and reviews findings. Ask any provider for written procedures, sample inspection records, how they confirm the person is authorized, and how they report suspected tampering to you. Also confirm they will not be the assessor for the same work, since assessment must be independent.

What does the targeted risk analysis for 9.5.1.2.1 need to contain?

The targeted risk analysis must define how often you inspect POI devices and what type of inspection you perform, based on your own environment. Requirement 9.5.1.2.1 points to a targeted risk analysis under Requirement 12.3.1, and that requirement became mandatory on 31 March 2025. A workable analysis names the device types and locations in scope, the threats relevant to each (such as substitution, skimming overlays or unauthorized access to terminals), the factors that raise risk (public access, unattended periods, device mobility, prior incidents), and the reasons for the chosen frequency and inspection method. It should be approved, dated and reviewed when your device fleet or threat picture changes. Do not copy a generic frequency from another organization; the analysis must justify your own choice.

Can a consultant perform the 9.5 assessment and issue the report?

No. A consultant can prepare your device list, inspection procedures, training and evidence, but only a Qualified Security Assessor can complete the Report on Compliance for entities that require one. For smaller entities, the Self-Assessment Questionnaire and its Attestation of Compliance are completed by the organization itself, and the attestation is signed by an authorized officer. The consultant's role is preparation, so keep it separate from the assessment itself. An implementation partner such as DeployOpen prepares systems, controls and evidence for assessment, but does not issue reports, attestations or certificates. Confirm with your acquirer which validation path applies to you, and check the PCI SSC FAQ on compliance certificates, since certificates are not recognized as validation.

What does our team need to provide before outside help can start?

Outside help moves faster when your team gathers the facts first. Typical inputs include:

A list of every card-present payment terminal, with location, model and current status, or access to the systems where that information lives
Your current policies for device handling, inspection and staff training, and the names of owners for each
Floor plans or site lists showing where devices sit, and any mobile or temporary deployments
Records of past inspections, incidents and device replacements
Access to the people who receive, install and repair devices, and to the staff who will be trained

Agree in writing on scope, deliverables and timelines before work starts, because most engagements are fixed-scope. The clearer the inputs, the more accurate the quote.

Is there a published price for 9.5 readiness work from DeployOpen?

No. DeployOpen does not publish a price list, and a quote follows from a written scope that covers the device count, sites, inspection approach, training audience and evidence required. Cost drivers for 9.5 include how many devices and locations are in scope, whether inspections are performed by your staff or a provider, how often the device fleet changes, how much of the device data already exists, and whether training is delivered once or repeated for new staff. Ongoing support and continuous testing are available as retainers and are priced separately from the initial scope. When you request a quote, ask for one-time and recurring components listed separately, and for the assumptions behind each.

How DeployOpen prepares 9.5 systems and evidence

DeployOpen begins with a written scope that names which card-present devices, locations and inspection tooling are covered, before any system is configured. The scope document should state which POI devices capture card data through physical interaction, which fall outside Requirement 9.5 (such as merchant-owned smartphones or tablets, which the SAQ D notes say are not subject to 9.5.1), and who owns each inventory field. We set up the device inventory in the client's own infrastructure, typically as a register that records device make, model, serial number, location, assigned owner and last inspection date. Where a client already runs an asset tool such as GLPI, we can configure a device class and custom fields for POI hardware so the register is maintained in the same place as other assets. Confirm with your QSA whether a spreadsheet, a CMDB or a GLPI asset class is acceptable for the evidence your assessor expects, because the format is a decision for your team and the assessor, not for us.

For inspections, the key decision is the inspection frequency and type, which Requirement 9.5.1.2.1 requires to be defined in a targeted risk analysis under 12.3.1. We prepare the risk analysis template, the inspection checklist that records tamper and substitution checks for each device, and the logging format that ties each inspection to a device serial number and an inspector. Where the device estate is large, we can use the inventory and logs to show that every device was inspected at the defined frequency. DeployOpen does not set the frequency for you, and it does not decide whether a device is in scope. Those are decisions your organization owns and documents. Training content is prepared as a course that the client's learning platform can host, such as Moodle, where activity completion can record that each cashier or technician has viewed the material. Confirm with your QSA which training records and attestations they will sample.

DeployOpen prepares systems, controls and evidence for the 9.5 assessment, but it does not issue reports, attestations or certifications. Only a Qualified Security Assessor, through the Report on Compliance or the relevant Self-Assessment Questionnaire and Attestation of Compliance, can state that 9.5 is met. Work is fixed-scope: we agree the scope, deliverables and timeline in writing, and then quote from that written scope. DeployOpen does not publish a price list, so the quote will depend on the number of device types, locations, tooling to configure and training material to produce. Ask any provider to itemize one-time setup (inventory design, risk analysis template, training build) separately from recurring work such as periodic inspection support or retainer-based reviews, and ask who will hold the evidence after handover.

9.5 Point-of-interaction device protection