Payment Card Industry Data Security Standard (PCI DSS)

What is the PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is the shared security baseline for protecting payment card account data. It applies to the people, processes, and technology involved in accepting cards, from a small online store using a hosted checkout page to a global payment processor running its own infrastructure.

PCI DSS exists because payment data travels through many organizations. One weak link can expose thousands or millions of accounts. The standard sets a common minimum for securing that chain and for showing payment partners that the controls are in place.

The current version is PCI DSS v4.0.1. It became the only active version after v4.0 retired on December 31, 2024. Requirements that v4 originally treated as future-dated became fully effective on March 31, 2025.

PCI DSS is not a law and the PCI Security Standards Council does not enforce it. Compliance usually becomes an obligation through agreements with payment brands, acquiring banks, and other payment partners. Those organizations also decide how you must validate and report compliance.

Who PCI DSS applies to

PCI DSS applies to entities that:

• store, process, or transmit cardholder data or sensitive authentication data;
• are involved in payment card processing, including merchants, processors, acquirers, issuers, and service providers; or
• can affect the security of a cardholder data environment, even if they do not directly handle card numbers.

That last point catches people by surprise. A managed service provider with administrator access, for example, may affect payment security without processing a single sale.

Business size does not decide whether PCI DSS applies. A shop processing ten card payments still has a responsibility to protect the data. Size, transaction volume, payment channels, and contractual rules instead affect how the business validates its compliance.

Outsourcing payment processing can reduce your scope, but it does not outsource your responsibility. You still need to use appropriate service providers, understand which responsibilities they perform, and secure the parts of the payment experience you control.

Who manages and enforces PCI DSS

The PCI Security Standards Council (PCI SSC) writes and maintains PCI DSS. It also manages qualification programs for assessors and scanning vendors. The Council does not assign merchant levels, accept compliance reports, fine merchants, or declare organizations compliant.

Those jobs belong to the organizations operating payment compliance programs:

• Payment brands establish their own compliance programs and validation rules.
• Acquiring banks, often called merchant banks or acquirers, commonly tell merchants what to submit and when.
• Other compliance-accepting entities may set requirements for service providers or business partners.

This division matters because the standard alone cannot tell you whether your organization must complete a particular Self-Assessment Questionnaire (SAQ) or obtain a Report on Compliance (ROC). Get that answer from the organization that will receive your compliance documentation.

Noncompliance can lead to extra oversight, fees, increased transaction costs, restrictions, or termination of a payment relationship. The actual consequences come from contracts and payment-brand programs, not from a universal PCI fine schedule. Following a breach, an organization may also face forensic investigation, notification, legal, and remediation costs.

What is in scope

Scope is where PCI DSS stays manageable or becomes a very large project.

The starting point is account data:

• Cardholder data (CHD) centers on the primary account number (PAN), commonly called the card number. A cardholder name, expiration date, and service code are also cardholder data when stored with the PAN.
• Sensitive authentication data (SAD) includes full track data, card verification codes, and PIN data. It must not be stored after authorization, even if encrypted.

The cardholder data environment (CDE) includes the people, processes, and technology that store, process, or transmit this data. Scope can also reach systems connected to the CDE and anything that could affect its security. Identity systems, administrator workstations, logging platforms, cloud management tools, and service providers may all matter.

A useful scope exercise traces every payment channel and asks:

1. Where does account data enter?
2. Where does it travel?
3. Where could it be stored, including logs, recordings, exports, and backups?
4. Which people and systems can access it or affect its security?
5. Which third parties perform part of the process?

Reducing unnecessary data flows is often the most effective PCI project. Hosted payment pages, validated point-to-point encryption, tokenization, and network segmentation may reduce scope when they are designed and operated correctly. None of them removes obligations automatically. Their effect depends on the implementation and your validation method.

What PCI DSS requires

PCI DSS organizes its controls into 12 requirements. In plain language, organizations must:

1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
3. Protect stored account data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect systems and networks from malicious software.
6. Develop and maintain secure systems and software.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access to system components.
9. Restrict physical access to cardholder data.
10. Log and monitor access to systems and cardholder data.
11. Test the security of systems and networks regularly.
12. Support information security with organizational policies and programs.

The list is broad by design. PCI DSS is not just a firewall checklist. It reaches software development, access reviews, employee training, incident response, vendor oversight, physical security, vulnerability management, and evidence that recurring activities happened when they were supposed to happen.

