How to Make Your WordPress Site PCI DSS Compliant: 2026 Guide

If your WordPress website accepts card payments, you need to understand your PCI DSS responsibilities. Whether you sell products, collect service deposits, or accept occasional online payments, your PCI DSS requirements depend on how your payment process handles cardholder data. The payment method you choose can also affect your compliance scope.

When a PCI DSS-compliant payment provider keeps cardholder data outside your WordPress environment, you may have fewer requirements to manage. However, your website still needs appropriate security controls.

In this guide, you’ll learn what PCI DSS v4.0.1 means for WordPress, how payment methods affect your PCI DSS scope, which SAQ may apply, and how to follow a practical WordPress PCI compliance checklist. 

What is PCI DSS Compliance?

PCI DSS stands for Payment Card Industry Data Security Standard. It was created by the PCI Security Standards Council, an organization founded by Visa, Mastercard, American Express, Discover, and JCB, to set a consistent bar for protecting cardholder data before, during, and after a transaction.

The current version is PCI DSS v4.0.1.

For context:

• PCI DSS v3.2.1: Retired on December 31, 2024.
• PCI DSS v4.0: Retired on December 31, 2024.
• PCI DSS v4.0.1: Published in 2024 and remains the current PCI DSS version.
• March 31, 2025: The future-dated requirements in PCI DSS v4.0/v4.0.1 became effective.

If you find a current compliance guide that still treats PCI DSS v3.2.1 as the active standard, check its publication date and update status.

PCI DSS organizes its 12 requirements into six goals:

1. Install and Maintain Network Security Controls — Protect the cardholder data environment with appropriate network security controls.
2. Apply Secure Configurations to All System Components — Remove default passwords and settings and maintain secure configurations.
3. Protect Stored Account Data — Protect stored account data and limit its storage to what you actually need.
4. Protect Cardholder Data With Strong Cryptography During Transmission Over Open, Public Networks — Protect account data while it travels across public networks.
5. Protect All Systems and Networks From Malicious Software — Use appropriate malware protections and keep them current.
6. Develop and Maintain Secure Systems and Software — Manage vulnerabilities, secure software development, and security updates.
7. Restrict Access to System Components and Cardholder Data by Business Need to Know — Give users only the access they need.
8. Identify Users and Authenticate Access to System Components — Use unique accounts and appropriate authentication controls.
9. Restrict Physical Access to Cardholder Data — Protect physical systems and media that contain or can access account data.
10. Log and Monitor All Access to System Components and Cardholder Data — Maintain appropriate logging and monitoring.
11. Regularly Test Security Systems and Processes — Test security controls and address vulnerabilities.
12. Support Information Security With Organizational Policies and Programs — Maintain documented security policies and related processes.

Keep attackers out, don’t hold onto data you don’t need, encrypt what you do handle, limit who can access it, watch for trouble, and document how your team is supposed to handle all of this.

For the full technical detail, the Council publishes the PCI DSS Quick Reference Guide and the standards overview directly.

The Truth About WordPress and PCI Compliance

The primary question that is often asked: Is WordPress PCI compliant?

WordPress itself does not determine whether your business meets PCI DSS requirements. PCI DSS applies to the people, processes, systems, and services involved in your payment environment. Your WordPress site’s role in that environment depends on how customers pay, where payment data is stored, which third-party services handle it, and which systems can affect transaction security.

That’s a subtle but important distinction, and it’s the same one WordPress.com’s own compliance documentation makes: compliance is about your implementation, not your platform.

Do I need PCI compliance if I use a payment gateway like Square, Stripe, or PayPal? 

Yes, merchants can still have PCI DSS responsibilities when they use a third-party payment provider. However, a PCI DSS-compliant payment provider that keeps account data outside your WordPress environment can significantly reduce your PCI DSS scope. Your exact responsibilities still depend on the payment integration, the provider’s PCI DSS validation, and the eligibility criteria for your applicable SAQ.

The Scope Principle: Your Payment Method Decides Your Workload

It’s the most useful thing you can understand before doing anything else.

PCI DSS scope covers the systems, people, processes, technologies, and services that store, process, or transmit account data, as well as systems and components that can affect the security of the cardholder data environment or payment transaction. The larger your cardholder data environment (CDE), the more PCI DSS requirements you’ll need to satisfy.

