10.7 Critical security control failures: PCI DSS evidence

What PCI DSS 10.7 requires when a security control fails

Requirement 10.7.2 expects you to detect, alert on and address a failure of a critical security control promptly, and it applies to every entity from 31 March 2025. A QSA or internal assessor will ask how your team knows that a firewall, IDS/IPS or logging pipeline has stopped working. The covered systems include network security controls, intrusion detection and prevention, change detection, anti-malware, physical and logical access controls, audit logging, segmentation controls, audit log review mechanisms and automated security testing tools. The requirement superseded 10.7.1, the earlier version that applied only to service providers, so a merchant or acquirer can no longer treat this as a provider-only duty. Confirm the current wording and the exact list of covered systems against your copy of the standard and the SAQ D template, since assessors will test against those documents.

Requirement 10.7.3 describes what the response must include. Once a failure is found, the team must restore the security function, record how long the failure lasted and what caused it, address any security issues that arose while the control was down, and resume monitoring. The duration and cause entries are where many teams fall short, because a restart that leaves no record cannot show an assessor when the gap began. The risk is silent failure: if a logging agent stops shipping events from a payment database, or a segmentation control drops rules after an update, cardholder data can be exposed for days with no alert and no record of the gap. Plan for that case in advance by deciding who receives control-health alerts, who may take a system out of service, and where failure tickets are kept.

The difficulty is that each control system reports health differently. A firewall may show a process running while its rule set is stale, an IDS may run with no signatures loaded, and a log forwarder may stay up while its queue backs up. A tool being up is not the same as a tool alerting, so the test for each control should confirm that a deliberate, safe fault produces an alert that reaches a person. Keep a register of the covered controls, their health signals and their alert routes, and test that register on a schedule you can evidence. Tools such as Prometheus can collect health metrics and Grafana Alerting can route alerts from metrics and logs together, but you must confirm that each covered control exposes a usable signal before relying on either.

Which controls, systems and teams 10.7 covers in your environment

Requirement 10.7 applies to every security control that protects the cardholder data environment, not only logging. The cards below group the controls, systems, responders and third parties that usually fall inside that scope, and each one changes how failures must be detected and answered.

Network security controls and segmentation

Firewalls, routers with access lists and the segmentation controls that separate the CDE from other networks are the first controls an assessor expects to see covered. A silent failure here can expose cardholder data without any obvious symptom. Check that each NSC and segmentation control produces a status signal, that a loss of that signal raises an alert, and that someone is named to act on it. Confirm with your assessor which segmentation controls they treat as critical for your CDE.

Intrusion detection and prevention systems

IDS and IPS sensors that watch traffic into and inside the CDE must keep running for monitoring to mean anything. A sensor that stops receiving traffic, loses its rule updates or crashes can look healthy while seeing nothing. Verify that sensor health, rule currency and traffic volume are monitored and that a gap triggers an alert. Record the affected period, because 10.7.3 expects you to document it.

Change detection and anti-malware

Change detection tools and anti-malware agents protect the integrity and malware defenses of CDE systems. When an agent is disabled, out of date or unable to report, the gap must be detected and addressed promptly. Confirm which hosts run each agent, how the console reports agents that go silent, and who receives those reports. Coverage gaps on systems added later are a common finding.

Audit logging and log review mechanisms

Audit logging, log collection and the automated review mechanisms that read those logs are controls in their own right. If a log source stops sending, or the review pipeline stalls, the organization loses the ability to see events that matter. Map each in-scope log source to its collector and to its review rule, and alert when expected events stop arriving. Ask your assessor how they will test that failures are noticed.

Physical and logical access controls

Physical access controls (badge readers, locks, camera systems) and logical access controls (directory services, access control systems, privileged access tools) both sit within the critical control list. Failures can include a badge reader going offline or an access control service losing its connection to the directory. Define which of these your organization treats as critical, document how each failure is detected, and confirm that the response team receives the alert.

People, on-call duties and third-party monitoring

