PCI DSS Frequently Asked Questions

PCI DSS frequently asked questions

The Payment Card Industry Data Security Standard (PCI DSS) sets security requirements for protecting payment account data. Your assessment scope, validation route and evidence depend on how payments are handled, your role and the requirements of the organisations accepting your compliance submission.

This FAQ refers to PCI DSS v4.0.1. Version 4.0 retired on 31 December 2024, and the requirements originally future-dated to 31 March 2025 are now in effect. The PCI SSC version announcement explains these dates.

Start here: describe every way your business accepts payments, identify the systems and suppliers involved, then confirm the required validation route with your acquirer or payment brand. Use the answers below to turn that scope into controls, evidence and recurring tasks.

Scope and responsibilities

Start with three decisions: map where account data flows, establish who can affect payment security, and confirm which assessment documents your acquirer or payment brand requires. Keep evidence of the scope and the division of responsibilities.

Who does PCI DSS apply to?

PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to systems or services that can affect the security of that environment. Establish the actual payment flows and dependencies before deciding which requirements apply.

Does outsourcing payments remove our responsibilities?

No. Outsourcing can reduce the systems and requirements directly relevant to your environment, but responsibilities remain. Check the provider’s assurance for the services you use, document shared responsibilities and maintain the required agreements and oversight. Confirm your own validation obligations with your acquirer or payment brand. See the PCI SSC outsourcing FAQ.

Can segmentation reduce scope?

Effective segmentation may reduce scope by isolating the cardholder data environment (CDE). A diagram, VLAN name or firewall rule alone does not establish effective isolation. Define the boundaries and validate them through appropriate testing; systems that can affect payment security may remain in scope.

Choosing a validation route

The PCI SSC explains that compliance-accepting entities, typically payment brands and acquirers, determine validation and reporting requirements. Assessors help verify scope and applicability. Avoid choosing a route solely from a generic transaction-volume table.

A Qualified Security Assessor (QSA) can help assess scope and applicable requirements. Confirm the reporting route with your compliance-accepting entity rather than assuming that a scan vendor or software provider decides it.

Check current assessor and scanning-vendor status. Use PCI SSC's official QSA listing and ASV listing when selecting a provider. Confirm the company, relevant region and service, and the assessor's current qualification with the QSA company. An old certificate, website badge or previous engagement is not a current-status check. Agree scope, deliverables and the reporting route with the provider and the organisation accepting your compliance submission.

What are an SAQ, ROC and AOC?

An AOC is not a separate shortcut around the underlying assessment. Confirm the documents and signatories your compliance-accepting entity requires.

Can every small merchant use the same SAQ?

No. SAQ eligibility depends on the payment arrangement and technical environment, not just business size. E-commerce, telephone, terminal and outsourced-payment arrangements can have different conditions. Check every eligibility statement against your actual environment.

Confirm the route for every payment channel, not just the website. An environment may combine in-person, online and telephone payments. Do not assume that qualifying for one SAQ covers all channels.

What should we request from a service provider?

Request assurance that covers the actual service you use, its assessed scope, relevant responsibilities and applicable assessment period. A generic certificate or a merchant-only SAQ may be insufficient evidence for a provider’s services. See PCI SSC guidance on third-party service-provider evidence.

Do embedded payment forms and redirects have the same SAQ A conditions?

No. PCI SSC FAQ 1588 distinguishes the specific script-attack eligibility condition for embedded payment pages or forms, such as iframes, from redirects and fully outsourced payment links. For an embedded form, confirm protection through appropriate techniques or confirmation from the compliant payment provider about its correctly implemented solution. A provider’s general compliance claim is not the same confirmation.

The specific script condition does not apply to redirects in the same way, but the other SAQ eligibility criteria and applicable requirements still matter. See PCI SSC FAQ 1588.

Do SAQ A websites still need ASV scans when payments are outsourced?

Yes. PCI SSC’s June 2026 clarification says SAQ A e-commerce webpages using redirects or embedded iframes remain subject to the included external-scanning requirements. Outsourcing payment processing does not automatically remove scanning of the merchant’s relevant web environment. Confirm the scan scope with your ASV and the organisation accepting your assessment. See PCI SSC FAQ 1604.

Worked example: an online shop using a hosted checkout

Consider a shop whose website redirects a customer to a payment provider and receives a payment result. This is an illustration, not an eligibility decision for your environment.

1. Draw the actual journey. Include the merchant website, redirect, payment provider, administration access and how payment results return. Confirm whether any other process handles account data, including telephone orders.

2. Confirm the assessment route. Check all relevant eligibility criteria with the organisation accepting compliance. Do not select SAQ A solely because the provider advertises a hosted checkout.

3. Collect provider evidence. Check that assurance covers the specific service and document who is responsible for the applicable controls.

4. Maintain the merchant environment. Apply the included ASV scanning requirements and other applicable controls. Outsourcing processing does not make a compromised merchant website irrelevant.

5. Reassess changes. Adding an embedded form, changing integrations or introducing another payment channel can change the relevant conditions. Review scope before assuming the previous assessment remains suitable.

