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.1 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 payment-terminal inventory and inspection subsystem, not logging across the whole cardholder-data environment.

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