What is PCI Compliance?

PCI compliance is one of the core security requirements for companies that accept, process, store or otherwise handle payment card data. For merchants, FinTech companies, payment providers, SaaS platforms and marketplaces, it affects much more than the payment form itself.

It can influence payment architecture, infrastructure, vendor selection, software development, access controls, monitoring and incident response. It also affects how easily a company can launch new payment products or expand into additional markets.

When people ask what is PCI compliance, they usually mean compliance with the Payment Card Industry Data Security Standard, or PCI DSS. PCI DSS is a global security standard designed to protect payment account data throughout the payment ecosystem.

As of 2026, the current active version is PCI DSS v4.0.1. PCI DSS v4.0 was retired at the end of 2024, and requirements that were initially introduced as future-dated requirements became effective on 31 March 2025.

Table of contents

1. What is PCI compliance?
2. What does PCI stand for?
3. What is PCI DSS?
4. Who needs to be PCI compliant?
5. What data does PCI DSS protect?
6. Understanding PCI scope and the Cardholder Data Environment
7. What are the 12 PCI DSS requirements?
8. PCI compliance in e-commerce
9. Does outsourcing payments remove PCI responsibility?
10. SAQ, ROC, AOC and QSA explained
11. Tokenization, encryption and scope reduction
12. PCI compliance as a product and architecture decision
13. PCI compliance in the EU and UK
14. Common PCI compliance mistakes
15. FAQ
16. Conclusion

1. What is PCI compliance?

PCI compliance means meeting the security requirements that apply to an organisation under the PCI Data Security Standard.

PCI DSS is intended for organisations that store, process or transmit cardholder data. It also applies to certain service providers that can affect the security of payment account data or the Cardholder Data Environment, even if they do not directly handle card data themselves.

For a merchant, this can include the systems used to accept card payments, infrastructure supporting checkout, internal networks, user access and third-party providers. For payment companies and other service providers, the scope can be significantly broader.

PCI compliance is therefore not simply about completing a questionnaire once a year. It requires organisations to understand where payment data flows, which systems can affect its security and whether the relevant controls actually operate as intended.

This distinction is important. A business can have a technically secure checkout page and still have a weak PCI environment if access controls, vulnerability management, logging or third-party governance are poorly designed.

2. What does PCI stand for?

PCI stands for Payment Card Industry.

When people talk about "PCI compliance", they normally mean compliance with PCI DSS, which stands for Payment Card Industry Data Security Standard.

The standard is maintained by the PCI Security Standards Council, or PCI SSC. The Council develops the security standards, supporting documentation and assessment frameworks used across the payment card industry.

However, PCI SSC does not operate one global compliance programme for every merchant. Payment brands and acquirers determine how merchants and service providers are required to validate and report their compliance.

This is why two companies with similar payment environments may have different reporting requirements depending on their acquirer, payment brand relationships and role in the payment ecosystem.

3. What is PCI DSS?

PCI DSS is a security standard covering technical and operational controls used to protect payment account data.

Its purpose is to reduce the risk of cardholder data being exposed, stolen or misused. The standard addresses areas such as network security, access management, cryptography, secure software development, logging, vulnerability management and information security governance.

PCI DSS is not a payment product specification. It does not tell a merchant which payment provider to use or which checkout design will convert best.

Instead, it defines security outcomes and controls that need to be achieved when payment account data is within scope.

The current PCI DSS framework contains 12 main requirements grouped into six broader security goals.

4. Who needs to be PCI compliant?

PCI DSS is intended for entities involved in payment card processing that store, process or transmit cardholder data.

This includes merchants of all sizes, payment processors, acquirers, issuers and many service providers. The standard is intended to apply regardless of merchant size or transaction volume, although the method used to validate compliance can differ.

A small e-commerce merchant using a hosted payment page may have a relatively limited PCI scope. A payment gateway or processor can have a far more complex environment and broader assessment.

Service providers deserve particular attention. PCI DSS can apply to a provider that does not directly store or process payment data if its services can affect the security of another organisation's Cardholder Data Environment.

This can include certain hosting, managed security or infrastructure providers.

For SaaS and FinTech companies, the first question should therefore not be only "Do we store card numbers?". It should be "Can our systems, people or services affect the security of payment account data?"

