PCI DSS Isn’t “Done” — What Ongoing Compliance Looks Like in Year Two

Completing your first PCI DSS assessment is a major milestone, but it is not the end of the work. It establishes the starting point for the first full compliance cycle, in which your organization must operate the controls and processes it just put in place.

PCI SSC does not define an official "Year Two" program. Here, Year Two means the first subsequent compliance cycle after your initial PCI DSS assessment.

The shift is straightforward: Year One focuses on establishing the program. Year Two is about demonstrating that the program continues to work.

That makes PCI DSS ongoing compliance less about preparing for one assessment and more about maintaining controls, completing recurring activities on schedule, managing changes to the cardholder data environment (CDE), and preserving evidence throughout the year.

What changes after your first PCI DSS assessment?

The biggest difference in Year Two is that your organization now has a compliance history.

However, once you submit a formal compliance validation document for that requirement, later assessments of that requirement are no longer considered initial assessments.

That distinction changes what readiness looks like.

In other words, you can't compress Year Two into a few weeks of audit preparation. If an activity was supposed to happen months ago, doing it just before the assessment doesn't prove it happened when required.

The formal validation route also varies. PCI SSC says compliance-accepting entities, typically payment brands and acquirers, determine how merchants and service providers must validate and report compliance, including whether a Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) is appropriate.

So the practical Year Two question is not simply, "When do we start the next assessment?"

It is: "What do we need to keep doing between assessments so we can demonstrate that PCI DSS remained in place?"

» Not sure whether your business needs a RoC or SAQ? Get expert guidance to evaluate your payment environment and determine the right PCI DSS compliance path.

What ongoing PCI DSS work needs to happen during Year Two?

Applicable PCI DSS controls need to continue operating throughout the year. Activities with defined frequencies must occur within those timeframes. At the same time, continuous controls must remain effective as systems, people, and business processes change.

The exact requirements depend on your environment, assessment scope, entity type, payment channels, and applicable validation method. The examples below are therefore representative rather than a universal checklist.

Recurring security activities need to happen on schedule

Vulnerability management is one of the clearest examples.

Where applicable, PCI DSS requires internal and external vulnerability scans, including necessary remediation, at least once every three months. PCI SSC explains that three months, or approximately 90 days, is the maximum intended interval between these recurring scans. Scans are also required after significant changes where applicable.

Other time-bound requirements operate on different schedules. For example, network security control configurations must be reviewed at least once every six months. PCI DSS also requires patches and updates addressing vulnerabilities the entity categorizes as critical to be installed within one month of release; other applicable patches follow risk-based timeframes defined by the organization.

Where PCI DSS penetration-testing requirements apply, internal and external penetration tests must be performed at least once every 12 months and after significant infrastructure or application upgrades or changes. Address exploitable vulnerabilities and security weaknesses identified through the tests based on risk, then retest to verify the corrections.

Governance activities also recur. Depending on applicability, these include annual security-awareness training, reviewing and testing the incident-response plan at least once every 12 months, and reviewing targeted risk analyses used to determine the frequency of certain activities.

The point is not to memorize a list of annual and quarterly tasks. The point is to translate your applicable PCI DSS requirements into an operating calendar with owners, due dates, and escalation paths.

Evidence should be created as the controls operate

Year Two evidence should normally be a by-product of doing the work, not something the compliance team has to reconstruct before the next assessment.

Depending on your scope, that evidence may include:

• Vulnerability scan reports and remediation records;
• Penetration-test and retest results;
• Access and configuration reviews;
• Security-training records;
• Change tickets;
• Targeted risk analyses;
• Incident-response exercises;
• Third-party reviews; and
• Documentation showing how findings were resolved.

Good evidence also needs ownership and context. A scan report sitting in a folder may prove that a scan ran. Still, teams should also be able to show what happened when the scan identified an issue, who handled it, and how remediation was verified where required.

This is where Year Two becomes much easier or much harder. If evidence is captured while activities happen, assessment preparation becomes a review exercise. If nobody has tracked the work for 10 months, the compliance team may find itself chasing engineering, IT, security, HR, and vendors for records that should already exist.

Missed periodic controls create a real Year Two problem

Time-bound PCI DSS activities cannot simply be backdated.

PCI SSC explicitly states that if an organization fails to perform a periodic control within its required timeframe, there is no way to perform that control retroactively or treat a later occurrence as if it happened during the missed period. A missed external ASV scan, for example, means the organization will not have the required scan report for that period.

That does not mean every missed activity automatically produces the same assessment outcome. PCI SSC allows an assessor, in limited circumstances, to determine that a requirement is in place after corrective action if the organization demonstrates a repeatable documented process, shows that the miss resulted from an exceptional circumstance rather than recurring poor practices, addresses the cause, successfully performs the control, and takes steps to prevent recurrence.

The practical lesson is simpler: Don't rely on assessment preparation to tell you you missed a quarterly activity six months ago.

How should scope, third parties, and business changes be handled in Year Two?

