Who needs PCI DSS compliance and does it apply to your business
PCI DSS applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers, and it applies to merchants regardless of size or transaction volume. Size only changes how validation is handled, not which requirements apply. If a customer, acquirer or contract now asks for PCI DSS evidence, the answer starts with that test: does your organization touch account data, or can it affect the systems that do? The PCI Security Standards Council owns and maintains the standard, and the current active version is PCI DSS v4.0.1, which replaced v4.0 as the only active version after v4.0 was retired on 31 December 2024.
The PCI SSC does not decide who must validate or how. The individual payment brands set those rules, and your acquiring bank, or the card brands if you are a payment service provider, administers them. Ask your acquirer whether you must validate, which validation level applies and what reporting it expects. Parent and subsidiary companies may validate together or separately depending on each brand's rules, so confirm that point in writing before you scope the work. If you fully outsource payment pages or processing and never store, process or transmit card data yourself, the requirements may apply to you only in limited form, but you still need written agreements with your provider and must check its compliance status at least annually.
Only two routes produce recognized validation: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each supported by an Attestation of Compliance on official PCI SSC templates. Certificates, logos and vendor badges are not accepted as validation. Before you commit to either route, confirm which path your acquirer or brand requires, then decide whether your team, a consultant or an assessor will prepare the evidence. Preparation support is not validation, and only the assessor or the signed SAQ and AOC process can establish compliance status.
Which entities does PCI DSS apply to?
PCI DSS does not apply because of company size or industry. It applies because of a relationship to account data: holding it, moving it, operating the systems that handle it, or affecting the security of the systems that do. The four cases below cover the most common triggers, and each one has a point where you should confirm your status with your acquirer or the payment brands.
Merchants handling account data
A merchant that stores, processes or transmits cardholder data or sensitive authentication data is in scope whatever its size or transaction volume. Storing a primary account number in a spreadsheet, a support ticket or a log file counts, as does passing card details through your own servers before they reach a processor. Your transaction volume decides your validation level, but not whether the requirements apply. Ask your acquiring bank which validation path and reporting it expects you to file.
Processors, acquirers and issuers
Payment processors, acquiring banks and card issuers are named in the standard's scope because they handle account data at the center of the payment ecosystem. Their obligations are usually set by the card brands and their contracts rather than by the PCI SSC, which does not enforce compliance. If your organization sits in one of these roles, confirm with the individual payment brands which validation and reporting apply to your entity, and whether parent and subsidiary companies validate together or separately.
Service providers with CDE access
A service provider is in scope when it can affect the security of a customer's cardholder data environment, even if it never stores, processes or transmits that data itself. Typical triggers are administrative access to a customer's CDE, managing firewalls or hosting infrastructure for a payment environment, or meeting a PCI DSS requirement on a customer's behalf. Before you accept such work, confirm with the card brands which validation level and attestation your service falls under, and what you must give each customer in writing.
Systems that affect CDE security
Some organizations never touch card data but run systems that could weaken the protection of the CDE. Examples include identity providers that control access to payment systems, shared network segments, monitoring tools, and internal IT teams that patch or administer connected servers. These entities are in scope by influence rather than by data flow, and assessors examine connections between systems as closely as the systems themselves. Map every connection to the CDE, then confirm with your acquirer or brand whether those systems fall inside the assessment.
How PCI DSS applies to outsourced payments and small merchants
A merchant that sends customers to a provider's hosted payment page, or embeds a provider's iframe, and never stores, processes or transmits cardholder data itself may find that many PCI DSS requirements do not apply to its own systems directly. That reduction does not remove the merchant's obligations. The merchant still has to confirm that its payment provider is compliant for the services it uses and document how responsibilities are split.
- Provider compliance: Confirm the provider is PCI DSS compliant for the specific services in use, not only at the corporate level.
- Written agreements: Keep written agreements with each provider that include the provider's responsibilities, as Requirement 12.8.2 asks.
- Annual status checks: Check each provider's compliance status at least once every year, under Requirement 12.8.4.
- Shared responsibilities: Define in writing which requirements the provider meets and which remain with the merchant, such as its own web pages, staff access and redirect logic.
- Eligibility for a lighter questionnaire: Whether the merchant can use the shortest self-assessment depends on how the payment page is delivered and on current eligibility criteria.
Before relying on outsourcing, check with your acquiring bank which reporting applies to you, because the answer determines what you must submit.
Size and transaction volume do not decide whether PCI DSS applies. The standard applies to all merchants regardless of size. What volume changes is how a merchant validates compliance. Payment brand levels, set by the card brands rather than the PCI Security Standards Council, determine which validation route and reporting a merchant must follow, so a small business can have the same requirements as a large one and a lighter reporting path.
- Same requirements: A small merchant that stores, processes or transmits card data must meet the requirements that apply to its environment.
- Level set by brands: Ask your acquiring bank which level and validation method apply, because the brands, not the standard, decide.
- Validation route: Smaller merchants often validate with a self-assessment questionnaire, but the questionnaire type depends on how cardholder data is handled.
- Scope still matters: Terminals, office networks and staff devices that touch card data can all fall in scope regardless of business size.
- Enforcement: The Council does not penalize merchants directly, but individual payment brand programs can apply consequences to non-compliant businesses.
Confirm your level and reporting requirement in writing with your acquirer before you choose a questionnaire.
A service provider does not have to store, process or transmit account data to fall under PCI DSS. It is in scope when it can affect the security of payment account data, for example where it has access to a customer's cardholder data environment or meets a PCI DSS requirement on a customer's behalf. Hosting, managed security and IT support firms are common examples of providers in this position.
- Access to the CDE: Remote administration, support sessions or privileged accounts that reach a customer's cardholder data environment bring the provider into scope.
- Requirements on behalf of customers: If the provider performs a PCI DSS requirement for a customer, the provider's controls over that work are assessed.
- Scope boundaries: Define which of the provider's systems can affect the customer's environment and which cannot, since that boundary sets the scope of assessment.
- Brand rules: Ask the individual card brands which validation and reporting apply to your service, since their rules govern provider validation.
- Internal providers: Shared services teams inside a larger company may also need to be treated as service providers, so confirm how the rules apply to your organization.
Write down the access your staff and tools have into customer environments, then check that boundary against the brand rules before you agree what your customers should expect from you.
Who tells you how to validate, and why the PCI SSC will not
The PCI Security Standards Council maintains PCI DSS, but it does not enforce the standard, run compliance programs or penalize businesses that fall short. The individual payment brands decide which entities must validate, how they validate and what happens when they do not. Merchant levels and service provider levels come from those brands, not from the PCI SSC, so the first question to answer is who sets your validation rules, not which requirements you must meet.
If you are a merchant, ask your acquiring bank whether you must validate compliance and which reporting applies to you. If you provide services to payment processing, ask the individual card brands instead. Confirm the answer in writing, including the validation method (for example, whether a Report on Compliance or a Self-Assessment Questionnaire is expected) and the deadline. Parent and subsidiary companies may validate as one entity or separately, depending on each brand's rules, so ask your acquirer or the brands how your corporate structure is treated before you scope the work.
Consequences for non-compliance come from brand programs, which can carry monetary or operational impact after a breach or a failed validation. The PCI SSC does not set those amounts, and this page does not estimate them. Ask your acquirer what program applies, what notification duties follow a suspected card data compromise and whether your level could be raised. Record those answers now, because they shape the budget, the timeline and the decision to bring in an outside assessor.
Which validation path fits your situation?
This table compares five common situations, who usually tells you what applies, the validation path that often follows, and what to confirm. Read it as a starting point, not a final answer: the payment brands and your acquirer decide which entity validates and how.
| Your situation | Who usually tells you | Likely validation path | What to confirm |
|---|---|---|---|
| Fully outsourced e-commerce merchant (payment page hosted by a provider) | Your acquiring bank, and the card brands through your acquirer | Often a self-assessment questionnaire, with eligibility depending on the provider handling all payment pages and no card data touching your systems | That your payment page is fully outsourced, that you hold written agreements with the provider, that you have the provider's compliance status, and the reporting your acquirer requires |
| Small merchant | Your acquiring bank or payment processor | A self-assessment questionnaire is common, but the path depends on your payment channels and how card data flows | That PCI DSS still applies to you regardless of size, your merchant level as set by the brands, and whether any scans or other activities are required for your path |
| Merchant with in-house card data handling | Your acquiring bank and the card brands | Usually a more extensive validation than a fully outsourced merchant, which may require a Report on Compliance completed by a Qualified Security Assessor, depending on level and brand rules | Your merchant level and reporting requirements, whether you store, process or transmit card data, and whether your scope includes connected or security-impacting systems |
| Service provider with access to a customer CDE | The individual card brands, and your customers may also ask for evidence | Service provider requirements apply even without storing card data, and validation may be a Report on Compliance or a questionnaire depending on the service and brand rules | Whether your access to a customer's cardholder data environment or your fulfilment of a requirement on a customer's behalf brings you into scope, and which brands and levels apply |
| Parent company with subsidiaries | Your acquirer and each payment brand's compliance rules | Could be validated as one entity or separately, depending on each brand's rules | Whether the parent and each subsidiary validate together or apart, and which entities' systems connect to cardholder data |
How to confirm applicability before you commit budget
This sequence establishes whether PCI DSS applies to your business, which validation path and reporting your acquirer or card brands expect, and who will confirm scope, so budget goes to the right work from the start.
Map where cardholder data flows
Trace every path that account data takes, from the point of capture through authorization, storage, transmission and any backups or logs. Involve the people who run payment pages, point-of-sale devices, call handling and finance reconciliation, not only IT. The output is a dated data-flow diagram with each store, system and third party that touches account data labeled. You know the step is done when the compliance lead can point to every entry in the diagram and name the person who maintains it.
Identify who can affect the cardholder data environment
List every system and organization that could affect the security of the cardholder data environment, even if it never sees account data. This includes network administrators with access to payment segments, identity providers, hosting platforms, managed service providers and internal teams that support payment systems. Check each entry against PCI DSS service provider guidance, since a party with access to a customer's environment can bring its own obligations. The output is a written inventory of connected and security-impacting parties with the reason each is included or excluded.
Ask the acquirer or card brand which validation applies
Send a written question to your acquiring bank asking whether your organization must validate compliance, which validation method and reporting it expects, and which deadlines it sets. Service providers should put the same question to the individual card brands, and parent and subsidiary entities should ask whether they validate together or separately. Do not rely on general web guidance for this answer, because the brands set the rules. The output is a reply from the acquirer or brand, filed with its date and the name of the person who answered.
Record the applicability decision in writing
Write a single applicability memo that states whether PCI DSS applies, the entities covered, the validation path confirmed by the acquirer or brand, the reporting required and the open questions. Attach the data-flow diagram, the party inventory and the acquirer or brand response. Have an accountable executive sign or approve the memo so it becomes the reference for budget requests. The output is a signed memo the compliance lead can file and update when payment systems change.
Decide who will confirm scope
Choose whether an independent Qualified Security Assessor will confirm scope and validation, or whether an internal assessor will do so, based on the validation path the acquirer or brand confirmed. Ask any firm you consider to explain its independence from the work it would later assess, and confirm that the acquirer accepts the chosen assessor. Keep this decision separate from any consulting that prepares your systems. The output is a written decision record naming the assessor type, the reason for the choice and the acquirer's acceptance.
Confirm the budget request matches the record
Compare the signed applicability memo with the budget request before funds are committed. Check that the validation path, reporting and scope in the request match what the acquirer or brand confirmed, and that the request lists which costs are one-time and which recur. Ask any vendor or consultant for a quote built on the written scope so the figures can be traced back to the memo. The output is a budget request that cites the memo by date and version.
Common questions about whether PCI DSS applies
Does PCI DSS apply to a small merchant?
Yes. PCI DSS applies to all merchants regardless of size or transaction volume. What changes with size is how you validate compliance, not which requirements apply. The payment brands set merchant levels and decide which validation path and reporting a given merchant must use, so the first step is to ask your acquiring bank what it requires from you. Small merchants often validate with a Self-Assessment Questionnaire, and the eligible questionnaire depends on how your payment channel is built. Your effort depends on how much cardholder data your systems touch, so confirm the validation path before you plan any work.
If we outsource all payment processing, do we still need to validate?
Possibly. Outsourcing all payment processing to a provider that never lets your systems store, process or transmit cardholder data can reduce the number of requirements that apply to you directly. It does not remove the obligation to confirm compliance. You must confirm that the provider is compliant for the services it provides, keep written agreements that acknowledge its responsibility for cardholder data, check its compliance status at least once a year, and define which party handles each requirement. Your acquirer or the card brands determine whether you still submit a validation document and which one.
Do we need a QSA to be compliant with PCI DSS?
It depends on the validation path your acquirer or the card brands assign. A Qualified Security Assessor completes a Report on Compliance, which is the path larger or higher-risk organizations usually follow. Many smaller merchants and some service providers complete a Self-Assessment Questionnaire with an Attestation of Compliance instead, and that work does not require a QSA. Some cases may require an independent assessment rather than a self-assessment, so confirm this with your acquirer before you engage anyone. An implementation partner can prepare your systems and evidence, but only the assessor you are required to use issues the validation documents.
Does a vendor certificate or compliance logo count as PCI DSS validation?
No. The PCI SSC recognizes only the official validation documents: a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates and compliance logos do not count as validation, including a vendor's statement that its product is PCI compliant. A product from a compliant vendor can help you meet specific requirements, but it does not make your environment compliant. Ask each vendor for its own Attestation of Compliance where it applies, and ask your acquirer which of those documents it accepts from you.
If our parent company already validates PCI DSS, are we covered?
Not automatically. Whether parent and subsidiary companies validate as one entity or separately depends on each payment brand's compliance rules. A parent's validation may cover a subsidiary only where the scope and the card flows genuinely match, so do not assume coverage from the corporate structure. Ask your acquirer or the payment brands in writing how they treat your entity, which systems and card flows count toward the parent's scope, and what each entity must submit. Keep that answer with your scope documentation.
How much effort does confirming whether PCI DSS applies take, and what must our team provide?
The effort is driven by how many systems, people and connections touch cardholder data, and no official figure exists for it. Expect to provide a list of payment channels, a description of how card data enters, is stored and leaves your environment, the names of any outsourced payment providers and their contracts, and a view of the systems connected to payment flows. Your team should also gather the answers your acquirer gives in writing. Outside help can assist with mapping the flows and documenting the results, but the organization owns the decision and must sign the validation document. Ask any provider to put the scope of this work in writing before it starts.
Who decides whether we must comply with PCI DSS?
The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or impose penalties. Your acquiring bank is usually the first contact for merchants, and service providers to payment processing should ask the card brands directly. Get the decision in writing, including the validation method, the due date and the reporting you must submit, because that is the document you will rely on when a question about your status comes up later.
How an implementation partner helps once applicability is clear
Once you know PCI DSS applies, the practical work is documenting what sits in scope, preparing systems and evidence, closing gaps and keeping the paperwork current. The four areas below are what DeployOpen can take on under a fixed-scope written agreement. Your organization keeps ownership of every control, and only an independent QSA or assessor can issue the ROC, SAQ validation or Attestation of Compliance.
Document data flows and inventories
Before anyone can decide which validation path applies, the organization needs a current picture of where account data enters, moves, is stored and leaves. DeployOpen can map data flows and build system and component inventories for the scope you agree in writing, including connected and security-impacting systems. Check that the agreed scope names the card brands' relevant validation level and the systems that are excluded, and that you own the final sign-off on both.
Prepare systems and evidence
An assessor tests what your systems do and what records prove it. DeployOpen can configure in-scope systems, collect logs, configuration exports and access records, and arrange them so an assessor can trace each requirement to its evidence. Ask the partner to show which artifacts it produces and which ones only your staff can generate, such as signed policies and management approvals. Evidence prepared by a partner remains your evidence.
Support remediation of gaps
Gaps found during readiness work need engineering time, not just a list. DeployOpen can help fix open items in self-hosted platforms, such as hardening, access control changes, logging gaps and segmentation fixes, within the agreed scope. The organization decides which risks to accept and which compensating controls or customized approach to use, and the assessor must agree that the chosen approach meets the requirement. Ask for a remediation log that shows who changed what and when.
Hand over documentation
Documentation that only the implementation team understands fails at the next annual cycle. At the end of the engagement, DeployOpen can deliver written runbooks, configuration records, network and data-flow diagrams and a recurring task calendar that your own staff can operate and update. Confirm the format, ownership and version control of each deliverable in the written scope, and confirm that your QSA or SAQ reviewer has access to them before the assessment starts.
How DeployOpen scopes and prepares PCI DSS evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Where PCI DSS applies, we help prepare the systems and evidence that an assessor will examine, starting with the scope decision. Before any technical work, the question is which systems store, process or transmit account data, which systems could affect their security, and which validation path your acquirer or payment brands require. Those answers determine how much of the environment we touch. We do not decide your validation level or your scope on your behalf.
Engagements are fixed-scope. The systems in scope, the deliverables, the evidence to be produced and the timeline are agreed in writing before work starts, so you can see what is included and what remains with your team. Pricing is not published. A quote follows from that written scope, and it should separate one-time build and documentation work from recurring items such as quarterly scanning, periodic testing and retainer support. Ask for those line items explicitly. If your scope changes during the work, the change should be recorded in writing as well.
DeployOpen does not issue Reports on Compliance, Self-Assessment Questionnaires, Attestations of Compliance or certificates. Only an independent Qualified Security Assessor or the appropriate validation body can do that, and your acquirer or the payment brands decide what they accept. Where you need independent checks before the assessor arrives, DeployOpen can run security testing and, if you want ongoing coverage, provide retainers for upgrades, testing and support. Confirm with your assessor which evidence they will accept from a third party, and keep the assessor and any consulting work separate so that the independence rules are respected.
