PCI DSS certification explained: AOC, ROC and what counts

What counts as PCI DSS certification, and why a certificate is not enough

PCI DSS compliance is shown by a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ), each backed by an Attestation of Compliance (AOC) on official PCI SSC templates. Vendor certificates, consultant certificates and compliance logos are not recognized as validation, and the PCI SSC issues no seal or mark that proves compliance. When a customer, acquirer or contract asks for proof of PCI DSS certification, the document they need is the AOC, and they should ask for the completed form, not a badge or letter. The PCI SSC FAQ on compliance certificates sets out which documents count.

Divide the work clearly before you start. Your organization owns its controls and is accountable for them. An implementation partner such as DeployOpen can prepare systems, configurations and evidence, but it does not issue reports or attestations. A ROC must be completed by a Qualified Security Assessor, while an SAQ is completed by the organization itself on its validation path. Either way, the signed AOC is what you hand over. Confirm with your acquirer which validation type and reporting format they require, because the payment brands and acquirers decide which entities must validate and how results are accepted.

Validity is also set outside the PCI SSC. The council does not enforce compliance or impose penalties, and the payment brands and acquirers decide how long a result stays valid and how often reassessment is required. Retirement of the standard version you were assessed against does not shorten that period. Ask your acquirer for its current rules in writing, and keep the AOC, scope statement and supporting evidence together so you can answer follow-up questions from the customer or brand.

Which logos, badges and certificates do not validate PCI DSS

Many vendors, consultants and marketing pages describe their products or services as making you PCI compliant. The PCI SSC recognizes only its own official templates as validation evidence, so each item below looks like proof but does not replace the AOC, the ROC or a confirmed scope.

Vendor certificates and badges

A software or hosting vendor may issue a certificate, letter or badge saying its platform is PCI DSS compliant. Such documents are not recognized as validation evidence. Your organization owns its own PCI DSS compliance, so a vendor's status covers only the vendor's own environment and services. Ask for the vendor's current AOC and the responsibility matrix that shows which requirements the vendor covers and which remain yours.

Consultant certificates

A consultant may hand you a certificate of compliance, a readiness letter or a gap-assessment badge. None of these is an official PCI SSC template. A consultant can help prepare your systems and evidence, but only a QSA completes a ROC, and only you or your acquirer can sign the AOC for your organization. Ask the consultant to state in writing what it delivered and what remains for your assessor to test.

Compliance logos and seals

The PCI SSC issues no official seal, mark or logo for PCI DSS compliance. A logo on a website, pitch deck or product sheet is therefore not evidence of validation, whoever designed it. Ask for the AOC itself, check that its date and scope match the service you buy, and confirm with your acquirer which version of the AOC they accept.

Claims such as PCI Compliant

Phrases such as PCI Compliant, PCI Certified, PCI DSS Compliant or PCI DSS Certified, and PCI paired with check marks, may not be used in a way that implies compliance. When a supplier uses them without naming a current AOC, treat the claim as unverified. Ask which assessment covered the product, when it was signed, and which scope it covers.

SOC 2 reports and other auditor evidence

A SOC 2 report or an ISO certificate can supply useful evidence for some controls, but PCI SSC FAQ 1567 addresses reliance on SOC 2 reports and FAQ 1566 addresses evidence collected by other auditors. Neither replaces a PCI DSS assessment. Ask your QSA which items it will accept from another report, how it maps those items to PCI DSS requirements, and what it will still test directly.

Who decides whether your PCI DSS result is valid

The PCI Security Standards Council (PCI SSC) maintains PCI DSS but does not enforce it or impose penalties. That job belongs to the individual payment brands, which decide which entities must validate compliance and run any enforcement programs. The practical consequence is that the authority that matters for your result is your acquirer or the brand that requires your validation, not the standards body. Before you scope or budget an assessment, ask your acquirer which validation level and method applies to you, which templates it will accept, and where the completed AOC must be sent. The PCI SSC enforcement FAQ and the consequences of non-compliance FAQ set out this division of responsibility.

Acquirers and brands also decide how long a result remains valid and how often you must be reassessed. Retiring a PCI DSS version does not shorten that period. An assessment completed against v4.0 remained valid after v4.0 was retired on 31 December 2024, because the validity rules come from the payment brands, not from the version's retirement date. Confirm the current validity period in writing with your acquirer, and calendar the reassessment date from that answer rather than from the date you last signed an AOC.