Most organizations use the standard’s defined approach, which follows the stated requirements and testing procedures. PCI DSS v4 also permits a customized approach for some requirements. That option requires the organization to demonstrate that its controls meet the requirement’s objective and provide equivalent protection. It is not a shortcut and is not supported by SAQs.

How compliance is validated

Complying with PCI DSS and validating that compliance are related, but they are not the same thing. The standard describes the security baseline. Your payment brand, acquirer, or other compliance-accepting entity decides what proof it expects.

Merchant and service-provider levels

Payment programs commonly group organizations into levels using transaction volume, entity type, breach history, and other risk factors. The thresholds and validation rules vary by payment brand. “Level 1” usually carries the most demanding external validation, but a lower-volume organization can still be required to complete a ROC.

Do not choose a level from a generic chart and assume the job is settled. Ask your acquirer or payment brand to confirm your level and reporting obligations in writing.

SAQ, ROC, and AOC

• A Self-Assessment Questionnaire (SAQ) is a PCI SSC reporting tool for eligible organizations that assess their own compliance. Different merchant SAQs cover different payment environments. Service providers eligible to self-assess use SAQ D for Service Providers.
• A Report on Compliance (ROC) records a detailed assessment against the applicable PCI DSS requirements. Organizations with higher-risk or more complex validation obligations are commonly required to use a ROC.
• An Attestation of Compliance (AOC) is the signed summary that accompanies an SAQ or ROC. It is usually the document shared to attest to the result, while the underlying report may contain sensitive environment details.

These documents are validation records, not permanent certificates. They cover a particular entity, environment, scope, and point in time. A certificate sold by a vendor may be a convenient summary, but it is not a universal PCI SSC credential for merchants.

If you are choosing between forms, start with the official SAQ types and Which PCI SAQ do I need?. If a QSA will review or sign the SAQ, see What is a QSA-validated SAQ?. Whether a ROC is required instead is the receiving organization’s call; the next section covers how to get that answer.

Who performs the work

• A Qualified Security Assessor (QSA) works for a Qualified Security Assessor company (QSAC) qualified by PCI SSC to perform PCI DSS assessments.
• An Internal Security Assessor (ISA) is trained by PCI SSC to support assessments inside the ISA’s own organization. Whether an ISA may complete a required validation depends on the applicable compliance program.
• An Approved Scanning Vendor (ASV) performs the external vulnerability scans required for applicable environments.
• Qualified internal or external penetration testers perform penetration tests. A penetration tester does not have to be an ASV or QSA simply because the test supports PCI DSS.

PCI SSC publishes searchable lists of currently qualified QSA companies and ASVs. Check the listing before you hire, and check it again when you engage them. Qualification is current status, not a lifetime badge.

Scanning and penetration testing solve different problems: an ASV scan is an automated external check for known vulnerabilities on a fixed schedule, while a penetration test is a person actively trying to break in, on a broader scope and at least annually.

The PCI compliance process

The reporting form is the output, not the program. A practical first validation cycle usually looks like this:

1. Confirm the assignment. Ask the receiving organization which level, validation method, reporting period, documents, and submission deadline apply.
2. Define scope. Document payment channels, data flows, systems, locations, people, connections, and service providers.
3. Assess gaps. Compare the scoped environment with the applicable PCI DSS requirements and testing procedures.
4. Remediate. Change configurations, software, architecture, policies, contracts, and operating practices. Collecting evidence starts here, not the week before assessment.
5. Test controls. Perform the required scans, penetration tests, access reviews, interviews, observations, and evidence checks.
6. Complete validation. Finish the applicable SAQ or ROC and its AOC, then resolve any remaining findings.
7. Submit and maintain. Send the requested documents to the compliance-accepting entity and continue recurring control activities.

Who decides, and what to ask them

Step one is the one people skip, usually because they do not know who to call. Your obligations are set by whoever receives your compliance paperwork. For most merchants that is the acquirer: the bank or payment company that settles card sales into your account. Its name is on your monthly merchant statement and on the portal where you see payment reports. Many acquirers run PCI through a compliance program vendor; an email from one of those vendors asking you to complete a questionnaire is the request, and that vendor’s support line is a valid place to start. If you truly cannot tell who your acquirer is, your payment processor’s support team will know. Service providers answer to their customers, and where a brand’s service-provider program applies, to that brand.

Ask, and keep the answers in writing:

