PCI DSS Prioritized Approach milestones and when acquirers accept it

Can the Prioritized Approach replace a ROC or AOC for PCI DSS?

The Prioritized Approach is optional, it does not replace PCI DSS, and only your acquiring bank or the payment brands decide whether progress against its milestones can be reported in place of a Report on Compliance (ROC) or an Attestation of Compliance (AOC). The PCI Security Standards Council does not run compliance reporting, so it cannot make that call for you. If your acquirer or a customer has set a deadline, the first step is to ask in writing whether milestone progress is accepted, for which milestones, in what format, and by which date. Treat the answer as the governing requirement for your plan.

The answer varies by organization because it depends on who sets your reporting obligation and what they have agreed to accept. Ask your acquirer which payment brand program applies to your merchant or service provider level, whether a partial report is acceptable, and whether a full ROC or AOC will still be due on a later date. Confirm whether the acquirer expects a partial assessment documented in a ROC covering only selected milestones, or a different artifact. Some entities also need to confirm how requirements the acquirer excludes will appear in their Self-Assessment Questionnaire (SAQ) or ROC, since untested requirements must be reported accurately and not silently omitted.

Before you commit to a milestone-based plan, get the acquirer's answer in a form you can file, such as an email or letter that names the milestones and the deadline. Then map each milestone to the systems, owners and evidence it requires, and identify which parts a QSA will need to validate later. If the answer is that a full ROC or AOC is still required, the Prioritized Approach remains a useful way to order remediation, but it will not reduce the reporting you owe. Consider raising this with your assessor early, since a clear reporting decision shapes how much work the final assessment will involve.

The six Prioritized Approach milestones and their order

The Prioritized Approach sorts PCI DSS work into six milestones so the most widespread risks to card data are reduced first. Each milestone ends with a defined output that shows progress and can be reviewed before the next one begins. The sequence does not replace the full standard, and the acquirer or payment brands decide whether progress can be reported.

Locate card data and connected networks
Milestone 1 starts by finding where payment card data is stored, processed or transmitted and which networks connect to those systems. The PCI SSC places this first because it targets the most widespread risks before less pressing ones. The same milestone removes sensitive authentication data that should not be kept after authorization and sets retention limits for the data that remains. The output is a current data discovery record, a data-flow view and a retention schedule that names what is kept, where and for how long. Confirm with your acquirer whether they expect these records in a specific format.
Protect systems and networks from breach
Milestone 2 hardens the systems and network paths identified in milestone 1. The team configures network security controls to restrict traffic into and out of the cardholder data environment, changes vendor default settings and applies secure configurations to in-scope components. It also prepares for a breach by documenting an incident response plan with named roles and contacts. The output is a reviewed firewall rule set with a recorded business reason for each rule, configuration standards for in-scope systems and a written incident response plan. A walkthrough of several in-scope systems against their standards confirms the work is done.
Secure the payment applications
Milestone 3 covers every payment application that stores, processes or transmits card data, whether purchased or built in-house. The team confirms each application runs on a supported version, applies security patches through a controlled process and tracks known vulnerabilities until they are closed. Custom code also needs secure development practices and documented change control. The output is an inventory of payment applications with versions, patch records and a change log. The milestone is complete when each application has a named owner and a documented update path that the owner can show.
Monitor and control access to systems
Milestone 4 limits each user and system account to the access its job requires and records who uses it. The team assigns unique IDs, requires multi-factor authentication for access into the cardholder data environment, schedules periodic access reviews and sends audit logs to a protected location where they are reviewed. The output is an access matrix by role, signed review records from account owners and a log collection setup with alerts. To check the work, select a privileged account and trace it back to an approved request and a recent review entry.
Protect stored cardholder data
Milestone 5 makes stored account data unreadable wherever it remains after the earlier milestones. The team masks the primary account number wherever it is displayed, renders stored data unreadable with strong cryptography and documents how encryption keys are generated, stored, rotated and retired. It also confirms that no sensitive authentication data is kept. The output is a key management record with named custodians, masking rules and evidence that key custodians are separated from data administrators. A test extract from storage that shows no readable card numbers is a useful check.
Finish remaining requirements and record results
Milestone 6 closes the rest of the PCI DSS requirements, including recurring activities such as vulnerability scans, penetration tests, security awareness training, policy reviews and oversight of third-party service providers. Each requirement needs an owner, the evidence it produces and a schedule for repeating it. The output is a gap list that is either empty or lists documented exceptions, plus a status record that shows which requirements were tested and when. Whether this progress can be reported in place of a ROC or AOC is decided by the acquirer or payment brands, so confirm that before reporting.

