PCI DSS 4.0 Requirement 10 overview
Requirement 10 covers 'Log and Monitor All Access to System Components and Cardholder Data'. The key sub-requirements: 10.2.1 (log all individual user accesses to cardholder data), 10.2.1.1 (log all actions by individuals with root or administrative privileges), 10.2.1.2 (log all access to audit trails), 10.2.1.5 (log use of identification and authentication mechanisms), 10.3.3 (retain audit logs for at least 12 months, 3 months immediately available), and 10.4 (review logs from security controls at least once daily).
PCI DSS 4.0 added Requirement 10.7 (promptly detect and address failures of critical security controls) and strengthened 10.6.3 to require automated anomaly detection for significant deviations from mean behaviour. These additions effectively mandate a behavioural detection capability — static threshold rules are no longer sufficient.
Cardholder Data Environment log sources
Every system in the CDE requires logging. Define the CDE boundary first — all systems that store, process, or transmit cardholder data (CHD), plus all systems that could affect the security of the CDE. Common CDE components: payment gateway servers, POS systems, databases containing PAN data, authentication systems (IdP, PAM), network infrastructure in the CDE segment, and any cloud resources in the CDE scope.
ManySignal ingests CDE log sources via connectors. For databases (PostgreSQL, MySQL, Oracle), use the database audit log connector. For network infrastructure, use syslog connectors. For cloud CDE components, use the corresponding cloud connector. Validate each connector by confirming a known access event appears in the entity graph.
# connector.yaml — PostgreSQL CDE database audit log
key: postgres_cde_audit
name: PostgreSQL CDE — Audit Log
mode: poll
schedule_seconds: 60
source_query: |
SELECT log_time, user_name, database_name,
command_tag, object_type, object_name,
application_name, client_addr
FROM pg_catalog.pg_log
WHERE log_time > $cursor
AND command_tag IN ('SELECT','INSERT','UPDATE','DELETE')
AND object_name ILIKE '%cardholder%'
OR database_name = 'payments_db'
ocsf:
class_uid: 3005 # API Activity
retention:
hot_days: 90
cold_days: 365Meeting the daily log review requirement (10.4)
Requirement 10.4 mandates daily review of logs from security controls, authentication servers, and systems in the CDE. This is the requirement most often failed by organisations relying on manual log review — the volume makes consistent daily review impossible without automation.
ManySignal satisfies 10.4 via the automated review model: the detect agent evaluates all CDE logs continuously, and the triage agent renders verdicts on every finding. The daily metrics report (generated automatically) is the documented evidence of daily review — it shows the total events processed, findings generated, verdicts rendered, and any open cases. This report is the QSA evidence artefact for Requirement 10.4.
Anomaly detection requirement (10.6.3 and 10.7)
PCI DSS 4.0 Requirement 10.6.3 requires detection of significant deviations from mean behaviour. ManySignal's per-entity behavioural baselines satisfy this requirement directly: every identity, device, and application in the CDE has a baseline, and deviations are scored and alerted. The baseline methodology is documented and available for QSA review.
Requirement 10.7 requires prompt detection of failures of critical security controls. ManySignal monitors the connector health for all CDE log sources — a connector that stops receiving events generates a platform alert within the configured staleness window (default 15 minutes). This alert is evidence that the organisation detects monitoring failures promptly.
Retention and evidence for QSAs
Requirement 10.3.3 specifies 12 months retention with 3 months immediately available. Configure ManySignal retention for all CDE connectors: hot tier 90 days (immediately available), cold tier 275 days (total 365 days). Export retention configuration as a PDF for the QSA evidence package.
For each sub-requirement in Req 10, prepare a one-page evidence sheet: the requirement text, the ManySignal capability that satisfies it, a screenshot or export of the capability in action, and a pointer to the policy document that mandates its use. QSAs process dozens of requirements per engagement — clear evidence packages reduce assessment time.
Key takeaways
- PCI DSS 4.0 Req 10.6.3 mandates behavioural anomaly detection — static threshold rules are insufficient.
- Req 10.4 daily log review is satisfied by automated detection + daily metrics report as evidence.
- Req 10.3.3: 90-day hot tier + 275-day cold tier = 365 days total, 3 months immediately available.
- Connector health monitoring satisfies Req 10.7 — document the staleness alert window.
- Prepare per-requirement evidence sheets; QSAs process dozens of requirements per engagement.
- The automated verdict rate and daily metrics report are the primary operating evidence artefacts for Req 10.