What Is PCI DSS Compliance? A Plain-Language Guide for 2026

If your bank, payment processor, or enterprise client has told you that you need PCI DSS compliance, and you have no idea what that means or whether it applies to you this guide is the starting point.

PCI DSS is not a government regulation. It is not optional. It is the global security standard that governs how any business that accepts, processes, stores, or transmits payment card data must protect that data. If you handle credit or debit card information in any form whether you run an e-commerce store, a SaaS platform with subscription billing, a payment gateway, or a brick-and-mortar business with card terminals PCI DSS applies to you.

This guide explains what PCI DSS compliance is, who it applies to, what the requirements actually involve, and how to determine which validation path your business needs to follow in 2026.

1. What Is PCI DSS?
2. Who Needs PCI DSS Compliance?
3. What Version of PCI DSS Is Current in 2026?
4. The 12 PCI DSS Requirements Explained
5. Merchant Levels: What Validation You Need
6. SAQ Types: The Self-Assessment Questionnaires
7. What Happens If You're Not Compliant?
8. How to Start Your PCI Compliance Journey
9. How SecurityWall Supports PCI DSS Compliance

What Is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security requirements designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment to protect cardholder data from theft, fraud, and breaches.

The standard was created in 2004 by the major payment card brands Visa, Mastercard, American Express, Discover, and JCB and is managed by the PCI Security Standards Council (PCI SSC), a global forum responsible for developing, maintaining, and updating the standard.

PCI DSS is not a law, but compliance is contractually mandated. When a business signs up with a payment processor or acquiring bank to accept card payments, it agrees to comply with PCI DSS as a condition of that contract. The payment brands enforce compliance through acquiring banks, who in turn require merchants and service providers to validate their security posture annually.

Why PCI DSS exists: Payment card data is one of the most targeted assets in cybercrime. Breaches of cardholder data result in financial losses, fraud, legal liability, and reputational damage. PCI DSS provides a baseline security framework that reduces the risk of these breaches by standardizing how organisations protect payment data across the entire payments ecosystem.

Who Needs PCI DSS Compliance?

PCI DSS applies to any organisation that stores, processes, or transmits cardholder data — or that could impact the security of cardholder data.

This includes:

• Merchants — any business that accepts payment cards as a form of payment, whether online, in-store, via telephone, or mail order
• Service providers — companies that process, store, or transmit cardholder data on behalf of merchants or other service providers, including payment gateways, processors, hosting providers, managed security providers, and SaaS platforms that handle payment data
• Acquiring banks — financial institutions that enable merchants to accept card payments
• Technology vendors — companies that develop or manage payment applications, terminals, or infrastructure

If you accept card payments in any form, PCI DSS applies to you. The validation requirements differ based on your transaction volume and how you handle card data, but the underlying security obligations are the same.

Common Misunderstandings About PCI DSS Applicability

"We use a third-party payment processor, so PCI DSS doesn't apply to us."

Not true. Even if you outsource payment processing entirely to a third party, you still have PCI DSS obligations. The specific requirements you must validate depend on how the integration works. If your website or application redirects customers to a fully hosted payment page managed by a PCI-compliant provider, your validation burden is minimal — but you are still required to complete an annual Self-Assessment Questionnaire (SAQ) and demonstrate that your service provider is compliant.

"We don't store card data, so we don't need PCI compliance."

Partially true. If you never store, process, or transmit card data electronically — meaning you only retain paper receipts with truncated card numbers and no electronic records — then your PCI DSS scope is significantly reduced. However, if card data passes through your systems at any point during a transaction (even if it is not stored), PCI DSS requirements apply to those systems.

"We're a small business, so PCI DSS is not enforced for us."

False. PCI DSS applies to businesses of all sizes. While smaller businesses — those processing fewer than 20,000 e-commerce transactions or fewer than 1 million card-present transactions per year — may use simpler self-assessment validation methods rather than undergoing a full external audit, they are still required to comply with the security standard. Non-compliance can result in fines, the inability to accept card payments, and liability for breaches.

What Version of PCI DSS Is Current in 2026?

As of 2026, the current and only active version of PCI DSS is PCI DSS v4.0.1.

PCI DSS v4.0 was published in March 2022 as the first major update to the standard in over a decade. It introduced significant changes to reflect modern payment environments, evolving threat landscapes, and new technologies. In June 2024, the PCI SSC released PCI DSS v4.0.1 as a limited revision that clarified certain requirements, corrected typographical errors, and improved guidance without introducing any new requirements.