Who decides whether an acquirer accepts milestone progress

The PCI Security Standards Council does not decide whether milestone progress counts for reporting. The Council maintains the standard and the Prioritized Approach, but it does not run compliance reporting. Whether your acquiring bank accepts Prioritized Approach progress in place of a ROC or AOC is set by the acquirer, and by the payment brands whose programs apply to you. The same Prioritized Approach document can therefore be accepted by one acquirer and rejected by another, so the answer depends on your relationship, not on the standard alone.

Before you start remediation, get the acceptance requirement in writing from your acquirer or the relevant payment brand. Ask which milestones they expect you to complete, whether they want a full or partial assessment, which evidence they will review at each milestone, who must sign or attest to progress, and what date they expect the work to finish. Confirm whether they require the Prioritized Approach at all. Your organization must also confirm which reporting route applies to its own card brand obligations, since the Prioritized Approach is not mandatory unless an acquirer or brand requires it. If the answer is not in writing, treat it as unknown and plan for a full ROC or AOC.

Keep this written acceptance with your remediation plan and revisit it if your acquirer changes, your payment flows change, or the brand program updates. An implementation partner can prepare the systems and milestone evidence the acquirer asks for, but only the acquirer, the payment brand, or an assessor you engage for the agreed reporting route determines whether that evidence meets the requirement.

How partial assessments of selected milestones are documented

Some acquirers ask for only certain Prioritized Approach milestones rather than a full assessment. The documentation then has to show exactly which requirements were tested, which were excluded, and what the report does not speak to. The cards below cover the decisions to settle with your acquirer and assessor before fieldwork begins.

Confirm the acquirer's exact request

Start by getting the acquirer's request in writing, naming which milestones or requirements it covers. A partial assessment is only as useful as that request, so a vague ask such as "the first milestones" should be turned into a list of requirement numbers. Confirm whether the acquirer accepts the output as a substitute for a full report or only as interim progress. Acquirers and payment brands make this call, not the PCI SSC, so the answer belongs in their written reply.

Agree the in-scope requirement set

Work with the assessor to fix the subset of requirements that will be tested and documented. Each excluded requirement needs a clear reason tied to the acquirer's request, not to convenience. Requirements that touch the cardholder data environment but fall outside the chosen milestones still need a documented position. Record the agreed set before fieldwork so the report and the scope do not drift apart.

Mark excluded requirements as Not Tested

In SAQ D, Not Tested is the marking for a requirement excluded entirely, such as when an acquirer limits the review to certain milestones. It is different from Not Applicable, which must be verified against the environment, for example by confirming that no wireless technology touches the cardholder data environment. Using Not Applicable to hide an excluded milestone misstates the position. Ask the assessor which marking and wording the template expects for each excluded item.

Define what the report states

The report should state which requirements were assessed, the period and systems covered, and the findings for each tested requirement. It should also say that the partial scope was set by the acquirer's request, so no reader mistakes it for an overall validation. Ask the assessor to show how the report language identifies the partial scope on the cover and within each section. Review the draft against the acquirer's wording before signing.

Document what the report does not cover

A partial report does not validate the entity's overall PCI DSS compliance, and it should say so. Excluded milestones, unassessed systems and requirements outside the agreed set all belong in a clear statement of limits. Recipients such as customers, card brands or internal boards may read only the summary, so the limits must appear where they will be seen. Ask the acquirer whether it expects this limitation written into the attestation or in a cover letter.

Reporting untested requirements: Not Applicable versus Not Tested

A requirement is Not Applicable when the environment genuinely has nothing it would govern. The SAQ D instructions require that this be verified rather than assumed. The standard's own example is wireless: before marking the wireless requirements N/A, the entity must confirm that no wireless technology touches the cardholder data environment (CDE). That confirmation is evidence, so it needs a dated record that a named person can produce on request.

Verify before marking: Document the check itself, such as a scan of the CDE boundary, a configuration review or a signed statement from the system owner, rather than a general belief that the technology is absent.
Re-verify when the environment changes: A new terminal, a Wi-Fi access point or a new cloud service can turn a Not Applicable requirement into an applicable one.
Explain each N/A in the report: Assessors expect a short rationale per requirement that names the environment and the reason it falls outside the requirement.
Keep the evidence on file: Store the verification records with the scope documentation so an assessor can sample them.
Do not use N/A for gaps: A requirement that applies but is not yet met is not Not Applicable, even if remediation is planned.

