Who Needs to Be PCI DSS Compliant? Scope Rules, Examples, and Next Steps

Who needs to be PCI compliant is one of the most common questions payment teams ask when launching or scaling payment operations. The simple answer is this: if your business stores, processes, or transmits cardholder data, or if your systems can affect the security of the cardholder data environment, you are in the scope for PCI DSS. That applies not only to businesses that handle card data directly, but also to environments, tools, and integrations that can influence payment security.

Many businesses reduce PCI burden by changing the architecture, not just the paperwork. For companies looking to simplify payment operations, Akurateco’s PCI DSS-compliant payment orchestration platform can support cleaner scope management, tokenization, and more controlled payment flows across providers.

In this article, we break the topic down into a practical decision framework. You will see common payment scenarios, clear examples of what is usually in scope, and straightforward guidance on how hosted payment pages, tokenization, and segmentation can help reduce PCI burden. We will also cover common questions, including UK applicability, ACH clarification, and the next steps to take if you are still unsure.

Save the PCI scope checklist to review it with your product, security, and payments teams later.

What It Means to Be PCI Compliant

PCI compliance is not just about passing an annual review. In practice, it is an ongoing process of applying security controls, fixing gaps, and documenting your status over time.

Quick compliance term explanations:

• Self-Assessment Questionnaire (SAQ) — a self-assessment questionnaire used by eligible businesses to validate PCI DSS compliance.
• Report on Compliance (ROC) — a detailed formal PCI DSS assessment report, typically for larger or more complex environments.
• Attestation of Compliance (AOC) — the document that confirms the business’s compliance status after assessment.

PCI SSC describes PCI DSS compliance as a continuous cycle of assessment, remediation, and reporting. In simple terms, that means you review your environment, address any issues, and validate your status through the reporting path your payment program requires.

That validation path is not the same for every business. Some organizations complete a Self-Assessment Questionnaire (SAQ). Others require a Report on Compliance (ROC).

It also helps to separate compliance from validation. Compliance is your actual security posture in day-to-day operations. Validation is the formal process of showing that status to the organizations that oversee PCI requirements.

Those organizations may include a payment brand, such as Visa or Mastercard, or an acquirer, meaning the acquiring bank or financial institution that processes card payments for your business. These parties usually determine what type of PCI validation you need and what documents you must submit.

You may also come across an Attestation of Compliance (AOC). This is the formal document that confirms the result of your PCI DSS validation. In simple terms, it is the declaration of your compliance status and is typically submitted together with an SAQ or ROC.

The Simple Rule: Who Needs to Be PCI DSS Compliant?

The simplest answer is this: if your business stores, processes, or transmits Cardholder Data (CHD) or Sensitive Authentication Data (SAD), you are in scope. And even if you do not handle that data directly, you may still be in scope if your systems can connect to the CDE or impact its security.

PCI SSC says PCI DSS requirements apply to all system components included in or connected to the CDE, and its FAQ makes clear that service providers that can impact the security of payment account data may still have a PCI DSS assessment scope even if they do not directly store, process, or transmit the data themselves.

At a high level, CHD is the payment card data that identifies an account, while SAD refers to especially sensitive elements used for authentication. You do not need to memorize every field to make the first scoping decision. You need to know where payment card data enters your environment, where it flows, who can touch it, what connects to it, and what could weaken its security. That is the real start of PCI DSS scope work.

PCI DSS Scope Explained

The easiest way to understand PCI DSS scope is to think of it in layers, not just in one isolated payment system:

1. The CDE. At the center is the Cardholder Data Environment (CDE). This includes the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.
2. Connected-to systems. The next layer is systems that can communicate with the CDE, even if they do not handle payment data themselves.
3. Security-impacting systems. The third layer is security-impacting systems. These are systems, services, or providers that may never touch payment data themselves but can still affect the security of the CDE or the payment environment around it.