PCI DSS v3.2.1 was officially retired on March 31, 2024. All assessments and validations conducted in 2026 must be against PCI DSS v4.0.1.

The Major Changes in PCI DSS v4.0

The shift from v3.2.1 to v4.0 was substantial. Key updates include:

• Customized Approach — organisations can now implement alternative controls that achieve the same security objective as the defined requirements, as long as they can demonstrate through a Targeted Risk Analysis that the customized controls meet the intent
• Continuous compliance — the standard emphasises year-round security practices rather than annual compliance events
• Expanded multi-factor authentication (MFA) requirements — MFA is now required for all access into the Cardholder Data Environment (CDE), not just administrative access
• Payment page script management — new requirements (6.4.3 and 11.6.1) address the security of payment pages and the risk of client-side attacks such as e-skimming (Magecart attacks)
• Roles and responsibilities — many requirements now explicitly require that roles and responsibilities for security functions be documented and assigned
• Authenticated vulnerability scanning — internal vulnerability scans must now be authenticated (credentialed scans) to identify vulnerabilities that cannot be detected through unauthenticated scans
• Enhanced logging and monitoring requirements — automated log reviews and continuous monitoring of critical security control failures

The March 31, 2025 deadline: When v4.0 was first published, 51 of the 64 new requirements were designated as "future-dated," meaning they were best practices until March 31, 2025. As of that date, all future-dated requirements became mandatory. This means that 2026 is the first full year where every requirement in PCI DSS v4.0.1 is in effect and will be validated during assessments.

The 12 PCI DSS Requirements Explained

PCI DSS is organised into 12 high-level requirements, grouped into six control objectives. These requirements define what organisations must implement to secure cardholder data.

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain network security controls

Firewalls and network segmentation are the first line of defense in protecting cardholder data. This requirement mandates that organisations implement network security controls to restrict traffic between untrusted networks (such as the Internet) and the Cardholder Data Environment (CDE).

Requirement 2: Apply secure configurations to all system components

Default configurations provided by vendors are often insecure. This requirement ensures that all systems are hardened — default passwords are changed, unnecessary services are disabled, and security parameters are configured according to industry-accepted standards.

Protect Cardholder Data

Requirement 3: Protect stored account data

If your organisation stores cardholder data (such as Primary Account Numbers), it must be rendered unreadable. This is typically achieved through encryption, tokenisation, or hashing. PCI DSS also requires that organisations retain only the minimum data necessary and securely delete data when it is no longer needed.

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

Whenever cardholder data is transmitted across networks that could be accessed by unauthorised individuals — such as the Internet or wireless networks — it must be encrypted using strong cryptography (TLS 1.2 or higher).

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems and networks from malicious software

Anti-malware software must be deployed on all systems commonly affected by malware, kept up to date, and configured to generate audit logs.

Requirement 6: Develop and maintain secure systems and software

This requirement addresses the full software development lifecycle and system management. Organisations must apply security patches promptly, conduct secure code reviews for custom applications, and protect payment pages from tampering (including monitoring third-party scripts for unauthorised changes).

Implement Strong Access Control Measures

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

Access to cardholder data must be limited to only those individuals whose job requires such access. This is enforced through role-based access controls and the principle of least privilege.

Requirement 8: Identify users and authenticate access to system components

Every user must have a unique ID, and authentication must be strong. Multi-factor authentication (MFA) is now required for all access into the CDE and for all remote access.

Requirement 9: Restrict physical access to cardholder data

Physical security controls must be in place to prevent unauthorised individuals from gaining access to systems or media that contain cardholder data.

Regularly Monitor and Test Networks

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

Comprehensive logging of all access to system components and cardholder data is required, and logs must be reviewed regularly. Automated mechanisms for log review and alerting on suspicious activity are now expected.

Requirement 11: Test security of systems and networks regularly

This requirement mandates regular vulnerability scanning (quarterly by an Approved Scanning Vendor for external scans, and quarterly authenticated scans for internal systems) and annual penetration testing. Any significant infrastructure or application changes must trigger additional penetration testing.

Maintain an Information Security Policy

Requirement 12: Support information security with organizational policies and programs

A formal information security policy must be in place, maintained, and communicated to all personnel. Security awareness training is required, and third-party service provider relationships must be managed to ensure they meet PCI DSS obligations.

Merchant Levels: What Validation You Need