For the distinction between redirects and embedded forms, and the external scanning position, see PCI SSC FAQ 1588 and FAQ 1604.

Scanning, testing and remediation

Does a passing ASV scan make us PCI DSS compliant?

No. An Approved Scanning Vendor (ASV) scan addresses an external vulnerability-scanning requirement where applicable. It does not assess every PCI DSS requirement, internal system, process or business responsibility. Resolve failures and obtain the required passing results, while maintaining the rest of the applicable controls.

Keep the official scan report and attestation required by the ASV programme. Marketing certificates or letters do not replace the recognised assessment documents.

Are scanning and penetration testing the same?

No. Scanning identifies potential weaknesses using a defined scanning process. Penetration testing examines whether weaknesses and access paths can be used to compromise security. Segmentation testing checks intended isolation. These activities provide different evidence and are not interchangeable.

Correct exploitable weaknesses according to the assessed risk and repeat penetration testing to verify the corrections. A report listing vulnerabilities without closure evidence does not complete that obligation.

How often must tests be performed?

The following summarises the defined approach in PCI DSS v4.0.1. Apply each row only where that requirement is applicable to your assessed environment; an eligible SAQ can contain a subset of requirements.

The significant-change external scan does not itself have to be performed by an ASV: qualified, organisationally independent personnel can perform it. This does not remove the recurring ASV requirement. Review the complete requirements, applicability notes and remediation conditions in the PCI SSC document library when setting the schedule.

Validation, non-compliance and customer assurance

How do merchant levels affect our assessment?

Payment brands and acquirers operate compliance programmes with their own reporting criteria. Transaction volumes can matter, but do not use a generic four-level table as a universal eligibility decision. Ask your acquirer to confirm the applicable programme, assessment route, submission date and evidence for your payment channels. Keep that confirmation with the scope record. PCI SSC explains the role of compliance-accepting entities.

What happens if we are not compliant?

PCI SSC publishes standards but does not impose non-compliance penalties. Payment-brand programmes and commercial arrangements can have financial or operational consequences. Discuss your position with the acquirer rather than relying on a universal fine or deadline quoted online. PCI SSC’s consequences FAQ explains this distinction.

If there are gaps, describe them accurately, establish remediation owners and dates, and agree the required next steps with the organisation accepting your submission. Do not present an incomplete assessment as a compliant result. Suspected compromise also needs the relevant incident and notification procedures; a future assessment date is not an incident response plan.

Can a certificate or website badge prove compliance?

A marketing certificate or badge does not replace official PCI SSC reporting forms. Be precise about the entity, service, scope, assessment period and evidence behind a claim. An external scan result alone cannot support a claim that the whole organisation satisfies every applicable requirement. See PCI SSC’s guidance on compliance certificates.

When customers request assurance, provide the appropriate official documentation through an agreed channel and explain its scope. Avoid circulating detailed assessment findings unnecessarily. Confirm permission before using a provider’s logo or badge, and keep any public statement consistent with the actual assessment.

Maintaining compliance

Make compliance part of routine operations. Keep a single working plan linking each applicable task to its owner, frequency or change trigger, evidence location and unresolved exceptions.

Before submission: reconcile the environment and assessment scope, confirm the correct documents and signatories, check that required scans and tests cover the relevant period, and resolve or properly address gaps through the applicable assessment process. Do not assume an internal risk acceptance can waive a PCI DSS requirement.

Is compliance a once-a-year exercise?

No. Controls must operate throughout the relevant period. Assign owners and retain evidence for recurring tasks such as access review, vulnerability handling, monitoring, supplier oversight and training. Reassess scope and responsibilities when payment methods, systems or providers change.

Does compliance guarantee that we cannot be breached?

No. An assessment evaluates conformity within its scope and evidence. New weaknesses, changes, operational failures and attacks still require attention. Use the assessment to support ongoing risk management and incident readiness.

What should we prepare for a QSA discussion?

Bring payment and network diagrams, a system inventory, details of every payment channel, provider contracts and assurance, your last assessment, scanning and test results, significant changes and unresolved findings. Identify who owns payments, IT operations, security and supplier relationships.

How do we start, and how much work will it take?

First document payment channels and providers, confirm scope and the required validation route, then assess gaps and assign remediation owners. The effort depends on system complexity, segmentation, existing controls, evidence quality and unresolved findings. Ask for a scoped estimate rather than relying on a price based solely on transaction volume. Agree recurring tasks as well as the assessment date.

What replaced PA-DSS?

PA-DSS retired on 28 October 2022. The PCI Software Security Framework includes the Secure Software Standard and Secure Software Lifecycle (Secure SLC) Standard. Do not describe PA-DSS as the current software-validation programme or assume an old listing establishes a product’s present status. Check the PCI SSC retirement notice and current listings.

Software validation does not by itself establish the PCI DSS compliance of the environment in which the software is deployed.

Related guidance and support

For more detail, read the PCI compliance guide. For assessment and testing support, see PCI DSS QSA consultancy and ASV scanning.

Read the ProCheckUp PCI DSS QSA case study for a scoping example. For authoritative requirements and current reporting documents, use the PCI SSC document library and confirm the submission requirements with your compliance-accepting entity.