5. What data does PCI DSS protect?

PCI DSS distinguishes between cardholder data and sensitive authentication data.

Cardholder data includes the Primary Account Number, or PAN, and can also include elements such as the cardholder name, expiration date and service code when they are stored, processed or transmitted together with the PAN.

Sensitive authentication data includes information used to authenticate card transactions, such as certain card verification values, full track data and PIN-related data.

The distinction matters because some sensitive authentication data cannot be stored after authorisation, even if the customer agrees to it. PCI SSC explicitly states that customer approval does not create an exception allowing a merchant or service provider to retain prohibited card verification data.

From an architecture perspective, companies should minimise how much payment account data they collect and retain. The less sensitive data that enters the environment, the easier it becomes to reduce both security risk and PCI scope.

6. Understanding PCI scope and the Cardholder Data Environment

One of the most important concepts in PCI DSS compliance is scope.

The Cardholder Data Environment, commonly called the CDE, consists of the people, processes and technologies that store, process or transmit cardholder data, together with systems that can affect its security.

Scope is not always obvious.

A database containing card data is clearly relevant. But systems that administer that database, provide network access, manage security controls or enable privileged access can also become part of the assessment.

This is why PCI projects often begin with data-flow mapping.

A company needs to understand where card data enters the organisation, how it moves, where it is stored, which systems can access it and which third parties participate in the process.

Poor scoping creates two opposite problems. A company can underestimate scope and leave relevant systems outside security controls, or it can overestimate scope and create unnecessary compliance cost and complexity.

7. What are the 12 PCI DSS requirements?

PCI DSS organises its main requirements around six security goals.

Build and maintain secure networks and systems

Requirement 1: Install and maintain network security controls.

Requirement 2: Apply secure configurations to all system components.

The objective is to reduce unnecessary exposure and ensure infrastructure is configured securely rather than relying on insecure default settings.

Protect account data

Requirement 3: Protect stored account data.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks.

These requirements focus on how payment account data is stored and transmitted.

Maintain a vulnerability management programme

Requirement 5: Protect all systems and networks from malicious software.

Requirement 6: Develop and maintain secure systems and software.

For technology companies, Requirement 6 is particularly relevant because PCI compliance is closely connected with software development, vulnerability management and change control.

Implement strong access control measures

Requirement 7: Restrict access to system components and cardholder data by business need to know.

Requirement 8: Identify users and authenticate access to system components.

Requirement 9: Restrict physical access to cardholder data.

These controls are based on a simple principle: access to sensitive systems and data should be limited to people who genuinely need it.

Regularly monitor and test networks

Requirement 10: Log and monitor all access to system components and cardholder data.

Requirement 11: Test the security of systems and networks regularly.

The objective is not only to prevent incidents, but also to detect abnormal activity and identify weaknesses before they are exploited.

Maintain an information security policy

Requirement 12: Support information security with organisational policies and programmes.

This includes responsibilities, governance, third-party management and broader security processes.

The official PCI SSC framework lists these 12 requirements as the core structure of PCI DSS.

8. PCI compliance in e-commerce

PCI compliance is especially important in e-commerce because the payment journey can involve several systems before the payment reaches the processor.

A merchant may use a payment gateway, hosted checkout, JavaScript payment components, an e-commerce platform, fraud tools and several infrastructure providers.

The PCI implications depend heavily on the integration model.

If card data is entered directly into a merchant-controlled environment, PCI scope can become significantly larger. If the payment page or card fields are hosted by a compliant third-party provider, the merchant may be able to reduce the number of systems directly exposed to card data.

But scope reduction does not mean that website security stops mattering.

PCI SSC changed SAQ A requirements in 2025 to clarify how e-commerce merchants should address payment-page script risk. Certain requirements were removed from the SAQ A reporting form, but merchants must meet an eligibility criterion confirming that their site is not susceptible to attacks from scripts that could affect the e-commerce payment environment.

This is important because modern e-commerce attacks often target the website around the payment page rather than the payment processor itself.

For product teams, PCI should therefore be considered when choosing between redirects, hosted payment pages, embedded payment fields and more deeply integrated checkout architectures.

---

Ensure your payment infrastructure is secure, reliable, and PCI DSS compliant.
z3x can guide you through the entire compliance journey - from gap analysis to audit preparation.

