If your business processes, stores, or transmits cardholder data — credit card numbers, CVVs, expiration dates, or any sensitive authentication data — PCI DSS is not optional. The Payment Card Industry Data Security Standard mandates specific technical controls, and unlike some compliance frameworks that describe goals, PCI DSS Requirements 10 and 11 describe operational monitoring in concrete terms.
Most teams think of PCI DSS as a network segmentation and encryption exercise. That's true, but requirements 10 through 11 put monitoring squarely in scope: audit logging of access to cardholder data, alerting on suspicious activity, and regular testing of security controls. When your QSA (Qualified Security Assessor) reviews your evidence, "monitoring" is one of the first things they examine.
This guide explains what PCI DSS actually requires from a monitoring perspective, what QSAs look for during assessments, and how to set up monitoring that produces the evidence you'll need.
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.
How PCI DSS Directly Requires Monitoring
PCI DSS v4.0 (current as of 2024) dedicates two full requirements to monitoring and testing.
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 — Network intrusion detection (NIDS/NIPS) and file integrity monitoring
- 11.6.1 — Deploy a change and tamper detection mechanism for payment pages (especially relevant for e-skimming attacks on web-based payment flows)
For operational teams, Requirement 11.6.1 (added in PCI DSS v4.0) is one of the most actionable new requirements: you must continuously monitor payment pages for unauthorized changes to HTTP headers and script content. This is directly served by uptime monitoring with content validation.
What "Monitoring" Means Under PCI DSS v4.0
PCI DSS doesn't prescribe specific tools. It prescribes outcomes. QSAs evaluate whether your monitoring satisfies the intent of each requirement. For practical purposes, they look for:
- 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 CDE Systems
Every system in your cardholder data environment must be continuously monitored for availability:
- Uptime monitoring on all CDE-scoped services with check intervals of 1–5 minutes
- TLS / SSL monitoring — Encryption in transit is required (Requirement 4.2); expired or downgraded TLS is both an availability and a confidentiality issue
- 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 — PCI DSS v4.0 requires monitoring at least every 7 days (and ideally continuously)
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 |
Setting Up PCI DSS-Aligned Monitoring
Minimum viable baseline
- Uptime monitoring of all CDE-scoped services at 5-minute or tighter intervals
- 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
PCI DSS requires notification to your acquiring bank and potentially your card brand(s) for suspected breaches. Your QSA can advise on thresholds, but don't delay — the faster you notify, the better your position.
Incident Communication: Status Updates During Outages covers the customer-facing communication side.
How Webalert Helps
Webalert provides external monitoring specifically valuable for PCI DSS compliance:
- 24/7 uptime monitoring — continuous availability evidence for all CDE-scoped services
- Content change detection — monitor payment pages for new scripts, iframes, and header changes (Req 11.6.1)
- SSL / TLS monitoring — catch certificate issues on payment domains before they affect availability or encryption
- Multi-region HTTP checks — coverage across all regions where cardholders access your systems
- 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 — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
- Status pages — transparent customer communication during payment system incidents
- 5-minute setup — start building PCI-relevant monitoring evidence today
Webalert does not store, process, or transmit cardholder data. We monitor the availability and integrity of systems that may. Confirm with your QSA how external monitoring integrates with your CDE boundary and evidence requirements.
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's Requirement 11.6.1 mandates continuous monitoring of payment pages for unauthorized script and header changes — a direct use case for content change detection.
- 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.
PCI DSS turns payment security into an auditable process. Monitoring is how you prove the process actually runs.