Cardholder Data Environment (CDE) refers to every system, network, and application that stores, processes, or transmits payment card information. Keeping payment cardholder data outside your WordPress environment can significantly reduce your PCI DSS scope, but it does not automatically remove every PCI DSS responsibility. Your WordPress site can still affect the security of the payment transaction, so you must review the eligibility criteria and requirements that apply to your payment setup.

How you accept payments determines which Self-Assessment Questionnaire (SAQ) you’ll likely complete:

Payment setup	Possible SAQ	What determines eligibility
Fully outsourced payment page or redirect to a PCI DSS-compliant payment provider	SAQ A	You must meet all SAQ A eligibility criteria.
Payment page uses elements from both your website and a PCI DSS-compliant payment provider	SAQ A-EP	The payment page and implementation must meet SAQ A-EP eligibility criteria.
Your systems directly handle account data through an applicable payment channel	SAQ D or another applicable SAQ	The exact SAQ depends on the payment channel, data flow, and eligibility criteria.

A quick definition of each:

• SAQ A applies to eligible merchants that fully outsource payment account-data functions to a PCI DSS-compliant third-party service provider and meet all SAQ A eligibility criteria. For ecommerce, the payment page or form must meet the specific criteria defined by PCI SSC; a redirect or certain third-party-hosted payment implementations may qualify.
• SAQ A-EP applies to eligible ecommerce merchants whose website does not itself receive account data but can affect the security of the payment transaction or payment page. The payment page can contain elements originating from the merchant website and the PCI DSS-compliant third-party service provider, subject to the full SAQ A-EP eligibility criteria.
• SAQ D can apply when your payment environment does not meet the eligibility criteria for a more specific SAQ and your systems directly handle account data. However, you should not select SAQ D simply because your site processes payments. Review the applicable SAQ eligibility criteria and confirm your validation requirements with your acquirer or payment provider.

Important: Don’t choose an SAQ based only on whether you use a redirect, iframe, popup, API, or hosted checkout. PCI SSC defines eligibility criteria for each SAQ, and you must meet all applicable criteria before using that questionnaire. Your payment processor or acquiring bank may also impose additional validation requirements. When you’re unsure, confirm your SAQ with the entity that requires your PCI DSS validation or consult a QSA.

For detailed information on the Self-Assessment Questionnaire and its types: take a look at the PCI SAQ Overview Chart.

What is the easiest way to make my WordPress site PCI compliant? 

Use a PCI DSS Level 1 validated gateway that keeps cardholder data off your site, never stores card numbers or CVV codes anywhere on your systems, runs HTTPS across your entire site, and completes the SAQ that matches how your payment flow actually works.

What are PCI DSS Requirements and How to Make Your WordPress Website PCI Compliant?

Even with cardholder data off your server, your WordPress site itself still needs to be secured. Here’s a practical checklist mapped to the 12 PCI DSS requirements.

• Network security controls (Requirement 1). Use appropriate network security controls to protect systems that fall within your PCI DSS scope. A web application firewall can add protection for WordPress web traffic, but a WAF does not replace the broader network security controls required by your environment.
• Secure configurations (Requirement 2). Remove or change vendor-default passwords and settings, disable unnecessary services, and maintain secure configurations for systems within your PCI DSS scope.
• Protect stored account data (Requirement 3). Avoid storing payment account data unless your business genuinely needs it and your environment can protect it appropriately. Never store sensitive authentication data such as card verification codes after authorization. Check databases, logs, backups, emails, and third-party integrations for unintended payment-data storage.
• Protect data in transit (Requirement 4). Use HTTPS and strong cryptography to protect account data during transmission across open, public networks. Configure modern TLS protocols and disable obsolete or insecure protocols and cipher suites. Sitewide HTTPS also protects login credentials, forms, cookies, and other sensitive website traffic.
• Malware protection (Requirement 5). Protect applicable systems from malicious software using security controls appropriate to your environment. On WordPress, scheduled malware scanning can help detect compromised files, plugins, and themes, but a WordPress security plugin does not replace all security controls required by PCI DSS.
• Secure systems and software (Requirement 6). Keep WordPress core, plugins, themes, servers, and other in-scope software patched and supported. Remove abandoned components when possible, monitor vulnerabilities, and follow a documented process for applying security updates.
• Role-based access (Requirement 7). Give each user the minimum permissions they actually need. 
• User authentication (Requirement 8). Give every administrator a unique account and use appropriate authentication controls, including multi-factor authentication where PCI DSS requires it. Never share administrator credentials, and remove accounts when users no longer need access.
• Physical security (Requirement 9). Lock away any printed reports, backup drives, or offline copies of anything payment-related.
• Logging and monitoring (Requirement 10). Maintain appropriate audit logs and monitoring for systems within your PCI DSS scope. Track relevant authentication events, administrative activity, security events, and access to account data according to the requirements that apply to your environment. WordPress security plugins can help, but review their coverage rather than assuming they satisfy the requirement by default.
• Security testing (Requirement 11). Test security controls and systems according to the requirements that apply to your environment. Depending on your payment setup, this can include vulnerability scanning, penetration testing, wireless testing, or other security tests. Do not assume that a WordPress malware scan replaces a PCI DSS vulnerability scan.
• Written security policy (Requirement 12). A short, documented policy covering passwords, updates, access, and what to do if something goes wrong. Review it whenever your setup changes.

