PCI DSS 4.0
Req 10: Logging and Monitoring

PCI DSS 4.0 10.7.3: 10.7.3 Respond promptly to critical security control failures

When any critical security control system fails, the entity must respond promptly, including at least by: restoring the security functions; identifying and recording the duration of the failure (start and end date and time); identifying and recording the cause(s) and the remediation needed; identifying and dealing with any security problems that arose while the control was down; deciding whether further action is needed because of the failure; putting controls in place so the cause does not recur; and resuming monitoring of security controls. Applicability: applies to service providers only until 31 March 2025 (an existing v3.2.1 service provider requirement) and to all entities after that date. Future-dated for entities other than service providers: treated as a best practice up to 31 March 2025 and mandatory since then. Objective under the customized approach: failures are analysed, contained and resolved, controls are restored to limit impact, resulting security issues are dealt with and recurrence is prevented.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 61 controls across 21 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

NIST Cybersecurity Framework 2.0 · 7 controls

  • NIST-CSF-DE.AE-06 Information on adverse events is provided to authorized staff and tools
  • NIST-CSF-RC.RP-01 The recovery portion of the incident response plan is executed once initiated from the incident response process
  • NIST-CSF-RC.RP-02 Recovery actions are selected, scoped, prioritized, and performed
  • NIST-CSF-RC.RP-04 Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
  • NIST-CSF-RS.AN-08 An incident's magnitude is estimated and validated
  • NIST-CSF-RS.MA-04 Incidents are escalated or elevated as needed
  • NIST-CSF-RS.MI-02 Incidents are eradicated

HIPAA Security Rule · 6 controls

NIST SP 800-66 Rev 2 · 6 controls

CIS Controls v8 · 4 controls

  • CIS-13.1 Centralize Security Event Alerting
  • CIS-17.4 Establish and Maintain an Incident Response Process
  • CIS-17.8 Conduct Post-Incident Reviews
  • CIS-8.11 Conduct Audit Log Reviews

ISO 27001:2022 · 4 controls

  • 5.24 Information security incident management planning and preparation 
  • 5.25 Assessment and decision on information security events
  • 5.26 Response to information security incidents
  • 5.27 Learning from information security incidents

NIST SP 800-53 Rev 5 · 4 controls

SOC 2 · 4 controls

  • SOC2-A1.3 A1.3 Testing recovery plan procedures
  • SOC2-CC7.3 CC7.3 Evaluating security events to identify incidents
  • SOC2-CC7.4 CC7.4 Responding to security incidents
  • SOC2-CC7.5 CC7.5 Recovering from security incidents

FedRAMP High · 3 controls

  • AU-5 Response to Audit Logging Process Failures
  • IR-4 Incident Handling
  • SI-4(5) System-Generated Alerts

FedRAMP Moderate · 3 controls

  • AU-5 Response to Audit Logging Process Failures
  • IR-4 Incident Handling
  • SI-4(5) System-Generated Alerts

ISO 27002:2022 · 3 controls

  • 5.24 Information security incident management planning and preparation
  • 5.26 Response to information security incidents
  • 5.27 Learning from information security incidents

ISO/IEC 42001:2023 · 3 controls

  • 10.2 Nonconformity and corrective action
  • 8.3 AI risk treatment
  • 9.1 Monitoring, measurement, analysis and evaluation

AWS Well-Architected Security Pillar · 2 controls

  • SEC10-BP02 Develop incident management plans
  • SEC10-BP08 Establish a framework for learning from incidents

C5 (Germany) · 2 controls

  • C5-OPS-17 Logging and Monitoring - Availability of the Monitoring Software
  • C5-SIM-02 Processing of security incidents

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 2 controls

NIST SP 800-171 Rev 3 · 2 controls

Azure Security Benchmark · 1 control

  • ASBv3-IR-6 Containment, eradication and recovery - automate the incident handling

CMMC 2.0 · 1 control

ISO 22301:2019 · 1 control

  • 10.2 Continual improvement

ISO 27701:2019 · 1 control

  • 6.13.1 Management of information security incidents and improvements

NIS2 Directive · 1 control

  • Art.21.4 Take corrective measures without undue delay on finding that the measures are not met

PCI 3DS Core Security Standard · 1 control

  • P2-2.3.2 P2-2.3.2 Security control failures detected and responded to

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 10: Logging and Monitoring

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 10.7.3 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

If you hold ISO 27001:202249.6% covered · 141 gapsIf you hold FedRAMP Moderate49.3% covered · 142 gapsIf you hold NIST SP 800-53 Rev 547.5% covered · 147 gapsIf you hold ISO 27002:202243.2% covered · 159 gapsIf you hold CIS Controls v838.2% covered · 173 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.136.4% covered · 178 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 61 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll PCI DSS 4.0 controls