This is where many teams underestimate PCI scope. It is not limited to the server or application that handles payments. Scope can also expand to the surrounding systems that connect to that environment or influence its security.

That is also why flat networks create so much risk from a scoping perspective. Network segmentation is not mandatory, but PCI SSC strongly recommends it because it can reduce assessment scope, cost, and operational complexity.

Without proper segmentation, a flat network can pull much more of your infrastructure into scope than expected. In practice, one poorly isolated payment-related system can make a much larger part of the business environment relevant to PCI DSS.

How PCI Scope Changes Across Payment Scenarios

Use these mini-cases as a directional guide, not legal advice. The exact SAQ or ROC path still depends on your environment and what your acquirer or payment brand requires. PCI SSC’s own materials note that SAQs are for eligible entities, while some businesses, especially larger-volume or more complex ones, may need annual on-site assessments and broader reporting.

1. E-commerce using a hosted payment page

If the checkout redirects to a provider-controlled payment page or uses a tightly outsourced model, your environment may handle far less card data directly. That can support scope reduction, but it does not mean “no PCI.”

You still need to assess the parts of your site, scripts, redirects, integrations, and admin access that remain in your environment. Directionally, this is where SAQ eligibility is often narrower than fully integrated card capture.

2. E-commerce directly capturing card data on your server

If your web server receives card details, you are squarely in scope. Your application stack, supporting systems, logs, administrative access paths, and any connected components become much more important in the assessment. This is the kind of architecture that often drives broader PCI scope and a heavier validation burden.

3. Mobile app with card entry

A mobile flow can still be in scope if card details are entered into your app and your backend, SDK usage, or supporting systems participate in processing or transmitting that data.

Teams often underestimate mobile because the screen feels separate from the server side, but the real question is still where the data goes and what systems can affect its security.

4. Call center or MOTO flow

If agents take card details by phone and enter them into a system, people, endpoints, procedures, and supporting technology are part of the scoping discussion. This is not just a “payments page” issue. It is also a people-and-processes issue because PCI DSS scope includes people and processes, not only servers.

5. Subscription billing with tokenization

Tokenization can meaningfully reduce exposure if your systems stop handling raw card data and use tokens instead. But tokens do not magically erase scope.

You still need to understand where initial card capture happens, what systems participate, who has admin access, and whether logs, support tools, or integrations could reintroduce risk. PCI SSC’s scoping approach remains architecture-first, not buzzword-first.

6. Marketplace or platform with sub-merchants

A platform that routes, manages, or facilitates card payments for sub-merchants should assume a serious scoping exercise. Even where a third party processes the payments, the platform’s role, integrations, access rights, payment orchestration layer, and operational support may still matter. This becomes even more important if the platform acts like a technical payment layer for many merchants.

7. SaaS product embedding a payment form script

A script-based checkout can still leave important responsibilities in your environment. If your site loads, controls, modifies, or depends on scripts around the payment experience, those surrounding components may still matter for PCI DSS scoping and security reviews. This is one reason checkout ownership should be mapped carefully, not assumed away.

8. Company with one in-scope payment server on a flat corporate LAN

This is the classic scope explosion. PCI SSC states that without adequate network segmentation, the entire network is in scope. So if your payment server sits on the same flat network as broader corporate assets, your assessment boundary may become far larger than expected.

9. Business outsourcing all card handling but keeping payment admin tools internally

Even if a third party processes the cards, internal admin workstations, support tools, or remote access systems can still matter if they connect to the payment environment or can affect its security. Outsourcing the transaction flow reduces some burden. It does not erase all of it.

Using a PSP: What PCI Responsibility Still Stays with You

Working with a service provider or PSP can reduce your PCI DSS scope, but it does not automatically make your business out of scope. This is one of the most common misunderstandings in payments. Outsourcing part of the payment flow can shift some security and compliance work to the provider, but your team still needs to understand what stays inside your own environment.

