PCI DSS compliance

PCI DSS compliance means protecting payment account data in line with the Payment Card Industry Data Security Standard, it also means validating that protection through the route required for your role, payment flow, transaction volume, and acquirer or payment-brand program. The practical question is not only “Do we meet the 12 requirements?” but “What is in scope, what validation path applies, and what evidence proves the controls are operating?”

What PCI DSS compliance means

PCI DSS is a global baseline of technical and operational requirements designed to protect payment account data. At publication, PCI DSS v4.0.1, dated June 2024, is the current listed standard in the PCI Security Standards Council’s PCI DSS document library.

PCI DSS is not simply a government regulation. More accurately, it is an industry standard governed through payment card ecosystem rules. Whether your organization must validate compliance, and how, is typically determined by the relevant payment brand, acquirer, processor, contractual program, or assessor requirements.

The right compliance path depends on what your organization does with card data: whether you store it, process it, transmit it, or operate systems that could affect the security of the cardholder data environment.

Who needs PCI DSS compliance?

PCI DSS is intended for entities that store, process, or transmit cardholder data or sensitive authentication data, and for entities that could affect the security of the cardholder data environment, according to the PCI SSC standard overview and glossary.

That basically includes two broad groups:

• Merchants: organizations that accept payment cards for their own goods or services.
• Service providers: non-payment-brand entities directly involved in storing, processing, or transmitting cardholder or sensitive authentication data on another entity’s behalf, including entities that control or could affect its security.

Small businesses are not automatically exempt. A small retailer, SaaS company, nonprofit, marketplace, or professional services firm may still have PCI DSS responsibilities if it accepts card payments or affects cardholder-data security. The validation route may be lighter for some environments, but size alone does not remove the need to confirm obligations with the acquirer and applicable payment brands.

Outsourcing payments can reduce what is in scope, but it does not make PCI DSS irrelevant by default. A hosted payment page, third-party gateway, tokenization service, or payment facilitator may reduce the systems and controls you need to assess, but eligibility and remaining responsibilities depend on the payment flow and must be verified.

Start with scope: what is your cardholder data environment?

Before selecting an SAQ, before hiring an assessor, or gathering evidence, map your cardholder data environment. PCI SSC defines the CDE as the people, processes, and system components that handle cardholder data or sensitive authentication data, plus components with unrestricted connectivity to them.

In practical terms, ask:

• Where is card data entered?
• Where is it transmitted?
• Is it ever stored?
• Which systems can affect the security of payment pages, payment APIs, terminals, call-center workflows, logs, databases, or integrations?
• Which vendors process or could affect cardholder data on your behalf?

Common payment flows create different scoping questions:

Scope affects the likely validation route, evidence burden, ASV scan relevance, and whether a QSA or other expert review is needed. PCI SSC also states that a requirement may be treated as inapplicable to a system component only when that conclusion is verified and supported by documented evidence; controls used to reduce applicability must also be verified as implemented and operating as intended.

The 12 PCI DSS requirements, summarized by outcome

PCI DSS v4.0.1 sets out 12 requirements. The table below summarizes their operational intent and the kind of evidence teams often need to prepare. The evidence and owner examples are practical planning aids, not a substitute for the standard or assessor judgment.

How PCI DSS validation works: levels, SAQs, RoCs, AoCs, ASV scans, and QSAs

PCI DSS compliance and PCI DSS validation are related, but they aren’t the same thing. Compliance is the state of meeting applicable requirements. Validation is the process and paperwork used to show that state to the party asking for it.

Key terms:

• SAQ — Self-Assessment Questionnaire: a PCI SSC form used to document self-assessment results. PCI SSC provides different SAQs for different merchant environments.
• ROC — Report on Compliance: a detailed report documenting PCI DSS assessment results.
• AOC — Attestation of Compliance: the PCI SSC form used by merchants and service providers to attest to assessment results.
• ASV — Approved Scanning Vendor: a PCI SSC-approved vendor that conducts external vulnerability scanning services for applicable PCI DSS requirements.
• QSA — Qualified Security Assessor: a PCI SSC-qualified independent assessment organization.
• ISA — Internal Security Assessor: an individual trained to perform internal assessments for their own organization.

Compliance levels aren’t universal across every card brand and region. Visa states that merchant level is based on Visa transaction volume over a 12-month period and that acquirers obtain the required validation documentation through its Account Information Security program. Mastercard’s Site Data Protection program uses annual ROC or SAQ validation by level, while also noting exceptions and acquirer oversight.

The practical takeaway: use transaction volume, channel, and role to identify the likely route, but check the required validation documents with your acquirer, applicable payment brand, and assessor.

Choose your likely PCI DSS validation route

A directional guide only; confirm your validation route with your acquirer, applicable payment brand, and assessor.

1. Are you a merchant or a service provider?

If you accept cards for your own products or services, start with merchant validation requirements. If you store, process, transmit, or can affect cardholder data for customers, evaluate service-provider obligations as well. Some organizations are both.

2. Do you store, process, or transmit cardholder data, or affect the CDE?

If yes, PCI DSS scope likely exists. If you believe the data is fully outsourced, document the payment flow and vendor responsibilities rather than assuming you are out of scope.

3. What payment channels do you use?

Use separate flows for:

• ecommerce
• in-person terminals
• mobile payments
• call-center or mail/telephone orders
• recurring billing
• marketplace or platform payments
• service-provider processing for customers

Mixed channels often complicate SAQ selection because one simple payment flow does not necessarily cover the whole environment.

4. Is payment fully outsourced, partially outsourced, or handled by your systems?

PCI SSC’s SAQ guidance gives examples of why this matters:

• SAQ A is for eligible card-not-present merchants that fully outsource cardholder-data functions and do not electronically store, process, or transmit cardholder data on their own systems or premises.
• SAQ A-EP addresses eligible ecommerce merchants whose websites can affect payment-transaction security.
• SAQ D is used by merchants outside the listed specialized SAQ categories.

These examples are not automatic classifications. The SAQ is appropriate only if the eligibility criteria and acquirer or payment-brand requirements are met.

5. What is your approximate transaction volume?

Transaction volume helps determine validation level under specific payment-brand programs. Do not rely on a generic “PCI level” table without checking the named brand, region, time period, and acquirer requirements.

6. Is an SAQ or ROC more likely?

An SAQ may be available for eligible environments when the relevant acquirer or payment brand accepts self-assessment. A ROC is typically associated with more detailed assessment routes, including certain higher-volume, service-provider, or complex environments, depending on the applicable program.

7. Are ASV scans likely required?

Use an ASV where the applicable PCI DSS requirement or validation program requires external scanning. Do not assume ASV scans are always required, or that a clean scan alone proves PCI DSS compliance.

8. When should a QSA or expert be involved?

A QSA may be required by the applicable validation program or useful when scope is complex. Consider expert review when you have card-data storage, custom payment applications, multiple channels, service-provider responsibilities, unclear segmentation, or uncertainty about SAQ eligibility.

PCI DSS readiness checklist: evidence, owners, remediation, and reassessment

Use this as a conservative operating checklist, not an official PCI SSC checklist.

• Map payment flows

  • Document every channel where card payments are accepted.
  • Identify systems, people, vendors, and processes that store, process, transmit, or could affect cardholder data.

• Confirm role and validation expectations

  • Determine whether you are acting as a merchant, service provider, or both.
  • Confirm validation level and required documentation with your acquirer and applicable payment brands.

• Select the likely validation route

  • Identify the relevant SAQ type or ROC path.
  • Document why the selected path appears eligible.
  • Preserve evidence for any systems or requirements treated as out of scope or not applicable.

• Assign control owners

  • Name owners for network controls, configurations, access, vulnerability management, logging, physical security, policies, vendors, and evidence collection.
  • Avoid leaving “PCI” solely with security if engineering, IT, operations, finance, and vendors operate relevant controls.

• Gather evidence

  • Policies and procedures
  • Data-flow and network diagrams
  • Asset and vendor inventories
  • Configuration records
  • Access approvals and reviews
  • Vulnerability scan results
  • Log-review records
  • Training records
  • Change tickets
  • Remediation tickets
  • Vendor attestations or responsibility documentation

• Run required testing and scans

  • Schedule ASV scanning where required.
  • Track findings to closure.
  • Keep evidence that remediation was completed and retested where applicable.

• Prepare the validation package

  • Complete the SAQ and AOC, or prepare for ROC work, as applicable.
  • Keep supporting evidence close to each assertion rather than scattered across tools and inboxes.

• Create a reassessment rhythm

  • Review scope when payment flows, vendors, infrastructure, applications, transaction volumes, or business models change.
  • Treat validation as recurring work, not a once-a-year scramble.

Can you do PCI DSS compliance yourself?

Some organizations may be able to complete self-assessment if their environment is eligible and their acquirer or payment brand accepts that route. That is most plausible when payment flows are well understood, cardholder-data handling is limited, and the organization can produce credible evidence for each applicable requirement, at least in most cases.

Self-assessment does not mean informal assessment. The organization still needs accurate scope, working controls, documented evidence, remediation tracking, and an appropriate AOC.

External support may be useful when scope is unclear, systems store or affect card data, multiple payment flows exist, or the organization needs help preparing for QSA-led assessment. The safest first move is to confirm the required route before investing effort in the wrong SAQ or evidence package, if possible.

What happens if you are not PCI DSS compliant?

Consequences depend on the applicable payment-system rules and contracts. Visa states that it may assess non-compliance assessments to an issuer or acquirer when a merchant or service provider does not comply with PCI DSS or fails to rectify a security issue.

Avoid relying on generic fine ranges or informal internet estimates. The practical risk is that non-compliance can create contractual, operational, and assessment pressure through the payment ecosystem, especially if a security issue remains unresolved.

Next steps for building a sustainable PCI DSS compliance program

Start with a scope review, not a controls checklist. Confirm your role, payment flows, CDE boundaries, validation route, and evidence owners before remediation begins.

For ongoing operation, keep PCI DSS tied to normal change management: new payment vendors, application changes, infrastructure moves, call-center processes, and transaction-volume changes should trigger reassessment. For organizations managing PCI DSS alongside other frameworks, an operational compliance system can help keep evidence, ownership, and remediation current.

The best next step is simple: document your payment flows, confirm the required validation route with your acquirer or assessor, and build the evidence plan around that route.