Detection only counts if a named team responds, restores the function and records the cause and duration. Identify who holds on-call duty for each control, who approves the return to monitoring, and which managed SOC or SaaS logging provider must notify you of its own outages. Responsibility matrices should state who detects, who acts and who records. Confirm contractual notification times with each provider.

How an assessor tests PCI DSS 10.7 failure detection

This table compares what an assessor samples, tests, requests and commonly finds for each part of Requirement 10.7. Read each row as a test step paired with the record that proves it, and use the findings column to check your own alert routing and ticket closure before an assessment begins.

Assessment step	Evidence requested	Common findings
Sample of critical control systems	Inventory of NSCs, IDS/IPS, change detection, anti-malware, access controls, audit logging, segmentation controls, log review mechanisms and automated security testing tools, with the sampled set selected	Inventory omits a critical control added after the last review, such as a new cloud segmentation control or a log forwarder
Deliberate or safe disablement test	Test plan, change record, timestamps showing the control was disabled, the alert generated, and the time it reached a responder	Alert fires in the tool console but no notification is sent, because the integration to the paging or ticketing system was never configured
Alert routing review	Alert rule definitions, notification policies, contact points or channel configuration, and on-call schedules	Alerts configured but routed to an unmonitored shared mailbox or a former employee's address
Failure ticket review	Tickets or incident records for a sample of failures, with open and close dates, assigned owner and linked alert	Failures logged in the tool but never closed, or tickets closed with no evidence that the control was restored
Response record completeness	Response record showing restoration of the security function, duration of the failure, root cause, security follow-up and the date monitoring resumed	Duration recorded as a rough estimate, cause left blank, or no statement that monitoring resumed after the fix
Security follow-up review	Post-incident actions tied to the failure, such as reviewing logs for activity during the gap, scanning affected systems or updating rules	Follow-up limited to restarting the service, with no check of what happened while the control was down
Timeline reconstruction	Time-synchronized logs from the monitoring platform and the affected system covering the failure window	Failure window cannot be reconstructed because the monitoring stack's own logs were not retained or clocks disagree

PCI DSS 10.7 evidence that passes an assessment

A QSA testing 10.7 looks for proof that critical control failures were caught, acted on and closed out, not just a monitoring tool that was installed once. The cards below cover the records the organization should hold in its own systems, and each one should be refreshed between assessments so it reflects what is running today.

Inventory of monitored critical controls

Keep a current list of every critical security control system in the cardholder data environment: NSCs, IDS/IPS, change detection, anti-malware, access controls, audit logging, segmentation controls, log review mechanisms and automated security testing tools. For each entry, record the owner, the host or platform, and the health signal that feeds monitoring. Review the list whenever a system is added, retired or moved, because an assessor will compare it against the network diagram and asset inventory. A missing entry is the most common gap found in sampling.

Alert rule definitions and change history

Export the alert rules that detect a silent or failed control, such as a stopped log forwarder, a sensor that stops reporting, or a rule set that loads with errors. Store the rule definitions in version control so each change carries an author, a date and an approval. Assessors look for evidence that the rules were in force throughout the assessment period, not only on the day of the audit. Tools such as Grafana Alerting and Wazuh keep rule definitions you can export and review.

Alert routing and notification test records

Keep records showing that a control failure alert reaches a person or on-call rotation who can act on it. Run scheduled test alerts through each channel, such as email, chat or paging, and record the time sent, the time received and the responder. Confirm that routing still works after staff changes, because a rule that fires into an unmonitored mailbox does not meet the requirement. Ask your platform owner to confirm which channels its alerting supports in your deployment.

Failure incident records with timestamps

For each real or simulated control failure, keep a record showing when the failure started, when it was detected, when it was alerted, and who responded. An assessor will sample these records and check whether the dates and times line up with system logs. Store the records in a ticketing or case system that enforces a timestamp and cannot be edited silently. Include incidents that were resolved quickly, since a sample with no failures can prompt questions about whether monitoring worked.

Restoration, duration and cause records