PCI DSS compliance validation requirements vary based on merchant level, which is determined by the volume of card transactions processed annually. The payment card brands (Visa, Mastercard, etc.) define these levels, and while the thresholds are similar across brands, there are minor variations.

Level 1 merchants — typically large retailers, e-commerce platforms, and enterprises — must undergo a rigorous annual assessment conducted by a Qualified Security Assessor (QSA). The assessment results in a Report on Compliance (ROC), a comprehensive document that can run hundreds of pages detailing how every applicable PCI DSS requirement has been met.

Level 2, 3, and 4 merchants can typically self-assess using a Self-Assessment Questionnaire (SAQ), which is a simplified validation tool tailored to specific payment environments. However, the underlying security requirements remain the same — the difference is only in how compliance is validated, not in what must be implemented.

Merchants that have experienced a data breach are typically elevated to Level 1 status regardless of transaction volume, which means they must undergo a full QSA assessment.

SAQ Types: The Self-Assessment Questionnaires

The Self-Assessment Questionnaire (SAQ) is a validation tool for merchants and service providers that qualify to assess themselves rather than undergoing a full external audit. There are nine SAQ types, each designed for a specific payment channel or technical architecture.

Selecting the correct SAQ is critical. Completing the wrong SAQ can result in compliance failures, audit findings, or non-acceptance by your acquiring bank.

SAQ A — Card-Not-Present, Fully Outsourced

Who it's for: E-commerce or mail/telephone-order merchants that have fully outsourced all cardholder data functions to PCI-compliant third parties. No cardholder data is stored, processed, or transmitted on the merchant's systems.

Example: An online store that redirects customers to a hosted payment page (such as Stripe Checkout or PayPal).

Number of questions: 24

Key requirement: The merchant's website must use HTTPS, and the merchant must verify that all service providers handling payment data are PCI DSS compliant.

SAQ A-EP — E-Commerce with Partial Outsourcing

Who it's for: E-commerce merchants that outsource payment processing but whose website can impact the security of the payment transaction (such as hosting a payment form via an iframe or controlling the payment page).

Example: An online retailer that embeds a payment form on its own domain but processes transactions through a third-party gateway.

Number of questions: 192

Key requirement: Payment page script management (monitoring and controlling all scripts loaded on the payment page to prevent tampering) is now a significant focus under PCI DSS v4.0.

SAQ B — Imprint or Standalone Dial-Out Terminals

Who it's for: Merchants using only imprint machines or standalone, dial-out terminals with no electronic cardholder data storage.

Example: A small retail shop with a single countertop card reader connected via a landline.

Number of questions: 41

Not applicable to e-commerce.

SAQ B-IP — Standalone IP-Connected Terminals

Who it's for: Merchants using only standalone, IP-connected payment terminals (such as Wi-Fi or Ethernet-connected card readers) with no electronic cardholder data storage.

Example: A coffee shop using a Wi-Fi-enabled payment terminal.

Number of questions: 87

Not applicable to e-commerce.

SAQ C — Internet-Connected Payment Application

Who it's for: Merchants with payment application systems connected to the Internet, with no electronic cardholder data storage.

Example: A retail business with networked point-of-sale (POS) systems.

Number of questions: 84

SAQ C-VT — Virtual Terminal (Single Computer)

Who it's for: Merchants that manually enter transactions one at a time via a virtual terminal (a web-based payment interface) accessed on a single, isolated computer.

Example: A B2B service provider that manually processes customer payments via a browser-based virtual terminal.

Number of questions: 161

Not applicable to e-commerce.

SAQ P2PE — Point-to-Point Encryption

Who it's for: Merchants that use only PCI-validated Point-to-Point Encryption (P2PE) solutions from a PCI-listed provider, with no electronic cardholder data storage.

Example: A pop-up retail business using a mobile P2PE reader certified by the PCI Council.

Number of questions: 34

Key requirement: The P2PE solution must be PCI-listed and validated. Not all encrypted card readers qualify.

SAQ D for Merchants — All Other Merchants

Who it's for: Merchants that do not meet the eligibility criteria for any other SAQ type. This includes merchants that store cardholder data electronically, merchants with e-commerce environments that accept card data directly, and merchants with complex payment infrastructures.

Example: A subscription-based SaaS business that stores customer payment data for recurring billing.

Number of questions: 328

SAQ D is the most comprehensive self-assessment and covers all 12 PCI DSS requirements. It is effectively equivalent to a full ROC in terms of scope, but completed as a self-assessment rather than by a QSA.

SAQ D for Service Providers

