PCI DSS 10.2.1 requires audit logs that capture access to cardholder data, administrative actions, access to the logs, invalid access attempts, credential changes, log start and stop events, and creation or deletion of system objects. 10.2.2 sets the fields for each event, and 10.5.1 requires 12 months of history. This is not legal advice.
Events to capture
Per the SAQ D text, audit logs are enabled and active for all system components and cardholder data, and capture:
- All individual user access to cardholder data (10.2.1.1).
- All actions by anyone with administrative access, including interactive use of application or system accounts (10.2.1.2).
- All access to audit logs (10.2.1.3).
- All invalid logical access attempts (10.2.1.4).
- Changes to identification and authentication credentials, including new accounts, privilege elevation, and changes to admin accounts (10.2.1.5).
- Initialization of new audit logs and starting, stopping or pausing of existing ones (10.2.1.6).
- Creation and deletion of system-level objects (10.2.1.7).
Fields per event
10.2.2 lists: user identification, type of event, date and time, success or failure indication, origination of event, and the identity or name of the affected data, component, resource or service.
An example record shape
| Field | Example value |
|---|---|
| user_id | An internal ID, not a card number |
| event_type | login_failed, admin_role_granted |
| timestamp | ISO 8601 with time zone |
| outcome | success or failure |
| source | IP address or service name |
| resource | The record, endpoint or service affected |
Never write full card numbers, CVV or other sensitive authentication data into logs. See our post on SAD after authorization. Where PAN must appear, 3.5.1 expects it to be unreadable wherever stored, and the SAQ D text lists audit logs among the places it applies.
Protect and review the logs
| Need | Requirement |
|---|---|
| Limit read access to those with a job-related need | 10.3.1 |
| Protect from modification | 10.3.2 |
| Back up promptly to a secure central location | 10.3.3 |
| File integrity or change detection on logs | 10.3.4 |
| Review key logs at least daily | 10.4.1 |
| Keep 12 months, most recent three immediately available | 10.5.1 |
Developer checklist
- Use one structured logging format across services.
- Log security events from the application, not only the infrastructure.
- Scrub card data from messages and stack traces.
- Ship logs off the host quickly.
- Test that an invalid login produces a record.
Quick check
Do I log every read of every record?
10.2.1.1 asks for all individual user access to cardholder data. Scope depends on where that data is, so check with your assessor.
How long must logs be kept?
At least 12 months, with at least the most recent three months immediately available for analysis.
On Safeguard: compliance and evidence automation can collect and retain evidence of controls, though your application logs themselves come from your own systems. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