---

9. Does outsourcing payments remove PCI responsibility?

No.

This is one of the most common misunderstandings around PCI compliance.

A merchant that outsources all card payment processing may significantly reduce its technical PCI scope, but outsourcing does not automatically remove PCI DSS responsibilities.

PCI SSC explicitly states that merchants that outsource payment processing remain responsible for ensuring relevant third-party providers protect account data appropriately. They also need to manage third-party relationships, understand shared responsibilities and monitor provider compliance status.

For many fully outsourced e-commerce environments, the validation process may be significantly simpler, often through an applicable Self-Assessment Questionnaire.

But the merchant still needs to know which provider performs which part of the control environment.

This is why vendor management is a real PCI requirement rather than a procurement formality.

10. SAQ, ROC, AOC and QSA explained

PCI terminology can make compliance look more complicated than it needs to be.

SAQ

SAQ stands for Self-Assessment Questionnaire.

SAQs are validation tools used by eligible merchants and service providers to assess and report their PCI DSS compliance. Different SAQs exist for different merchant environments, while SAQ D is the only SAQ available for eligible service providers.

The correct SAQ depends on how payments are accepted and how the technical environment is designed.

A company should not simply select the shortest questionnaire.

It must meet all eligibility criteria for the specific SAQ.

ROC

ROC stands for Report on Compliance.

It is a detailed assessment report used when a formal PCI DSS assessment is required.

Depending on the organisation and compliance programme, the assessment may need to be conducted by a Qualified Security Assessor.

QSA

QSA means Qualified Security Assessor.

A QSA is a professional qualified through the PCI SSC programme to perform PCI DSS assessments.

AOC

AOC stands for Attestation of Compliance.

It is the formal attestation associated with a PCI DSS assessment or self-assessment.

Which validation method is required is determined by the relevant compliance-accepting entity, typically an acquirer or payment brand.

11. Tokenization, encryption and scope reduction

One of the best PCI strategies is to avoid handling cardholder data wherever possible.

Tokenization can replace a sensitive card number with a non-sensitive token that can be used by the merchant's systems without repeatedly exposing the underlying PAN.

This is especially useful for recurring payments, card-on-file products, marketplaces and subscription businesses.

Encryption is also important, but encryption alone does not automatically remove systems from PCI scope. If the organisation controls the cryptographic keys or can decrypt the data, the environment can remain relevant to PCI DSS.

Validated point-to-point encryption solutions can reduce the value of intercepted payment data and may also help reduce PCI scope. PCI SSC explicitly recognises this as a benefit of approved P2PE solutions.

From a product architecture perspective, scope reduction should be a design objective.

Every system that never receives sensitive card data is one less system that needs the same level of card-data protection.

12. PCI compliance as a product and architecture decision

PCI is sometimes treated as a security team's responsibility.

For FinTech, SaaS and e-commerce businesses, that approach is too narrow.

Payment integration choices made by product and engineering teams can determine the future PCI scope of the business.

For example, choosing to store PANs internally creates a very different architecture from using tokenization through a payment service provider. Building a custom payment form creates different responsibilities from redirecting users to a fully hosted payment environment.

The same applies to customer support and operations.

If support teams can see full card numbers, more users and systems may become relevant to PCI. If interfaces are designed so that sensitive data is masked or unavailable, the risk and scope can be reduced.

PCI should therefore be considered early in product design.

Changing payment architecture after launch is usually much more expensive than choosing a lower-scope model from the beginning.

13. PCI compliance in the EU and UK

PCI DSS is a global industry security standard rather than an EU or UK regulation.

This means PCI compliance should not be confused with compliance with GDPR, PSD2, the UK GDPR or other regulatory frameworks.

The requirements can overlap in practice.

For example, both PCI DSS and data protection rules create expectations around access control, security and data protection. Payment regulations can also affect authentication and operational security.

But one framework does not replace another.

A merchant can be PCI compliant and still fail to meet its GDPR obligations. A regulated payment institution can meet PSD2 requirements and still have gaps in PCI DSS compliance.

For companies operating across the EU and UK, the practical approach is to treat PCI DSS as part of the wider security and compliance architecture.

The advantage is that many controls, including identity management, logging, vulnerability management, incident response and third-party governance, can support several regulatory and security obligations at the same time.

