Take the lead in data protection best practices with our unified SIEM solution!
Disclaimer: This guide has been created with reference to official documents on the PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 10. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
Requirement 10: Log and monitor all access to system components and cardholder data
This PCI DSS requirement is further divided into 10.1, 10.2, 10.3, 10.4, 10.5, 10.6 and 10.7. Let's explore these in detail.
PCI DSS Requirement 10.1: Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
This PCI DSS requirement is further divided into 10.1.1 and 10.1.2. Let's explore these in detail.
PCI DSS Requirement 10.1.1: Management of security policies and procedures
This requirement focuses on the effective management of security policies and operational procedures related to logging and monitoring activities (Requirement 10). It ensures these policies and procedures are documented, up-to-date, actively used, and communicated to relevant personnel.
- Security policies: These documents define the organization's overall information security goals and principles related to logging and monitoring.
- Operational procedures: These documents detail specific steps and instructions on how to perform logging and monitoring activities.
Business implication
- Effective implementation of logging and monitoring: Properly managed policies and procedures ensure a consistent and effective approach to logging and monitoring activities. This helps detect suspicious behavior, identify security incidents promptly, and minimize potential damage.
Best practices to meet this requirement
- Develop documentation inventory: Maintain a central repository of all security policies and operational procedures related to logging and monitoring.
- Document maintenance: Establish a process for updating policies and procedures whenever there are changes to systems, technologies, or business practices.
- Accessibility and communication: Ensure all relevant personnel (IT staff, security team) have access to and understand the documented policies and procedures.
- Periodic reviews: Conduct periodic reviews of your security policies and procedures to ensure they remain relevant and effective.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.1.1 | Examine documentation for security policies and operational procedures related to logging and monitoring. | The assessor will review your documented policies and procedures to verify they cover all aspects of Requirement 10 (logging processes, access control, audit log review, etc.). |
| 10.1.1 | Interview personnel involved in logging and monitoring activities. | The assessor will interview personnel responsible for logging and monitoring to assess their understanding of the documented policies and procedures and how they apply them in their daily work. |
PCI DSS Requirement 10.1.2: Roles and responsibilities for logging and monitoring
This requirement focuses on ensuring clear and documented roles and responsibilities for personnel involved in logging and monitoring activities (as outlined in Requirement 10).
- Roles and responsibilities: The requirement mandates that an organization defines, documents, and assigns specific responsibilities for activities related to logging and monitoring network resources and cardholder data.
Business implication
- Accountability for security controls: Clearly defined and documented roles and responsibilities ensure personnel are aware of their specific tasks within the logging and monitoring process. This promotes accountability and helps ensure all critical activities are performed effectively.
Best practices to meet this requirement
- Develop RACI Matrix: Create a responsibility assignment matrix (RACI) that defines who is responsible, accountable, consulted, and informed for each logging and monitoring activity.
- Document responsibilities: Document the roles and responsibilities for logging and monitoring activities within your security policies or a separate document.
- Communication and acknowledgement: Communicate these roles and responsibilities to relevant personnel and obtain acknowledgement of their understanding and acceptance.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.1.2.a | Examine documentation (e.g., policies, RACI matrix) for roles and responsibilities related to logging and monitoring activities. | The assessor will review your documentation to verify it clearly defines and assigns roles and responsibilities for all activities outlined in Requirement 10 (logging configuration, access control, log review, etc.). |
| 10.1.2.b | Interview personnel involved in logging and monitoring activities. | The assessor will interview personnel responsible for logging and monitoring to understand their assigned roles and responsibilities and confirm their alignment with documented information. |
PCI DSS Requirement 10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
This PCI DSS requirement is further divided into 10.2.1, 10.2.1.1, 10.2.1.2, 10.2.1.3, 10.2.1.4, 10.2.1.5, 10.2.1.6, and 10.2.2. Let's explore these in detail.
PCI DSS Requirement 10.2.1: Enabling and activating audit logs
This requirement focuses on ensuring that audit logging is enabled and active for all system components that process, store, or transmit cardholder data.
- Audit logs: These are electronic records that capture system activities related to accessing, modifying, creating, or deleting data.
- System components: This refers to all hardware, software, and network devices that store, process, or transmit cardholder data within your environment.
Business implication
- Improved detection of security events: Enabled and active audit logs provide a critical record of all activity within your systems. This allows you to identify suspicious events, potential security breaches, and unauthorized access attempts involving cardholder data.
Best practices to meet this requirement
- Inventory system components: Maintain a comprehensive inventory of all system components that interact with cardholder data.
- Enable audit logging: Verify that audit logging is enabled for all identified system components. This may involve reviewing system configurations or consulting system documentation.
- Log rotation and retention: Establish procedures for rotating audit logs regularly and securely storing them for the required retention period as defined by the PCI DSS.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1 | Interview system administrators. | The assessor will interview system administrators responsible for system configuration to understand their process for enabling audit logging on all system components. |
| 10.2.1 | Examine system configurations for audit logging settings. | The assessor will review relevant system configurations or documentation to verify that audit logging is enabled for all system components identified in your inventory. |
PCI DSS Requirement 10.2.1.1: Capturing individual user access to cardholder data
This requirement focuses on ensuring that audit logs capture all instances of individual user access to cardholder data.
- Individual user access: This refers to any attempt by a specific user (authenticated or unauthorized) to access, modify, create, or delete cardholder data.
- Audit log capture: The requirement mandates that audit logs record all such access attempts, regardless of success or failure.
Business implication
- Enhanced user accountability: Logging all individual user access to cardholder data helps identify potential misuse of authorized accounts and unauthorized access attempts. This allows for investigation and remediation actions to prevent data breaches and minimize financial losses.
Best practices to meet this requirement
- Granular user access controls: Implement granular access controls that restrict user access to cardholder data based on the principle of least privilege. This minimizes the potential for unauthorized access even if credentials are compromised.
- Session monitoring: Consider implementing session monitoring tools that track user activity and can detect suspicious behavior patterns.
- Log review and alerting: Establish procedures for reviewing audit logs regularly and configure alerts for suspicious access attempts to cardholder data.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.1 | Examine audit log configurations to verify they capture user identity and access attempts related to cardholder data. | The assessor will review your audit log configuration settings to ensure they are designed to capture user identification and details of access attempts involving cardholder data. |
| 10.2.1.1 | Sample audit logs to verify they contain user identification information for access attempts to cardholder data. | The assessor will sample audit logs and analyze them to confirm they capture user IDs associated with access attempts to cardholder data (successful or failed). |
PCI DSS Requirement 10.2.1.2: Logging administrative actions
This requirement focuses on ensuring that audit logs capture all actions taken by any individual with administrative access to systems that process, store, or transmit cardholder data.
- Administrative access: This refers to user accounts with elevated privileges that allow modifying system configurations, creating or deleting user accounts, and performing other critical administrative tasks.
- Action logging: The requirement mandates that audit logs record all activities performed by individuals using administrative accounts, including interactive sessions and automated scripts.
Business implication
- Improved accountability for privileged users: Logging administrative actions provides a record of activity within your systems by users with elevated privileges. This allows for identifying potential misuse of administrative access, accidental configuration changes, or unauthorized modifications that could compromise cardholder data.
Best practices to meet this requirement
- Principle of least privilege: Implement the principle of least privilege, granting users only the minimum level of access required to perform their jobs. This minimizes the potential damage caused by compromised administrative credentials.
- Strong password management: Enforce strong password policies for administrative accounts, including complex password requirements and regular password changes.
- Multi-factor authentication: Consider implementing multi-factor authentication (MFA) for administrative access to further strengthen security and prevent unauthorized login attempts.
- Log review and monitoring: Establish procedures for regularly reviewing audit logs to identify suspicious activity or unusual access patterns associated with administrative accounts.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.2 | Examine audit log configurations to verify they capture activities performed by administrative accounts. | The assessor will review your audit log configuration settings to ensure they are designed to capture all actions taken by users with administrative access, including interactive sessions and automated tasks. |
| 10.2.1.2 | Sample audit logs to verify they contain details of administrative activity. | The assessor will sample audit logs and analyze them to confirm they capture details of actions performed using administrative accounts (e.g., user ID, timestamp, action performed). |
PCI DSS Requirement 10.2.1.3: Logging access to audit logs
This requirement focuses on ensuring that audit logs capture all attempts to access audit logs, regardless of success or failure.
- Audit log access: This refers to any attempt by a user to view, modify, or delete audit log data.
- Logging requirement: The requirement mandates that all access attempts to audit logs, including successful and failed attempts, are recorded within separate audit logs.
Business implication
- Preserving audit log integrity: Logging access to audit logs helps detect attempts to tamper with or delete security-related events. This ensures the integrity of your audit trails and allows for investigation of potential security incidents involving cardholder data.
Best practices to meet this requirement
- Separate audit logs for access attempts: Maintain separate audit logs specifically for recording access attempts to primary audit logs. This allows for independent verification and ensures tampering with primary logs doesn't erase evidence of access attempts.
- Strong access controls for audit logs: Implement strong access controls for audit logs, restricting access only to authorized personnel with a legitimate need to review them. Consider implementing MFA for additional security.
- Log review and monitoring: Establish procedures for regularly reviewing audit logs for access attempts, especially unsuccessful attempts or access from unusual locations or times.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.3 | Examine audit log configurations to verify they capture access attempts to audit logs. | The assessor will review your audit log configuration settings to ensure they are designed to capture all attempts to access audit logs, including successful and failed attempts. |
| 10.2.1.3 | Sample audit logs for separate logs recording access attempts. | The assessor will review your audit logs to confirm the existence of separate logs specifically for capturing access attempts to primary audit logs. |
PCI DSS Requirement 10.2.1.4: Logging invalid logical access attempts
This requirement focuses on ensuring that audit logs capture all instances of invalid logical access attempts to systems that process, store, or transmit cardholder data.
- Invalid logical access attempts: This refers to any attempt to access a system using incorrect credentials (username and password), such as failed login attempts or attempts with invalid usernames.
- Logging requirement: The requirement mandates that audit logs record all such attempts, regardless of the specific method used (e.g., brute-force attacks, credential guessing).
Business implication
- Early detection of potential attacks: Logging invalid logical access attempts allows you to identify potential brute-force attacks or unauthorized access attempts targeting your systems. This enables early detection and mitigation actions to prevent security breaches and compromise of cardholder data.
Best practices to meet this requirement
- Implement account lockout policies: Configure account lockout policies that automatically lock user accounts after a certain number of consecutive failed login attempts. This helps prevent brute-force attacks and unauthorized access attempts.
- Strong password policies: Enforce strong password policies for user accounts, including complex password requirements, minimum password length, and regular password changes. This reduces the effectiveness of password guessing attempts.
- Monitor login attempts: Establish procedures for monitoring audit logs to identify trends or patterns in invalid login attempts, especially repeated attempts from suspicious locations or times.
- Implement intrusion detection systems (IDSs): Consider implementing IDS that can analyze network traffic and identify suspicious login attempts in realtime.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.4 | Examine audit log configurations to verify they capture details of invalid login attempts. | The assessor will review your audit log configuration settings to ensure they are designed to capture all invalid logical access attempts, including failed login attempts, attempts with invalid usernames, and other unsuccessful authentication attempts. |
| 10.2.1.4 | Sample audit logs to verify they contain records of invalid login attempts. | The assessor will sample audit logs and analyze them to confirm they capture details of invalid logical access attempts (e.g., timestamp, username, source IP address). |
PCI DSS Requirement 10.2.1.5: Logging changes to identification and authentication credentials
This requirement focuses on ensuring that audit logs capture all modifications made to user accounts and access privileges within systems that process, store, or transmit cardholder data.
- Identification and authentication credentials: This refers to any information used to verify a user's identity and authorize access to a system, such as usernames, passwords, multi-factor authentication tokens, and access control lists (ACLs).
- Changes to credentials: The requirement mandates that audit logs record all activities that modify user accounts or access privileges, including:
- Creation of new user accounts
- Elevation of privileges for existing accounts (granting additional access rights)
- Any modifications, additions, or deletions to accounts with administrative access
Business implication
- Enhanced detection of account compromise: Logging changes to user accounts and access privileges helps identify potential security incidents involving compromised credentials. This allows for investigation and remediation actions to prevent unauthorized access and potential misuse of accounts that could compromise cardholder data.
Best practices to meet this requirement
- Implement strong password policies: Enforce strong password policies for all user accounts, including complex password requirements, minimum password length, and regular password changes. This reduces the effectiveness of stolen credentials and unauthorized account modifications.
- Separation of duties: Implement the principle of least privilege and Separation of duties to minimize the number of users with administrative access and limit the scope of their privileges.
- Review user activity: Establish procedures for regularly reviewing audit logs to identify suspicious changes to user accounts or access privileges, especially for administrative accounts.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.5 | Examine audit log configurations to verify they capture changes to user accounts and access privileges. | The assessor will review your audit log configuration settings to ensure they are designed to capture all activities specified in this requirement, including creation of new accounts, privilege elevation, and modifications to administrative accounts. |
| 10.2.1.5 | Sample audit logs to verify they contain records of changes to user accounts and access privileges. | The assessor will sample audit logs and analyze them to confirm they capture details of relevant activities such as timestamps, usernames affected, types of changes made (e.g., new account creation, privilege elevation, and account deletion). |
PCI DSS Requirement 10.2.1.5: Logging changes to identification and authentication credentials
This requirement focuses on ensuring that audit logs capture all modifications made to user accounts and access privileges within systems that process, store, or transmit cardholder data.
- Identification and authentication credentials: This refers to any information used to verify a user's identity and authorize access to a system, such as usernames, passwords, MFA tokens, and ACLs.
- Changes to credentials: The requirement mandates that audit logs record all activities that modify user accounts or access privileges, including:
- Creation of new user accounts.
- Elevation of privileges for existing accounts (granting additional access rights).
- Any modifications, additions, or deletions to accounts with administrative access.
Business implication
- Enhanced detection of account compromise: Logging changes to user accounts and access privileges helps identify potential security incidents involving compromised credentials. This allows for investigation and remediation actions to prevent unauthorized access and potential misuse of accounts that could compromise cardholder data.
Best practices to meet this requirement
- Implement strong password policies: Enforce strong password policies for all user accounts, including complex password requirements, minimum password length, and regular password changes. This reduces the effectiveness of stolen credentials and unauthorized account modifications.
- Separation of duties: Implement the principle of least privilege and Separation of duties to minimize the number of users with administrative access and limit the scope of their privileges.
- Review user activity: Establish procedures for regularly reviewing audit logs to identify suspicious changes to user accounts or access privileges, especially for administrative accounts.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.5 | Examine audit log configurations to verify they capture changes to user accounts and access privileges. | The assessor will review your audit log configuration settings to ensure they are designed to capture all activities specified in this requirement, including creation of new accounts, privilege elevation, and modifications to administrative accounts. |
| 10.2.1.5 | Sample audit logs to verify they contain records of changes to user accounts and access privileges. | The assessor will sample audit logs and analyze them to confirm they capture details of relevant activities such as timestamps, usernames affected, types of changes made (e.g., new account creation, privilege elevation, account deletion). |
PCI DSS Requirement 10.2.1.6: Logging audit log activity
This requirement focuses on ensuring that audit logs capture all actions that modify the operational status of existing audit logs and the creation of new audit logs within systems that process, store, or transmit cardholder data.
- Audit log activity: This refers to the operational state of the audit logging function (enabled, disabled, paused).
- Logging requirement: The requirement mandates that audit logs record the following activities:
- Initialization of new audit logs (creation of new log files)
- Starting, stopping, or pausing of existing audit logs
Business implication
- Preserving Audit Log Integrity: Logging changes to the operational status of audit logs helps detect attempts to tamper with or disable logging functionality. This ensures the completeness and integrity of your audit trails and prevents malicious actors from hiding their activities.
Best practices to meet this requirement
- Enable tamper protection: Configure audit logging systems with tamper protection features that prevent unauthorized modification or disabling of the logging function.
- Monitor audit log status: Establish procedures for monitoring the operational status of audit logs to identify any unexpected changes or disruptions. Consider using automated alerting systems to notify administrators of potential issues.
- Restrict access controls: Implement strong access controls that restrict the ability to modify audit log settings or disable logging functionality to authorized personnel only.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.1.6 | Examine audit log configurations to verify they capture changes to the operational status of existing audit logs and initialization of new logs. | The assessor will review your audit log configuration settings to ensure they are designed to capture all activities specified in this requirement, including enabling/disabling, starting/stopping, and pausing collection of audit logs as well as creation of new logs. |
| 10.2.1.6 | Review audit logs for entries related to changes in audit log activity. | The assessor will review your audit logs to confirm they contain records of relevant activities such as timestamps and details of changes made (e.g., audit log started, stopped, paused, and new log initialized). |
PCI DSS Requirement 10.2.2: Audit log content requirements
This requirement focuses on ensuring that audit logs capture specific details for each auditable event recorded within systems that process, store, or transmit cardholder data.
- Auditable event: This refers to any activity or action within the system that is relevant to security and potentially impacts cardholder data. Examples include user access attempts, changes to access controls, modifications to system configuration, etc.
- Required details: The requirement mandates that audit logs capture the following information for each auditable event:
- User identification: The unique identifier of the user involved in the event (username, employee ID, etc.).
- Type of event: A description of the specific action performed (e.g., login attempt, file access, configuration change).
- Date and time: The precise timestamp of when the event occurred.
- Success and failure indication: Whether the event was successful (e.g., successful login) or unsuccessful (e.g., failed login attempt).
- Origination of event: The source or location from where the event originated (e.g., workstation IP address, device identifier).
- Identity of affected data/system: The specific data, system component, resource, or service impacted by the event (e.g., filename, application name, or network device).
Business implication
- Enhanced forensic analysis: Capturing detailed information within audit logs allows for comprehensive forensic analysis in case of a security incident. This detailed data helps identify the source of the attack, affected systems and data, and potentially compromised user accounts.
Best practices to meet this requirement
- Review audit log schema: Ensure your audit logging system is configured to capture all the details specified in this requirement for each auditable event.
- Customize logging levels: Consider customizing logging levels to capture additional details relevant to your environment and security needs while balancing the need for comprehensive data with managing log storage capacity.
- Regular log review: Establish procedures for regularly reviewing audit logs to identify suspicious activity or unusual patterns that could indicate potential security incidents.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.2.2 | Interview system administrators to understand how audit logs are configured for capturing details. | The assessor will interview personnel responsible for system configuration to confirm their understanding of the specific details required for each auditable event as defined in 10.2.1.1 through 10.2.1.7. |
| 10.2.2 | Examine audit log configurations and sample log data. | The assessor will review your audit log configuration settings and analyze sample log entries to verify they capture all the required details for each auditable event as specified in the requirement. |
PCI DSS Requirement 10.3: Audit logs are protected from destruction and unauthorized modifications.
PCI DSS Requirement 10.3.1: Restricted access to audit logs
This requirement focuses on restricting access to audit log files within your environment. It mandates that only authorized personnel with a legitimate business need can view audit log data.
- Audit log files: These are electronic records that capture system activities related to accessing, modifying, creating, or deleting cardholder data.
- Restricted access: The requirement mandates that access controls are implemented to limit who can view audit log files. Access should only be granted to personnel who require this information to perform their job duties, such as security analysts, auditors, or incident response personnel.
Business implication
- Preserving confidentiality of security data: Restricting access to audit logs protects sensitive security information from unauthorized viewing or potential manipulation. This helps ensure the confidentiality and integrity of your audit trails, which are critical for detecting and investigating security incidents involving cardholder data.
Best practices to meet this requirement
- Implement role-based access control (RBAC): Implement RBAC to define user roles and permissions within your system. Grant read access to audit logs only to users assigned roles with a legitimate need for this information.
- Least privilege principle: Adhere to the principle of least privilege, granting users only the minimum level of access required to perform their jobs. This minimizes the number of personnel with access to sensitive audit data.
- Strong password policies: Enforce strong password policies for user accounts with access to audit logs.
- Physical security: Implement physical security measures to protect systems that store audit logs, such as restricted access to server rooms and secure storage for backup media.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.3.1 | Interview system administrators to understand access control mechanisms for audit logs. | The assessor will interview personnel responsible for user access management to understand how access controls are implemented for audit logs. This includes understanding the process for granting and reviewing user permissions for accessing audit log files. |
| 10.3.1 | Examine system configurations and user privileges. | The assessor will review your system configurations and user privilege settings to verify that only authorized users with a job-related need have read access to audit log files. |
PCI DSS Requirement 10.3.2: Protection of audit logs
This requirement focuses on safeguarding audit log files within your environment to prevent unauthorized modifications. It mandates that you implement controls to ensure the integrity and trustworthiness of your audit trails.
- Audit log files: These are electronic records that capture system activities related to accessing, modifying, creating, or deleting cardholder data.
- Protection from modification: The requirement mandates that you implement controls to prevent unauthorized individuals from altering or tampering with audit log data. This includes protecting both the original audit logs on the originating systems and any backups or copies that exist.
Business implication
- Ensuring reliable security evidence: Protecting audit logs from modification ensures the integrity and trustworthiness of your audit trails. This allows for reliable forensic analysis in case of a security incident and helps identify the true sequence of events without the risk of compromised data.
Best practices to meet this requirement
- Write onceread many (WORM) technologies: Consider using WORM technologies for storing audit logs, which allow writing data only once but enable multiple read operations. This helps prevent unauthorized modifications after the logs are written.
- Digital signing and hashing: Implement digital signing and hashing techniques to ensure the integrity of audit logs. These techniques create a digital fingerprint of the log data, allowing for detection of any unauthorized changes.
- Regular log archiving: Establish procedures toregularly archive audit logs to asecure, tamper-proof location. This ensures the availability of historical data for forensic analysis even if the original logs are compromised.
- Network segregation: Consider implementing network segmentation to isolate systems that store audit logs from other systems within your network. This reduces the risk of unauthorized access and potential manipulation attempts.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.3.2 | Interview system administrators to understand how audit logs are protected from modification. | The assessor will interview personnel responsible for system security to understand the controls implemented to protect audit logs from unauthorized modifications. This includes discussing WORM technologies, digital signing, archiving procedures, and network segmentation strategies. |
| 10.3.2 | Examine system configurations and user privileges. | The assessor will review your system configurations and user privilege settings to verify that write access to audit logs is restricted and only authorized personnel have the ability to modify them (for legitimate purposes such as archiving). |
PCI DSS Requirement 10.3.4: File integrity monitoring for audit logs
This requirement focuses on implementing file integrity monitoring (FIM) or change-detection mechanisms on your audit logs. It mandates that you have a system in place to detect any unauthorized modifications to audit log data.
- FIM: A security tool that continuously monitors critical files and systems for unauthorized changes. Any deviations from the baseline integrity are flagged as potential security incidents.
- Change-detection mechanisms: Broader term encompassing various techniques to identify unauthorized modifications to files or systems, including FIM tools and log analysis solutions.
Business implication
- Early detection of tampering attempts: Implementing FIM on audit logs helps detect attempts to tamper with security data. This allows for prompt investigation and remediation actions to prevent attackers from obscuring their activities within the audit trails.
Best practices to meet this requirement
- Configure alerting for modifications: Configure your FIM solution to generate alerts whenever existing audit log data is modified or deleted. This ensures you are notified of potential tampering attempts.
- Baseline establishment: Establish a baseline for your audit logs, which serves as a reference point for FIM tools to identify unauthorized changes.
- Focus on unmodified files: Configure FIM to prioritize monitoring files that don't change regularly (e.g., historical logs). New log entries should not trigger alerts as they represent normal system activity.
- Regular review of alerts: Establish procedures for regularly reviewing alerts generated by your FIM solution. Investigate flagged events to determine their legitimacy and take appropriate action.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.3.4 | Review system settings to verify FIM or change-detection mechanisms are enabled for audit logs. | The assessor will review your system configuration settings to confirm that FIM or change-detection software is implemented for monitoring audit logs. |
| 10.3.4 | Examine the list of monitored files to confirm it includes audit logs. | The assessor will review the list of files monitored by your FIM solution to verify that it includes all relevant audit log files. |
| 10.3.4 | Analyze results from FIM activities to identify alerts related to audit log modifications. | The assessor will review reports or logs generated by your FIM solution to confirm it detects and flags any unauthorized modifications to audit logs. |
PCI DSS Requirement 10.4: Audit logs are reviewed to identify anomalies or suspicious activity
PCI DSS Requirement 10.4.1: Daily review of specific audit logs
This requirement focuses on the frequency of reviewing specific types of audit logs within your environment. It mandates that you conduct daily reviews of security events and logs from critical systems that process cardholder data (CHD) or system security data (SAD).
- Security events: Events within your system that may indicate a potential security breach or suspicious activity. Examples include failed login attempts, access attempts to unauthorized resources, or malware detections.
- Critical system components: Systems or devices that play a vital role in protecting cardholder data, such as firewalls, intrusion detection systems (IDS), and authentication servers.
- Systems processing CHD/SAD: Any system that stores, processes, or transmits cardholder data or system security data.
Business implication
- Early detection of security incidents: Daily review of security events and critical system logs allows for prompt identification of potential security incidents. This minimizes the window of opportunity for attackers and facilitates faster response actions to contain threats and prevent data breaches.
Best practices to meet this requirement
- Utilize log management tools: Implement centralized log management systems or security information and event management (SIEM) solutions to aggregate and analyze log data from various sources. This streamlines the log review process and simplifies identification of security events.
- Establish review procedures: Develop documented procedures that outline the process for daily log review, including identification of reviewers, specific logs to be reviewed, and procedures for handling identified anomalies or suspicious activities.
- Define security events: Clearly define what constitutes a security event within your environment. This definition should consider factors such as the type of technology, location, and function of the device.
- Maintain a baseline: Establish a baseline of normal system activity for your network. Deviations from this baseline can indicate potential anomalies or security incidents.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.4.1.a | Review security policies and procedures to verify documented processes for daily review of specified logs. | The assessor will review your security policies and procedures to confirm they define a process for daily review of all elements specified in this requirement, including security events, logs from CHD/SAD systems, critical system components, and security function systems. |
| 10.4.1.b | Observe the log review process and interview personnel to verify daily review of specified logs. | The assessor may observe your personnel conducting daily log reviews and interview them to understand their process for reviewing security events and critical system logs. |
PCI DSS Requirement 10.4.1.1: Automated log review mechanisms (effective March 31, 2025)
This requirement, becoming mandatory on March 31, 2025, focuses on utilizing automated mechanisms to review audit logs within your environment. It emphasizes the importance of leveraging technology to analyze the vast amount of log data generated by your systems.
- Automated mechanisms: Software tools or systems that can automatically parse, analyze, and identify potentially suspicious or anomalous activities within audit logs. Examples include log management systems, SIEM solutions, and security information and event management (SIEM) tools.
Business implication
- Improved efficiency and accuracy: Automated log review tools can efficiently process large volumes of log data, identifying potential security incidents with greater accuracy and speed compared to manual review methods. This allows your security team to focus on investigating and responding to identified threats.
Best practices to meet this requirement
- Implement log management tools: Invest in centralized log management systems or SIEM solutions that can collect, aggregate, and analyze log data from various sources in your environment.
- Configure alerting rules: Configure automated tools with appropriate alerting rules to flag suspicious activities within logs. These rules could be based on specific events, user behavior patterns, or deviations from established baselines.
- Regularly review tool settings: Periodically review and update the settings of your automated log review tools to ensure they remain aligned with changes in your environment and security posture.
How to comply with this requirement (effective March 31, 2025):
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.4.1.1 | Review documentation and interview personnel to verify the use of automated mechanisms for log review. | The assessor will review your documentation and interview personnel responsible for security operations to confirm your organization utilizes automated tools or SIEM solutions for reviewing audit logs. |
| 10.4.1.1 | Examine the configuration of automated tools to understand how they analyze logs and identify suspicious activities. | The assessor may review the configuration settings of your automated log review tools to ensure they are configured with appropriate rules and filters to identify potential security events within audit logs. |
Note: This requirement is currently considered a best practice but becomes mandatory on March 31, 2025. PCI DSS assessments will consider this requirement for compliance after that date.
PCI DSS Requirement 10.4.2: Periodic review of other system component logs
This requirement focuses on reviewing audit logs from system components beyond those explicitly mandated in Requirement 10.4.1. It emphasizes the importance of reviewing logs from a broader range of systems within your environment to identify potential security risks.
- System components: Any device or software application within your network that stores, processes, or transmits cardholder data (CHD) or system security data (SAD). This includes systems not explicitly mentioned in Requirement 10.4.1, such as web servers, application servers, databases, workstations, and network devices.
- Periodic review: The requirement mandates that you establish a defined schedule for reviewing logs from these additional system components. The frequency of these reviews should be based on a risk assessment.
Business implication
- Comprehensive security posture: Periodically reviewing logs from all system components helps identify potential security incidents that might not be readily apparent by solely focusing on critical systems. This contributes to a more comprehensive security posture by addressing potential threats that could exploit less-critical systems as entry points.
Best practices to meet this requirement
- Conduct a TRA: Perform a TRA to identify all system components that store, process, or transmit CHD or SAD. This analysis will help determine the risk associated with each system and define the appropriate frequency for log review.
- Define a review schedule based on risk: Develop a documented schedule for reviewing logs from all system components. Higher-risk systems should be reviewed more frequently compared to lower-risk systems.
- Utilize log management tools: Implement centralized log management systems or SIEM solutions to simplify the process of collecting and analyzing logs from various system components.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.4.2.a | Review security policies and procedures to verify documented processes for periodic review of logs from all other system components. | The assessor will review your security policies and procedures to confirm they define a process for periodically reviewing logs from all system components beyond those specified in Requirement 10.4.1. |
| 10.4.2.b | Examine documented results of log reviews and interview personnel to verify that log reviews are performed according to the defined schedule. | The assessor will review documentation of your log review activities to verify they are conducted periodically for all other system components, as defined in your risk assessment and security policies. They may also interview personnel responsible for log review to understand their process. |
PCI DSS Requirement 10.4.2.1: Frequency of log reviews based on risk analysis (effective march 31, 2025)
This requirement, becoming mandatory on March 31, 2025, focuses on defining the frequency of log reviews for system components beyond those mandated in Requirement 10.4.1. It emphasizes the importance of basing the review schedule on a risk assessment.
- Targeted risk analysis (TRA): A comprehensive assessment that identifies security risks associated with your cardholder data environment (CDE). This analysis should consider the type of data stored, processed, or transmitted, the systems involved, and the controls in place to safeguard that data.
Business implication
- Risk-based approach to security: Defining the frequency of log reviews based on risk prioritizes security efforts towards areas with the greatest potential for compromise. This allows you to allocate resources efficiently and focus on reviewing logs from high-risk systems more frequently.
Best practices to meet this requirement
- Conduct a thorough TRA: Perform a comprehensive TRA that identifies all system components within your CDE and evaluates the associated security risks for each system.
- Define review frequency based on risk: Based on your TRA findings, define a documented schedule for reviewing logs from all system components. Higher-risk systems should be reviewed more frequently (e.g., daily, weekly) compared to lower-risk systems (e.g., monthly, quarterly).
- Utilize risk management framework: Consider utilizing established risk management frameworks like NIST CSF (National Institute of Standards and Technology Cybersecurity Framework) to guide your TRA process and define risk levels for your systems.
How to comply with this requirement (effective March 31, 2025):
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.4.2.1.a | Review the targeted risk analysis to verify it addresses the frequency of periodic log reviews for all system components not covered in Requirement 10.4.1. | The assessor will examine your TRA documentation to confirm it defines the frequency for reviewing logs from all system components beyond those specified in Requirement 10.4.1. They will ensure the TRA adheres to the elements outlined in Requirement 12.3.1, which focuses on conducting a comprehensive targeted risk analysis. |
| 10.4.2.1.b | Examine documented results of log reviews and interview personnel to verify they are conducted at the frequency defined in the TRA. | The assessor will review records of your log review activities to confirm they are performed according to the schedule defined in your TRA for all other system components. They may also interview personnel responsible for log reviews to understand their process for adhering to the defined frequency. |
PCI DSS Requirement 10.4.3: Addressing exceptions and anomalies in log reviews
This requirement focuses on the process for handling exceptions and anomalies identified during your audit log review activities. It emphasizes the importance of investigating and addressing any suspicious or unusual log entries to ensure potential security incidents are not overlooked.
- Exceptions: Deviations from established baselines or security policies within audit logs. These could be unusual access attempts, unexpected system activity, or changes to user accounts.
- Anomalies: Suspicious or irregular patterns identified within audit logs. Examples include repeated failed login attempts, access attempts from unusual locations, or activities outside of normal user behavior.
Business implication
- Prompt response to security threats: Promptly addressing exceptions and anomalies in log reviews allows for faster identification and response to potential security threats. This helps minimize the impact of incidents and prevents attackers from establishing a foothold within your network.
Best practices to meet this requirement
- Define exception and anomaly handling procedures: Develop documented procedures that outline how to identify, investigate, and address exceptions and anomalies identified during log reviews.
- Establish prioritization criteria: Define criteria for prioritizing exceptions and anomalies based on their severity and potential risk. High-risk anomalies, such as unauthorized access attempts, should be investigated promptly.
- Implement reporting and escalation procedures: Establish procedures for reporting and escalating identified exceptions and anomalies to the appropriate security personnel for further investigation and potential remediation actions.
- Maintain records of log review activity: Maintain records of your log review activities, including details of identified exceptions and anomalies, investigation steps taken, and any resulting remediation actions.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.4.3.a | Review security policies and procedures to verify documented processes for addressing exceptions and anomalies identified during log reviews. | The assessor will examine your security policies and procedures to confirm they define a process for handling exceptions and anomalies identified during log review activities. This process should cover identification, investigation, reporting, and remediation actions. |
| 10.4.3.b | Observe the log review process and interview personnel to verify they address identified exceptions and anomalies. | The assessor may observe your personnel conducting log reviews and interview them to understand their process for handling identified exceptions and anomalies. This includes how they determine severity, how they investigate, and how they report and escalate findings. |
PCI DSS Requirement 10.5: Audit log history is retained and available for analysis.
PCI DSS Requirement 10.5.1: Retention of audit log history
This requirement focuses on the duration for which you must retain audit log history within your environment. It mandates that you store audit logs for at least 12 months and ensure the most recent three months are readily accessible for analysis.
- Audit log history: Electronic records capturing system activities related to accessing, modifying, creating, or deleting cardholder data (CHD) or system security data (SAD).
Business implication
- Effective incident response and forensics: Retaining audit logs for at least 12 months provides historical data for forensic analysis during security incidents. This allows investigators to determine the scope of the breach, identify compromised systems, and understand the timeline of events. Additionally, having readily accessible logs for the past three months facilitates faster response and containment actions in case of a suspected breach.
Best practices to meet this requirement
- Define an audit log retention policy: Develop a documented policy that specifies the duration for retaining audit logs (minimum 12 months) and identifies procedures for archiving older logs.
- Implement secure log storage: Store audit logs securely to prevent unauthorized access or modification. Consider using centralized log management systems or secure cloud storage solutions.
- Ensure accessibility of recent logs: Maintain the most recent three months of audit logs readily available for analysis by security personnel. This could involve storing them online, replicating them to a separate system, or ensuring quick retrieval from backups.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.5.1.a | Review documentation to verify the existence of defined audit log retention policies. | The assessor will examine your documentation to confirm you have a documented policy outlining the minimum retention period for audit logs (12 months) and procedures for archiving older logs. |
| 10.5.1.b | Examine audit log storage configurations, interview personnel, and review sample audit logs. | The assessor will review your audit log storage configuration to verify logs are retained for at least 12 months. They will interview personnel responsible for log management and examine sample audit logs to confirm the retention period. |
| 10.5.1.c | Interview personnel and observe processes to verify the immediate availability of the most recent three months of audit logs for analysis. | The assessor will interview security personnel responsible for log analysis and observe their process for accessing audit logs. This assessment aims to confirm they can readily access and analyze the most recent three months of log data. |
PCI DSS Requirement 10.6: Time-synchronization mechanisms support consistent time settings across all systems
PCI DSS Requirement 10.6.1: Time synchronization using technology
This requirement focuses on ensuring consistent and accurate timekeeping across all systems within your CDE. It mandates the use of time-synchronization technology to achieve a synchronized time reference for all your systems.
- Time-synchronization technology: Software or hardware solutions that automatically adjust the system clock on your devices to match a reliable external time source.
Business implication
- Accurate forensic analysis: Maintaining synchronized time across all systems within your CDE is critical for accurate forensic analysis following a security incident. Consistent timestamps on log entries from different devices allow investigators to determine the exact sequence of events and identify compromised systems effectively.
Best practices to meet this requirement
- Implement Network Time Protocol (NTP): Use NTP as your primary time-synchronization technology. NTP is a widely used and reliable protocol that automatically synchronizes system clocks with designated time servers.
- Configure time servers: Configure your systems to obtain time from reliable external time sources, such as public NTP servers or dedicated internal NTP servers.
- Maintain time synchronization technology: Regularly update and patch your time-synchronization software or hardware to address any vulnerabilities that could compromise its functionality. Refer to PCI DSS Requirements 6.3.1 and 6.3.3 for guidance on vulnerability management and patching.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.6.1 | Examine system configuration settings to verify the implementation and current status of time-synchronization technology. | The assessor will review the configuration settings of your systems to confirm they are configured to use time-synchronization technology like NTP. They will also ensure the technology is up to date and functioning properly. |
PCI DSS Requirement 10.6.2: Configuration for accurate and consistent time
This requirement focuses on the specific configuration details for achieving accurate and consistent time synchronization across your CDE. It outlines various elements to ensure all systems rely on reliable and secure time sources.
- Designated time server(s): Specific system(s) within your network that act as the central source of time for all other devices. These servers receive time updates from external sources and distribute them to other internal systems.
- External sources: Reliable and secure time references outside your network, such as public NTP servers or dedicated time servers provided by time service organizations.
Business implication
- Mitigating risk of tampering: Configuring time synchronization with designated and secure external sources helps prevent unauthorized individuals from manipulating system clocks within your CDE. This ensures accurate timestamps on log entries, crucial for forensic analysis and identifying the timeline of security incidents.
Best practices to meet this requirement
- Implement NTP: Use NTP as your primary time-synchronization protocol. NTP automatically synchronizes system clocks with designated time servers.
- Configure designated time servers: Configure specific systems within your network to act as designated central time servers.
- Restrict access to external sources: Only designated central time servers should receive time updates directly from external sources. This prevents unauthorized modification of system clocks.
- Use reputable external sources: Ensure your designated time servers receive updates from reliable and secure external sources, such as public NTP servers maintained by reputable organizations or dedicated time service providers.
- Enable time server peering (optional): If you have multiple designated time servers, configure them to peer with each other for redundancy and ensure consistent time even if one server becomes unavailable.
- Restrict internal time updates: Configure internal systems within your CDE to receive time information only from the designated central time server(s). This prevents individual devices from relying on potentially inaccurate local time settings.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.6.2 | Examine system configuration settings for acquiring, distributing, and storing time information. | The assessor will review the configuration settings of your systems and designated time servers. They will verify that: * One or more designated time servers are configured. * Only designated central time servers receive updates from external sources. * External time sources are based on International Atomic Time (TAI) or Coordinated Universal Time (UTC). * Designated time servers receive updates only from specific industry *accepted external sources. * If applicable, time servers are configured for peering. * Internal systems receive time information only from designated time servers. |
PCI DSS Requirement 10.6.3: Protecting time synchronization settings and data
This requirement focuses on safeguarding the configuration settings and data associated with your time synchronization mechanisms. It emphasizes the importance of restricting access and monitoring changes to ensure the integrity of your timekeeping system.
- Time synchronization settings: Configuration parameters within your systems that define how they obtain and maintain synchronized time. This includes details about designated time servers, external time sources, and time update protocols.
- Time data: Information related to the current system time, including timestamps within log entries.
Business implication
- Preserving forensic integrity: Protecting time synchronization settings and data helps ensure the accuracy and reliability of timestamps within your security logs. This is critical for forensic analysis following a security incident, as accurate timestamps allow investigators to determine the exact sequence of events and identify compromised systems effectively. Tampered time data could hinder investigations and potentially allow attackers to cover their tracks.
Best practices to meet this requirement
- Implement RBAC: Enforce RBAC to restrict access to time synchronization settings and data. Only authorized personnel with a legitimate business need, such as system administrators, should have the ability to modify these settings.
- Enable logging of time changes: Configure your systems to log any changes made to time settings on critical systems within your CDE. These logs should capture details about the user who made the change, the time of the modification, and the specific changes implemented.
- Monitor time change logs: Regularly monitor logs related to time synchronization changes on critical systems. Investigate any suspicious or unauthorized modifications promptly.
- Consider encryption (optional): For an additional layer of security, consider encrypting sensitive time synchronization data, such as configuration files or communication between time servers.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.6.3.a | Examine system configurations and time-synchronization settings to verify restricted access to time data. | The assessor will review your system configurations and time-synchronization settings to confirm that access is limited to authorized personnel with a business need. This may involve reviewing ACLs or user permission settings. |
| 10.6.3.b | Examine system configurations, time-synchronization settings, logs, and observe processes for monitoring time change logs. | The assessor will review your system configurations and time-synchronization settings to ensure logging of changes on critical systems. They will also examine your logs for any time change events and observe your process for monitoring these logs for suspicious activity. |
PCI DSS Requirement 10.7: Failures of critical security control systems are detected, reported, and responded to promptly.
PCI DSS Requirement 10.7.1: Prompt detection and response to security control failures (service providers)
This requirement applies specifically to service providers and focuses on their processes for handling failures within critical security control systems. It mandates the implementation of mechanisms to promptly detect, alert on, and address any malfunctions within these systems to minimize security risks.
- Critical security control systems: Essential security mechanisms within a Cardholder Data Environment (CDE) that safeguard cardholder data. These include:
- Network security controls (firewalls, intrusion detection/prevention systems)
- Identity and access management (IAM) systems
- Anti-malware solutions
- Physical access controls (security cameras, door access controls)
- Logical access controls (user authentication, authorization)
- Audit logging mechanisms
- Segmentation controls (isolating specific network segments)
Business implication
- Minimizing risk of data breaches: Promptly detecting and addressing failures in critical security control systems helps prevent attackers from exploiting these vulnerabilities to compromise your CDE. This safeguards cardholder data and minimizes the risk of data breaches.
Best practices to meet this requirement
- Develop detection and alerting procedures: Define documented procedures for identifying and alerting personnel about failures within critical security control systems. This may involve automated monitoring tools, system logs, or manual checks.
- Establish response processes: Outline procedures for responding to security control failures. This includes escalation protocols, troubleshooting steps, and remediation actions to restore functionality and prevent further compromise.
- Regularly test security controls: Conduct periodic testing of your critical security control systems to identify any vulnerabilities or malfunctions before they are exploited by attackers.
How to comply with this requirement (service providers only):
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.7.1.a | Examine documentation to verify procedures for detecting and addressing failures of critical security control systems. | The assessor will review your documentation to confirm you have documented procedures for handling failures within critical security control systems. This includes procedures for detection, alerting, and remediation actions. |
| 10.7.1.b | Observe detection and alerting processes and interview personnel. | The assessor may observe your personnel performing tasks related to identifying and responding to security control failures. They will also interview personnel to understand how they detect failures, report them, and initiate remediation actions. |
Note: This requirement is specifically for service provider assessments and will be superseded by Requirement 10.7.2 on March 31, 2025.
PCI DSS Requirement 10.7.2: Prompt detection and response to security control failures (effective March 31, 2025)
This requirement, becoming mandatory on March 31, 2025, focuses on the process for identifying, alerting, and addressing failures within critical security control systems. It applies to all entities, including service providers, and emphasizes the importance of promptly responding to malfunctions within these systems to minimize security risks.
- Critical security control systems: Essential security mechanisms within a Cardholder Data Environment (CDE) that safeguard cardholder data. These include:
- Network security controls (firewalls, intrusion detection/prevention systems)
- IAM systems
- Anti-malware solutions
- Physical access controls (security cameras, door access controls)
- Logical access controls (user authentication, authorization)
- Audit logging mechanisms
- Segmentation controls (isolating specific network segments)
- Change-detection mechanisms (new): Tools that monitor for unauthorized or unexpected changes within systems or configurations.
- Audit log review mechanisms (new): Processes for analyzing and investigating activity captured in audit logs.
- Automated security testing tools (if used): Software applications that automate vulnerability scanning and penetration testing activities.
Business implication
- Reduced risk of financial loss: Promptly addressing failures in critical security control systems helps prevent attackers from exploiting vulnerabilities to compromise your CDE and potentially steal cardholder data. This translates to a reduced risk of financial losses associated with data breaches and regulatory fines.
Best practices to meet this requirement
- Develop detection and lerting procedures: Define documented procedures for identifying and alerting personnel about failures within critical security control systems. This may involve using automated monitoring tools, system logs, or manual checks.
- Establish response processes: Outline procedures for responding to security control failures. This includes escalation protocols, troubleshooting steps, and remediation actions to restore functionality and prevent further compromise.
- Regularly test security controls: Conduct periodic testing of your critical security control systems to identify any vulnerabilities or malfunctions before they are exploited by attackers.
- Implement change-detection mechanisms: Consider implementing tools that monitor for unauthorized or unexpected changes within systems or configurations. This can help identify potential security incidents early on.
- Establish audit log review processes: Develop documented procedures for regularly reviewing audit logs to identify suspicious activity and potential security control failures.
How to comply with this requirement (effective March 31, 2025):
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.7.2.a | Examine documentation to verify procedures for detecting and addressing failures of critical security control systems. | The assessor will review your documentation to confirm you have documented procedures for handling failures within critical security control systems. This includes procedures for detection, alerting, and remediation actions for all systems listed in the requirement. |
| 10.7.2.b | Observe detection and alerting processes and interview personnel. | The assessor may observe your personnel performing tasks related to identifying and responding to security control failures. They will also interview personnel to understand how they detect failures, report them, and initiate remediation actions. |
Note: This requirement is currently considered a best practice but becomes mandatory on March 31, 2025. PCI DSS assessments will consider this requirement for compliance after that date.
PCI DSS Requirement 10.7.3: Prompt response to security control failures (for service providers until March 31, 2025; for all entities after that)
This requirement focuses on the actions taken in response to failures within critical security control systems. It outlines specific steps organizations, including service providers (until March 31, 2025, and all entities thereafter), must take to effectively address these failures and minimize potential security risks.
- Critical security control systems: Essential security mechanisms within a Cardholder Data Environment (CDE) that safeguard cardholder data. These include:
- Network security controls (firewalls, intrusion detection/prevention systems)
- IAM systems
- Anti-malware solutions
- Physical access controls (security cameras, door access controls)
- Logical access controls (user authentication, authorization)
- Audit logging mechanisms
- Segmentation controls (isolating specific network segments)
Business implication
- Reduced downtime and data loss: Promptly responding to security control failures helps minimize the window of opportunity for attackers to exploit vulnerabilities and compromise your systems. This reduces the risk of downtime, data breaches, and associated financial losses.
Best practices to meet this requirement
- Develop response procedures: Define documented procedures for responding to failures within critical security control systems. These procedures should outline steps for:
- Restoring security functionality
- Identifying and documenting the duration of the failure
- Determining the root cause of the failure
- Implementing corrective actions to address the root cause
- Identifying and addressing any security issues arising from the failure
- Determining if further actions are necessary
- Resuming monitoring of security controls
- Train personnel: Ensure personnel responsible for security are aware of their roles and responsibilities during a security control failure. Regular training can help them effectively respond to such events.
- Maintain records: Document all aspects of the security control failure response, including the timeline, identified cause, implemented remediation steps, and lessons learned.
How to comply with this requirement (for service providers until March 31, 2025; for all entities thereafter)
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 10.7.3.a | Examine documentation and interview personnel. | The assessor will review your documented procedures for responding to security control failures. They will ensure these procedures address all elements specified in the requirement. They will also interview personnel to understand their awareness and involvement in the response process. |
| 10.7.3.b | Examine records of security control failure responses. | The assessor will review your records of past security control failures. They will verify that the records document all required details, including: * Duration of the failure * Identified cause(s) * Implemented remediation steps * Addressed security issues * Need for further actions * Implemented preventative measures to avoid reoccurrence * Resumption of security control monitoring |
Note: This requirement currently applies to service providers only. However, it becomes mandatory for all entities on March 31, 2025, and PCI DSS assessments will consider it for compliance after that date.