Check each N/A claim against the current network and data-flow diagrams before the assessment starts.

What your team, a partner and the QSA each own

A Prioritized Approach effort only works when each party knows its job. Your organization owns the controls and the decisions behind them, a partner such as DeployOpen can prepare systems and evidence, and the QSA or acquirer-accepted assessor is the only party that issues the report. Confirm these boundaries before the first milestone starts.

Your organization owns the controls

Your team decides how payment data flows, who holds access, and which systems are in the cardholder data environment. Those decisions remain yours even when a partner builds the technical work. Before milestone 1 begins, confirm named owners for data discovery, network connections and each milestone's remediation tasks, and record who approves changes to scope.

A partner prepares systems and evidence

An implementation partner can configure open-source platforms, harden systems, set up logging and document the results for each milestone inside your own infrastructure. Ask for a written scope that names the milestones, systems and deliverables, plus the evidence each deliverable will produce. Keep in mind that preparing evidence does not make the partner an assessor of that evidence.

The QSA or acquirer-accepted assessor reports

Only a Qualified Security Assessor, or the assessor your acquirer or payment brand accepts, can issue a Report on Compliance or an Attestation of Compliance. Confirm with your acquirer in writing whether Prioritized Approach progress is accepted in place of a ROC or AOC, since that decision belongs to the acquiring bank or payment brands and not to the PCI SSC.

The independence boundary

A partner that configures a control cannot also sign off on it in the report. Keep the people who build a milestone separate from the people who judge it, and ask your assessor how it will treat partner-prepared evidence. The partner cannot sign the ROC or AOC, and an AOC should never be presented as partner output.

Records of partial milestone scope

If your acquirer asks for only certain milestones, the excluded requirements must be handled with care. A partial assessment documented in a ROC can cover a subset of requirements, and the SAQ instructions treat excluded requirements as Not Tested rather than Not Applicable. Ask your assessor to confirm which requirements are in and out of the report before work begins.

Questions buyers ask about Prioritized Approach reporting

Is the PCI DSS Prioritized Approach mandatory?

No. The Prioritized Approach is not mandatory and does not replace PCI DSS. It is a staged planning tool that helps entities that are not yet compliant reduce risk to cardholder data in six milestones. Acquirers or payment brands may require it within their own compliance programs, so the practical question is whether your acquirer expects it in your reporting. Ask your acquirer directly, and get the answer in writing before you build a plan around it. The PCI SSC does not run compliance reporting, so the acquirer or brand sets that expectation.

Will my acquirer accept Prioritized Approach progress instead of a ROC or AOC?

Only if your acquiring bank or payment brand decides to accept it. The PCI SSC does not make that call, so acceptance varies by acquirer and program. Milestone progress is not a substitute for a Report on Compliance or an Attestation of Compliance unless the party that tracks your compliance says so. Confirm three things before you start: whether progress is accepted in place of a ROC or AOC, which milestones they expect you to complete, and what evidence and format they want at each stage. Keep that confirmation with your compliance file.

How are partial assessments of selected milestones documented?

A partial assessment covers a subset of requirements rather than the full standard, and it can be documented in a ROC. The PCI SSC notes this case explicitly, for example when an acquirer asks only for certain Prioritized Approach milestones. The scope of the partial assessment must match what the acquirer requested, and the report should state clearly which requirements were in scope. Requirements outside that subset are then handled through the reporting rules that apply to excluded requirements, which is covered in the next question. Agree the milestone list and the reporting format with your acquirer in writing before the assessor begins.

What does Not Tested mean on an SAQ D?

Not Tested is the status used when a requirement is excluded from the assessment entirely, such as when an acquirer asks for only certain Prioritized Approach milestones. It is different from Not Applicable. Not Applicable means the requirement does not apply to your environment, and the assessor or you must verify that claim, for example by confirming that no wireless technology touches the cardholder data environment before marking the wireless requirements N/A. Not Tested means the requirement was left out by agreement, not judged irrelevant. Do not use Not Tested to avoid requirements that do apply to you, because the reporting will not show that they were assessed.

How much effort do the six milestones take, and what do they need from my organization?

The PCI SSC does not publish a time or cost for each milestone, so the effort depends on your environment and should be estimated from your own inventory. The milestones start with finding where card data is stored and which networks connect to it, then remove unnecessary data, protect systems and networks, secure payment applications, monitor access, protect stored cardholder data, and finish the remaining work. The main demands are:

