What PCI DSS v4.0 sets on each scheduled job
Sets the daily log review, the three-month scans, the six-month account review and the annual plan test in figures the held text states. Tick PCI DSS on the register and every job in these classes carries its row below. A lit cell is a figure the clause states; a row that reads no clock stays that way, because the register never fills a blank the standard left open.
The clock each rule sets
| Consumer class | Clock | Clause |
|---|---|---|
| Security monitoring and log review | ||
| Card environment log review | 24h | PCI DSS 10.4.1 Daily log review for critical systemsreviewed at least daily |
| no clock | PCI DSS 10.4.1.1 Automated mechanisms for log reviewautomated mechanisms | |
| Security event log review export | 24h | PCI DSS 10.4.1 Daily log review for critical systemssecurity events reviewed at least daily |
| no clock | PCI DSS 10.4.1.1 Automated mechanisms for log reviewautomated mechanisms | |
| Other system log review | no clock | PCI DSS 10.4.2 Periodic review of other system component logsperiodically |
| no clock | PCI DSS 10.4.2.1 Frequency defined by TRAthe frequency the targeted risk analysis defines | |
| Security alert and monitoring report | no clock | PCI DSS 10.7.2 Critical security control failure detection (all entities)promptly |
| File integrity and change detection | no clock | PCI DSS 10.3.4 File integrity or change detection on logsalerts on change to log data |
| Audit log retention and archive | no clock | PCI DSS 10.5.1 Audit log retention 12 monthstwelve months retained, three immediately available; no run period |
| Backup, restore and replication | ||
| Offline media backup and location review | 8,760h | PCI DSS 9.4.1.1 Offline media backup securitysecurity reviewed at least once every 12 months |
| Incident and breach reporting | ||
| Breach notification report pack | no clock | PCI DSS 12.10.1 Incident response plan |
| Incident and service report | no clock | PCI DSS 12.10.1 Incident response plan |
| Incident response exercise or drill | 8,760h | PCI DSS 12.10.2 IRP reviewed and tested annuallyreviewed at least once every 12 months and tested annually |
| Material control weakness report | no clock | PCI DSS 10.7.2 Critical security control failure detection (all entities)promptly |
| Access and identity reviews | ||
| User access review export | 4,380h | PCI DSS 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: • At least once every six months. • To ensure user accounts and access remain appropriate based on job function.at least once every six months |
| Privileged account review | 4,380h | PCI DSS 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: • At least once every six months. • To ensure user accounts and access remain appropriate based on job function.at least once every six months |
| Credential and password rotation | 2,160h | PCI DSS 8.3.9 Password change frequency if only factorchanged at least every 90 days |
| Regulatory returns and filings | ||
| Compliance attestation and scope confirmation | 8,760h | PCI DSS 12.5.2 PCI DSS scope documented and confirmed annuallyconfirmed at least once every 12 months |
| Targeted risk analysis review | no clock | PCI DSS 10.4.2.1 Frequency defined by TRAthe frequency the targeted risk analysis defines |
| Vulnerability and patch reporting | ||
| Vulnerability scan export | 2,190h | PCI DSS 11.3.1 Internal vulnerability scans quarterlyat least once every three months |
| 2,190h | PCI DSS 11.3.2 External vulnerability scans quarterly by ASVat least once every three months | |
| Patch compliance report | no clock | PCI DSS 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within onethe held text sets a period for critical patches; the figure is not in the copy held |
| Asset inventory sync | 8,760h | PCI DSS 12.5.2 PCI DSS scope documented and confirmed annuallyconfirmed at least once every 12 months |
| Board and management reporting | ||
| Audit evidence pack export | no clock | PCI DSS 10.5.1 Audit log retention 12 monthstwelve months retained |
The clauses in full
The following audit logs are reviewed at least daily: all security events, logs of all CDE system components, logs of critical systems, and logs of authentication, authorization, and accounting services.
What an assessor asks to see: SIEM dashboard showing daily review sign-off; Documented use cases reviewed daily; Triage tickets from daily reviews; Reviewer assignment and rotation. Where it usually falls short: Reviews skipped on weekends
Automated mechanisms are used to perform audit log reviews.
What an assessor asks to see: SIEM correlation rules export; UEBA or analytics tool configuration; Sample alerts and triage; Tuning records reducing false positives. Where it usually falls short: Manual-only review
Logs of all other system components (those not specified in 10.4.1) are reviewed periodically.
What an assessor asks to see: Review schedule for non-critical systems; Sample of completed reviews; Sign-off records by reviewer; Inventory of systems in scope. Where it usually falls short: Reviews not performed
The frequency of periodic reviews for all other system components is defined in the entity's targeted risk analysis.
What an assessor asks to see: TRA document with risk inputs and chosen cadence; Annual TRA review records; Approval by senior leadership; Mapping of cadence to system criticality. Where it usually falls short: No TRA
Failures of critical security control systems are detected, alerted, and addressed promptly for all entities (not just service providers), with documented response procedures.
What an assessor asks to see: Documented list of critical security controls; Health monitoring configuration per control; Alert routing to on-call; Sample failure tickets with response evidence. Where it usually falls short: List of critical controls missing
File integrity monitoring or change-detection mechanisms are used on audit logs to ensure that existing log data cannot be changed without generating alerts.
What an assessor asks to see: FIM tool configuration covering log paths; Sample FIM alerts on log modification tests; Coverage list across systems; Procedure for FIM alert triage. Where it usually falls short: FIM not deployed on logs
Audit log history is retained for at least 12 months, with at least the most recent three months immediately available for analysis.
What an assessor asks to see: SIEM retention policy configuration; Hot storage configuration for last 3 months; Cold storage location and accessibility evidence; Sample log restoration test results. Where it usually falls short: Retention below 12 months
Offline media backups containing cardholder data are stored in a secure location, with security reviewed at least once every 12 months.
What an assessor asks to see: Offsite vendor agreement and SOC report; Annual site security review evidence; Inventory of backup media offsite; Chain of custody records for media transfers. Where it usually falls short: Annual review skipped
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident, covering roles, responsibilities, communication, containment, and recovery.
What an assessor asks to see: Incident response plan with named roles; Communication trees including legal, comms, law enforcement; Containment and recovery procedures; Approval and version control. Where it usually falls short: IRP stale
The incident response plan is reviewed at least once every 12 months and updated as needed, and tested annually.
What an assessor asks to see: Annual IRP review minutes; Tabletop exercise reports; Lessons learned and IRP updates; Participant lists for exercises. Where it usually falls short: No annual test
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: • At least once every six months. • To ensure user accounts and access remain appropriate based on job function.
What an assessor asks to see: Auditable consent records with timestamp, version, and channel. Where it usually falls short: Consent capture mechanism does not record purpose, time, and version of notice shown
If passwords are the only authentication factor, they are changed at least every 90 days, or access to resources is dynamically analyzed and access granted based on security posture.
What an assessor asks to see: Password expiration policy set to 90 days where applicable; Dynamic access posture tool configuration if used; Coverage matrix of password-only systems; Sample of forced password changes. Where it usually falls short: Expiration disabled with no compensating control
PCI DSS scope is documented and confirmed at least once every 12 months by identifying all data flows, system components, and segmentation controls in use.
What an assessor asks to see: Scope document with named components; Data flow diagrams covering all CHD flows; Network and segmentation diagrams; Annual scoping exercise minutes and sign-off. Where it usually falls short: Diagrams stale
Internal vulnerability scans are performed at least once every three months, with high-risk and critical vulnerabilities resolved per the entity's risk ranking, and re-scans confirm resolution.
What an assessor asks to see: Quarterly scan reports for past 12 months; Risk ranking documentation; Remediation tickets with closure; Re-scan reports confirming fix. Where it usually falls short: Coverage incomplete
External vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) with passing scans achieved.
What an assessor asks to see: ASV scan reports for past 4 quarters (passing); ASV attestation of scan compliance; Remediation tickets for failed scans; Re-scan reports confirming pass. Where it usually falls short: No passing scan
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one
What an assessor asks to see: Risk appetite statement; Risk tolerance thresholds; Impact and likelihood scales. Where it usually falls short: Criteria not approved by leadership
Requirement text quoted from the standards themselves, published at compliance.theartofservice.com, the same publisher as this register, read against the held text of each standard: our statement of each clause, not the instrument verbatim. Every regime: the index.