PCI DSS renewal is a re-scope, not a repeat

Nothing renews. PCI DSS issues no certificate with an expiry date to extend, and the anniversary does not entitle you to re-run last year's assessment against last year's environment. What the market calls a PCI DSS certification renewal is a fresh determination of what your cardholder data environment is now, followed by an assessment of that.

The standard says so in a requirement most renewal projects never open. PCI DSS v4.0.1, Requirement 12.5.2:

“PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.”

Its applicability note closes the obvious escape route:

“This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity's assessor during the annual assessment.”

The re-scope is the entity's own work. Handing over last year's diagrams so the assessor can work out what moved is not a substitute for it.

What 12.5.2 asks you to redo

The requirement names seven minimum elements — seven places where twelve months of ordinary engineering quietly invalidates last year's answer:

• All data flows for every payment stage — authorisation, capture, settlement, chargebacks, refunds — and every acceptance channel. A refunds console added to an admin panel is a new flow.
• Updated data-flow diagrams per Requirement 1.2.4 — the artefact most often re-dated rather than redrawn.
• Every location where account data is stored, processed or transmitted, including outside the current CDE, and file backups. A reporting replica; a log pipeline that started capturing request bodies.
• Every system component in the CDE, connected to it, or able to affect its security. A second cluster, a bastion host, a CI runner holding deploy credentials.
• Every segmentation control in use, with justification for what sits out of scope.
• Every third-party connection into the CDE — an observability agent, a support tunnel, an orchestration layer between you and the gateway.
• Confirmation that all of the above are in scope.

The standard tells you which changes count

PCI DSS declines to define a significant change generically — it depends on the environment — but it names six activities that “at a minimum, [have] potential impacts on the security of the CDE and must be considered and evaluated”:

• New hardware, software or networking equipment added to the CDE
• Any replacement or major upgrade of hardware and/or software in the CDE
• Any changes in the flow or storage of account data
• Any changes to the boundary of the CDE and/or to the scope of the assessment
• Any changes to the underlying supporting infrastructure of the CDE, including directory services, time servers, logging and monitoring
• Any changes to third-party vendors or service providers, or to the services provided, that support the CDE or meet PCI DSS requirements on your behalf

The last two catch competent teams. Moving from self-hosted logging to a managed platform touches no card data and lands on bullet five; changing SIEM vendors lands on bullet six. Neither feels like a payments change; both must be evaluated.

Two clocks, and it is the second one that gets missed

“At least once every 12 months” is a floor, not a schedule. A renewal file in which every artefact is dated within three weeks of the anniversary claims, implicitly, that nothing on the six-bullet list happened all year. The change record says otherwise, and Requirement 6.5.2 points straight at it — “These significant changes should also be captured and reflected in the entity's annual PCI DSS scope confirmation activity per Requirement 12.5.2.”

Why last year's test scope comes apart first

The testing procedures for 11.4.2 and 11.4.3 do not open on the findings. Both open the same way: “Examine the scope of work and results from the most recent… penetration test.” The scope of work is a document; the documented CDE from 12.5.2 is a document. Comparing two documents is the cheapest check there is, and it happens before a single finding is read. A scope narrower than the documented CDE is not a criticism of how the testing was done — it is a gap in what was covered, and depth inside the tested range does not close it. The same logic runs through 11.4.5, which requires coverage of “all segmentation controls/methods in use”: in use now, not when the statement of work was drafted.

Requirement 11.4.1 makes the same point about the methodology, which must include “Review and consideration of threats and vulnerabilities experienced in the last 12 months” — an input that did not exist when a carried-forward methodology was written. What gets a PCI penetration test report rejected takes the rest of that list apart.

The attestation asks the re-scope questions on its face

Part 2 of the Attestation of Compliance — the executive summary, before a single requirement response is recorded — asks which payment channels are included and why any are excluded; how each stores, processes or transmits account data; what the environment covered looks like and whether segmentation reduces scope; PCI SSC validated products in use, with listing reference numbers and expiry dates; and third-party service providers by name. Every one is a question about the current year. The expiry date is the quiet one: it sits on somebody else's document, it generates no change ticket on your side, and a P2PE or validated payment software listing that lapsed in month seven changes what you can put in Part 2e. Eligibility for a given SAQ is annual too — the Instructions and Guidelines require it to be confirmed before a self-assessment begins, not inherited from last year.

Sequencing the second year

Pull the change record first. It is the input 12.5.2 needs and the evidence of whether the event-triggered tests happened when they should have. Then reconcile three artefacts against each other and against the running environment: the data-flow diagram, which 1.2.4 requires to be “updated as needed upon changes to the environment”; the in-scope component inventory, which 12.5.1 requires to be “maintained and kept current”; and the 12.8.5 record of which requirements each service provider manages, which you manage, and which are shared. Where those three disagree, the disagreement is the re-scope, and what surfaces is usually mundane and expensive — a staging environment that acquired production card data, a decommissioned host that still answers.

Only then scope the testing, and leave room for the second pass: 11.4.4 requires exploitable findings to be corrected against your 6.3.1 risk ranking, and “Penetration testing is repeated to verify the corrections”. A test booked three weeks before the assessment window closes has no room for that retest. Related: scoping the CDE, which SAQ applies to you, segmentation testing under 11.4.5, and the tighter clock RBI-regulated payment aggregators run on.

The renewal that fails is run as a procurement exercise: repeat last year's statement of work, repeat last year's dates, re-date last year's diagram. The one that holds follows the standard's order — confirm the scope, test what it produced, fix, retest. Commissioned that way, penetration testing scoped to Requirement 11.4 produces evidence that answers the question asked first: what was in scope this year, and how do you know?