A PCI compliant service is a provider that has validated its own handling of payment card data against the PCI Data Security Standard (PCI DSS) for the part of the service you rely on. Compliance is not a badge you buy once. It is shown through validation documents, most often an Attestation of Compliance (AOC), and it covers only the systems and services the assessment included. This guide explains what the term means, what evidence to request, how scope works for B2B software companies, and how to keep the paperwork from slowing your deals.
TL;DR
- "PCI compliant" means a provider has validated its controls against PCI DSS for a defined scope. It does not mean your own company is automatically compliant.
- There is no generic PCI DSS certificate. Compliance is demonstrated through validation documents such as an AOC, a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ).
- Ask every provider for its current AOC and a responsibility matrix that shows which requirements it handles and which remain yours.
- Tokenization and hosted payment fields can shrink your PCI scope by keeping card data out of your systems.
- Buyers will send you PCI questions too. A maintained answer library and a public trust page keep those reviews fast.
Table of Contents
- What "PCI compliant" actually means
- What a PCI compliant service can do for you
- Does your company need to comply?
- Assessments, attestations and "certifications"
- What to ask a provider to show you
- Shared responsibility: why "compliant vendor" is not "compliant you"
- What happens if you are not compliant
- Keeping PCI questions from slowing your sales cycle
- Put your PCI evidence to work with Skypher
- FAQ
- Sources
What "PCI compliant" actually means
The PCI Security Standards Council describes PCI DSS as a baseline of technical and operational requirements designed to protect payment account data. It applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment.
That last clause matters for software companies. You may never touch a card number and still be in scope if your platform can influence the security of the systems that do.
The current version is PCI DSS v4.0.1. The Council published it in June 2024 as a limited revision that clarified requirements and responded to stakeholder feedback without adding or deleting any. If a vendor still describes its compliance against an older version, ask which version its latest assessment used.
Three ideas sit inside the phrase:
- Scope. Compliance is always about a defined set of systems, people and processes. A provider can be compliant for its payment gateway and say nothing about its marketing site.
- Validation. Saying you follow the standard is different from having it assessed or self-assessed in the format your payment brand or acquirer expects.
- Time. Compliance is a recurring cycle. Data flows, integrations and customer touchpoints change, so a validation from several years ago tells you little today.
What a PCI compliant service can do for you
Providers sell PCI help in two different ways, and it pays to separate them.
A service that handles card data for you. Payment processors, hosted checkout providers and tokenization vendors take cardholder data into their environment. Used well, they can reduce your PCI DSS scope through tokenization or hosted payment fields that keep cardholder data out of your systems. The mechanics are straightforward: the customer's card details go straight to the provider, and your systems only ever see a token. A short explainer on how card tokenization reduces the PCI burden shows the idea in three steps.
A service that helps you become compliant. Often sold as "PCI as a service," this covers readiness testing, gap analysis, vulnerability scanning and advice on required controls. Some providers also perform formal assessments. These services support your work. They do not transfer your responsibility to someone else.
A reduced scope is a real benefit, but it is a smaller job rather than no job. You still need to validate the environment that remains, and you still need to confirm how your provider's controls fit with yours. Our guide to the five SAQ paths developers and security teams still own when using a hosted payments provider walks through that split in practice.
Does your company need to comply?
Work through scope before you shop for anything.
- Map where card data goes. Trace every place a card number or sensitive authentication data is entered, stored, transmitted or logged: checkout pages, call recordings, support tickets, spreadsheets, backups.
- Identify connected systems. Anything that can affect the security of those systems, such as identity providers, admin consoles, network segments and monitoring tools, may belong in scope.
- Decide whether to remove data rather than protect it. If you can stop receiving card data altogether through a hosted field or tokenization, scope shrinks before you spend on controls.
- Write it down. Your assessor, acquirer or customers will want a scope statement that matches reality.
If you run on a cloud platform, the infrastructure vendor's own compliance covers its side of the line only. Our walk-through of mapping PCI DSS v4.x on AWS, including artifacts and automation shows how to separate inherited controls from the ones you must evidence yourself.
Security weaknesses elsewhere in an online business also affect payment risk, which is why a broader look at cybersecurity for e-commerce success helps frame where PCI fits.
Assessments, attestations and "certifications"
Searchers often type "PCI compliance certifications," but the standard does not work like an ISO certificate. Compliance is shown through the appropriate validation documentation and processes rather than a generic PCI DSS certificate. What you will actually encounter:
| Document | What it is | Who typically produces it |
|---|---|---|
| ROC (Report on Compliance) | Detailed report of an assessment against PCI DSS | A Qualified Security Assessor (QSA), or qualifying internal resources for some Level 1 merchants |
| SAQ (Self-Assessment Questionnaire) | Self-completed validation, with different versions by how you handle card data | The organization itself |
| AOC (Attestation of Compliance) | Short form attesting to the results of an assessment | The organization, with the QSA where a ROC applies |
| QSA | Independent security organization qualified and trained by the Council to perform assessments | Not a document, but the assessor behind a ROC |
The table follows the structure in Visa's PCI DSS validation guidance, a 2018 US document, which lists a Level 1 ROC, SAQs for Levels 2 and 3, and an SAQ or acquirer-defined alternative for Level 4. The same document explains that validation requirements vary with merchant or service-provider level and transaction volume. Your own level, and what you must file, is set by your payment brands and acquiring bank, so confirm it with your acquirer.
For a closer look at the ROC process, read our practical ROC guide for security teams, and for the wider picture our piece on PCI compliance certifications and their effect on security efficiency. If budget is the question, we cover what PCI certification costs in 2026.
What to ask a provider to show you
When you evaluate a payment processor, hosting vendor, support platform or any other service touching your cardholder data environment, request evidence rather than a logo. The Council's guidance says a third-party service provider with its own PCI DSS assessment should provide an applicable AOC on request, and may provide relevant ROC or SAQ D sections. A provider without an applicable AOC should supply evidence specific to the requirements relevant to its service.
A practical checklist:
- Current AOC that names the exact services you will use, not only the company.
- PCI DSS version the assessment used and the date it was completed.
- Responsibility matrix stating which requirements the provider handles, which are yours and which are shared.
- Scope description that matches how you plan to integrate the service.
- Subprocessors, because a provider may depend on other providers whose controls you also inherit.
- Incident contact and notification process, so you know who acts first when something goes wrong.
- Renewal rhythm, meaning how often the provider revalidates.
The same document says providers should tell customers which requirements they handle and which remain the customer's responsibility. A provider that can do this clearly, quickly and in writing is usually one that runs its compliance program well.
The Visa Global Registry of Service Providers is also worth checking. Visa's security compliance page describes the program and the registry, and notes that PCI DSS compliance is required of all entities that store, process or transmit Visa cardholder data.
Shared responsibility: why "compliant vendor" is not "compliant you"
The most common misunderstanding is assuming that buying from a compliant vendor makes you compliant. It does not. Customers may require a provider's platform to be PCI DSS compliant for the areas it manages within a shared responsibility model. Everything outside those areas, such as your access management, your code, your logging of data you receive and your employee training, remains with you.
A clean way to handle this is to build one internal table that lists each PCI DSS requirement area, who owns it, which document proves it and when that document expires. Review it whenever you add a vendor or change an integration.
What happens if you are not compliant
The Council itself does not run enforcement. It does not manage compliance programs or impose consequences for non-compliance, although individual payment brands may have compliance initiatives with financial or operational consequences. In practice, the pressure flows through contracts. Visa, for example, requires issuers and acquirers to ensure that their service providers and merchants comply, and non-compliance or failure to fix a security issue may lead to an assessment against the issuer or acquirer. Those banks pass obligations to you through your merchant agreement.
For a B2B software company, the more immediate cost is commercial. Enterprise buyers ask for proof of compliance during security review. If your answers are slow or inconsistent, deals wait.
Our perspective
We see PCI work from the buyer-review side every week. Teams that have done the hard compliance work often lose time not to the audit itself but to the stream of questionnaires that follows it: the same dozens of PCI questions, phrased a little differently by every customer, answered by whoever happens to be free.
Our view is that the evidence should be written once and reused with care. That means a knowledge base of approved answers and documents, versioned so everyone knows which AOC or policy is current, and an AI layer that retrieves from that approved content rather than inventing text. Skypher is built on this principle: our retrieval AI draws on your own content and shows a confidence score, so reviewers can focus on the answers that need a human.
We also think customers should not have to ask for the basics. A customizable Trust Center lets you publish your compliance documents and security posture in advance, so routine requests are answered before they arrive.
Gaspard
Keeping PCI questions from slowing your sales cycle
Once you have your own validation in order, the next bottleneck is communication. Security and sales leaders at software companies typically handle PCI questions in three recurring formats: portal-based vendor assessments, spreadsheets and Word documents, and due diligence questionnaires from finance customers.
A workable routine:
- Keep a single source of truth. Store the current AOC, policies, network diagrams and responsibility matrix in one controlled place with versioning.
- Assign subject-matter owners. Each PCI requirement area gets a named reviewer who signs off on its answers.
- Reuse approved answers. Pull from the library, then adjust only what the customer's wording genuinely changes.
- Publish what is safe to publish. Put shareable documents behind an access request on a trust page.
- Review on a schedule. Refresh answers each time your validation is renewed or your architecture changes.
Smaller teams can use the same pattern at a lighter scale, as we describe in our guide to automating PCI questionnaires with SME sign-off for small businesses. Continuous evidence collection helps too: see how to streamline security monitoring and automation for compliance and our guide to compliance scanning for secure operations.
If you also serve healthcare customers, the overlap with HIPAA is large enough to plan for together. Our 30 to 90 day crosswalk aligning PCI DSS and HIPAA and our note on avoiding costly PCI and HIPAA mistakes in 2026 cover where the two programs can share evidence.
Put your PCI evidence to work with Skypher
If your team spends days answering PCI and security questionnaires, our Questionnaire Automation Tool is designed to shorten that work. It reads questionnaires in every format, drafts answers from your approved content with a confidence score, and connects with more than 40 third-party risk management platforms and tools such as OneTrust, ServiceNow, Slack, MS Teams, Confluence, Notion, Google Drive and SharePoint. Your colleagues can collaborate in real time with unlimited users.
For customers who want evidence before they ask, our Trust Center gives you a customizable, customer-facing home for your compliance posture. If you handle diligence questionnaires from financial institutions, see our DDQ automation. Please feel free to reach out, and we will show you how it works with your own documents.
FAQ
What does PCI compliant mean?
It means an organization has validated its security controls against PCI DSS for a defined scope, using the format its payment brand or acquirer requires. The proof is a validation document such as an AOC, not a generic certificate. Always check what the scope covers.
What is PCI as a service?
It is a subscription-style offering in which a provider helps you assess cardholder data handling, find gaps, scan for vulnerabilities and prepare for your annual validation. Some providers also perform formal assessments. It supports your compliance work but does not make the responsibility disappear.
How can I tell whether a vendor is PCI compliant?
Ask for its current AOC covering the specific service you will use, the PCI DSS version assessed and a responsibility matrix. Where the vendor is a payment service provider, you can also look for it in the card brands' service provider registries, such as the one Visa describes on its security compliance page.
What happens if I am not PCI compliant?
The PCI Security Standards Council does not impose penalties itself, but payment brands and acquiring banks can apply financial or operational consequences through their contracts. Talk to your acquiring bank about your specific obligations and a remediation timeline.
Sources
- PCI Security Standards Council: PCI DSS
- PCI Security Standards Council: Standards overview
- PCI Security Standards Council: PCI DSS v4.0.1 published
- Visa: PCI DSS Validation Best Practice Review
- Visa: Account Information Security Program and PCI
- PCI SSC FAQ 1576: evidence a third-party service provider is expected to provide
- PCI SSC FAQ 1015: consequences of non-compliance
- Understanding PCI DSS for service providers
- PCI compliance service providers: how to choose one
- PCI DSS compliance checklist and requirements