An audit-ready, tamper-evident trail for your payment devices.

An audit log is only worth having if it can be trusted. If a record can be edited or deleted after the fact — even by an administrator — it proves nothing. PCI DSS v4.0 Requirement 10 exists for exactly this reason: capture what happened (10.2) and protect that record from modification (10.3). SkimGuard applies both to everything that happens to your payment devices.

What gets logged — Requirement 10.2

Requirement 10.2 asks an audit log to capture enough to reconstruct who did what. SkimGuard writes an entry for every device and inspection action — a device acquired, deployed, moved, sent for service, returned or decommissioned; an inspection recorded; a schedule changed; a permission-checked action refused. Each entry carries:

• Who — the actor's identity, their role, and whether they held privileged access.
• What — the action taken and the affected device, by serial number.
• When — a trustworthy server timestamp, not a client-supplied one.
• Where — the origin: source IP, app version and platform.
• Outcome — success or failure, so denied and unauthorized attempts are captured too, not only completed actions.

Capturing failed and invalid attempts is a specific expectation of Requirement 10.2 — a blocked attempt to alter a device record is often the more interesting event than a routine successful one.

How it's protected — Requirement 10.3

Requirement 10.3 asks that audit logs are protected from modification and that read access is limited to those with a need. SkimGuard's records are:

• Append-only — there is no edit or delete path on a written audit record; it can't be altered or backdated after the fact.
• Mirrored to a write-once (WORM) store — a retention-locked copy is held separately, so the trail survives even if the live data is tampered with.
• Access-scoped — the records are readable by ops and the owning business only, not the world.

Cardholder data stays out of the log — Requirement 3.2

Free-text inspection notes are convenient, and convenient fields are exactly where a card number can accidentally end up. SkimGuard runs a PAN-redaction pass over free-text before anything is stored, so a primary account number pasted into a note doesn't become part of the retained record — keeping the audit trail useful without turning it into a place cardholder data is stored.

Ready for the assessor — export

The device inventory audit, the inspection log and the training records export to CSV or PDF in one tap, so you can hand a QSA or acquirer the who/what/when/where/outcome record for your payment devices without reconstructing it by hand from screenshots and spreadsheets.

• 10.2 — Capture audit logs. Every device and inspection action logged with who, what, when, where (source IP / app version / platform), actor role, affected device, and outcome.
• 10.2 — Log failed & invalid attempts. Denied and unauthorized attempts are recorded, not just successful actions.
• 10.3 — Protect from modification. Append-only and immutable, mirrored to a write-once (WORM) retention-locked store.
• 10.3 — Limit read access. Records readable by ops and the owning business only.
• 3.2 — Don't store cardholder data you don't need. PAN redaction on free-text notes before storage.
• Scope: the POI-device inventory and inspection subsystem — not logging across the whole cardholder-data environment.

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