Do not assume that the CDE you assessed in Year One is still the CDE you have today.

PCI DSS Requirement 12.5.2 requires organizations to document and confirm PCI DSS scope at least once every 12 months and after significant changes to the in-scope environment. That review includes payment data flows, locations where account data is stored, processed, or transmitted, CDE and connected system components, segmentation controls, and third-party connections with access to the CDE.

For service providers, PCI DSS requires confirming scope at least once every six months and after significant changes.

Reconfirm the cardholder data environment

Year Two scope confirmation should be an actual validation exercise, not a copy-and-paste update to last year's documentation. Review whether anything changed in:

• Payment flows and channels;
• Applications handling payment data;
• Cardholder-data storage;
• APIs and integrations;
• Cloud infrastructure;
• Administrative access;
• Network connectivity and segmentation; or
• Third parties that access or affect the CDE.

Consider a fintech company that adds a new payment processor and API during Year Two. Even if the original architecture passed its assessment, the data-flow diagram and scope assumptions may no longer describe what is actually happening.

PCI DSS scope follows the environment, not the previous report.

Revalidate third-party dependencies

Third-party service providers (TPSPs) also require ongoing attention.

PCI DSS Requirement 12.8.4 requires a program to monitor relevant TPSPs' PCI DSS compliance status at least once every 12 months. Organizations also need to maintain information showing which applicable requirements the provider manages, which remain the organization's responsibility, and which are shared.

Year Two is therefore a good point to verify whether a provider's current assessment still covers the services you consume, whether its role has changed, whether new providers have been introduced, and whether responsibility assignments still reflect reality.

Treat significant change as an event, not something to review next year

PCI DSS work should also be connected to your change-management process.

A cloud migration, redesigned payment flow, new API, new processor, or segmentation change can affect scope or trigger additional testing requirements.

Waiting until the annual scope review to consider that impact can leave months between the change and the compliance work it requires.

For a cloud-native payment service provider, for example, a network redesign could change whether systems previously treated as out of scope can connect to or affect the CDE.

A useful change-management question is:

Does this change affect the CDE, PCI DSS scope, or the way an applicable control operates?

Ask it before implementation, not during the next assessment.

Third-Party Risk Support

GRSee helps you track vendors, map responsibilities, and keep your PCI DSS compliance secure.

Contact Our Experts

What makes the second PCI DSS assessment different from the first?

The second assessment may cover many of the same applicable requirements. Still, the evidence is different because the assessor can now examine a period of actual operation.

Instead of mainly evaluating recently established controls, the organization may need to show evidence that recurring, time-bound activities occurred as required throughout the subsequent cycle. That history could show that:

• Vulnerability scans occurred on schedule;
• Findings were remediated and rescanned where required;
• Penetration testing was repeated where applicable;
• Annual governance activities occurred;
• Scope was confirmed and updated;
• TPSP status was reviewed; and
• Significant changes were evaluated appropriately.

This is why Year Two often reveals whether PCI DSS became part of normal operations or remained an assessment project.

The initial-assessment provisions give organizations specific treatment when a defined-timeframe requirement is being assessed for the first time. Once that requirement has previously been formally assessed, that initial-assessment treatment no longer applies.

The exact validation method still depends on the compliance program that applies to your organization. PCI SSC does not determine how often each entity must be reassessed or whether each organization must submit a ROC. The relevant payment brands, acquirers, or other organizations managing the compliance program make those decisions.

A better question before the second assessment is therefore not: "Are we ready to start preparing?"

It is: "Can we demonstrate that our PCI DSS program operated as intended since the last assessment?"

A practical Year Two PCI DSS operating calendar

A compliance calendar makes recurring work easier to manage. Still, it needs to be built around the requirements that actually apply to your environment.

The following is a planning model, not a universal PCI DSS checklist:

The useful part of this table is not the calendar itself. It is the operating model behind it: every applicable recurring requirement should have an owner, frequency, evidence expectation, and mechanism for identifying missed or overdue work.

» Preparing for a PCI audit? Get expert guidance to assess your readiness, identify compliance gaps, prepare evidence, and strengthen your security controls.

Keep your PCI DSS program operating between assessments

Year Two is less about relearning PCI DSS and more about keeping the program running: completing recurring activities, maintaining accurate scope, retaining evidence, and staying on top of required testing.

GRSee supports organizations across the PCI DSS lifecycle, from PCI DSS Level 1/ROC assessments and PCI DSS SAQ support to ongoing compliance. Our approach covers scope, gap assessment, remediation guidance, testing, assessment support, and continued maintenance after the initial validation.

For Year Two, that means turning applicable requirements into a manageable operating schedule. So the next assessment reflects work maintained throughout the year, not rushed at the end.

If your first PCI DSS assessment is complete, the next step is to review your Year Two maintenance plan and confirm that you're managing scope, evidence, testing, and recurring controls now.

Simplify Your PCI Compliance

The path to compliance requires expert guidance. Let GRSee's team help you through the process.

Talk to Us