For each failure, document the steps taken to restore the security function, the total duration of the gap, and the root cause. Under 10.7.3, the response must also address any security issues that arose during the gap, so record the follow-up review of activity during that window. Assessors read these records against the requirement, so a ticket that says only "fixed" will not show restoration or duration. Use the same template for every incident so samples are easy to compare.

Resumed monitoring confirmation and monitoring health checks

Each incident should end with a confirmation that monitoring of the restored control resumed, with the evidence attached, such as a fresh heartbeat or a new log event from the sensor. Separately, schedule periodic checks that prove the monitoring itself works, for example a deliberate test that stops a feed and confirms an alert fires. Record the results of these checks with dates and the person who ran them. Organizations should confirm with their own platform team how often these checks run in their environment, since no frequency is set by the standard's supplied facts.

How to implement 10.7 in sequence and what each step produces

This sequence turns Requirement 10.7 from a policy statement into a working cycle: know which critical controls exist in the cardholder data environment, detect when each one stops working, respond with a documented procedure, and keep proof that the cycle runs.

Inventory and classify critical control systems in the CDE
Start by listing every security control system that protects the cardholder data environment: network security controls, IDS and IPS, change detection, anti-malware, physical and logical access controls, audit logging, segmentation controls, log review mechanisms and automated security testing tools. Record the owner, the host or service, the data source and the network segment for each one, and mark which ones the standard names explicitly. The output is a control register that the assessor can compare against your network and data-flow diagrams. The step is done when every control in the CDE has one owner and one entry, and the register is signed off by the security lead.
Define a failure signal for each control
For each registered control, decide what a failure looks like in measurable terms. Examples include a sensor that stops sending heartbeats, a log source that goes silent, a signature update that falls behind, an agent that is missing from a host, or a segmentation check that fails. Write the signal, the data source that carries it and the condition that triggers an alert. Where a control cannot report its own failure, document a compensating signal, such as a check from outside the control. The output is a failure signal catalog. The step is done when every register entry maps to at least one signal that someone has tested to fire.
Build detection rules and route alerts to an accountable group
Translate each failure signal into a rule in your monitoring stack. Open-source options such as Prometheus with Grafana Alerting, or OpenSearch Security Analytics and Wazuh for log-based detection, can evaluate these conditions, but confirm each capability in your own environment before you rely on it. Assign each rule to an on-call group with a named escalation path, and set the routing so that alerts reach a person outside the team that operates the failing control where possible. The output is a rule set with owners and a routing configuration. The step is done when a test alert reaches the on-call group through each channel you rely on, and that delivery is recorded.
Write and rehearse the response procedure
Write a runbook that covers the four elements 10.7.3 expects: restoring the failed security function, recording when the failure started and ended and what caused it, addressing any security issue that arose during the gap, and resuming monitoring. Add decision points for when the CDE must be restricted or when activity must be reviewed. Rehearse the runbook with the on-call group using a controlled failure, such as disabling a test sensor in a non-production copy of the environment. The output is a response runbook with a record of the rehearsal and the lessons captured. The step is done when the rehearsal record shows each 10.7.3 element was performed or explicitly handled.
Run a recurring test and capture evidence
Schedule recurring tests that deliberately trigger each failure signal and confirm that the alert fires, reaches the right group and produces a complete incident record. Store the rule definitions, routing configuration, test results, incident tickets and rehearsal notes in a location that cannot be silently edited, and tie each record back to a register entry. Review the register whenever the CDE changes, such as after a new system is added or a segment is redesigned. The output is an evidence set that shows the control operated over time. The step is done when a recent test cycle can be traced from register entry to alert to closed record without gaps. Confirm the test frequency with your QSA, since the standard sets expectations that depend on your assessment approach.

Self-hosted open-source tools that can produce 10.7 evidence

Requirement 10.7 is met by a process that detects, alerts on and responds to failures of critical controls, and assessors look for records of that process. The four tools below can each generate part of that evidence, from metric-based health alerts to log-based detection and alert records. None of them satisfies 10.7 alone, so the organization must decide which failures each tool watches and confirm how it behaves in its own environment.

