PCI DSS Audit and Assessment: Process, Evidence, ROC, and AOC

A PCI DSS audit is commonly used to describe the process of checking whether an organization meets the Payment Card Industry Data Security Standard, but PCI SSC uses the term "assessment" more precisely. The assessment verifies the environment in scope, which requirements apply, whether the controls are implemented and operating as required, and whether the evidence supports the result.

The validation path is not the same for every organization. Depending on the merchant or service-provider program, an entity may complete a Self-Assessment Questionnaire (SAQ) or undergo an assessment documented in a Report on Compliance (ROC). An Attestation of Compliance (AOC) records the result using an official PCI SSC form. Payment brands, acquirers, and other compliance-accepting entities decide which validation and reporting method they require.

That distinction matters because readiness work and formal validation are different jobs. A team can be technically prepared but still lose time during assessment if scope is incomplete, evidence is scattered, control ownership is unclear, or the wrong reporting path was assumed at the start.

PCI DSS audit and assessment at a glance

The table separates the main assessment terms before we get into the workflow. The exact route still depends on the requirements of the entity receiving your compliance documentation.

Is a PCI audit the same as a PCI DSS assessment?

In everyday use, yes: teams often say "PCI audit" when they mean a PCI DSS assessment. For formal documentation, however, the wording matters. PCI SSC publishes assessment procedures, SAQs, ROC templates, AOCs, and other official forms rather than a universal "PCI audit certificate."

For the standard-level view of scope, validation, and the control structure, see our PCI DSS requirements guide. This page focuses on how the assessment itself is prepared, performed, documented, and submitted.

PCI SSC also states that official PCI DSS validation is evidenced through its approved forms rather than an informal certificate. See PCI SSC FAQ 1220 for the Council's position on compliance certificates.

Who decides whether you need an SAQ or ROC?

The entity accepting your compliance result determines the validation and reporting route. For merchants, that is commonly an acquirer or payment brand. Service providers may also have reporting obligations set by payment brands, customers, acquirers, or contractual programs.

PCI SSC explains this split in FAQ 1473: compliance-accepting entities decide how compliance must be evidenced, while assessors validate that assessment scope and requirement applicability are accurately defined and documented.

What happens during a PCI DSS assessment?

A good assessment follows a controlled sequence. The steps below are useful whether the final evidence is an SAQ or a ROC, although who performs the testing and how the results are documented will differ.

1. Confirm the validation route and assessment owner

Before evidence collection begins, confirm whether the organization is expected to complete an SAQ, undergo a ROC-based assessment, provide ASV scan evidence, or satisfy another reporting requirement set by the compliance-accepting entity. If a QSA is required, confirm the assessor and engagement scope early enough to avoid rebuilding the evidence pack later.

PCI SSC maintains the qualification program for Qualified Security Assessors and recognizes QSA companies as qualified to assess PCI DSS compliance.

2. Validate the PCI DSS scope

The assessment cannot be better than the scope it tests. Teams need to map payment account data flows, define the cardholder data environment (CDE), identify connected and security-impacting systems, include relevant people and processes, and account for third-party services that affect the environment.

For a deeper explanation of CDE boundaries, connected-to systems, segmentation, and dependencies that can affect scope, see our What Is the CDE in PCI DSS? guide.

3. Determine which requirements are applicable

After scope is established, the organization and assessor determine which PCI DSS requirements apply to the assessed environment. A requirement should not be treated as out of scope simply because the team considers it low risk. Where a requirement is not applicable, the basis needs to be supported by the environment and the applicable PCI DSS instructions.

Targeted risk analyses can also affect how certain flexible-frequency requirements are implemented and evidenced.

4. Collect and test evidence

Assessment work is not a document inventory exercise. Evidence has to show that the control exists, applies to the right systems and people, and operates as required. Testing can include interviews, observation, configuration review, sample inspection, log review, technical testing, and examination of records over the required period.

Evidence should be traceable to a requirement, control owner, system or process in scope, and relevant period. A policy can show intent, but it does not prove that a technical control is configured or that a recurring activity happened on schedule.