Who it's for: Service providers eligible to complete an SAQ instead of undergoing a full ROC.

Example: A payment gateway operator or hosting provider that processes cardholder data on behalf of merchants.

Number of questions: 370

What Happens If You're Not Compliant?

PCI DSS compliance is not optional. Non-compliance exposes organisations to financial penalties, operational restrictions, and significant liability in the event of a data breach.

Fines from acquiring banks

Acquiring banks (the financial institutions that enable merchants to accept card payments) enforce PCI DSS compliance on behalf of the payment card brands. Non-compliant merchants can be subject to monthly fines ranging from $5,000 to $100,000, depending on the merchant's size and the duration of non-compliance.

These fines are not one-time penalties — they continue to accrue until compliance is achieved. For Level 1 merchants, prolonged non-compliance can result in fines exceeding $1 million annually.

Loss of ability to accept card payments

In severe cases of non-compliance, acquiring banks can revoke a merchant's ability to accept card payments. This effectively shuts down the revenue stream for any business that relies on card transactions, which is the majority of modern commerce.

Liability for breach costs

If a non-compliant merchant experiences a data breach involving cardholder data, they can be held financially liable for:

• Card reissuance costs (the cost of replacing every compromised card)
• Fraud losses (fraudulent transactions made with stolen card data)
• Investigation and forensic analysis costs
• Legal fees and regulatory fines
• Brand damage and customer notification obligations

According to industry data, the average cost of a payment card data breach is approximately $4.45 million, but the total impact can be far higher depending on the scale of the breach and the organisation's size.

Reputational damage

A publicised data breach destroys customer trust and can result in long-term revenue loss. Many customers will stop doing business with an organisation that has demonstrated poor security practices, and the reputational damage can persist for years.

How to Start Your PCI Compliance Journey

If you are new to PCI DSS or have just been told that compliance is required, the following steps provide a clear starting point.

Step 1: Determine your merchant level and SAQ type

Contact your acquiring bank or payment processor and confirm your merchant level based on your annual transaction volume. They will also help you identify which SAQ type applies to your business, or whether you need a full ROC.

If you process payments through a third-party provider (such as Stripe, Square, or PayPal), ask them for guidance on which SAQ is appropriate for your integration method.

Step 2: Define your cardholder data environment (CDE)

The CDE is the portion of your network and systems that stores, processes, or transmits cardholder data — or that could impact the security of cardholder data. Properly scoping your CDE is one of the most important steps in PCI compliance, because it determines which systems and applications are subject to PCI DSS requirements.

Reducing the scope of your CDE through network segmentation, tokenisation, or point-to-point encryption can significantly reduce your compliance burden.

Step 3: Conduct a gap assessment

A gap assessment compares your current security posture against the PCI DSS requirements to identify what controls are missing, what controls are partially implemented, and what controls are already in place.

A gap assessment is typically conducted internally or with the assistance of a QSA or security consultant. It produces a prioritised remediation plan that guides your compliance programme.

Step 4: Implement required security controls

Based on the gap assessment findings, implement the security controls required to meet PCI DSS. This may include:

• Installing and configuring firewalls
• Implementing MFA for all access into the CDE
• Deploying anti-malware software
• Encrypting cardholder data at rest and in transit
• Conducting vulnerability scans and penetration testing
• Establishing logging and monitoring mechanisms
• Documenting policies and procedures

Step 5: Complete quarterly vulnerability scans

Engage an Approved Scanning Vendor (ASV) to conduct quarterly external vulnerability scans of all public-facing systems. Four consecutive passing scans within a 12-month period are required for compliance validation.

Internal authenticated vulnerability scans must also be conducted quarterly.

Step 6: Conduct annual penetration testing

Penetration testing is required annually and after any significant infrastructure or application changes. The test must be conducted by qualified personnel (internal or external) and must cover the entire CDE, including network infrastructure, applications, and any external-facing systems.

Step 7: Complete your SAQ or undergo a QSA assessment

If you qualify for an SAQ, complete the appropriate questionnaire based on your payment environment. If you are a Level 1 merchant or do not qualify for an SAQ, engage a QSA to conduct a full assessment and produce a Report on Compliance (ROC).

Step 8: Submit compliance documentation to your acquiring bank

Submit your completed SAQ and Attestation of Compliance (AOC), along with your ASV scan reports, to your acquiring bank. If you underwent a QSA assessment, submit your ROC and AOC.

Your acquiring bank will review the documentation and confirm your compliance status with the payment card brands.

