Passing a PCI DSS assessment shows you met the requirements on the assessment date. Staying compliant means running a calendar of recurring work: scope confirmation, log reviews, vulnerability scans, access reviews, awareness training and change checks, each with a record. Build that calendar in the first month after you pass.
What changed in version 4.0 about "business as usual"
Version 4.0 makes many recurring tasks explicit. The Council's summary of changes lists new requirements that are really calendar items: scope confirmed at least every 12 months and after significant change (12.5.2), cipher suites and protocols reviewed every 12 months (12.3.3), hardware and software technologies reviewed every 12 months (12.3.4), the awareness program reviewed every 12 months (12.6.2), and user account reviews (7.2.4). Service providers carry a tighter cycle: scope confirmed every six months (12.5.2.1).
A year in four layers
Daily and weekly. Automated audit log review is now expected (10.4.1.1). Alerts on failures of critical security controls, such as logging, anti-malware or access control, need prompt response (10.7.2 and 10.7.3). Payment page change and tamper detection should alert you, not wait for a review (11.6.1).
Monthly. Patch cycles, vulnerability triage and review of any exceptions. Internal scans should be authenticated (11.3.1.2), and findings below high or critical still need managing (11.3.1.1). Keep scan reports, rescans and the ticket that closed each finding.
Quarterly. Intervals that you set yourself belong here, and your targeted risk analysis (12.3.1) is the justification for them. Typical examples are malware scans and periodic reviews of systems not at risk for malware, which the standard asks you to define in a targeted risk analysis (5.2.3.1, 5.3.2.1). Review them whenever the threat picture or your systems change.
Annually. Scope confirmation, inventory reviews (software, certificates, technologies), policy review, awareness training refresh, incident response test, third-party responsibility matrix, and a rebuild of the evidence set for the next assessment.
Change is the real risk
Most drift comes from change: a new payment provider, a new network segment, a script added by marketing. Add a PCI check to your change process. Ask three questions for every significant change: does it touch account data, does it alter the network path to the cardholder data environment, does it add third-party code to a payment page? If any answer is yes, update scope and diagrams and trigger the relevant reviews. Requirement 12.5.2 expects scope to be reconfirmed after significant change, not just yearly.
Keep evidence as you go
The cheapest way to survive next year's assessment is to file evidence at the time: dated, attributable, and stored where an assessor can reach it. A folder per requirement area with monthly subfolders is enough. Record who performed each task, not just that it happened.
What to do
- Turn every recurring item above into a calendar entry with an owner and a place to store proof.
- Set up automated log review and alerts, and test that the alerts reach a person.
- Schedule authenticated internal scans and external scans, and define remediation targets in your procedure.
- Add the three PCI questions to your change approval form.
- Hold a short monthly review: open findings, expired exceptions, upcoming annual items.
- Revisit targeted risk analyses at least when your environment changes.
- Start the next evidence pack on day one.
Quick check
Do I need to rescan after every change?
The material we reviewed ties scanning to a schedule and to significant changes. Confirm the exact wording of 11.3 and your acquirer's rules in the standard itself.
Who decides my review frequencies?
For requirements that allow flexibility, you do, through a documented targeted risk analysis under 12.3.1. An assessor will test that your analysis supports the interval.
How Safeguard helps automate this
The calendar above is where most teams lose momentum, because the work is repetitive and the proof is scattered. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and checks run continuously between assessments. That saves your team time for other work. Technical evidence for scanning and vulnerability handling comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you pick which categories run automatically and the approval level. Safeguard does not replace your assessor or guarantee a result. Book a call to see continuous monitoring on your stack.
Sources
- PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0
- PCI SSC: Just Published, PCI DSS v4.0.1
- The full standard is behind a download gate we could not fetch. Check intervals against v4.0.1.
Last reviewed: 18 October 2026.