5. Record gaps, remediate, and retest

If testing finds a control gap, the organization normally has to correct the issue and provide enough evidence for the assessor or self-assessment owner to verify the result. The remediation work may be technical, procedural, documentary, or a combination of all three.

The assessment record should make the difference between the original finding, the corrective action, and the evidence used to verify the updated state clear. That history matters when several teams are fixing findings in parallel.

6. Complete the official validation documents

A self-assessment route uses the applicable SAQ and its associated AOC. A ROC-based assessment uses the current ROC reporting template and a corresponding AOC. The documents should accurately describe scope, testing, findings, and the final result rather than presenting a broader claim than the assessment supports.

For ROC-based assessments, PCI SSC states that the ROC must be finalized before the AOC is provided. See FAQ 1375.

7. Submit the required evidence and keep the program current

The final step is submission to the required recipient according to the applicable compliance program. Validation is a point-in-time reporting event supported by ongoing control operation. Changes to systems, payment flows, providers, access, software, or network design can alter scope and the evidence required for the next assessment.

What evidence does a PCI DSS assessor review?

The evidence set depends on the requirements in scope, but the categories below recur across many assessments. The goal is to prove both design and operation, not to collect documents because they have familiar titles.

Logging evidence often becomes its own assessment workstream because Requirement 10 has detailed expectations for audit logs, reviews, retention, and monitoring. Our PCI DSS Requirement 10 guide covers that evidence path separately.

Vulnerability scanning and penetration testing also answer different assessment questions. For internal and external scanning, ASV requirements, remediation, and rescanning, see our PCI DSS vulnerability scanning guide. For Requirement 11.4 penetration testing, use the Q-Sec guide and playbook below.

For the detailed testing requirements themselves, read our PCI DSS penetration testing requirements guide.

What is the difference between SAQ, ROC, and AOC?

These documents are related, but they do different jobs. Treating them as interchangeable creates confusion about who performed the assessment and what the result actually covers.

PCI SSC's self-assessment guidance describes the basic SAQ path: identify the applicable SAQ, confirm scope and eligibility, perform the required assessment activities, complete the SAQ and AOC, complete ASV scans when required, and submit the documentation requested by the acquirer or payment brand. See PCI SSC FAQ 1134.

The assessment route also affects cost. A self-assessment, a ROC engagement, remediation work, and external testing create very different budgets. We break those cost drivers down in our PCI DSS compliance cost guide.

Do you get a PCI DSS certificate after an assessment?

No. PCI SSC does not recognize a general PCI DSS compliance certificate as an official validation document. The recognized evidence comes from the Council's approved forms, including ROCs, AOCs, SAQs, and relevant scan attestations.

This is why "how to get PCI DSS certification" is better reframed as "which PCI DSS validation method applies to us, and what documentation must we submit?" A vendor can help an organization prepare, remediate, organize evidence, and coordinate with an assessor. That does not turn an informal certificate into PCI SSC validation.

What happens when an assessment finds gaps?

A finding is not automatically the end of the assessment. In many engagements, the organization corrects the issue, collects new evidence, and the relevant control is tested again before the assessment is finalized. Whether that can happen within the same assessment window depends on the finding, the evidence required, and the assessor or compliance program.

Teams should keep remediation ownership explicit. Security may fix a configuration, engineering may change an application, IT may update access, procurement may obtain third-party evidence, and compliance may maintain the final record. Without a single findings tracker, the assessment can stall even when the technical fix itself is straightforward.

Can a PCI DSS assessment cover only part of the standard?

Yes, a partial assessment can be documented in a ROC when there is a legitimate reason to test only a subset of PCI DSS requirements. The report and AOC need to make clear which requirements were tested and which were not tested so the result cannot be mistaken for a full assessment.

PCI SSC explains permitted partial ROC use cases and the documentation boundary in FAQ 1382. A partial ROC should therefore be read as evidence about the tested scope, not as a blanket statement about the whole environment.