Grafana Alerting for control health

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it can alert on metrics and logs together from a single view. For 10.7, this is useful for watching whether a control is still reporting, such as a log pipeline that has stopped delivering events or a sensor that has gone silent. Confirm which data sources your team can connect, who receives each notification, and how acknowledgment and follow-up are recorded. Grafana is licensed under AGPL-3.0-only, so have legal counsel review the license terms before deployment.

Prometheus for control metrics

Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels, on autonomous local storage. Teams use these series to show that a control service, such as an agent or scanner, is running and reporting. Your team should confirm which control components expose metrics, how long local retention lasts in your design, and how gaps in scrape data are detected and treated. Prometheus is licensed under Apache-2.0, and a legal review of your deployment is still advisable.

OpenSearch Security Analytics detection

OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, and alerts can go to channels such as Slack or email, with a correlation engine linking findings across log types. For 10.7, the findings and alert history can show that a failure was detected and routed. Confirm which rules cover your critical controls, that each detector is still active, and that the findings are retained for your review. OpenSearch is licensed under Apache-2.0; review the license with counsel before deployment.

Wazuh alert records and mapping

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for dashboard review. These files can serve as a durable record of control-failure alerts if you confirm which rules fire for events such as agent disconnection or disabled security services. Wazuh is licensed under GPL-2.0-only, so legal review is needed before you deploy or distribute it.

What meeting PCI DSS 10.7 costs in money and effort

This table breaks down the main cost components of building and evidencing failure detection for critical security controls, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to shape a written scope before asking for quotes, since no price or duration is supplied for this requirement. The main takeaway is that open-source tools remove license spend but leave engineering, runbook and evidence effort in place.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Tooling and licenses	Recurring if commercial; none for the software itself if self-hosted open source	Commercial alerting or SIEM licenses scale with data volume and users; open-source tools shift cost to hosting and operations	Confirm each license term (for example, AGPL-3.0 obligations for Grafana) with counsel before deployment
Infrastructure to host monitoring	Recurring	Log and metric volume, retention period, number of monitored control systems and high-availability design	Scope monitored components to the controls 10.7.2 names; size retention to the 10.5 requirement
Engineering time to build health signals and rules	One-time, with ongoing tuning	Number of control types covered, heterogeneity of log sources, and how many detection rules must be written from scratch	Reuse vendor or community rulesets where they fit, and standardize log formats early
Alert routing and response integration	One-time build, recurring maintenance	Number of alert channels, on-call rota design and integration with ticketing	Limit alerts to actionable control failures to reduce noise and rework
Runbooks and training	One-time, refreshed on change	Number of teams involved in restoration, staff turnover and changes to controls	Write one runbook per control family covering restoration, cause recording and monitoring resumption
Evidence upkeep	Recurring	Frequency of control failures, volume of failure records and the detail each record must hold for 10.7.3	Use a standard incident template that captures restoration, duration, cause and resumed monitoring
External testing or review	Recurring or per engagement	Scope of testing, whether an independent party reviews alert coverage, and frequency of changes	Agree scope in writing and test the detection path on a defined schedule rather than ad hoc
Auditor sampling during assessment	Recurring, per assessment cycle	Assessor sample sizes, quality of records and whether failures can be traced end to end	Keep records complete from the first failure so sampling does not expose gaps

Who does what for 10.7: your team, a partner and the assessor

Your organization owns the outcome of Requirement 10.7. The standard expects you to know which critical security controls are in scope, to detect when one stops working, and to respond in a documented way. Those decisions belong to your security and operations staff, even when a partner builds the tooling. Your team is also accountable for the on-call rota, because an alert that nobody acts on does not satisfy the requirement.

Control inventory: Maintain the list of critical controls in scope, such as NSCs, IDS/IPS, change detection, anti-malware, audit logging, log review mechanisms and automated security testing tools.
Alert routing: Decide who receives failure alerts, through which channel, and what the escalation path is when no one acknowledges them.
On-call response: Staff the rota and run the response steps: restore the function, record duration and cause, address related security issues and resume monitoring.
Evidence: Keep alert records, incident tickets and root-cause notes that show each failure was handled, not only detected.
Ownership of the policy: Approve the procedures that describe the above, and review them when systems change.

