You added a checkout page. You integrated Stripe or Square. The payments work. What most businesses don't realise is that processing card payments — even through a third-party gateway — creates Payment Card Industry Data Security Standard (PCI DSS) obligations you are contractually bound to meet.
PCI DSS v4.0, fully mandatory since March 2025, raised the bar significantly. The new version introduced 64 future-dated requirements, expanded multi-factor authentication mandates, and hardened requirements around web-facing payment pages. Businesses that were technically compliant under v3.2.1 may no longer be under v4.0.
This checklist covers all 12 PCI DSS requirements with actionable steps, explains who actually needs to comply, and shows where businesses most often fall short. No certification jargon — just what you need to do.
🧠 How compliant is your business?
Take our free 2-minute Compliance Score Quiz — get a personalized risk rating and know exactly where your PCI DSS gaps are.
Take the Free Compliance Score Quiz →Who Needs PCI DSS Compliance?
PCI DSS applies to every entity that stores, processes, or transmits cardholder data — or that could impact the security of the cardholder data environment (CDE). That includes:
- E-commerce businesses that accept card payments online — even via a hosted payment page
- Retail businesses with card-present (POS) transactions
- SaaS companies that bill customers by card, including subscription businesses
- Fintech companies that handle card data as part of their core product
- Service providers (payment processors, hosting companies) that handle cardholder data on behalf of merchants
The common misconception: "We use Stripe so we don't need to worry about PCI." Wrong. Outsourcing payment processing to Stripe, Braintree, or Square reduces your PCI scope significantly — but it does not eliminate your obligations. You still need to complete the appropriate Self-Assessment Questionnaire (SAQ) annually and ensure your integration meets the required controls.
Your PCI compliance level determines the validation requirements: Level 1 merchants (over 6 million transactions/year) require an annual on-site audit by a Qualified Security Assessor (QSA). Levels 2–4 (smaller volumes) can self-assess using an SAQ. Failing to validate annually is itself a compliance breach — even if your actual security posture is fine.
PCI DSS Merchant Levels at a Glance
| Level | Annual Transaction Volume | Validation Required |
|---|---|---|
| Level 1 | Over 6 million (any card brand) | Annual QSA audit + quarterly network scan |
| Level 2 | 1 million – 6 million | Annual SAQ + quarterly network scan |
| Level 3 | 20,000 – 1 million (e-commerce) | Annual SAQ + quarterly network scan |
| Level 4 | Under 20,000 (e-commerce) or under 1 million (other) | Annual SAQ (simplified) — acquirer may waive scan |
Not Sure Where Your PCI DSS Gaps Are?
Run a free risk scan in 60 seconds. See your PCI DSS readiness score and top gaps — no signup required.
Run Free PCI DSS Compliance ScanThe PCI DSS 12-Requirement Compliance Checklist
PCI DSS v4.0 is organised into 12 requirements grouped into six goals. Below is each requirement with the critical controls you need to have in place.
R1
Install and Maintain Network Security Controls
- ✓Define and document your cardholder data environment (CDE) — every system that stores, processes, or transmits cardholder data
- ✓Implement firewall rules that restrict inbound and outbound traffic to only what is required for the CDE
- ✓Segment the CDE from the rest of your network — systems outside the CDE must not have direct access to cardholder data
- ✓Review all network security control rulesets at least every six months; document justification for every rule
- ✓Block direct public internet access to and from systems in the CDE — all traffic must route through a DMZ or equivalent
R2
Apply Secure Configurations to All System Components
- ✓Change all vendor-supplied default passwords before deploying any system into the CDE — no exceptions
- ✓Disable all unnecessary services, protocols, and functionality on CDE systems (turn off what you don't use)
- ✓Maintain a configuration standard for each system type — document the hardening steps and apply them consistently
- ✓Protect non-console administrative access with strong cryptography (SSH, HTTPS — never Telnet or unencrypted HTTP for admin interfaces)
- ✓Review configuration standards at least once every 12 months and update when new vulnerabilities are identified
R3
Protect Stored Account Data
- ✓Minimise stored cardholder data — keep only what you absolutely need, and only for as long as you need it
- ✓Never store sensitive authentication data (SAD) after authorisation — this includes the full magnetic stripe, CVV2/CVC2, and PIN data. This is an absolute prohibition.
- ✓Mask the Primary Account Number (PAN) when displayed — show only the first six and last four digits at most
- ✓If you must store PANs, render them unreadable using strong cryptography (AES-256), truncation, tokenisation, or one-way hashing
- ✓Implement a data retention policy with defined deletion schedules — run automated processes to delete cardholder data that exceeds the retention period
- ✓Protect cryptographic keys used to encrypt cardholder data — key management procedures, key custodians, and key rotation schedules are required
R4
Protect Cardholder Data with Strong Cryptography During Transmission
- ✓Use TLS 1.2 or higher for all transmission of cardholder data across open, public networks — TLS 1.0 and 1.1 are prohibited
- ✓Never send PANs via unencrypted messaging (email, chat, SMS) — implement a policy and technical controls to prevent this
- ✓Confirm that all trusted certificates are valid, from trusted CAs, and that certificate validation is enforced (no certificate bypass)
- ✓Maintain an inventory of trusted keys and certificates — review annually for expiration and validity
R5
Protect All Systems and Networks from Malicious Software
- ✓Deploy anti-malware solutions on all system components in the CDE that are commonly targeted by malware
- ✓Ensure anti-malware solutions are current, actively running, and generating audit logs
- ✓Configure anti-malware to run automatic periodic scans, or perform continuous behavioural analysis
- ✓Review systems not otherwise targeted by malware at least annually to confirm that anti-malware protection is not needed
- ✓Implement anti-phishing mechanisms — email authentication (SPF, DKIM, DMARC) and security awareness training for personnel
R6
Develop and Maintain Secure Systems and Applications
- ✓Establish a process to identify and rank security vulnerabilities — use a reputable source like NIST NVD or CVE programme
- ✓Protect web-facing applications against the OWASP Top 10 — injection, broken auth, XSS, insecure direct object references, and more
- ✓Install critical security patches within one month of release; lower-risk patches within a defined timeframe (typically three months)
- ✓Deploy a web application firewall (WAF) in front of all public-facing payment applications, or conduct regular penetration testing as an alternative
- ✓New in v4.0: Implement a Content Security Policy (CSP) on all payment pages and monitor for unauthorised scripts — this directly addresses Magecart-style payment skimming attacks
- ✓Maintain an inventory of all bespoke and custom software and third-party components — review at least annually for security risks
R7
Restrict Access to System Components and Cardholder Data by Business Need to Know
- ✓Implement least-privilege access — grant individuals only the minimum access rights needed to perform their job function
- ✓Deny all access by default; access to CDE components must be explicitly granted, not implicitly allowed
- ✓Document all access control models — role definitions, data access levels, and justifications for elevated privileges
- ✓Review user access privileges at least every six months — revoke access for employees who change roles or leave the organisation
R8
Identify Users and Authenticate Access to System Components
- ✓Assign a unique ID to each user account — never use shared accounts or group logins in the CDE
- ✓Require multi-factor authentication (MFA) for all access into the CDE — this is now mandatory for all personnel accessing any CDE system component (not just remote access)
- ✓Enforce minimum password complexity: at least 12 characters (v4.0 raised this from 7), with numeric and alphabetic characters
- ✓Lock accounts after at most 10 failed authentication attempts; require unlock by an administrator or time-limited unlock
- ✓Set idle session timeout at 15 minutes or less for sessions accessing the CDE
- ✓Use phishing-resistant authentication for all access by administrators and users — hardware tokens or FIDO2/passkeys preferred over SMS OTP
R9
Restrict Physical Access to Cardholder Data
- ✓Implement physical access controls to systems in the CDE — badge readers, locks, and visitor logs for server rooms and network equipment
- ✓Distinguish between onsite personnel and visitors — issue badges, escort visitors in sensitive areas
- ✓Maintain a log of physical access to sensitive areas — retain logs for at least 90 days
- ✓Protect POS devices and payment terminals — implement device inspection procedures to detect tampering or skimming devices
- ✓Securely destroy physical media containing cardholder data when no longer needed — cross-cut shredding or secure disposal services
R10
Log and Monitor All Access to System Components and Cardholder Data
- ✓Enable audit logging on all CDE system components — logs must capture user identification, event type, date/time, success or failure, origination, and identity of affected data
- ✓Protect audit logs from modification — logs must be write-protected and stored on a separate, secured logging server
- ✓Retain audit logs for at least 12 months; the most recent three months must be immediately available for analysis
- ✓Review logs for anomalies and suspicious activity at least daily — ideally via automated SIEM alerting
- ✓Synchronise all system clocks using Network Time Protocol (NTP) with a reliable time source — inconsistent timestamps break forensic analysis
R11
Test Security of Systems and Networks Regularly
- ✓Run automated vulnerability scans of all CDE components at least quarterly — use an Approved Scanning Vendor (ASV) for external scans
- ✓Conduct penetration testing annually and after any significant infrastructure or application changes
- ✓Test segmentation controls at least every six months to confirm that the CDE is isolated from out-of-scope systems (or annually for service providers)
- ✓Deploy intrusion detection/prevention systems (IDS/IPS) to monitor all traffic in and around the CDE
- ✓Detect and identify rogue wireless access points — scan for unauthorised wireless connections at least quarterly
- ✓New in v4.0: Monitor all payment page scripts in real-time — any new or modified script on a payment page must be reviewed and authorised
R12
Support Information Security with Organisational Policies and Programs
- ✓Maintain a comprehensive information security policy — reviewed and updated at least annually, and after any significant change
- ✓Conduct a risk assessment at least annually and after any significant environmental changes — document identified risks, likelihood, and impact
- ✓Deliver security awareness training to all personnel when hired and at least annually thereafter — cover phishing, social engineering, and acceptable use
- ✓Maintain a list of all third-party service providers with access to cardholder data — manage engagements with written agreements confirming PCI DSS responsibility
- ✓Maintain a documented incident response plan — test it at least annually with tabletop exercises; include roles, escalation paths, and communication procedures
- ✓Assign accountability: designate a person or team responsible for information security program management and PCI DSS compliance
5 PCI DSS Violations That Keep Coming Up
-
1Storing sensitive authentication data after authorisation. CVV2/CVC2 codes, magnetic stripe data, and PINs must never be stored post-authorisation — full stop. Auditors find these in application logs, debug databases, and analytics tables far more often than merchants expect. If your payment integration ever touched this data and you have logs, audit them now.
-
2Scoping the CDE too narrowly. Merchants try to shrink their PCI scope by saying systems aren't "in scope." But any system that can communicate with CDE components — your CI/CD pipeline, your admin VPN endpoint, your monitoring tool — is potentially in-scope. If it could affect the security of cardholder data, it's in scope. Underscoping is the number-one way businesses fail audits they thought they would pass.
-
3No MFA for CDE access. PCI DSS v4.0 extended the MFA requirement from remote access to all access into the CDE. Many businesses implemented MFA for VPN but still allow direct SSH with password-only authentication from internal networks. That's a v4.0 violation. Every access path into the CDE needs MFA.
-
4Payment page JavaScript not monitored. Magecart attacks — where malicious scripts are injected into payment pages to skim card data — have compromised thousands of e-commerce sites. PCI DSS v4.0 now explicitly requires monitoring and authorising all scripts on payment pages. Most businesses have no visibility into what JavaScript is running on their checkout. This is a new requirement with high breach risk if ignored.
-
5Annual SAQ completed, then forgotten. PCI compliance is a continuous operating state, not an annual checkbox. Businesses complete their SAQ, file it with their acquirer, and then make infrastructure changes for the next 11 months without reviewing their PCI impact. A single undocumented firewall rule change or a new admin account can move you out of compliance hours after your SAQ was filed.
How ComplytixHub Helps with PCI DSS Compliance
PCI DSS v4.0 has 264 individual requirements across 12 high-level domains. For most businesses, the complexity isn't in understanding the requirements — it's in knowing where you currently stand, prioritising the gaps, and tracking progress systematically.
ComplytixHub makes that structured:
- PCI DSS Gap Assessment: Work through all 12 requirements with 34 targeted controls. Get an instant readiness score and a ranked list of gaps by severity — Critical, High, and Medium.
- Remediation Roadmap: Each identified gap includes concrete remediation steps, estimated effort, and business impact. Know exactly what to fix first and why.
- Audit-Ready Reports: Download a branded HTML audit report showing your assessed controls, gap analysis, and remediation plan — useful for QSA preparation, acquirer submissions, and enterprise prospect due diligence.
- Progress Tracking: Re-assess after implementing changes. Watch your compliance score improve. Surface regression — if a new deployment introduces a gap, find it before your QSA does.
The free risk scan gives you an instant PCI DSS posture snapshot in 60 seconds — no signup, no credit card. For the full 34-control assessment with a downloadable audit report, start a full assessment from $49/month.
Run a Free PCI DSS Compliance Scan in 60 Seconds
See your PCI DSS readiness score and top gaps instantly. No signup required. Know your exposure before your acquirer asks.
Start Free PCI DSS Compliance ScanNot sure where to start? Check your compliance score — free quiz →
🔑 Key Takeaways
- PCI DSS applies to every business that stores, processes, or transmits cardholder data — using Stripe or a third-party processor reduces scope but does not eliminate obligations.
- PCI DSS v4.0 is fully mandatory as of March 2025 — if you were compliant under v3.2.1, review the 64 new requirements to confirm you still are.
- Never store sensitive authentication data (CVV2, magnetic stripe, PIN) post-authorisation — this is an absolute prohibition, not a best practice.
- MFA is now required for all access into the CDE, not just remote access — internal-network SSH with password-only auth is a v4.0 violation.
- Monitor all JavaScript on payment pages in real-time — Magecart-style script injection is now explicitly addressed by PCI DSS v4.0.
- Scope your CDE correctly — systems that can communicate with or impact cardholder data systems are in-scope, even if they don't directly touch card data.
- PCI compliance is a continuous operating state — validate annually, but maintain controls every day between validations.
- Conduct penetration testing annually and after significant infrastructure changes — quarterly vulnerability scans alone are insufficient.