Accurate data-flow and network inventories, owned by someone who can maintain them
Staff time from IT, security, application owners and payment operations
Changes to systems and processes, plus evidence that each change is in place
Budget for tools, configuration work and any outside help you choose to buy

Ask any provider for a quote built from a written scope that names the milestones, systems and deliverables.

Can a PCI DSS partner complete the Prioritized Approach work on its own?

A partner can prepare systems, configurations and evidence for the milestones, but it cannot issue the validation. Your organization owns its controls and its compliance decisions. An implementation partner such as DeployOpen can plan, implement, harden and document self-hosted open-source platforms inside your infrastructure, and it can prepare the evidence an assessor will review. Only an independent QSA, or the reporting path your acquirer accepts, issues a ROC or AOC. Confirm with your acquirer whether the work you plan to hand over counts toward the milestones they expect, and keep your internal owner accountable for the final evidence file.

Does working through the milestones reduce the scope of my assessment?

Not automatically. The milestones reduce risk in stages, and early steps such as removing unneeded card data or limiting its retention can shrink the systems you need to protect. However, finishing a milestone does not by itself remove systems from scope. Scope is determined by where cardholder data is stored, processed or transmitted and by systems that could affect that environment. Use your data-flow diagrams and inventories to decide what remains in scope at each stage, and confirm the reduction approach with your assessor before counting on it.

What usually stalls milestone 1 and how to avoid it

Milestone 1 is where most Prioritized Approach projects lose time, because it depends on facts that many organizations have never written down. The three cards below cover the blockers we see most often: incomplete card data discovery, unclear network scope and acquirer expectations that exist only in conversation. Each one can be checked early, before remediation work begins.

Incomplete card data discovery

Milestone 1 starts with finding where payment card data is stored, processed or transmitted. Projects stall when discovery covers the obvious databases and misses file shares, email archives, support tickets, call recordings, logs and spreadsheets used for reconciliation. Ask each system owner to confirm in writing whether card data can appear there, and run a discovery tool or scripted search against the locations you have listed. Every location you miss becomes a surprise during later milestones.

Unclear network scope

Milestone 1 also asks which networks connect to systems that hold card data. Scope stalls when the team cannot produce a current network diagram, or when flat internal networks, management VLANs, backup networks and vendor remote access paths are not mapped. Confirm which segments can reach the cardholder data environment, who administers them and which connections are documented. Unresolved scope questions usually mean the remediation plan has to be redrawn after the work is already underway.

Undocumented acquirer requirements

Whether the Prioritized Approach can replace a ROC or AOC is decided by your acquiring bank or the payment brands, not by the PCI SSC. Projects stall when a team builds a plan around an assumed reporting format and learns late that the acquirer wants a partial assessment of specific milestones or a particular report. Ask your acquirer, in writing, which milestones they expect, what evidence they accept and whether untested requirements must be reported as Not Tested. Get the answer before scoping the remediation work.

How DeployOpen scopes milestone work and prepares evidence

DeployOpen works on the Prioritized Approach as an implementation partner: we help plan and build the technical changes and the evidence for the milestones your acquirer or payment brand has asked for. Your organization owns its controls and decides what is reported, and an independent assessor issues any report or attestation.

How we scope

Engagements are fixed-scope, with milestones, deliverables and timelines agreed in writing before work starts.
We confirm with you which milestones your acquirer or payment brand expects, since whether progress is accepted is their decision.
The written scope names the systems, networks and payment applications in each milestone so no area is left unassigned.

How we build

We help locate stored card data and map the networks connected to it, which is where milestone 1 begins.
We implement and harden the technical controls in each milestone's scope and document configuration changes as they are made.
We test the changes against the requirements in scope and flag gaps to your team before anything is marked complete.

How we hand over

You receive the milestone documentation, configuration records and test results needed for your own review.
Requirements outside the agreed milestones are recorded as not tested, with the reason stated for your assessor.
We do not sign or issue any report, attestation or certificate, so your QSA or acquirer reviews the evidence independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the agreed scope is delivered.
A retainer can cover ongoing evidence collection for recurring tasks between assessments, based on the written agreement.
Ask any provider, including DeployOpen, to confirm in writing which parts of the work are their responsibility and which remain yours.

PCI DSS Prioritized Approach: six milestones toward compliance