PCI DSS is one of the few frameworks that gives you hard numbers for logging. Requirement 10 says which events you log, which fields every event carries, how you protect the logs, how often you review them and how long you keep them. Since 31 March 2025 the review part must also be automated. This guide walks through Requirement 10 of PCI DSS v4.0 and what it means for your log setup.
Not legal advice
This guide summarises PCI DSS v4.0.1. Your Qualified Security Assessor (QSA) and the official standard from the PCI Security Standards Council decide what applies to your cardholder data environment (CDE).
What to log: Requirement 10.2
Audit logs must be enabled and active on every system component in the CDE (10.2.1). They must capture seven types of events:
| Requirement | Event |
|---|---|
| 10.2.1.1 | Every individual user access to cardholder data |
| 10.2.1.2 | Every action by anyone with administrative access, including root |
| 10.2.1.3 | Every access to the audit logs themselves |
| 10.2.1.4 | Invalid logical access attempts |
| 10.2.1.5 | Changes to identification and authentication: new accounts, privilege changes, credential changes |
| 10.2.1.6 | Starting, stopping or pausing the audit logs |
| 10.2.1.7 | Creation and deletion of system-level objects |
Each event records at least (10.2.2): the user, the type of event, the date and time, success or failure, the origin of the event and the affected data, component or resource. Structured logs make that much easier to prove; see structured logging.
Protect the logs: Requirement 10.3
- Read access only for people with a job-related need (10.3.1).
- Logs protected against changes (10.3.2) and backed up promptly to a central log server or media that is hard to alter (10.3.3).
- File-integrity monitoring or change-detection on the logs, so changes to existing log data raise an alert (10.3.4).
Review the logs: Requirement 10.4
Security events, logs of CDE components and logs of security-critical systems (firewalls, IDS/IPS, authentication servers) are reviewed at least once a day (10.4.1). Since 31 March 2025, automated mechanisms must do these reviews (10.4.1.1): reading logs by hand is no longer enough. Logs of other system components are reviewed at a frequency your risk analysis sets (10.4.2), and exceptions found in a review are followed up (10.4.3).
In practice that means a SIEM or log platform with detection rules that run continuously and raise an alert, plus evidence that someone handles those alerts.
How long to keep logs: Requirement 10.5
Keep audit logs for at least 12 months, of which at least the most recent 3 months are immediately available for analysis (10.5.1). That is one of the strictest fixed numbers among the common frameworks. See log retention by regulation for the comparison.
Time sync and control failures: 10.6 and 10.7
All system clocks are synchronised to a trusted time source (10.6), so events from different systems line up. Failures of critical security controls, including the logging itself, are detected, alerted and handled promptly (10.7). A log source that goes silent is an incident, not a detail.
How LogPulse fits Requirement 10
| Requirement | In LogPulse |
|---|---|
| 10.2 collect events | Agent, syslog, OTLP and cloud integrations send logs to one place; parsers turn them into fields such as user, action, outcome and source. |
| 10.3.1 read access | Roles limit which indexes a user can search; on Enterprise also SSO with SAML or OIDC. |
| 10.3.3 central copy | Logs are stored centrally in the EU; a stream pipeline can also send a copy to your own S3-compatible storage. |
| 10.4.1.1 automated review | Detection rules from the Detection Hub run continuously and raise notables with a risk score. |
| 10.5.1 12 months | Enterprise retention is set in your contract; on other plans keep the 12 months in your own storage via a stream pipeline. |
| 10.7 failures | Data health flags log sources that go silent or drop far below their normal volume. |
What LogPulse does not do
LogPulse is not a file-integrity monitoring tool for 10.3.4 or 11.5.2: use a FIM tool and send its events to LogPulse. LogPulse supports your PCI DSS programme and produces evidence; it is not itself a PCI DSS certification and does not replace your QSA.