14. Common PCI compliance mistakes

One common mistake is to treat PCI compliance as an annual documentation exercise.

Security controls need to work continuously. Systems change, developers deploy new code, new providers are introduced and user access changes throughout the year.

Another mistake is assuming that using a PCI compliant payment provider makes the merchant automatically compliant.

A provider can be compliant for the services it performs while the merchant still has separate responsibilities. The shared-responsibility model needs to be clearly understood.

Companies also frequently fail to control scope.

Card data may appear unexpectedly in logs, support tickets, analytics tools or internal databases. Once sensitive data enters a system, that system can become part of the PCI problem.

Another issue is treating compliance and security as the same thing.

PCI DSS provides a strong security baseline, but passing an assessment does not guarantee that an organisation cannot be breached. Good security requires continuous monitoring, risk management and secure engineering beyond a point-in-time validation.

15. FAQ

What is PCI compliance?

PCI compliance normally means meeting the applicable requirements of the Payment Card Industry Data Security Standard, or PCI DSS.

The standard is designed to protect payment account data and applies to entities that store, process or transmit cardholder data, as well as certain organisations that can affect the security of that data.

What does PCI stand for?

PCI stands for Payment Card Industry.

PCI DSS stands for Payment Card Industry Data Security Standard.

Is PCI compliance mandatory?

PCI DSS is an industry security standard rather than a general government law.

However, merchants and service providers are typically required to meet PCI DSS obligations through their relationships with payment brands, acquirers and other participants in the payment ecosystem.

The specific validation and reporting requirements are determined by those compliance programmes.

Does every business accepting cards need PCI compliance?

PCI DSS is intended for all merchants accepting payment cards within the relevant payment-brand programmes, regardless of size or transaction volume.

The amount of compliance work can differ significantly depending on the payment architecture and how much card data the merchant handles.

What is PCI DSS v4.0.1?

PCI DSS v4.0.1 is the current active version of the PCI Data Security Standard.

It replaced PCI DSS v4.0, which was retired on 31 December 2024. The future-dated requirements introduced in the v4 framework became effective on 31 March 2025.

What is a PCI SAQ?

A Self-Assessment Questionnaire is a PCI DSS validation tool available to eligible organisations.

There are different SAQs for different merchant payment environments. The organisation must meet the eligibility requirements of the selected SAQ.

Does Stripe, Adyen or another PSP make a merchant PCI compliant?

Using a PCI compliant payment service provider can reduce the merchant's PCI scope, sometimes significantly.

It does not automatically remove all PCI responsibilities.

The merchant still needs to understand its own environment, manage its third-party relationships and complete the appropriate validation required by its acquirer or payment brand.

Can tokenization reduce PCI scope?

Yes, tokenization can significantly reduce the amount of sensitive card data handled by the merchant's systems.

The exact scope impact depends on the implementation and whether systems can still access or influence the underlying cardholder data environment.

Is PCI compliance only an IT responsibility?

No.

IT and security teams play a major role, but PCI also affects product, engineering, operations, procurement, customer support and management.

Payment architecture and business processes can determine which systems and people enter PCI scope.

16. Conclusion

So, what is PCI compliance in practical terms?

It is the process of protecting payment account data in accordance with PCI DSS and demonstrating that the relevant security controls are in place.

For many companies, the difficult part is not understanding that card data should be protected. The difficult part is defining exactly where that data flows, which systems can affect it and which responsibilities belong to the merchant, payment provider and other third parties.

This is why PCI compliance should be considered during payment architecture and product design, not only during an annual security assessment.

A well-designed payment environment can reduce PCI scope dramatically. Hosted payment components, tokenization, appropriate encryption, restricted access and carefully selected providers can reduce both security exposure and the amount of compliance work required.

The opposite is also true. Allowing card data to spread across internal applications, logs, databases and operational processes can create unnecessary complexity that becomes difficult and expensive to remove later.

For FinTech, e-commerce and SaaS companies, PCI should therefore be treated as part of payment infrastructure design.

The objective is not simply to pass an assessment.

It is to build a payment environment where sensitive card data is exposed to as few systems and people as possible, security controls remain effective as the company grows and PCI compliance becomes a natural result of the architecture rather than a recurring operational problem.