PCI DSS 10.3.1: Read access to audit logs files is limited to those with a job-related need
PCI DSS v4.0.1 control 10.3.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.3.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.3
Read access to audit logs files is limited to those with a job-related need.
Summary
Only people whose job needs it can read the audit logs.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 10.3.1 | Interview system administrators and examine system configurations and privileges to verify that only individuals with a job-related need have read access to audit log files. |
Read access, specifically. 10.3.2 covers modification; this one covers looking, and it is the weaker-sounding half that entities most often skip, because logs feel like an operational resource rather than sensitive data. They are not: audit logs describe who did what and when across the environment, and they frequently contain account names, source addresses and enough detail to plan an attack. The procedure interviews administrators and examines privileges, so the assessor compares the access list against a job-need argument you have to be able to make. It works with 10.2.1.3, which records the reads that this control permits.
What to prepare
- The list of everyone with read access to logs, at the host, at the collector and in the analysis tool.
- The job-related need for each, by role rather than by person.
- Service accounts and integrations that read logs, which are access too.
How to implement it
1. Restrict at the collector, which is where the interesting copy lives. Host-level permissions matter less once everything is forwarded, because the aggregated store is the one worth reading.
2. Scope by role in the analysis tool. A SIEM that grants everyone visibility of everything is the common finding, and most tools support restricting by source or index.
3. Justify by role and keep it short. "The security operations team investigates incidents" is a job-related need. "Engineering finds it useful" invites the question this control asks.
4. Review it alongside 7.2.4. Log access drifts the same way any other access does, and it is rarely on the list being reviewed.
Where this commonly fails
- Broad read access in the SIEM because restricting it was more work at setup time.
- Developers with log access granted for a production incident and never removed.
- Only host-level permissions considered, while the aggregated store is open.
- Integrations reading logs with no owner and no stated need.
Related controls
Others in section 10.3:
| Control | What it requires |
|---|---|
| 10.3.2 | Audit log files are protected to prevent modifications by individuals |
| 10.3.3 | Audit log files, including those for external-facing technologies… |
| 10.3.4 | File integrity monitoring or change-detection mechanisms is used on audit logs to ensure… |
← 10.2.2 · All controls · 10.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.