How SecurityWall Supports PCI DSS Compliance

PCI DSS compliance is not a one-time project — it is an ongoing security programme that requires continuous monitoring, regular testing, and evidence management. SecurityWall provides end-to-end PCI DSS compliance support for merchants and service providers across all validation levels.

PCI DSS Gap Assessments

We conduct comprehensive gap assessments that map your current security posture against PCI DSS v4.0.1 requirements, identify control gaps, and produce a prioritised remediation roadmap. Our assessments are scoped to your specific payment environment and SAQ type, so you implement only what is required — no over-engineering, no wasted effort.

Penetration Testing for PCI DSS Compliance

Penetration testing is a mandatory PCI DSS requirement (Requirement 11.4). SecurityWall's penetration testing engagements are conducted by OSCP, CREST, and CISM-certified practitioners and are scoped specifically to satisfy PCI DSS validation requirements.

Our penetration tests cover:

• External network infrastructure
• Internal network segmentation and access controls
• Web applications and APIs
• Payment page security and script integrity (Requirements 6.4.3 and 11.6.1)
• Mobile applications (if applicable)
• Cloud environments (AWS, Azure, GCP)

Every engagement produces a PCI DSS-compliant penetration test report with CVSS-scored findings, exploitation evidence, and remediation guidance — structured for submission to QSAs, acquiring banks, or internal audit teams.

Quarterly Vulnerability Scanning

SecurityWall is not an Approved Scanning Vendor (ASV), but we work with ASV partners to coordinate your quarterly external scans and can conduct your internal authenticated vulnerability scans as part of a managed compliance programme.

Ongoing Compliance Support

PCI DSS v4.0 emphasises continuous compliance — not annual events. We support organisations through:

• Quarterly scan coordination and remediation tracking
• Annual penetration testing cycles
• Incident response readiness and tabletop exercises
• Policy and procedure development
• Third-party service provider due diligence

Related reading:

• PCI DSS Penetration Testing Requirements: What Assessors Check (coming soon)
• How to Choose the Right PCI DSS SAQ for Your Business (coming soon)
• PCI DSS v4.0 Compliance Checklist for E-Commerce Merchants (coming soon)
• Payment Page Script Management: Requirements 6.4.3 and 11.6.1 Explained (coming soon)

Frequently Asked Questions

Is PCI DSS a legal requirement?

PCI DSS is not a government law, but it is a contractual requirement enforced by the payment card brands (Visa, Mastercard, American Express, Discover, JCB). When you sign up to accept card payments, you agree to comply with PCI DSS as a condition of that agreement. Non-compliance can result in fines, loss of payment processing privileges, and liability for breach costs.

Do I need PCI DSS if I use Stripe, Square, or PayPal?

Yes, but your compliance obligations are significantly reduced. If you redirect customers to a fully hosted payment page managed by a PCI-compliant provider (such as Stripe Checkout or PayPal), you likely qualify for SAQ A, the shortest and simplest self-assessment. However, you are still required to complete the SAQ annually and verify that your payment provider is PCI DSS compliant.

What is the difference between PCI DSS and PCI compliance?

"PCI compliance" is shorthand for "PCI DSS compliance." The terms are used interchangeably. PCI DSS is the standard; being PCI compliant means you meet that standard.

How much does PCI DSS compliance cost?

The cost varies widely based on your merchant level, the complexity of your environment, and whether you qualify for an SAQ or require a full QSA assessment. For Level 4 merchants using outsourced payment processing, compliance costs can be as low as a few thousand dollars annually (gap assessment, quarterly scans, and SAQ completion). For Level 1 merchants with complex environments, annual compliance costs can range from $50,000 to over $500,000, including QSA fees, penetration testing, vulnerability management, and ongoing remediation.

How long does it take to become PCI DSS compliant?

For organisations starting from scratch, achieving initial compliance typically takes 3 to 12 months, depending on the size of the environment and the number of control gaps identified during the gap assessment. Smaller businesses with simple payment environments (such as those qualifying for SAQ A) can often achieve compliance in 4 to 8 weeks. Larger organisations or those with significant security gaps may require 12 months or more.

Do I need penetration testing for PCI DSS?

Yes. PCI DSS Requirement 11.4 mandates annual penetration testing of the entire CDE, as well as penetration testing after any significant infrastructure or application changes. The penetration test must be conducted by a qualified individual or organisation and must include network-layer testing, application-layer testing, and testing of segmentation controls if network segmentation is used to limit PCI scope.