PCI DSS logging requirements sit in Requirement 10. In plain terms: record every access to system components and cardholder data, tie each event to an individual user, review the logs every day with automated tools, protect them from tampering, and keep the history for at least 12 months, with the most recent three months available for immediate analysis. This guide explains each part, shows where assessors find gaps, and covers the related questions merchants ask about log retention, receipt truncation and stored payment data.
TL;DR
- Log everything that touches cardholder data or the systems around it, and link each event to a named individual, not a shared account.
- Review logs daily with automated mechanisms. Manual reading alone rarely holds up in an assessment.
- Retain 12 months of audit history. Keep the latest 3 months instantly searchable, not in slow cold storage.
- Protect the logs with centralized storage, restricted access and integrity monitoring.
- Smaller scope means fewer logs to manage. Using a compliant processor with tokenization and a hosted checkout shrinks what you must log yourself.
Table of Contents
- Why Requirement 10 exists
- What changed with PCI DSS v4.0.1
- What you must log
- Time synchronization
- Daily review and automated monitoring
- PCI log retention: 12 months, 3 months immediately available
- Protecting the logs
- Related questions: truncation, masking and stored payment data
- Where assessments go wrong
- Our perspective: log less by handling less
- A practical Requirement 10 checklist
- How PaySec helps with compliance
- FAQ
- Sources
Why Requirement 10 exists
Logs are how a business answers the question every breach raises: what happened, to which systems, and when. PCI Security Standards Council guidance reproduced by AWS states that Requirement 10 mandates comprehensive audit logging of all access to system components and cardholder data, and that logging and monitoring are essential for detecting, investigating and responding to incidents in cardholder data environments. Without usable logs, you cannot establish the scope of a compromise, find the root cause, or show that your other security controls worked.
That is why assessors treat logging as evidence. Every other control you claim, from access restrictions to file-integrity monitoring, leaves a trail. Requirement 10 is where that trail lives.
The standard has also moved from a yearly exercise to a daily one. The PCI Council has described the shift to v4.x as a move toward continuous security processes rather than a one-time checkbox. Logging is the clearest example.
What changed with PCI DSS v4.0.1
PCI DSS v4.0 introduced new requirements, and many were future-dated. As of March 31, 2025, 51 future-dated requirements became mandatory for all entities, and assessors now expect full adherence. If you last reviewed your logging setup under v3.2.1, three changes matter most:
- Automated daily review. Requirement 10.4.1.1 calls for automated mechanisms to perform daily log reviews, replacing the older habit of relying only on a person reading logs each morning.
- Clearer wording. The Council's summary of changes updated the Requirement 10 title to focus on audit logs, system components and cardholder data, and replaced the term "audit trails" with "audit logs."
- More focus on e-commerce. Payment pages now carry their own monitoring expectations, including Requirements 6.4.3 and 11.6.1, which the Council points merchants to when securing e-commerce environments.
The standard's wording is stable, so the practical work is making sure your tooling and your written policy match what is actually running.
What you must log
Requirement 10 begins with a simple idea: audit logs must exist for all system components in the cardholder data environment, and each event must be attributable to an individual. Shared admin logins break that chain, so unique IDs come first.
The standard asks you to capture, at minimum, these categories of activity:
- All individual access to cardholder data. Who viewed, exported or changed it.
- Actions by anyone with administrative privileges. Root and admin sessions are the highest-risk activity on any system.
- Access to the audit logs themselves. Reading or changing the record is itself an event.
- Failed logical access attempts. Repeated failures are an early sign of credential attacks.
- Changes to identification and authentication. New accounts, privilege escalations, password and MFA changes.
- Start, stop or pause of audit logging. Switching off logs is a classic step in covering tracks.
- Creation and deletion of system-level objects. New services, scheduled tasks and similar changes.
For each event, the entry must show enough detail to reconstruct what happened. Plan for these fields in every log line:
| Field | What it answers |
|---|---|
| User identification | Who did it |
| Type of event | What was done |
| Date and time | When it happened |
| Success or failure | Whether it worked |
| Origination of event | Where it came from (host, IP, application) |
| Identity or name of affected data, component or resource | What was touched |
One rule saves a lot of trouble: logs must never contain full card numbers, sensitive authentication data or other secrets. If an application dumps a full PAN into a debug log, the log itself becomes part of your PCI scope. Check verbose and error logging in particular.
Time synchronization
Logs from ten systems are only useful if their clocks agree. Requirement 10 includes time-synchronization controls so events from firewalls, servers, applications and databases can be lined up into one timeline during an investigation. Point every system component at the same trusted time sources, restrict who can change time settings, and log changes to them. When a breach investigation starts, a 90-second drift between two servers can turn a clean sequence into a guess.
Daily review and automated monitoring
The Council's own guidance, Effective Daily Log Monitoring, explains that PCI DSS rests on defense in depth, and that log monitoring is one of its detective measures. Daily review exists because the gap between a compromise and its discovery is where most of the damage happens.
In practice, v4.0.1 expects this:
- Automation does the first pass. Tools collect, parse and correlate logs, then flag anomalies. Assessors generally look for this kind of setup, typically a SIEM or a log-management platform with alerting, when judging whether daily review is genuinely happening.
- Humans handle the exceptions. Someone with the authority to act must follow up on alerts, and you need a record that they did.
- Some systems need explicit daily attention. Security controls, critical systems and components that store, process or transmit cardholder data are the usual focus of the review scope.
Manual review alone is rarely sufficient in modern, complex environments, and automated log harvesting, parsing and SIEM tooling is the standard expectation for demonstrating that daily review is real. Keep evidence: alert rules, review reports, tickets opened from alerts and the sign-offs showing someone looked.
A worked example: a 12-location restaurant group
Take a restaurant group with point-of-sale terminals at each site, a back-office server and an online ordering platform. A reasonable setup:
- Each terminal and server sends logs to one central collector.
- The collector normalizes time stamps and tags events by location and user.
- Alert rules flag admin logins outside business hours, repeated failed logins and any change to logging settings.
- A manager reviews the daily exception report and opens a ticket for anything unusual.
- The collector archives events for 12 months, with the latest three months in the searchable index.
This is an illustration of the pattern, not a statement about any specific merchant.
PCI log retention: 12 months, 3 months immediately available
This is the most searched part of the topic, and the most misread. The rule in Requirement 10.5.1 is that audit log history must be retained for at least 12 months, with at least the most recent three months immediately available for analysis.
Two separate tests apply:
| Test | Requirement | What passes |
|---|---|---|
| Retention | 12 months of audit log history | Logs exist and can be produced for any day in the past year |
| Availability | Last 3 months immediately available | Logs are searchable now, without a restore job |
The difference matters. Logs moved to cold storage that take hours or days to retrieve satisfy the 12-month retention test but fail the immediate availability test. If your archive tier needs a restore ticket, the last three months must live somewhere faster.
Check the setting, not just the policy
A common pitfall is a mismatch between the written policy and the tool. Assessors often find a policy that promises 12 months while the logging platform's default is significantly shorter. The fix is quick:
- Open the retention setting in every logging platform, cloud service and appliance.
- Compare it with your written policy.
- Test it by pulling a log from 11 months ago and one from last week.
- Record the test result and date as evidence.
If your business also has other retention duties, such as tax, employment or contract rules, those are separate obligations. PCI sets a floor for audit logs, not a ceiling, and your counsel or accountant can tell you about longer periods that apply to you.
Protecting the logs
Logging is only worth something if the records can be trusted. Attackers and malicious insiders often try to wipe or edit logs to hide what they did. The Council's monitoring guidance stresses protecting logs from tampering through centralized repositories and file-integrity monitoring.
Build these protections in from the start:
- Centralize. Ship logs off the originating system in near real time, so wiping a server does not wipe the evidence.
- Restrict access. Limit who can view logs to people with a job-related need, and limit write and delete rights further.
- Monitor integrity. Use file-integrity monitoring or change-detection so any edit to a log triggers an alert.
- Back up promptly. Copy logs to a separate, protected location.
- Log the logging. Access to the logs and any change to logging configuration are themselves auditable events.
The same discipline applies in any regulated record-keeping setting. Compliance platforms in other fields, for example the security approach described by an AML compliance platform, also rest on protecting audit trails from alteration, which shows how widely the principle carries.
Related questions: truncation, masking and stored payment data
Searchers who ask about logging usually ask about what card data may appear where. Keep these rules of thumb in mind.
Do not store what you do not need. Sensitive authentication data, such as the card security code and full track data, may not be stored after authorization. That includes inside logs, screenshots, emails and support tickets.
Truncation is not the same as masking. Truncation permanently removes part of the card number, so the stored value cannot be rebuilt. Masking hides digits on a screen or receipt while the full number may still exist elsewhere. The long-standing display convention keeps no more than the first six and last four digits, and many receipts show fewer. Your processor or acquirer can confirm what your receipts must show, and U.S. state and federal receipt laws can be stricter than the card brand rules.
Tokenization shrinks the problem. A token replaces the card number with a meaningless value that is useless if stolen. Systems that only handle tokens usually have a much smaller PCI footprint, and so fewer logs to retain, review and defend.
Payment data retention should have a business reason. Keep card data only as long as you need it for a stated purpose, then delete it on a schedule you can prove. Retention of audit logs is a different matter: those are the records about access, not the card data itself.
Where assessments go wrong
Based on the patterns in the research above, these are the gaps worth closing before an assessor arrives:
- Retention set by default. The platform keeps 30 or 90 days, while the policy says 12 months.
- Cold storage for everything. Nothing is searchable on demand.
- Manual-only review. A spreadsheet checklist replaces automated alerts.
- Shared accounts. Events cannot be tied to a person.
- Logs with card data. Debug output leaks PANs into the log system.
- Unprotected logs. Admins can edit or delete the record they are reviewed against.
- Unsynchronized clocks. Events cannot be ordered across systems.
A quarterly self-check against this list takes an hour and prevents most findings.
Our perspective: log less by handling less
We process payments for merchants in SaaS, restaurants, eCommerce, healthcare and CBD retail, and the same pattern repeats. Businesses that handle raw card data themselves inherit a large logging program: more systems in scope, more events to review, more storage to defend. Businesses that route card data through a compliant processor inherit far less.
That is why we build around PCI DSS Level 1 and SOC 2 compliance, tokenization and a dedicated merchant account. Card data goes to the compliance-focused environment, and your own systems see tokens. The Requirement 10 work you still own is smaller and easier to prove. Our PCI scope reduction guide shows how to document what sits outside your scope, and our PCI compliance checklist for small businesses turns the standard into steps a owner-operator can follow.
Our advice: decide first what you can take out of scope, then build logging for what remains. Reporting matters too. Real-time, detailed transaction reporting gives finance and operations teams a clear view of activity, and it complements the security logs your compliance team keeps.
— PaySec Marketing Team
A practical Requirement 10 checklist
Use this as a working list for your next review:
- Inventory every system component in or connected to your cardholder data environment.
- Confirm each one produces audit logs with user, event, time, outcome, origin and affected resource.
- Replace shared logins with individual accounts.
- Send logs to a central, access-controlled repository.
- Synchronize time across all components.
- Configure automated daily review with alerts, and assign who responds.
- Set retention to 12 months and verify the last three months are searchable instantly.
- Turn on integrity monitoring for the log store.
- Check that no log contains full card numbers or sensitive authentication data.
- Save evidence: screenshots of settings, alert rules, review reports and test retrievals.
For the wider picture of how card data is protected across a business, our guide to how payment data security works for business owners and our fraud protection guide cover the controls that sit alongside logging.
How PaySec helps with compliance
PaySec offers PCI compliance assistance that is simplified and included, along with enterprise-grade security and encryption for payment data. Our merchant services cover in-store processing, an eCommerce gateway, recurring billing, fraud prevention and more, with transparent pricing, no long-term contracts and no monthly minimums. See how Network Offset pricing works, or review the pricing options.
FAQ
How long do PCI logs need to be kept?
Audit log history must be kept for at least 12 months. The most recent three months must be immediately available for analysis, meaning searchable without a restore process. Any other retention rules that apply to your business are separate from this PCI floor.
Do I need a SIEM to meet PCI logging requirements?
PCI DSS asks for automated mechanisms to perform daily log reviews, and assessors commonly expect centralized log management with alerting to show that. A SIEM is the usual way to do it, though the standard cares about the outcome: logs collected, reviewed daily, and exceptions followed up with evidence.
Do small merchants have to follow Requirement 10?
Requirement 10 applies to system components in your cardholder data environment. Merchants that outsource card handling and keep card data off their own systems have far fewer components in scope. Your validation path and questionnaire depend on how you accept payments, so confirm yours with your processor or a qualified assessor.
Can card numbers appear in logs?
No full card numbers or sensitive authentication data should appear in logs. Check debug, error and application logs for leaks, and use tokens or truncated values wherever a reference to a card is needed.
What is the difference between retention and immediate availability?
Retention is how far back your logs go: 12 months. Immediate availability is how fast you can search the latest three months of them. Archived logs that take hours or days to restore meet the first but not the second.
Sources
- PCI DSS Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
- PCI DSS 10.5.1: Keep twelve months of audit logs
- Effective Daily Log Monitoring, PCI Security Standards Council
- Now Is the Time to Adopt the Future-Dated Requirements of PCI DSS v4.x
- Coffee with the Council: Guidance for PCI DSS E-commerce Requirements
- PCI DSS v3.2.1 to v4.0 Summary of Changes
- Logging, Monitoring, and Incident Response, AWS Prescriptive Guidance
- Security overview, AML Guard