Work through that list, and you’ve covered the practical surface of all six PCI DSS goals on WordPress.

How to Make Your WordPress Store Compliant

Understanding the requirements is one thing. Documenting that you meet them is another, and it’s the part your processor or acquiring bank will eventually ask about.

The Self-Assessment Questionnaire (SAQ) is a document covering the requirements that apply to your specific setup. You complete it yourself, keep it on file, and produce it if your processor or bank requests it.

The process typically looks like this: identify how your payment flow handles account data, review the eligibility criteria for the applicable SAQ, confirm the correct validation method with your acquirer or payment provider, complete the questionnaire based on your actual environment, retain the required evidence and Attestation of Compliance, and repeat the validation according to your applicable program requirements.

For some merchants, an SAQ may not provide the required validation. Your acquirer, payment brand, or other entity may require a Report on Compliance (ROC), a Qualified Security Assessor (QSA), an Approved Scanning Vendor (ASV) scan, or another validation method. Don’t determine your validation requirements from transaction volume alone; confirm them with the entity that requires your PCI DSS compliance validation.

Common Mistakes To Look Out For

A few patterns show up again and again on small WordPress websites, and most of them are easy to avoid once you know to look for them.

• Storing cardholder data you don’t need. Order confirmation emails, error logs, and database backups are the most common accidental storage spots. If you don’t need it, don’t keep it.
• Assuming a gateway is compliant without checking. Confirm directly with the provider. Don’t take it on faith.
• Skipping updates. Outdated or vulnerable plugins can create a serious attack path for WordPress websites. Keep WordPress core, plugins, themes, and server software patched, and remove components that you no longer need.
• HTTPS on only the checkout page. Use HTTPS across the entire WordPress site, not only the checkout page. Sitewide HTTPS protects login credentials, cookies, forms, account pages, and other sensitive traffic while also reducing the risk of attackers modifying pages involved in the payment process.
• Shared admin logins. This quietly defeats the entire point of access control requirements.
• No documented security policy. Document the security policies and procedures that apply to your business, including access management, software updates, incident response, and security responsibilities. Review the documentation when your environment or payment process changes.
• Filing the wrong SAQ, or none at all. Pick the type that matches how your cardholder data actually flows, and keep it on file.
• Using abandoned or unsupported WordPress plugins. Attackers frequently exploit outdated plugins, increasing the risk of data breaches and compliance failures.

Put Your PCI Compliance Plan into Action

Compliance scales with how much cardholder data your site is exposed to, so the highest-leverage move is keeping cardholder data off your server entirely. From there, complete the SAQ that matches your setup and keep your WordPress site itself hardened using the checklist above.

If you’re setting up Square payments on WordPress, WP Easy Pay can help you create a payment flow without requiring you to build your own card-processing system. Keep payment card data within the PCI DSS-compliant payment provider’s environment whenever your integration supports that model, test your payment flow before launch, and confirm your applicable SAQ and validation requirements with your payment provider or acquirer.

Also, take a look at:

• How Payment Processing Works
• What is Square Payment Gateway
• What Is a Merchant Account

Frequently Asked Questions