That remaining scope often includes your checkout pages, embedded scripts, integrations, admin access, internal logs, support tools, and the way your network is segmented. If any of those elements can store, process, transmit, connect to, or affect the security of payment data, they still matter for PCI DSS.

This is where shared responsibility becomes important. Your PSP may secure its own platform and infrastructure, but you are still responsible for the parts you control around the payment flow. That includes how payment forms are presented, who has access, what systems connect to the environment, and how third-party tools are governed.

The practical takeaway is simple: using a PSP can help reduce PCI burden, but it does not make you “PCI-free.” You still need to map what remains in your environment and confirm how responsibilities are split between your business and your provider.

How Akurateco Helps Reduce PCI Burden

For many payment businesses, the goal is not to make PCI DSS disappear. It is to reduce unnecessary scope, simplify operations, and build on a more structured payment architecture from day one. That is where the right platform makes a real difference.

Akurateco helps businesses centralize payment operations, avoid scattered integrations, and move toward cleaner deployment models that can support a lower PCI burden depending on the payment flow and environment.

Why PCI DSS Level 1 matters for payment businesses

Akurateco offers a PCI DSS Level 1 certified platform, which gives payment businesses a stronger starting point when security, procurement, and compliance reviews begin. That matters in practice because buyers and internal stakeholders want confidence that the core payment infrastructure already operates within a mature security framework.

For companies launching a PSP, gateway, or orchestration product, this can also shorten the path to market. Instead of building and certifying a full payment stack from scratch, teams can start with a platform that already supports a stronger compliance posture and enterprise-level payment operations.

SaaS vs on-premise: what Akurateco covers and what you still own

Akurateco offers both SaaS and on-premise deployment models, but the PCI responsibility split is not the same in each case.

• For SaaS clients, Akurateco’s certified environment covers the platform side of the solution.
• For on-premise deployments, where the system runs on the client’s own infrastructure, the client is responsible for obtaining and maintaining its own PCI DSS certification. Akurateco can support that process with the documents and guidance needed for QSA-led preparation.

This gives businesses flexibility. Teams that want faster deployment and less infrastructure overhead can use SaaS, while businesses that need local hosting, infrastructure ownership, or country-specific control can choose on-premise or cloud-based deployment on their own terms.

Akurateco does not remove PCI DSS responsibilities, but it can make them easier to manage. By centralizing payment operations and supporting a cleaner architecture, it helps reduce PCI burden, while the final scope still depends on your payment flow, deployment model, and surrounding environment.

How Akurateco Supports Scope Reduction

Akurateco helps reduce PCI burden by giving payment businesses a cleaner and more controlled architecture to build on. While the exact scope still depends on your payment flow and environment, the platform can support scope reduction in several practical ways:

• Centralized payment layer helps replace scattered direct integrations with a more structured payment architecture.
• Standardized provider integrations reduce the need for multiple internal systems to interact with payment data and payment logic.
• Cleaner payment flow design supports architecture patterns built around hosted payment pages, tokenization, and more controlled access paths.
• Consolidated reporting and monitoring help reduce fragmented operational data, shadow logs, and reconciliation confusion across providers.
• More consistent operational controls make it easier to manage payment processes across multiple PSPs without spreading payment-related handling across disconnected tools.
• Flexible deployment options allow businesses to choose a setup that better fits their regulatory, operational, and infrastructure needs.

These advantages do not eliminate PCI DSS obligations, but they can help businesses move toward a more manageable scope and a more efficient payment operation.

How to Reduce PCI Scope: Effective Strategies

When teams ask how to reduce PCI burden, the answer is usually not one tool or one checkbox. Scope reduction comes from making deliberate architecture choices that limit where card data appears, how far it travels, and how many systems and people can influence the payment environment.

A few measures consistently make the biggest difference.

Hosted payment page

A hosted payment page can help reduce scope by moving card entry away from your own application environment and into a provider-controlled payment flow. That can shrink the number of internal systems involved in handling payment data and make the assessment boundary easier to manage. It does not automatically make you out of scope, but it can significantly reduce how much of your environment needs to be reviewed.