QSAs and ASVs do not send ROCs or scan results to the PCI SSC. They work under each brand's procedures, which means the reporting path depends on the brand that requires your validation. When you choose an assessor, ask which brand procedures they follow and how they will deliver the ROC or scan results to your acquirer. Your own team should keep the signed AOC and the evidence behind it, since that is what you will share with customers and partners under brand rules.

Who owns the controls, who prepares evidence, and who issues the report

Your organization is the entity being validated, and it owns every control, every decision about scope, and the final compliance status. Responsibility cannot be transferred to a vendor or consultant, even when much of the technical work is outsourced. Your team is also the party that signs the Attestation of Compliance and answers for it to your acquirer or the payment brands.

Ownership of controls: Policies, risk decisions, access approvals and exceptions are yours to set and enforce, day to day.
Scope decisions: Your team defines the cardholder data environment and confirms it against data-flow and network diagrams.
Recurring activities: Log reviews, access reviews, and the quarterly and annual tasks must be performed and recorded by your staff or contracted staff under your direction.
Evidence retention: You keep the records that show each control operated over time, not just on the day of assessment.
Attestation: Your authorized officer signs the AOC and must be able to stand behind its statements.

Before engaging anyone, confirm with your acquirer which validation path and reporting template apply to you, and document who on your side owns each requirement.

How a PCI DSS validation runs from scope to signed AOC

A PCI DSS validation moves in a fixed sequence, from confirming which systems are in scope and which validation method applies, through evidence gathering and the ROC or SAQ, to a signed Attestation of Compliance that the organization shares under payment brand rules.

Confirm scope and validation method
The organization defines the cardholder data environment and every connected or security-impacting system, then confirms with its acquirer or payment brand which validation path applies, meaning a ROC completed by a Qualified Security Assessor or an SAQ of a specific type. The output is a written scope statement and a named validation route. You know this step is done when the scope boundary and the validation path are agreed in writing with the party that receives your results.
Prepare controls and evidence
Internal owners close gaps against the requirements in force, including the future-dated requirements that became mandatory on 31 March 2025, and build records of recurring activities such as log reviews, access reviews and policy sign-offs. Your team owns these controls, and an implementation partner can help prepare systems and evidence, but neither can declare compliance. The output is an evidence folder mapped to each requirement, and the step closes when an assessor can trace each control to a dated record.
Obtain ASV scan and penetration test evidence
Where the chosen path requires them, the organization obtains external vulnerability scans from a PCI SSC Approved Scanning Vendor and penetration test results covering internal, external and segmentation testing. Scan and test results are dated, scoped to the same boundary defined in step one, and checked for any failing findings that need remediation and rescanning. The output is a set of passing scan reports and penetration test reports that match the current scope. Confirm with your acquirer how recent these must be.
Complete the ROC or SAQ
A QSA completes the Report on Compliance using the official PCI SSC ROC template, after interviewing staff, observing systems and sampling evidence. For an SAQ, the merchant or service provider completes the official questionnaire for its type, and the answers must be supported by the evidence gathered earlier. The output is a finished ROC or SAQ that records the status of every requirement, including any compensating controls or customized approach documentation. The step is done when the assessor or the signatory has reviewed the answers against the evidence.
Sign the Attestation of Compliance
The Attestation of Compliance is the official PCI SSC form that accompanies a ROC or SAQ and declares the organization's compliance status. An authorized officer of the organization signs it, and the QSA signs the AOC where a ROC is issued. The output is a signed AOC that matches the ROC or SAQ it summarizes. Check that the status, dates and scope on the AOC agree with the underlying report before anyone relies on it.
Share the AOC under brand rules
The organization sends the signed AOC to the acquirer, payment brands or other requesting entities that require it, following each brand's submission rules and deadlines. QSAs and ASVs do not send ROCs or scan results to the PCI SSC, so the organization or its assessor follows the reporting route set by the relevant brand or acquirer. The output is documented acceptance or a record of submission. Keep a copy of the AOC and the supporting report on file, and confirm with the acquirer how long the result is valid before the next reassessment.

What must be ready before an assessor will accept your evidence

An assessor can only test what is documented and running when they arrive. The items below connect the scope, the validation path, the recurring activities and the requirements that became mandatory on 31 March 2025, so each one can be checked before evidence is collected.

