Free payment device inventory template (PCI DSS 9.5.1.1)

Q: Do spare terminals have to be in the inventory?

Yes. PCI DSS v4.0.1 Requirement 9.5.1.1 covers the POI devices you operate, which includes spares, units out for repair, units in transit between sites and retired units you still hold — not only the terminals currently plugged in. Give each one a record. With this template, import your spares as a separate file so they exist from the start; moving one into service later is then a status change on an existing device, and its history follows it.

Q: What details does PCI DSS 9.5.1.1 ask you to record for each device?

Enough to tell one device from another and to tie a device to a place: at minimum the make, the model, the serial number or another unique identifier, and the location of the device. Most merchants also record an internal asset tag and the specific position the device sits in, because that is what makes a substituted device noticeable. This template's columns are make, model, serial, asset tag, kind and slot label, plus an optional notes column.

Q: Can I just keep my reader list in a spreadsheet?

Nothing in the requirement mandates a particular tool, and a spreadsheet is a reasonable place to start for a single site. The practical limit is evidence: a spreadsheet can be edited without trace, so it shows what you believe today rather than proving what was recorded and when. Merchants with several sites, or with an assessor who asks how the record is protected, generally move to a system that keeps an append-only history.

Q: How is the device inventory related to tamper inspections?

The inventory is what makes an inspection meaningful. Requirement 9.5.1.2 asks you to check devices periodically for tampering and substitution — and you can only detect a substitution if you already know which serial number belongs in which position. Build the inventory first; the inspection routine sits on top of it.

Q: Is this template free?

Yes — free to download, use, modify and share, with no account and no email required. It is provided to help you document and evidence device-inventory activity under PCI DSS v4.0.1 Requirement 9.5.1.1; it is not an attestation or certification of PCI compliance.

Why it matters

The list an assessor asks for first — and the one most merchants have half-finished.

It’s just an up-to-date list of the card readers you run — detailed enough that anyone can tell one from another and confirm the reader in front of them is the one that’s supposed to be there. That’s what PCI’s 9.5.1.1 asks for.

That last part is the whole point. If you can’t say which serial number belongs in which spot, someone could swap a reader for a tampered one and you’d never know. The list isn’t paperwork for its own sake — it’s what makes catching a swap possible at all.

What goes in the list

One row per physical device.

Here are the columns in the template, in the order the importer reads them. The header names aren’t fussy — serial, serialNumber, serial_number and SN all mean the same thing, and anything it doesn’t recognise is simply ignored — but these are the names the download comes with.

make and model — the manufacturer and model, written the same way every time. Pick one spelling per model and stick to it; “MX925”, “MX 925” and “Verifone MX-925” being three different things in one spreadsheet is the most common reason an inventory stops being usable.
serial — the manufacturer’s serial number, copied from the device, not from the invoice. This is the identifier the whole requirement turns on. Every serial appears once and only once.
asset tag — your own internal label, if you use one. Optional, but it is what your staff will actually say out loud, so it makes the list easier to work with.
kind — the type of device: one of pump, register, atm, kiosk or other. Optional — if you leave it blank or type something it doesn’t recognise, it imports as register, so set it explicitly where the difference matters.
slot label — the fixed spot the device sits in: “Pump 3 — road side”, “Checkout lane 5”, “Bar — service well”. Keep this separate from the serial. A device moves; the position does not. Recording both is what lets you notice that the right position now holds the wrong device.
notes — a free-text column for anything the other columns don’t cover. The importer ignores it, so it never breaks your import; it is there because you will want it.

What is not a column

Three things you might expect to type in — and where they actually live.

Chosen at import

Which site the devices belong to

You pick the location when you run the import, so one file covers one site. Keep a separate file per site and the mapping stays obvious.

Chosen at import

Deployed, or a spare

Also chosen at import time — a file goes in either as devices deployed into positions, or straight into your spares pool. So run two imports per site: one for what is on the floor, one for what is in the cupboard.

From your schedule

How often it’s inspected

Inspection cadence is not set per row. It resolves from an org-wide baseline, overridden per location and then per device only where the risk genuinely differs. Set the baseline once. Not sure what yours should be? The free inspection cadence assessment gives you the written justification 9.5.1.2.1 expects.

The part people miss

Spares are still your devices.

This covers every reader you own — not just the ones plugged in right now.

A reader sitting in a back-office drawer as a spare is still yours, still has a serial, and could still be swapped for a tampered one before it goes into service. Same goes for readers out for repair, ones in transit between sites, and ones you’ve retired but haven’t destroyed yet.

A lot of businesses list the readers on the floor and stop there. Then a spare goes into a lane, its serial doesn’t match anything on the list, and the swap check quietly stops working. Import your spares as their own file, so every reader you own has a record from day one. After that, putting one into service just updates the record it already has — and its history follows it.

Four practical rules

One row per reader, forever. The whole point of a serial is that it has one continuous history. When a reader moves from one lane to another, update its record — don’t add a second row.
Serials come from the hardware. Read them off the device on a walk-around, not from a purchase order. What you bought and what’s actually installed drift apart more than you’d think — and that gap is exactly what you’re trying to catch.
Record who changed what. A spreadsheet has no memory. If it’s your official record, add a dated note next to every edit — because “the list is current” is something you may have to prove, not just say.
Walk it at least once a year. A list you haven’t checked against the actual floor is just a document, not real protection.

Where a spreadsheet runs out

A CSV gets one site through. Then it gets harder.

A spreadsheet can get a single site through an assessment. It gets harder at ten sites — and it stops working the moment someone asks you to prove the file wasn’t edited after the fact. SkimGuard’s business plans include an inspection logbook that holds this same list, follows each reader through deploy, move, repair, spare, and retirement with a history that can’t be changed, and keeps a who-did-what-when record of the kind PCI 10.2 and 10.3 look for — exportable to CSV or PDF for your assessor. It’s included in every plan at no extra cost, and this template uses the exact columns the importer reads, so importing what you’ve already filled in is the whole setup.

Download the template (CSV) PCI inspection log Business pricing

Questions

Common questions.

Do spare terminals have to be in the inventory?

Yes. The rule (9.5.1.1) covers every reader you operate — including spares, ones out for repair, ones in transit, and retired ones you still have. Give each one a record; with this template, import your spares as a separate file so they exist from the start.

What details does PCI DSS 9.5.1.1 ask you to record for each device?

Enough to tell one reader from another and tie it to a place: at least the make, the model, the serial number (or another unique ID), and where it is. Most businesses also add an internal asset tag and the exact spot the reader sits in — that’s what makes a swapped device stand out.

Can I just keep my reader list in a spreadsheet?

The rule doesn’t require any particular tool, and a spreadsheet is a fine place to start for one site. The catch is proof: a spreadsheet can be edited without a trace, so it shows what you believe today — it doesn’t prove what was recorded and when. Businesses with several sites, or an assessor who asks how the record is protected, usually move to a system that keeps a history that can’t be changed.

How is the device inventory related to tamper inspections?

The list is what makes an inspection worth anything. PCI 9.5.1.2 asks you to check readers regularly for tampering and swaps — and you can only spot a swap if you already know which serial belongs in which spot. Build the list first; the inspection routine sits on top of it.

Is this template free?

Yes, free to download, use, modify and share, with no account and no email required.

SkimGuard, Inc. is not a Qualified Security Assessor and does not perform PCI assessments. This template and page are intended to help you document and evidence device-inventory activity under PCI DSS v4.0.1 Requirement 9.5.1.1. They are not an attestation or certification of PCI compliance and do not cover the other requirements in your cardholder-data environment. Your compliance is assessed by your QSA or acquirer.