• Which merchant or service-provider level you are assigned, and under which brand’s rules.
• Whether you validate with an SAQ or a ROC, and if an SAQ, which type they will accept for each payment channel.
• Whether a QSA or ISA must be involved, and what “involved” means to them: coaching, evidence review, or a signature on the AOC.
• What must accompany the submission: the AOC alone, or also ASV scan reports, penetration test summaries, or other evidence.
• The reporting period, the submission deadline, and how to submit (portal, email, or through the program vendor).
• What happens if you miss the deadline or cannot attest to every requirement: fees, added monitoring, or a remediation timeline.

The answers may differ from what a generic PCI chart says, and the acquirer’s answer is the one that counts.

The neat seven-step list should not fool you: scope and remediation usually consume most of the calendar. A well-scoped environment with mature controls can move quickly. A sprawling environment with undocumented data flows will take longer, regardless of how fast someone can fill in a questionnaire.

Cost, time, and internal effort

The cost range on this page covers validation fees only, for the most common audited path: a QSA-led ROC at a typical organization. That definition keeps standards comparable across this site, and it is the number you can check against an assessor’s quote.

Which validation path you are assigned drives the fee more than anything else:

• A self-completed SAQ has no assessor fee. Where the SAQ requires ASV scanning, a scanning service typically costs a few hundred dollars a year.
• A QSA-validated SAQ, where an assessor reviews or signs the questionnaire, commonly runs $5,000 to $40,000 depending on the SAQ type and environment.
• A QSA-led ROC typically runs $25,000 to $60,000. Large or multi-site environments run into six figures, and published QSA ranges reach $200,000 for enterprise engagements.

The validation fee is often not the largest cost. Surrounding costs sit outside the range above:

• replacing or reconfiguring systems;
• changing payment architecture;
• purchasing security and monitoring tools;
• gathering evidence across teams and locations;
• fixing findings and repeating failed tests; and
• operating the controls throughout the year.

For early planning, the page’s cost and effort ranges are directional, not a quote. The best predictors are the size of the CDE, the required validation method, the number of payment channels and locations, reliance on service providers, and how much remediation is needed. A full breakdown, including where these figures come from, is in How much does PCI DSS cost?

Time follows the same pattern. A simple, already-compliant environment might finish an SAQ in weeks. A first ROC involving architecture changes can take many months. Start with scope before requesting a firm estimate.

Maintaining compliance

PCI DSS is an operating rhythm, not an annual paperwork event. Validation is commonly annual, but the controls run throughout the year.

Depending on the environment and applicable requirements, recurring work may include:

• external ASV scans at least once every three months;
• internal vulnerability scans;
• penetration tests at least annually and after significant changes;
• tests of segmentation controls;
• access and user-account reviews;
• log review and security monitoring;
• risk analyses, policy reviews, and security awareness training;
• incident-response exercises; and
• checks that third-party service providers remain compliant.

Not every activity applies to every SAQ or environment, and some frequencies depend on a targeted risk analysis. Use your applicable PCI DSS requirements, SAQ, and compliance-program instructions as the source of truth. For the organization-wide risk assessment many assessors still expect to see, the free risk assessment tool on this site produces a register and report without sending your data anywhere.

Scope also needs maintenance. A new checkout integration, cloud account, office, support tool, service provider, or administrator path can change it. Include PCI impact in architecture, procurement, and change-management reviews so those surprises happen before deployment.

How to get started

If PCI DSS has just landed on your desk, begin with five concrete actions:

1. Contact your acquirer or compliance-accepting entity. Confirm your merchant or service-provider level, required validation method, deadline, and submission process.
2. Draw the payment flows. Include every channel, such as e-commerce, terminals, phone payments, recurring billing, and manual processes.
3. Build a scope inventory. List the systems, people, locations, service providers, and connections involved in or able to affect those flows.
4. Collect service-provider documentation. Obtain current AOCs and document which PCI DSS responsibilities each provider performs.
5. Assess before attesting. If you are SAQ-eligible, pick the correct questionnaire, identify gaps, and leave time to fix and retest them. If a QSA-validated SAQ or a ROC applies, engage a Qualified Security Assessor company (QSAC) before you try to attest. The assessor will want your payment-flow diagrams and scope inventory from the steps above, so gather those first.

Use the PCI DSS page maintained by PCI SSC for the standard overview. The PCI SSC Document Library contains the current standard, SAQs, AOCs, guidance, and supporting documents. The PCI SSC FAQ library covers common scoping and validation questions.

The first goal is not to memorize all 12 requirements. It is to confirm what you have been asked to validate and understand where payment data touches your organization. Once those two facts are clear, the rest of the project becomes much easier to plan.