PCI DSS v4.0.1 has specific monitoring obligations, but an uptime tool does not make an environment PCI DSS compliant. Requirement 10 addresses audit logs and their review; Requirement 11 includes security testing and payment-page change/tamper detection. Scope, implementation, evidence, and validation still depend on your payment flow and assessment method.
This guide separates those control families from general availability monitoring, shows where outside-in checks can contribute evidence, and identifies the work that belongs in SIEM, file-integrity, vulnerability-management, and payment-page security tooling. Use the PCI SSC PCI DSS resource page and Document Library for the current standard and official supporting documents.
Disclaimer: This guide is general technical guidance, not legal or compliance advice. For binding PCI DSS interpretations specific to your merchant level and card brand requirements, consult your QSA, acquiring bank, or qualified payment compliance specialist.
Where PCI DSS v4.0.1 Requires Monitoring
PCI DSS v4.0.1 is the current limited revision in the v4.x line. Always verify requirement text in the official document rather than relying on a summary.
Requirement 10 — Log and Monitor All Access to System Components and Cardholder Data
Requirement 10 mandates that all access to system components in the cardholder data environment (CDE) be logged and monitored. Specific requirements include:
- 10.2.1 — Implement audit logs to capture individual user access to cardholder data
- 10.2.1.2 — Log all actions taken by any individual with root or administrative privileges
- 10.2.1.3 — Log access to all audit trails
- 10.2.1.4 — Log invalid logical access attempts
- 10.2.1.5 — Log use of and changes to identification and authentication mechanisms
- 10.2.1.6 — Log initialization, stopping, or pausing of audit logs
- 10.2.1.7 — Log creation and deletion of system-level objects
- 10.3 — Protect audit logs from destruction and unauthorized modifications
- 10.4 — Review audit logs and security events to identify anomalies
- 10.5.1 — Retain audit log history for at least 12 months, with at least 3 months immediately available
- 10.6 — Synchronize time across all system components (NTP)
- 10.7 — Detect failures of critical security controls — including monitoring systems themselves
The last point is crucial: if your monitoring system fails, PCI DSS expects you to detect and respond to that failure quickly.
Requirement 11 — Test Security of Systems and Networks Regularly
Requirement 11 covers active security testing:
- 11.3 — External and internal penetration testing at least annually and after significant changes
- 11.4 — Intrusion detection systems (IDS/IPS) to alert on personnel of suspected compromises
- 11.5 — Intrusion- and change-detection controls within its defined scope
- 11.6.1 — Deploy a change- and tamper-detection mechanism for the HTTP headers and contents of payment pages as received by the consumer browser
Requirement 11.6.1 is not ordinary uptime monitoring. The mechanism must evaluate payment-page headers and content as received by the consumer browser, detect unauthorized changes, and alert personnel. Its required cadence follows the standard's stated weekly option or a documented targeted-risk-analysis frequency. A basic server-side string check may add defense in depth but does not automatically satisfy this browser-facing requirement.
What "Monitoring" Means Under PCI DSS v4.0
PCI DSS generally defines control outcomes and testing procedures rather than endorsing tools. Assessors evaluate the applicable requirement text, implementation, and evidence. For monitoring-related controls, useful review dimensions include:
- Coverage — Are all CDE system components being monitored?
- Timeliness — How quickly are anomalies detected and responded to?
- Log integrity — Are logs tamper-evident and retained for at least 12 months?
- Review process — Are logs actually reviewed, not just collected?
- Alerting — Do anomalies generate alerts that reach personnel who act on them?
- Testing — Are monitoring controls tested regularly?
- Documentation — Is every control documented, with evidence of operation?
What to Monitor for PCI DSS Evidence
1) Availability of Payment Services
Availability checks can support service operations and incident evidence, but do not substitute for Requirement 10 log controls or Requirement 11 security testing:
- Uptime monitoring on selected in-scope and customer-facing services at a risk-appropriate cadence
- TLS / SSL monitoring — helps detect certificate and protocol failures; validate Requirement 4.2 separately against the actual transmission paths and strong-cryptography configuration
- Multi-region availability — If cardholders access your systems from multiple regions, confirm reachability from each (see Multi-Region Monitoring: Why Location Matters)
- Payment page availability — Your checkout is where cardholder data enters; monitor it as a dedicated check
2) Payment Page Integrity (Req 11.6.1)
PCI DSS v4.0 added explicit requirements for monitoring payment pages against e-skimming. QSAs will ask for evidence:
- Content monitoring on checkout pages — Verify the page HTML contains expected payment form elements and no unexpected scripts
- Script inventory — Alert when any new
<script>tag,<iframe>, or external resource appears on your checkout page - HTTP response header monitoring — Alert on changes to
Content-Security-Policy,X-Frame-Options, and related security headers - Change detection frequency — use the cadence permitted by Requirement 11.6.1 and document any targeted risk analysis; increase frequency when risk and business impact justify it
See Content Change Detection for how to implement this pattern.
3) Authentication and Access Control Monitoring
Requirements 10.2.1.4 and 10.2.1.5 specifically require logging invalid access attempts and authentication changes:
- Failed login rate on CDE systems — Alert on spikes that might indicate brute force
- Privileged action logging — Every admin action on CDE systems must be logged
- Authentication flow synthetics — Verify login to CDE-adjacent systems works (see How to Monitor Your Login and Authentication Flow)
- Session token rotation — Alert on unexpected changes to session management behavior
4) Audit Log Pipeline Integrity
Requirement 10.3 requires protecting audit logs. Requirement 10.7 requires detecting failures of the monitoring system itself:
- Log ingestion monitoring — Alert if the rate of log ingest drops unexpectedly (could mean logs are being suppressed)
- Log volume baselines — Alert on spikes (potential incident) and drops (potential logging failure)
- Log storage health — Monitor disk space and write availability on log storage
- Heartbeat from the monitoring system — Your monitoring tool should have its own health check
5) Network Security Monitoring (Req 11.4 / 11.5)
- Intrusion detection alerts from your IDS/IPS (via SIEM)
- Firewall rule change monitoring — Alert on any change to firewall rules that affects CDE access
- Unexpected open ports — Alert on new ports becoming accessible on CDE hosts
- File integrity monitoring (FIM) — Alert on unexpected changes to critical CDE system files and configurations
6) Time Synchronization (Req 10.6)
- NTP monitoring — All CDE clocks must be synchronized; a drifted clock invalidates your log timestamps and makes forensic reconstruction impossible
- Clock drift alerts — If any CDE system's clock drifts more than a few seconds from the NTP source
7) Third-Party Payment Processors
If you rely on a third-party payment processor (Stripe, Adyen, Braintree, etc.):
- Monitor their availability as a dependency (see Third-Party Dependency Monitoring)
- Track processor incidents in your incident log
- Verify your integration endpoints remain reachable and responsive
- Watch for webhook delivery failures from the processor (missed payment confirmations)
8) Incident Detection Time
PCI DSS doesn't specify a numeric detection time, but QSAs evaluate whether your response is timely. Track:
- Mean Time To Detect (MTTD) — How long between an anomaly occurring and your first alert?
- Mean Time To Acknowledge (MTTA) — How long until a human responds?
- Incident log completeness — Every security event must be documentable with a start time, detection time, and resolution time
Evidence QSAs Look For
When your QSA reviews your monitoring during an assessment:
| Question | Evidence to Provide |
|---|---|
| How is CDE availability monitored? | Monitoring tool, list of CDE endpoints, check intervals |
| How is the payment page monitored for unauthorized changes? | Content monitoring config, alert rules, last review date |
| How are invalid access attempts detected? | Log examples, alert thresholds, escalation records |
| Show me audit logs for a specific date range | Centralized log system, log query examples |
| How long are audit logs retained? | Retention policy, storage config, log rotation rules |
| What happens when monitoring fails? | Monitoring heartbeat, failure runbook, escalation policy |
| Show me an example security incident response | Incident timeline, root cause, remediation, evidence |
| When did your last penetration test occur? | Pen test report, remediation evidence |
| How are payment page scripts monitored (11.6.1)? | Script inventory, change detection alerts, review log |
| How are third-party processor issues handled? | Processor dependency monitoring, incident log |
Common PCI DSS Monitoring Gaps
| Gap | Requirement | Fix |
|---|---|---|
| No dedicated monitoring of the checkout page | Req 10, 11.6.1 | Uptime + content validation on /checkout |
| Audit log pipeline fails silently | Req 10.7 | Heartbeat + log volume baseline alert |
| Failed login attempts not alerted | Req 10.2.1.4 | Authentication failure rate alert |
| SSL cert expiry on payment domain unmonitored | Req 4.2 | SSL monitoring with 30-day notice |
| No script inventory for payment page | Req 11.6.1 | Content change detection with script diff |
| Single-region monitoring | Req 10 (coverage) | Multi-region HTTP checks |
| Log retention under 12 months | Req 10.5.1 | Review retention policy and storage |
| NTP drift unmonitored | Req 10.6 | Clock drift alerting |
| Third-party processor outages not logged | Req 12.8 | Processor dependency monitoring + incident log |
| Alert fatigue causes ignored real events | Req 10.4 | See Alert Fatigue |
Build Monitoring That Supports a PCI DSS Control
Operational baseline
- Inventory and scope the payment pages, supporting systems, scripts, and evidence owners with your assessor
- TLS certificate monitoring with at least 30-day expiry warnings on all payment domains
- Content change detection on the checkout/payment page (script inventory)
- Audit log pipeline heartbeat — alert on failure
- Incident log with timestamps for detection, acknowledgment, and resolution
- Multi-region checks from regions where cardholders access your systems
QSA-ready setup
Add:
- Script and header change detection on all payment pages (Req 11.6.1)
- Failed login rate alerts on CDE-adjacent systems
- Log volume baseline alerts (ingest drops and spikes)
- NTP clock drift monitoring
- Third-party processor health in your monitoring dashboard
- Quarterly vulnerability scan scheduling with automated alerts on findings
- Status page for transparent incident communication
- Annual monitoring effectiveness review documented for QSA evidence
What to Do When Monitoring Detects a CDE Incident
PCI DSS-aware incident response has additional obligations compared to a pure operational response.
1) Triage with cardholder data exposure in mind
For every detected incident, ask early: could cardholder data have been accessed, modified, or exfiltrated?
- If unauthorized access to CDE systems is possible — your breach notification obligations may apply
- If payment page content changed unexpectedly — assume e-skimming until proven otherwise
- If availability is impacted but no breach — document for the incident record and review timeline
2) Document rigorously
Your QSA will want log evidence from the detection period. Preserve:
- First alert timestamp from your monitoring tool
- All log entries from the relevant time window
- Actions taken and by whom
- Time of containment and resolution
3) Loop in your QSA and acquirer for significant incidents
Incident-notification duties can arise from card-brand programs, acquiring-bank agreements, law, and the organization's incident plan; they are not reducible to one PCI DSS sentence. Escalate internally without delay and follow the contacts and timelines confirmed with your acquirer and counsel.
Incident Communication: Status Updates During Outages covers the customer-facing communication side.
Where External Monitoring Can Contribute
External monitoring can contribute availability and integrity signals to a broader PCI DSS control environment:
- Availability checks — timestamped reachability evidence for the selected payment services and dependencies
- Content change detection — flag sampled page or header changes for investigation; validate separately whether the implementation meets every part of Requirement 11.6.1
- SSL / TLS monitoring — catch certificate issues on payment domains before they affect availability or encryption
- Multi-region HTTP checks — Webalert covers US, EU, and APAC regions; use additional probe locations if cardholder access or the targeted risk analysis requires them
- DNS monitoring — detect resolution failures that could redirect users away from your legitimate payment page
- Incident records — timestamped detection, acknowledgment, and resolution data for QSA evidence
- Multi-channel alerts — Webalert lists Email and Slack on all plans; SMS, webhooks, Discord, and Microsoft Teams are paid-plan channels
- Status pages — transparent customer communication during payment system incidents
Webalert's canonical pages do not list response-header assertions or script inventory. Use a header/browser-capable control for those Requirement 11.6.1 checks and validate the implementation with your QSA.
Do not put account data or sensitive authentication data into monitor URLs, request bodies, screenshots, logs, or alert payloads. Confirm scope, evidence, and requirement interpretation with your QSA or other validating entity.
See features and pricing for details.
Summary
- PCI DSS Requirements 10 and 11 are explicitly about monitoring: audit logging, anomaly detection, and security testing.
- PCI DSS v4.0.1 Requirement 11.6.1 addresses payment-page change and tamper detection in the consumer browser; generic uptime or content checks are not automatically sufficient.
- QSAs look for coverage, timeliness, log integrity, alerting, and documentation — not specific tools.
- Monitor CDE availability, TLS, payment page content, auth events, audit log pipelines, and third-party processors.
- Track detection time, acknowledgment time, and resolution time for every incident.
- The monitoring system itself must be monitored — Req 10.7 is explicit about this.
Monitoring supplies evidence for specific controls. Compliance depends on the complete, correctly scoped control environment and its required validation.