Tokenization

Tokenization helps replace raw card data with tokens, which reduces the chance of sensitive payment data spreading across internal systems, logs, and operational workflows. This is especially useful for recurring billing, stored payment credentials, and multi-provider payment setups where teams want to avoid unnecessary exposure to card data while keeping payment operations flexible.

Network segmentation

Network segmentation helps isolate the cardholder data environment from the rest of your infrastructure. This matters because without proper separation, a flat network can pull much more of your environment into PCI scope than expected. Strong segmentation can make the scope smaller, clearer, and easier to control.

Other practical ways to reduce scope

Beyond those three core levers, businesses can often reduce PCI burden by following a few simple rules:

• Reduce or avoid storage of payment data wherever possible
• Minimize access paths into payment-related systems
• Tighten admin access and permissions
• Review logs, support tools, and integrations for unnecessary exposure
• Remove old or uncontrolled connections that can expand scope

The key point is that technologies such as a hosted payment page, tokenization, and network segmentation can support scope reduction, but they do not define scope on their own. PCI DSS scope still needs to be evaluated against your full environment, architecture, and system connectivity.

PCI DSS Scope Questions by Region and Payment Type

Once the general scoping rules are clear, teams usually ask two practical follow-up questions: Does PCI DSS work differently in the UK, and does it apply to ACH payments? These are useful questions because they help separate what is truly specific to PCI DSS from what belongs to local banking, partner, or operational requirements.

Who needs to be PCI compliant in the UK?

PCI DSS is a global payment card security standard, not a UK-only framework. That means the same core scoping logic applies in the UK as it does elsewhere. If your business stores, processes, or transmits cardholder data, or if your systems can affect the security of the cardholder data environment, you still need to assess PCI DSS scope.

What may differ is the validation path. Whether your business needs an SAQ, a ROC, vulnerability scans, or other reporting is usually determined by your acquirer, payment brand, or another compliance program owner. For UK businesses, the most practical next step is to confirm those validation requirements directly with your acquiring bank rather than relying on assumptions.

Who needs to be PCI compliant for ACH?

PCI DSS is focused on payment card account data. Its scope is built around cardholder data and sensitive authentication data, not around bank transfer data in general.

So if a business handles only ACH or other bank transfer payments and never stores, processes, transmits, or can affect payment card data, PCI DSS generally would not apply. However, that does not mean there are no security or compliance responsibilities. ACH-only businesses may still need to meet other banking, partner, contractual, or regulatory requirements depending on how their payment operations are set up.

The key distinction is simple: PCI DSS applies to card-data environments. If card data is not part of your flow at all, PCI DSS is usually not the framework that governs it.

What to Do Next: A 30-Minute PCI Scope Checklist

If you are still unsure where your business stands, do not start with paperwork. Start with a quick scope review. In just 30 minutes, you can usually identify the biggest PCI DSS risk areas, spot obvious scope-expansion issues, and decide what needs deeper review next.

Use this checklist as a practical first pass with your product, security, and payments teams:

1. Map all CHD and SAD touchpoints. List every place where cardholder data or sensitive authentication data could appear, including checkout pages, APIs, logs, support tools, dashboards, and internal workflows.
2. Identify connected-to and security-impacting systems. Look beyond the obvious payment application. Include systems that connect to the CDE or could affect its security, such as admin tools, remote access paths, monitoring tools, and shared infrastructure.
3. Decide on your target architecture. Review whether your current setup should move toward a hosted payment page, broader tokenization, or stronger network segmentation to help reduce PCI burden.
4. Confirm your validation requirement. Ask your acquirer or payment brand what they expect from your business, whether that is an SAQ, a ROC, an AOC, scans, or another validation path.
5. Plan the annual compliance work. PCI DSS is an ongoing process, not a one-time project. Build in time for scans, testing, evidence collection, access reviews, and regular control checks throughout the year.

