Keeping track of who is accessing your systems and data is a critical part of any security program. Requirement 10 of the PCI DSS covers logging and monitoring controls that allow organizations to detect unauthorized access attempts and track user activities. In the newly released PCI DSS 4.0, Requirement 10 has seen some notable updates that expand logging capabilities and provide more flexibility for merchants and service providers.
In this post, we’ll break down the key changes to Requirement 10 from PCI DSS 3.2.1 to PCI DSS 4.0. We’ll cover the new sub-requirements added, clarify changes in language and intent, and explain how the updates aim to improve logging effectiveness for regulated entities.
Whether you’re currently compliant under PCI DSS v3.2.1 or preparing for your first PCI DSS v4.0 assessment, understanding these changes to Requirement 10 will help you strategize your implementation approach. Read on for a comprehensive look at what’s new and different in PCI DSS v4.0 when it comes to logging and monitoring. check out our comprehensive guide on the “12 requirements of PCI DSS.”
| Requirement | v3.2.1 (10.5.1 – 10.5.5) | v4.0 (10.3.1 – 10.3.4) | Changes |
|---|---|---|---|
| Access Controls | "Limit viewing of audit trails" to those with a need. | Tightens the language to specifically "read access", emphasizing that those with a need should only see, not modify. | Increased clarity, emphasis on viewing. |
| Protecting Logs | Logs must be protected from "unauthorized modifications". | Maintains the requirement, but removes specific methods (access control, physical/network segregation) | Less prescriptive, allows flexibility in implementation. |
| Backup Emphasis | "Promptly back up" to hard-to-alter location | Identical requirement | No changes. |
| External Tech Logs | Logs from external-facing tech must go to an internal log server/media. | Maintains the core concept. | No changes. |
| Integrity Monitoring | File-integrity or change-detection monitoring required for log protection. | Identical requirement. | No changes. |
| Testing Procedures | Broad testing, looking at system settings, monitored files, etc. | Testing aligns with the slightly narrowed focus (read access) but retains the emphasis on practical verification. | Minor adjustments to testing scope. |
In PCI DSS v4.0, audit log security principles are mostly unchanged. Key updates include:
- Emphasizing “read-only” access.
- More flexibility in log protection.
- Testing procedures align with updated access language.
| Requirement | v3.2.1 (10.6.1 – 10.6.3) | v4.0 (10.4.1 – 10.4.3) | Changes |
|---|---|---|---|
| Core Daily Review | Must review security events, logs of critical components, systems with cardholder data (CHD/SAD), and security systems (firewalls, etc.) daily. | Split the requirements: 10.4.1 focuses on those daily items, 10.4.2 covers everything else. | Increased clarity separates high-priority log review. |
| Other Logs | Review "periodically" based on the company's risk assessment | Periodic review is still required but now explicitly mentioned in Requirement 10.4.2 | Makes periodic review a distinct requirement. |
| Exception Handling | Follow-up on anomalies and exceptions. | Identical requirement (10.4.3). | No changes. |
| Automation Emphasis | Mentions both manual and automated log review tools. | v4.0 mandates the use of "automated mechanisms" for daily reviews. | Strong shift towards automation. |
| Testing Procedures | Review policies and procedures, observe processes, interview personnel. | Similar emphasis on policies and procedures. | No major changes. |
PCI DSS v4.0 changes log reviews by:
- Splitting daily and periodic reviews.
- Mandating automated tools for daily critical log reviews.
- Aligning periodic reviews with the organization’s risk profile.
| Requirement | v3.2.1 (10.4, 10.4.1 – 10.4.3) | v4.0 (10.6.1 – 10.6.3) | Changes |
|---|---|---|---|
| Core Requirement | Systems must be time-synchronized using a reliable technology. | Identical principle. | No changes. |
| System Configuration | Outlines specific best practices (central time servers, external sources based on Atomic Time/UTC, peer syncing). | Largely retains the same elements as prescriptive settings within the requirement itself. | More codified approach. |
| Time Source Protection | Suggests using encryption, access lists for added protection of internal time servers. | No longer optional. v4.0 mandates restricting access to time data AND logging any changes to time settings. | Significantly increased security requirements. |
| Testing Procedures | Focuses on configuration checks, reviewing processes, etc. | Similar emphasis on reviewing settings and procedures to verify compliance. | No major changes. |
PCI DSS v4.0 has stricter time synchronization:
- Time sources and configurations are now explicit requirements.
- Access restriction to time data and logging changes are mandatory.
| Requirement | v3.2.1 (10.8) | v4.0 (10.7.1) | Changes |
|---|---|---|---|
| Scope | Requires a process for detecting and reporting failures of specific security controls (firewalls, IDS/IPS, etc.) | Expands the scope to include the broader concept of "critical security control systems" while offering a similar list. | Provides more flexibility. |
| Terminology | Uses "timely detection and reporting" | Shifts to "prompt detection, alerting, and addressing", emphasizing a quick response. | Stronger sense of urgency. |
| Testing Procedures | Focus on policy review and verifying the existence of processes and alert generation. | Essentially the same focus on policies and real-world verification of the detection and alerting mechanisms. | No major changes. |
PCI DSS v4.0 enhances failure detection for service providers by:
- Shifting focus from specific technologies to “critical control systems”.
- Requiring prompt actions beyond detection and alerting.
| Requirement | v3.2.1 (10.8.1) | v4.0 (10.7.3) | Changes |
|---|---|---|---|
| Core Requirement | Must have processes for timely response to security control failures, including steps like restoring functions, root cause analysis, and prevention. | Identical core requirements. | No changes. |
| Scope | Applies specifically to failures of the controls listed in Requirement 10.8. | Broadens the scope to "any critical security control systems. | More flexibility for service providers. |
| Risk Assessment | Requires performing a risk assessment post-failure, to consider any further actions needed. | Maintains the risk assessment step. | No Changes. |
| Terminology | Requirement heading focuses solely on "responding to failures" | Emphasizes the process of "promptly" responding. | Subtle shift to convey a sense of urgency. |
| Testing Procedures | Focus on verifying the existence of processes and that failures are documented with specific details. | Essentially the same focus but adapted to the broader scope (critical security controls). | Minor alignment with scope change. |
PCI DSS v4.0 changes for security control failures include:
- Service providers can define “critical” based on their environment.
- Emphasizes the need for prompt response.
New Requirements in PCI DSS v4.0:
Requirement 10.4.1.1 introduces a new rule for the utilization of automated tools to conduct audit log reviews. (This rule is considered best practice until March 31, 2025.)
Requirement 10.4.2.1 introduces a new rule for a focused risk analysis to determine the frequency of periodic log reviews for all other system components not defined in Requirement 10.4.1. (This rule is considered best practice until March 31, 2025.)
Requirement 10.1.2 introduces a new rule for defining roles and responsibilities. (This rule is immediately effective for all v4.0 assessments.)
Requirement 10.7.2 introduces a new mandate for all entities to identify, alert, and swiftly rectify any failures in critical security control systems. (This requirement is considered a best practice until March 31, 2025).
This new mandate, applicable to all entities, encompasses two more critical security controls that are not part of Requirement 10.7.1 for service providers.
Requirement 10.7.3 introduces a new rule to swiftly react to any failures in critical security controls. (Until March 31, 2025, this rule is considered a best practice for non-service providers.)
For service providers, this is already a requirement in PCI DSS v3.2.1. For all other entities, excluding service providers, this is a new rule.
Conclusion:
In conclusion, PCI DSS 4.0 brings notable changes to Requirement 10, enhancing logging and monitoring controls. The updates offer more flexibility, stress automation, and introduce new mandates. These changes aim to improve logging effectiveness, facilitating the detection of unauthorized access and user activity tracking.
Key updates include a shift towards “read-only” access, increased log protection flexibility, and an emphasis on automation for daily critical log reviews. The scope of security control failures has been expanded, allowing service providers to define what is “critical” based on their environment. New rules have been introduced, such as the use of automated tools for audit log reviews and a focused risk analysis for periodic log reviews.
Understanding these changes is crucial whether you’re currently compliant under PCI DSS 3.2.1 or preparing for your first PCI DSS 4.0 assessment. It will aid in strategizing your implementation approach and ensuring compliance while enhancing security. The emphasis on prompt detection, alerting, and addressing security issues highlights the evolving nature of cybersecurity and the need to stay ahead of potential threats.
Also Read : PCI DSS Requirement 9
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