How should a team prepare for a PCI DSS assessment?

Preparation works best when the assessment is treated as an evidence and ownership exercise rather than a last-minute document request. Before formal testing begins, the team should be able to answer the following questions.

• Which payment flows and systems define the current CDE, and what changed since the previous assessment?
• Which validation route has the acquirer, payment brand, customer, or other compliance-accepting entity required?
• Who owns each applicable requirement and who can produce the supporting evidence?
• Which recurring controls need evidence over time rather than a single current screenshot?
• Which open findings, compensating controls, customized approaches, or targeted risk analyses need assessor attention?
• Are external ASV scans, penetration-test results, segmentation tests, access reviews, and log-review records current?
• Can third-party service providers supply current documentation that accurately describes the services and PCI DSS responsibilities in scope?
• Is there one findings and evidence tracker that shows status, owner, source, and next action?

A working evidence tracker should map each applicable requirement to its expected proof, control owner, implementation status, gap status, remediation action, and assessment record. That keeps the assessment process separate from the day-to-day work of collecting and maintaining evidence.

What should a PCI DSS readiness provider do, and what stays with the assessor?

A readiness provider can help define scope, identify gaps, implement controls, organize evidence, prepare teams for testing, coordinate penetration testing and scanning, manage remediation, and support communication with a QSA. Formal validation still follows the method required by the compliance-accepting entity and the official PCI SSC reporting documents.

Final thoughts: Assessment readiness comes down to scope, evidence, and ownership

A PCI DSS assessment becomes difficult when the organization discovers its real scope during testing, has controls without evidence, or cannot identify who owns a finding. The reporting form is the final layer. The work underneath it is proving that the right controls apply to the right environment and operate as required.

Teams that settle the validation route early, keep scope current, map evidence to owners, and fix gaps before formal testing give the assessor a clearer record to evaluate and give themselves fewer surprises at the end of the cycle.

Frequently Asked Questions About PCI DSS Audits and Assessments

Is a PCI DSS audit mandatory?

Well, it's a bit of a grey area. The PCI DSS validation requirements actually end up depending on who you are and who is paying the bill (your payment-brand acquirer, customer, or compliance program of choice). Some folks will be happy to use a self-assessment, but others are going to be wanting a full ROC assessment and some extra evidence to boot.

What is a PCI DSS ROC?

So, a Report on Compliance is one of those documents that gets put together, which outlines the work that was done (scope, testing, findings, etc.) all using the official PCI SSC template. The good news is this is the form that gets used by the entity that is responsible for accepting compliance.

What is a PCI DSS AOC?

An Attestation of Compliance is just a fancy bit of paper from the PCI SSC that gives you a quick summary of just what you got from your SAQ or ROC-based assessment.

What is the difference between an SAQ and a ROC?

So basically, an SAQ is where you, your good self, document your own self-assessment—and a ROC is a very detailed document that lets you know what was done (scope, testing, findings, etc.); it all depends on what your compliance program says you need to do.

Do I need a QSA for PCI DSS?

Not always. You probably only need one if your compliance program demands it. So, always check with the people who are footing the bill (your acquirer, payment brand, customer, or compliance-accepting entity) before you go down any particular route.

Can I get a PCI DSS certificate?

Oddly enough, the PCI SSC does not issue a general compliance certificate. What they do is use a bunch of forms, including SAQs, ROCs, AOCs, and the odd scan attestation, to prove you have done what you need to.

What evidence do I need for a PCI DSS assessment?

Well, that really depends on the scope and specific requirements of your particular assessment. But basically, you can expect to need all sorts of things (diagrams, inventory lists, policies, configuration files, access records, logs, scan results, penetration test reports, risk analyses, training records, and third-party documentation).

What happens if we fail a PCI DSS assessment?

You will need to close the gap in control and get some new evidence before it's all verified again—but the outcome of your assessment and what you do next will depend on how you did, who was doing the assessment, how you were reporting on it, and who is in charge of compliance overall.