The goal of this exercise is not to finish PCI in one sitting. It is to get clear on where the scope starts, where it may be wider than expected, and what architecture decisions can help reduce complexity before compliance work becomes more expensive.

Conclusion

So, who needs to be PCI compliant? The core rule is simple: if your business stores, processes, or transmits cardholder data, or if your systems can affect the security of the cardholder data environment, the PCI DSS scope needs to be assessed. That is why PCI compliance is not only about where card data is stored. It is also about connectivity, access, supporting systems, and the way your payment environment is designed.

The good news is that the scope can often be reduced with the right architectural choices. Hosted payment pages, tokenization, segmentation, and a more centralized payment setup can all help make PCI DSS more manageable. Before you move forward, go back to the 30-minute PCI scope checklist and use it to review your current setup with your product, security, and payments teams.

For businesses that want to simplify this process, Akurateco offers a stronger starting point. With a PCI DSS Level 1 certified SaaS platform, flexible deployment options, and an architecture that supports cleaner multi-PSP operations, Akurateco helps reduce PCI complexity without overpromising what remains your responsibility.

FAQ

Who needs to be PCI compliant?

Any entity that stores, processes, or transmits Cardholder Data (CHD) or Sensitive Authentication Data (SAD) is in scope for PCI DSS. Also, PCI DSS applies to entities that could impact the security of CHD or SAD, which is why the scope can extend beyond the obvious payment application.

Who needs to be PCI DSS compliant?

In practice, that includes merchants, service providers, and other businesses involved in payment account processing if they handle card data directly or can affect the security of the payment environment. Whether they must formally validate compliance is usually determined by the organization managing the compliance program, such as a payment brand, acquirer, or another relevant party.

If I don’t store card data, do I still need PCI?

Yes. PCI DSS scope is not limited to storage. If your systems process or transmit card data, connect to the Cardholder Data Environment (CDE), or can impact its security, you may still be in scope. That is why checkout pages, scripts, admin access, shared infrastructure, and connected systems should all be reviewed.

Does using a PSP make me out of scope?

No. Using a PSP or other third-party provider can reduce your PCI burden, but it does not automatically make you “PCI-free.” You still need to understand what remains in your own environment and how responsibility is split between your business and the provider. PCI SSC expects third-party service providers to demonstrate PCI DSS compliance for services that meet customer requirements or may impact customer cardholder data or sensitive authentication data.

Who needs to be PCI compliant UK?

PCI DSS is a global payment card security standard, so the same core scoping logic applies in the UK. If you handle card data or can affect the security of the CDE, you need to assess the scope. The exact validation path, such as SAQ, ROC, scans, or other reporting, is usually set by your acquiring bank, payment brand, or another compliance program owner.

Who needs to be PCI compliant ACH?

PCI DSS is designed to protect payment card account data. If a business handles only ACH or bank transfers and never stores, processes, transmits, or can affect payment card data, PCI DSS generally would not apply. Even so, ACH-only businesses may still have other security, banking, contractual, or regulatory requirements to follow.

What are SAQ, ROC, and AOC, and who asks for them?

SAQ is a self-assessment validation tool for eligible entities. ROC is the fuller assessment report typically associated with larger or more complex environments. AOC is the formal declaration of compliance status. These are usually requested through acquirers, payment brands, or related compliance programs.

How does Akurateco’s PCI DSS Level 1 certification affect my responsibilities?

Akurateco’s PCI DSS Level 1-certified white-label and payment orchestration platform can significantly reduce PCI burden, but the exact benefit depends on how you deploy it. In the SaaS model, Akurateco covers the certified platform environment, which helps reduce the PCI work on your side. In the on-premise model, your business is still responsible for certifying its own infrastructure, while Akurateco provides the payment technology, deployment flexibility, and support for your certification process. In both cases, your remaining PCI responsibilities depend on your integrations, access, and overall environment.