PCI DSS audit logging requirements (10.2) and how to satisfy them
PCI DSS v4.0 Requirement 10.2 requires audit logs to support the detection of anomalies and suspicious activity around cardholder data. This page covers exactly what that means for audit logging, what a QSA asks for as evidence during a Report on Compliance, and how AuditRails' hash-chained logs satisfy it.
The control
PCI DSS v4.0 Requirement 10.2: Audit Log Implementation
PCI DSS v4.0
“Audit logs are implemented to support the detection of anomalies and suspicious activity.”
10.2 evidence gets tested alongside 10.3 (log detail requirements) and 10.5 (log integrity and retention) during a Report on Compliance: a QSA checks not just that logs exist, but that they contain the right fields and can't be altered after the fact.
What an auditor asks for
A QSA conducting your Report on Compliance samples cardholder-data-environment logs directly: do they exist for the events Requirement 10.2 lists, do they contain enough detail to investigate an anomaly, and can you show the log itself hasn't been modified. A policy stating logging happens doesn't pass a ROC; a sampled, produceable record does.
Retention requirement
AuditRails retains PCI DSS audit logs for a minimum of 1 year by default, with the most recent 3 months immediately available for analysis. Retention extends automatically if you're also subscribed to a framework with a longer requirement.
What AuditRails captures
Cardholder-data access events are logged with masked/truncated references only, never the primary account number itself, matching how card data belongs in your CDE, not your audit trail.
import { AuditRails } from '@auditrails/node';
const audit = new AuditRails({ apiKey: 'at_live_...' });
await audit.log({
action: 'cardholder.accessed',
actor_id: '...', // required
resource: '...', // required
metadata: {
purpose: '...', // optional
masked: '...', // optional
pan_truncated: '...', // optional
}
});What you hand your auditor
Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof, evidence you can hand directly to your QSA, not a policy claim they have to take on faith.
Common ways teams fail this control
- Logging cardholder-data access but storing the actual PAN in log metadata: this puts your audit-log store back in PCI scope instead of keeping it out, exactly the opposite of what a well-scoped CDE wants.
- No distinction between administrative/privileged access and regular application access. Requirement 10.2 specifically expects privileged actions to be identifiable in the record, not blended in with routine traffic.
- Logs editable by the same administrators the control is meant to hold accountable. Requirement 10.5's integrity expectation needs a record a QSA can trust wasn't altered, not just one that exists.
- Retention shorter than 1 year, or the most recent 3 months not immediately available for analysis, both are explicit, checkable requirements a QSA will sample against.
- No consistent actor_id across the systems that touch the cardholder data environment, making it impossible to trace a single actor's activity across the full CDE during an investigation.
Frequently asked questions
Does AuditRails make us PCI DSS compliant?
No single tool does. AuditRails gives you the tamper-evident audit-logging evidence Requirement 10 needs: the rest of your PCI DSS scope (network segmentation, vulnerability management, access control, the full Report on Compliance) is separate.
Does AuditRails store cardholder data?
No. Log metadata should only ever contain masked or truncated references, never a raw primary account number: our own action catalog for this framework is built around exactly that (a masked/truncated field, never the PAN). Logging raw cardholder data yourself would put your log store back in PCI scope, which defeats the point.
How long do I need to keep PCI DSS audit logs?
A minimum of 1 year is what AuditRails retains by default for this framework, with the most recent 3 months immediately available for analysis as Requirement 10.5.1 expects.
Can I verify the logs haven't been tampered with, independent of AuditRails?
Yes: we publish an open-source CLI that independently recomputes the hash chain from an export. It doesn't call our API or trust our infrastructure.
This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.