The PCI DSS annual cycle: quarterly scans, annual validation and business as usual

Validation is yearly; compliance is continuous

After the first AOC is signed, the project has only changed shape. The acquirer, the card brands and, for service providers, your own customers expect a fresh validation every year, and the assessor who performs it samples evidence from across the whole period since the last one.

The standard builds this into its language. Many requirements carry a frequency: every quarter, every six months, at least once every twelve months, or after any significant change. Version 4 also asks you to define the frequency of some tasks yourself through a targeted risk analysis, and then to follow the frequency you chose. The annual cycle is therefore two things at once: a fixed calendar the standard imposes, and a set of dates your own risk analyses commit you to.

This guide covers what happens after validation. The steps of the assessment itself, and the choice between a ROC and an SAQ, are explained in PCI DSS validation step by step: ROC, SAQ and AOC.

A year-round PCI DSS calendar

The table below shows how a typical twelve-month cycle can be laid out, starting from the month after the last AOC. Your own dates depend on when your acquirer expects the next validation, on whether you are a merchant or a service provider, and on the frequencies set in your targeted risk analyses.

Quarterly scans: the rhythm the assessor checks first

Vulnerability scanning is the most visible part of the cycle, and the easiest to let slip. Internal scans run inside your network against the systems in scope; external scans must be performed by an Approved Scanning Vendor listed by the PCI Security Standards Council. Each is required once every quarter, and after significant change. A scan that finds high-risk or critical vulnerabilities is not the end of the task: you fix what it found and rescan until the result passes, then keep both reports.

What assessors look for is continuity. A year with a missed quarter, or a quarter with a failing ASV report and no passing rescan, is a finding that no amount of later scanning repairs. Schedule scans early in each quarter, leaving room for fixes and rescans.

Six-monthly and annual tasks that are easy to forget

The tasks that fall due once or twice a year are the ones that disappear when the person who owned them moves on. The main ones are:

• Penetration testing. Internal and external tests at least once every twelve months and after significant infrastructure or application change, with exploitable findings corrected and retested.
• Segmentation testing. Where segmentation reduces your scope, it is tested to prove the CDE is isolated: at least every twelve months for merchants, every six months for service providers, and after changes to the segmentation controls.
• Scope confirmation. A documented check that every location and flow of account data, and every connected system, is still inside the defined scope; annually for merchants and more often for service providers.
• Access reviews. User accounts and privileges reviewed every six months, with each decision recorded and unneeded access removed.
• Targeted risk analyses. Each analysis that sets a frequency or supports the customised approach is reviewed at least yearly.
• Training and incident response. Security awareness for everyone with access to the CDE, and a test of the incident response plan, each at least annually.
• Third parties. The compliance status of every service provider that can affect your card data is monitored, and their current AOCs collected, at least once a year.

Who needs which training, and how to record it, is covered in PCI DSS training: who needs what.

Handling significant change between assessments

The annual rhythm is interrupted by change, and PCI DSS expects that. A new payment channel, a data centre move, a cloud migration, a new firewall or a change to how network segments are separated can alter the CDE. The standard requires that such changes be assessed for their effect on PCI DSS: the requirements that apply to new or changed systems are confirmed as in place, documentation is updated, and the scans, penetration tests or segmentation tests that are triggered by significant change are performed before the change is treated as complete.

The practical difficulty is deciding what counts as significant. Write your own definition, agree it with your QSA, and build it into the change process as a mandatory question on every change request.

Changes that reduce scope, such as moving to a hosted payment page or tokenisation, belong in the cycle too; the options are explained in PCI DSS scoping and segmentation: shrinking the CDE.

Revalidation and the next version of the standard

Each year ends with a new validation. If the year has run well, the internal assessment in the last quarter confirms that every requirement has current evidence, and the ROC or SAQ becomes a record of work already done rather than a scramble to recreate it. The AOC then goes to your acquirer, and service providers share it with the customers who rely on it.

PCI DSS itself also moves. Version 4.0.1 is the only active version, and the requirements that were future-dated under version 4.0 have been mandatory since 31 March 2025. The PCI Security Standards Council publishes new versions with a transition period during which both versions may be used, followed by the retirement of the older one. When one is announced, map each change to your calendar and assign an owner. What changed in the current version is covered in PCI DSS v4.0.1: what changed and what your next assessment tests.

The PCI DSS annual cycle: questions buyers ask