Confirmed scope and cardholder data environment

Define which systems store, process or transmit account data, and which connected or security-impacting systems sit alongside them. Confirm the boundary with a documented scope statement that names every system, network segment and third party in the flow. Check it by asking whether an unlisted system could reach card data, and test segmentation before the assessor does. A scope that changes after evidence is gathered forces rework.

Current data-flow and network diagrams

Assessors compare the diagrams against what they observe, so each diagram must show how account data enters, moves through, is stored in and leaves your environment. Include payment channels, integrations, backups and support access paths. Check each diagram against a live configuration review and a recent system inventory. Out-of-date diagrams are one of the fastest ways to lose confidence in the rest of your evidence.

Chosen validation path and its owner

Decide between a Report on Compliance and a Self-Assessment Questionnaire before you collect evidence, because the path sets what must be documented. Confirm the choice with your acquirer or the payment brand, since they decide which entities must validate and how results are submitted. Record who signs the Attestation of Compliance. Check the decision in writing, because a path chosen late can mean evidence is gathered for the wrong template.

Periodic activities already running

Quarterly external scans, periodic access reviews, log reviews and penetration tests must already occur before the assessment period is evaluated. A test performed once for the audit is not evidence of an ongoing process. Pull the dated reports, tickets and sign-offs for the last full cycle and confirm each one covers the in-scope systems. Gaps in the record generally cannot be backdated, so start the cycle early.

Requirements effective since 31 March 2025

Requirements that were future-dated became mandatory on 31 March 2025, after a period in which they could be marked not applicable. Review each future-dated requirement and confirm it is implemented, not recorded as not applicable. Ask the team owning each control to show the working control and its evidence. Assessors expect these to be in place for the full assessment period, so an implementation completed late in that period may not cover the whole of it.

Responsibilities and third-party evidence

Identify which requirements your organization owns and which a service provider covers, and collect the responsibility matrix and the provider's current attestation. An assessor will not accept a vendor certificate in place of an AOC, so ask providers for the documents they can legally share. Confirm the provider's coverage matches the services you use. Unmatched responsibilities are a common reason an assessment stalls.

ROC or SAQ: which document a buyer should expect

This table compares the Report on Compliance completed by a QSA with the Self-Assessment Questionnaire, and shows who completes each, who usually asks for it and what the attached Attestation of Compliance states. Read it as a starting point, then confirm the required document with the payment brand or acquirer that asks for it.

Aspect	Report on Compliance (ROC)	Self-Assessment Questionnaire (SAQ)
Who completes it	A Qualified Security Assessor (QSA) completes the ROC after testing the environment	The organization completes the SAQ itself, using the PCI SSC template for its SAQ type
Typical buyers who request it	Large merchants and service providers that the payment brand or acquirer places at a higher validation level	Smaller merchants and entities that the payment brand or acquirer allows to self-assess
When it fits	Complex cardholder data environments, service providers, or entities whose acquirer requires an assessor-led review	Simpler payment flows with a defined SAQ eligibility match, confirmed with the acquirer
Evidence standard	The QSA reviews evidence and sampling, then documents findings in the ROC template	The organization answers the questions and keeps its own supporting evidence available for review
What the AOC states	The AOC attached to the ROC declares the compliance status found by the QSA	The AOC attached to the SAQ declares the organization's own compliance status
Who decides which is required	The payment brand or acquirer decides, not the organization alone	The payment brand or acquirer decides, not the organization alone
What to confirm with the requester	Which ROC template version and AOC form the acquirer accepts, and the QSA's listing status	Which SAQ type applies, and whether the acquirer requires an ASV scan or an assessor review

Questions buyers ask about PCI DSS certificates and the AOC

Can a DeployOpen engagement produce a PCI DSS certificate?

No. DeployOpen does not issue PCI DSS reports, attestations or certificates. Our role is to plan, implement, harden and document the self-hosted open-source platforms in your environment and to prepare the systems, controls and evidence that a validation needs. The validation itself comes from either a Qualified Security Assessor, who completes a Report on Compliance, or your organization, which completes a Self-Assessment Questionnaire. In both cases the Attestation of Compliance is the form that declares your status. Under PCI SSC FAQ 1220, vendor or consultant certificates are not accepted as validation, so ask any provider, including us, to show you the signed AOC that results from the work rather than a certificate.

