PCI DSS Requirement 10: logging and monitoring

By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS

v4.0 quietly ended the era of the daily manual log review. Automated mechanisms are now required — which is an acknowledgement that nobody was reading them anyway.

What must be logged

• All individual user access to cardholder data (10.2.1.1).
• All actions taken by any individual with administrative or root privileges (10.2.1.2).
• Access to all audit logs (10.2.1.3) — logging the log readers.
• Invalid logical access attempts (10.2.1.4).
• Changes to identification and authentication credentials, including account creation and privilege elevation (10.2.1.5).
• Initialisation, stopping, or pausing of audit logs (10.2.1.6) — the event an attacker generates when covering tracks.
• Creation and deletion of system-level objects (10.2.1.7).

What each entry must contain

Requirement 10.2.2 sets the minimum fields: user identification, type of event, date and time, success or failure indication, origination of the event, and the identity or name of the affected data, system component, resource, or service. A log line missing the user identity is close to useless for investigation, which is why Requirement 8's unique IDs are a prerequisite here.

Requirement 10.6 covers time synchronisation — systems synchronised to consistent, accurate time using recognised sources, with time data protected and changes restricted. Correlating an incident across systems whose clocks disagree by minutes is a genuinely miserable exercise.

Protection and retention

Audit logs must be protected from destruction and unauthorised modification (10.3): read access limited to those with a job-related need, protection against modification with any change generating an alert, and prompt backup to a secure, central, internal log server or media that is difficult to alter.

Retention under 10.5.1 is at least twelve months, with a minimum of three months immediately available for analysis. "Immediately available" means queryable now, not restorable from cold storage in a day — a distinction worth checking against your actual log platform tiering, since cost-driven archival policies often quietly breach it.

The move to automated review

Requirement 10.4.1 requires daily review of security events, logs of critical system components, and logs of servers and system components performing security functions. Requirement 10.4.1.1, added in v4.0, requires that automated mechanisms perform those reviews.

This is a sensible codification of reality — daily manual review of high-volume logs was a control that existed on paper and rarely in practice. A SIEM, log analytics platform with alerting rules, or equivalent tooling now satisfies the requirement, and the evidence becomes the alerting configuration and the response record rather than a signed review log.

Requirement 10.7 covers failures of critical security control systems — detection, alerting, and prompt response. In v4.0 this applies to all entities rather than service providers alone, and the list of in-scope systems includes network security controls, IDS/IPS, anti-malware, logging mechanisms, and segmentation controls. Logging that silently stops is a control failure you must detect.