An audit-ready PCI device inspection log your staff will actually use.

PCI DSS v4.0 asks merchants to keep a current list of their payment devices and to periodically inspect those devices for tampering and substitution — then be able to show an assessor the record. On paper that means clipboards, spreadsheets and a binder nobody can find at audit time.

SkimGuard turns that into a phone-based logbook. Staff record each inspection from the SkimGuard app right at the terminal, every record is stamped with the device, location, inspector and time, and the whole log exports to CSV or PDF in one tap. It helps you document and meet PCI DSS v4.0 Requirement 9.5 — the POI-device tamper-and-substitution controls at 9.5.1.1, 9.5.1.2, 9.5.1.2.1 and 9.5.1.3 — and it keeps an immutable audit trail of every device and inspection action of the kind Requirements 10.2 and 10.3 call for. It's included free in both the Handheld and Automated B2B tiers.

Master device inventory — Requirement 9.5.1.1

Track every payment device by make, model and serial number, including spares held in stock. Every movement is logged with a full audit trail of who changed what and when:

• Deployed to a location and assigned to a lane or counter.
• Moved between locations.
• Sent out for service and later returned — with an evidence trail for the time it was off-site.
• Decommissioned and retired from the fleet.

That gives you the maintained, current device list PCI DSS 9.5.1.1 expects, and answers the “where was this device?” question a substitution check depends on.

Inspection log — Requirement 9.5.1.2

Staff record each physical inspection from the phone against a structured tamper checklist:

• Security seals and tamper-evident labels intact.
• Serial number on the device matches the record.
• Casing, ports and cabling undisturbed — no added wiring or extra device.
• No skimming overlay, shim or hidden camera on the card slot or keypad.

Each inspection captures a pass / fail / suspicious outcome, free-text notes and photos, alongside the device identity, location, inspector and timestamp. Records are append-only — they can't be quietly edited or backdated — so the log is tamper-evident and stands up as evidence.

Risk-based frequencies — Requirement 9.5.1.2.1

You don't have to inspect every terminal on the same schedule. Set a custom inspection frequency justified by a documented targeted risk analysis — an unattended outdoor kiosk or fuel pump inspected far more often than a terminal behind a staffed counter — so your schedule matches the risk analysis you can show an assessor. Not sure where to start? Our free inspection schedule wizard estimates a cadence from your environment in about a minute (an educational guide, not a formal TRA).

In SkimGuard a schedule is the risk analysis. Each one bundles the frequency (daily, weekly, biweekly, monthly, quarterly, or a custom interval), the risk factors that justify it, a written justification, a photo policy, and a grace window before an inspection counts as overdue. That pairing of a chosen frequency with its documented rationale is exactly what 9.5.1.2.1 asks for.

Setting it up — one assessment, inherited everywhere

SkimGuard resolves a device's schedule from the most specific rule that applies, so you configure once and override only by exception:

1. Business baseline. Do one overall risk assessment for the business and set it as the baseline. Every location inherits it automatically — no per-site setup required to get started.
2. Per-location override. Where a site's risk differs (an unattended forecourt versus a staffed counter), give that location its own schedule; it supersedes the baseline for that location only.
3. Per-device override. When you deploy a specific terminal you can hand it its own schedule; otherwise it takes the location's, and failing that the business baseline.

Owners set the baseline and location schedules in the SkimGuard business portal; staff just record the inspections. From then on each recorded inspection advances the next-due date automatically — you never hand-maintain a calendar — and an overdue terminal raises a reminder and is reflected in the location's status.

Staff training records — Requirement 9.5.1.3

Record that on-site staff were trained to spot signs of tampering, to verify the identity of third-party service technicians before granting access to a device, and to know how to start incident response if something looks wrong. The training record lives alongside the inventory and the inspection log, so the whole 9.5.1 control set is in one place.

Immutable audit trail — Requirements 10.2 & 10.3

Every device and inspection action — a device deployed or moved, an inspection recorded, a schedule changed, even a denied attempt — is written to an append-only audit trail. Each entry records who did what, when, from where (source IP, app version and platform), the actor's role, and the outcome:

• Append-only and immutable — records can't be edited, backdated or deleted after the fact.
• Write-once (WORM) copy — the trail is mirrored to a locked, retention-protected log store, so it survives even if the live data is tampered with.
• Captures failures too — denied and unauthorized attempts are logged, not just successful actions.
• Card numbers are redacted from free-text notes before anything is stored.

That is the who / what / when / where / outcome evidence PCI DSS v4.0 Requirement 10.2 asks an audit log to capture, protected from modification the way Requirement 10.3 asks — see the payment-device audit trail for the full detail. Scope note: this is the audit trail for your POI-device inventory and inspection activity — one part of your overall Requirement 10 logging program, not a replacement for logging across your entire cardholder-data environment.

Reminders, alerts and export

• Automated reminders (push + email) when an inspection is overdue against its schedule.
• A failed inspection triggers an incident alert so a suspected tamper doesn't sit unnoticed.
• One-tap CSV / PDF export of the inspection log or the master inventory for your QSA or acquirer.
• A public “readers physically inspected on <date>” trust signal on your SkimGuard business page.

• 9.5 — Protect POI devices from tampering & substitution. The parent control, delivered end-to-end by the inventory, inspection log, risk-based frequencies and training below.
• 9.5.1.1 — Maintain a device list. Master inventory by make, model and serial (spares included) with a full movement audit trail.
• 9.5.1.2 — Periodically inspect device surfaces. Append-only inspection records with a tamper checklist, pass/fail/suspicious outcome, notes and photos.
• 9.5.1.2.1 — Frequency defined by targeted risk analysis. Per-location default frequency with per-terminal overrides.
• 9.5.1.3 — Train staff to detect tampering. Training records covering tamper awareness, technician verification and incident response.
• 10.2 — Capture audit logs of actions. Every device and inspection action logged with who/what/when/where and outcome, including denied attempts.
• 10.3 — Protect the audit trail. Append-only and immutable, mirrored to a write-once (WORM) retention-locked log store. Scope: POI-device & inspection activity, not whole-CDE logging.

See the full B2B feature set and current pricing on the for-business page.