When a critical security control system fails, the failure must be responded to promptly, with processes covering: restoring security functions; identifying and recording the duration (start and end date and time) of the failure; identifying and recording the cause(s), root cause included, and what remediation the root cause requires; working out which security problems came up while the control was down and dealing with them; deciding whether further action is needed because of the failure; implementing controls to stop the cause recurring; and restarting the monitoring of security controls. Related PCI DSS requirements: all twelve. Guidance: documented evidence, for example entries in a problem management system, should back up these processes. Applies only to designated entities. Objective under the customized approach: not eligible for the customized approach; only the defined approach can be used.
PCI DSS 4.0 A3.3.1.1 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.
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.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.