Does a SOC 2 report prove PCI DSS compliance?

Not by itself. A SOC 2 report covers the Trust Services Criteria your auditor tested, and it does not replace a PCI DSS ROC or SAQ with its AOC. PCI SSC FAQ 1567 addresses whether assessors can rely on SOC 2 reports, and the answer depends on the scope, period and controls covered, with the assessor deciding what evidence is acceptable. If you already hold a SOC 2 report, ask your QSA or acquirer how much of it they will accept, and map which PCI DSS requirements the report actually addresses before assuming any reduction in testing.

What happens to our result if the standard version changes?

Your result does not expire simply because a newer version of the standard appears. PCI SSC FAQ 1565 states that retiring the version you were assessed against does not shorten how long the result stays valid. Payment brands and acquirers decide how long a result remains valid and how often reassessment is required. PCI DSS v4.0.1 is the only active version, and v4.0 was retired on 31 December 2024, so plan your next assessment against v4.0.1 and confirm with your acquirer whether they expect an earlier reassessment. The PCI SSC has announced a request for comments on the next iteration, but it has not set a release date.

Who can I ask about my validation result and its acceptance?

Start with your acquirer, the bank or payment processor that accepts your card transactions. The PCI SSC does not enforce compliance or impose penalties. Under PCI SSC FAQs 1004 and 1015, the individual payment brands decide which entities must validate and run any enforcement programs. QSAs and ASVs do not send reports or scan results to the PCI SSC, because they follow each brand's procedures (PCI SSC FAQ 1014). For questions about which validation level or SAQ applies to you, and how often you must submit, ask your acquirer or the payment brand directly, and keep a copy of the signed AOC to share with requesting entities.

Can we complete the PCI DSS validation ourselves?

Yes, if your business qualifies for a Self-Assessment Questionnaire. Under PCI SSC FAQ 1215, an SAQ is a validation tool that merchants and some service providers can complete themselves, and it still ends with an Attestation of Compliance that your organization signs. Eligibility depends on how you accept cards and what systems you hold, and some SAQ types require quarterly external scans by an Approved Scanning Vendor. Your team can prepare the work in-house, but the signed AOC, not a consultant's letter, is what counts. If your payment environment is complex or your acquirer requires a ROC, a QSA will need to perform the assessment.

What does the work need from our team?

Expect your own staff to own the decisions and the evidence, even when an outside partner prepares it. Typical needs include a named owner for scope and validation method, access to system owners who can explain configurations, network and data-flow diagrams, policies and records of periodic activities such as log reviews, access reviews and penetration testing. Your team must also confirm the scope with your acquirer and sign the AOC. Before engaging anyone, ask for a written scope that lists the systems, the validation path and the deliverables, because the effort on your side depends mainly on the size of the cardholder data environment and how much evidence already exists.

How DeployOpen prepares PCI DSS evidence for your assessor

DeployOpen prepares the systems, controls and evidence that your organization and its assessor need for a PCI DSS validation. Your organization owns its controls and decides which validation method applies, and only a Qualified Security Assessor or the appropriate validation body issues the ROC or the AOC.

How we scope

We confirm the cardholder data environment, connected systems and security-impacting systems in a written scope before work starts.
We agree with you which validation path applies, ROC or SAQ, and record the basis for that choice in the scope document.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any implementation begins.

How we build

We plan, implement and harden the open-source platforms you run inside your own cloud accounts, data centers or air-gapped networks.
We configure logging, access control, encryption and network controls so each technical requirement produces retrievable evidence.
We test the controls we build, including segmentation and security testing, and record the results for your assessor to review.

How we hand over

We document configurations, data-flow and network diagrams, and the policies and procedures that your team owns and approves.
We organize evidence by requirement so your assessor can trace each control to its artifact without relying on verbal explanations.
We hand over systems, documentation and evidence, while your organization submits its own ROC or SAQ and AOC through payment brand procedures.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so evidence stays current between annual assessments.
We can help you keep recurring activities such as log reviews and scan remediation documented on the schedule your validation requires.
Ask any provider, including DeployOpen, to confirm in writing that it does not issue compliance certificates or attestations on your behalf.

PCI DSS certification explained: AOC, ROC and why certificates don't count