Before a validation, check that someone internal can explain how a failed control would be noticed and fixed, and can show a recent example from your own records.

Where organizations fall short on 10.7 and how to close each gap

Requirement 10.7.2 expects failures of critical security controls to be detected and addressed promptly, and 10.7.3 expects each response to be documented. The gaps below cluster around one problem: a control can fail silently, and nobody is accountable for noticing. Each card names a gap and a practical check an assessor is likely to ask about.

Controls listed but never health-monitored

Many organizations keep an inventory of NSCs, IDS/IPS, anti-malware, change detection and log review tools, yet none of them report whether they are running. A control that stopped sending heartbeats, lost its policy update or was disabled on one host looks identical to a healthy one on paper. For each control on the list, confirm a health signal exists, such as an agent check-in, a service status metric or a scheduled test, and that a missing signal raises an alert. Start with the systems in the cardholder data environment.

Alerts firing into an unwatched inbox

A failure alert is only useful if a named person or on-call rotation receives it during the hours the system operates. Alerts sent to a shared mailbox nobody reads, or to a channel without an owner, meet the letter of detection but not the intent of prompt response. Map each critical control to a routing rule, an owner and an escalation path. Test the path with a planned failure and keep the record, since an assessor will ask who acted and when.

Failure tickets without restoration or cause fields

Requirement 10.7.3 expects a response to restore the security function, record how long the failure lasted and its cause, address any security issue it created, and resume monitoring. Ticket templates that only ask for a description usually fail that test. Add required fields for restoration time, root cause, duration, related security events and the date monitoring resumed. A closed ticket missing these fields is the most common evidence gap we see in readiness reviews (illustrative).

Monitoring that stops when the log pipeline fails

Alerting depends on logs arriving. If the forwarder, broker or indexer fails, the detection rules keep running on nothing and produce no alerts, so the outage looks like a quiet night. Monitor the pipeline itself: ingestion rates, queue depth, forwarder check-ins and the age of the newest event from each critical source. Treat a source going silent as a failure in its own right, and include the pipeline in the 10.7 control list.

Third-party and cloud-managed controls left out

Firewalls, EDR consoles, WAFs and log services run by a cloud provider or managed service partner often sit outside the team's own dashboards. The organization still owns the requirement, so failures in those services must reach the organization's monitoring too. Ask each provider for the failure notifications it sends, the status feeds it exposes and the contractual response times. Record which controls are provider-operated in the responsibility matrix so an assessor can see who detects what.

Rule changes without change records

Detection rules, signature sets, alert thresholds and suppression lists change over time, and a quiet tweak can disable an alert that would have caught a control failure. Without a change record, nobody can show that a rule was intentionally modified or that the change was reviewed. Keep detection content in version control, require an approval step for changes, and log who changed what and why. Pair this with 10.7 testing so a rule change that silences an alert is caught before it causes a gap.

Questions buyers ask about 10.7 cost, effort and outside help

What drives the effort of meeting requirement 10.7?

Effort depends mostly on how many critical security controls are in scope and how well they already emit health signals. Each control in the cardholder data environment (NSCs, IDS/IPS, change detection, anti-malware, access controls, audit logging, segmentation, log review mechanisms and automated security testing tools) needs a way to notice when it stops working. Teams with centralized logging and existing alerting usually spend less time than teams where controls report only to their own consoles. Ask any provider to break the estimate down by control and by data source, and to state which assumptions about existing monitoring it depends on.

Who pays for what when a team works on 10.7?

The organization pays for its own staff time, for any licensed monitoring platforms it chooses, and for the infrastructure that runs them. An implementation partner is paid for the work in its written scope, such as designing detection rules, configuring alert routing, writing the failure response procedure and testing the alerts. An independent QSA or assessor is paid separately to assess the requirement. Most of the cost is one-time build work, while alert tuning, rule maintenance and on-call response recur every year. Open-source platforms remove license fees but not operating effort, so ask every quote to separate software, build labor and ongoing support.

What does the client team need to provide for a 10.7 engagement?

The client team needs to supply accurate information about its systems and people before any detection work starts. In practice this usually means:

An inventory of the critical security controls and the systems they protect
Access to the logging sources, consoles and cloud accounts that will feed alerts
A named owner who can approve alert routing and response steps
Staff available to review alerts during testing and to accept the failure response procedure

Without these inputs, the schedule slips, because the partner cannot validate that a failed control actually produces an alert.

Can our team meet 10.7 without an outside partner?

Yes, an internal team can meet 10.7 if it has the skills to deploy monitoring, write detection logic and test failure scenarios. The requirement does not require a partner, and the organization owns its controls and evidence either way. The practical question is capacity: the work spans logging, alerting, incident response and documentation, and it must be tested by deliberately failing controls in a controlled way. A partner can help by preparing systems and evidence on a fixed scope, while the internal team keeps ownership of the outcome.

What should a partner deliver under a fixed-scope 10.7 engagement?

A fixed-scope engagement should name its deliverables in writing before work starts. Expect a defined list such as:

An inventory of in-scope critical controls and their failure signals
Configured detection and alerting for each signal, with routing to named responders
A documented response procedure that covers restoring the function, recording the duration and cause, addressing the security issues that arose, and resuming monitoring
Test records showing that simulated failures generated alerts
An evidence pack that the organization can give its assessor

The partner prepares this material. Only the independent assessor decides whether the requirement is met.

Does requirement 10.7.1 still matter now that 10.7.2 applies?

Requirement 10.7.1 matters only for historical context and for teams reading older material. It was the earlier, service-provider-only version of the control failure requirement, and requirement 10.7.2 superseded it. From 31 March 2025, requirement 10.7.2 applies to all entities, and it covers a broader set of critical controls. Teams should build against 10.7.2 and its response requirement 10.7.3, and should confirm the current wording in the PCI DSS v4.0.1 document and the official SAQ D.

Does a certificate or tool badge prove 10.7 compliance?

No. A certificate, a tool badge or a platform logo does not count as validation of PCI DSS. The PCI SSC does not recognize certificates as validation, and compliance is documented through a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance. A monitoring platform can produce the alerts and logs that serve as evidence for 10.7, but the assessor decides whether the controls meet the requirement in the client's own environment.

How DeployOpen scopes and prepares 10.7 evidence

DeployOpen works on requirement 10.7 by agreeing the written scope of each monitored control first, then building detection, alerting and response records inside your own infrastructure. We prepare the systems and evidence, while your organization owns its controls and an independent QSA decides the assessment outcome.

How we scope

Inventory which critical security controls in your cardholder data environment fall under 10.7, including NSCs, IDS/IPS, anti-malware and logging.
Confirm which control failures generate alerts, who receives them and what response time your written scope commits to.
Agree in writing which deliverables, systems and environments are covered before any work begins, as most engagements are fixed-scope.

How we build

Configure health monitoring and alert rules for each in-scope control so a stopped or degraded control produces a recorded alert.
Set up response runbooks that capture restoration of the security function, duration, cause and any follow-up security issues.
Test failure scenarios in a controlled way to confirm that alerts fire, reach the right people and resume monitoring afterward.

How we hand over

Deliver documentation of the detection and alerting design, the list of monitored controls and the response procedure for failures.
Provide sample alert records, failure tickets and test results that show how each 10.7 element was met during the test.
Walk your team through operating the tooling so your staff can maintain the evidence trail between assessments.

How we support

Offer ongoing support, upgrades and continuous testing of the monitoring stack as a retainer when your team needs it.
Review alert coverage again when controls, network segments or the cardholder data environment change.
Coordinate evidence requests with your QSA, while the assessment conclusions and the Attestation of Compliance remain theirs to issue.