What Is PCI DSS and Why Is It Mandatory?
PCI DSS — the Payment Card Industry Data Security Standard — is a global standard maintained by the PCI Security Standards Council (an industry body founded by Visa, Mastercard, American Express, Discover, and JCB). It defines the security controls that any organization handling cardholder data must implement. Compliance is not government-regulated — it's contractually required by the card brands and your acquiring bank. Falling out of compliance can lead to fines (typically $5K–$100K per month), forced upgrades to a higher merchant level, increased transaction fees, suspension of your ability to process card payments, and significant reputational damage if a breach occurs while non-compliant. The current version is PCI DSS v4.0.1 — v3.2.1 was officially retired on March 31, 2024, and future-dated v4.0 requirements continue phasing in through March 31, 2025.
Who Needs PCI DSS Compliance?
PCI DSS applies to any entity in the cardholder data flow. The most common cases:
Anyone accepting card payments online — even if you outsource payment to Stripe, Shopify, or similar (you're still responsible for SAQ A or A-EP).
Card-present merchants using physical terminals, integrated POS systems, or virtual terminals.
Any organization that stores, processes, or transmits cardholder data on behalf of others — including hosting, MSSPs, dev shops handling integrations, gateways.
Payment platforms, billing tools, subscription managers, marketplaces — almost always Level 1 or Level 2 service providers with significant scope.
Issuers, acquirers, and processors face the most stringent requirements alongside parallel banking regulation.
Any operation that takes card numbers verbally or processes refunds/payments — often overlooked, with significant scope when not architected for compliance.
The trap most organizations fall into: assuming "we use Stripe so we don't need PCI DSS." You still need to attest — typically with SAQ A or SAQ A-EP. Outsourcing reduces scope dramatically, but it does not eliminate the obligation to demonstrate compliance.
PCI DSS Merchant Levels Explained
Your merchant level is determined by your annual transaction volume per card brand. Each level has different validation requirements — knowing yours is the first step in scoping a compliance program.
| Level | Annual Transactions | Validation Required |
|---|---|---|
| Level 1 | Over 6 million per year (or any merchant who has had a breach) | Annual onsite assessment by a QSA, producing a Report on Compliance (ROC) + Attestation of Compliance (AOC) + quarterly ASV scans. |
| Level 2 | 1 million to 6 million per year | Annual SAQ + AOC + quarterly ASV scans. May require QSA-led validation for some card brands. |
| Level 3 | 20,000 to 1 million e-commerce transactions per year | Annual SAQ + AOC + quarterly ASV scans. |
| Level 4 | Fewer than 20,000 e-commerce or up to 1 million in other channels | Annual SAQ + AOC. Quarterly ASV scans typically required by acquiring bank. |
Service providers have a separate scheme: Level 1 service providers process more than 300,000 transactions annually and require a QSA-led ROC. Level 2 service providers (under 300,000) typically complete SAQ-D for Service Providers. Service providers face stricter requirements than merchants in several areas — including 6-monthly segmentation testing.
The 12 PCI DSS Requirements
PCI DSS v4.0 contains 12 high-level requirements organized into 6 control objectives. Each requirement breaks down into dozens of specific sub-requirements.
Network Security Controls
Install and maintain firewalls and other network security devices. Define rulesets, inbound/outbound restrictions.
Secure Configurations
Apply hardened baseline configs to all system components. No vendor defaults for passwords, services, or settings.
Protect Stored Account Data
Strong cryptography for stored cardholder data. PAN truncated, masked, or tokenized wherever possible.
Encrypt Transmission
Strong cryptography (TLS 1.2+) over open and public networks. Trusted certificates only.
Anti-Malware
Endpoint protection against malware, regular signature updates, periodic evaluation of evolving threats.
Secure Software Development
Secure development lifecycle, code review, vulnerability remediation. Custom and bespoke code requirements in v4.0.
Restrict Access by Need-to-Know
Role-based access control, default-deny, documented access rights tied to job function.
Identify and Authenticate
Unique IDs for all users. MFA across the CDE for all users (v4.0 expansion). Strong password policy.
Restrict Physical Access
Physical security controls for facilities, media, devices. Visitor logs, secure disposal.
Log and Monitor
Comprehensive logging, daily log review, SIEM, log retention 12+ months. Alerting on critical events.
Test Security Regularly
Quarterly ASV scans, internal vuln scans, annual penetration testing, segmentation testing, payment page integrity (v4.0).
Information Security Policy
Overall information security policy, risk assessments, incident response plan, security awareness training.
SAQ vs ROC — Which Validation Path?
The validation path depends on your merchant level and how you handle cardholder data. There are 9 SAQ types — picking the wrong one creates real audit risk.
| SAQ | Who Uses It |
|---|---|
| SAQ A | E-commerce merchants who fully outsource cardholder data handling — e.g. redirect/iframe to Stripe Checkout, PayPal Hosted Pages. |
| SAQ A-EP | E-commerce with partial outsourcing (e.g. Stripe Elements, Adyen direct integration) where the merchant page can affect security of the payment. |
| SAQ B | Merchants using imprint machines or standalone dial-out payment terminals with no electronic storage. |
| SAQ B-IP | Merchants using IP-connected standalone payment terminals (no electronic storage). |
| SAQ C-VT | Merchants using web-based virtual terminals on a dedicated, isolated computer. |
| SAQ C | Merchants with payment application systems connected to the internet — but not storing cardholder data. |
| SAQ D — Merchant | All other merchants. The most comprehensive SAQ. If your environment doesn't fit one of the simpler types, you complete SAQ D. |
| SAQ D — Service Provider | Service providers eligible for SAQ validation (under 300K transactions). Even more comprehensive than SAQ D Merchant. |
| SAQ P2PE | Merchants using a PCI-listed Point-to-Point Encryption (P2PE) solution. Significantly reduces scope. |
A ROC (Report on Compliance) is required for all Level 1 merchants and Level 1 service providers. It's a comprehensive onsite assessment performed by a Qualified Security Assessor (QSA), typically running 1–3 weeks of fieldwork plus several weeks of report drafting. SecurityWall does not issue ROCs ourselves — that requires a QSA firm — but we prepare you for the ROC engagement and coordinate directly with your chosen QSA throughout the assessment.
PCI DSS v4.0 — What Changed
v4.0 is the biggest update to PCI DSS in a decade. v3.2.1 was retired on March 31, 2024, and future-dated v4.0 requirements continue to come into force through March 31, 2025. The most operationally significant changes:
MFA now required for ALL users with access to the cardholder data environment (CDE), not just administrative access. This applies to engineers, support staff, and anyone with logical access to in-scope systems.
Organizations can now meet a control's objective using their own approach (with documented Targeted Risk Analysis and QSA review) instead of the prescribed Defined Approach. Powerful for mature security programs but adds documentation overhead.
Minimum password length increased to 12 characters with complexity requirements. System and application accounts have stricter management controls.
Targets Magecart-style attacks. Requires inventory and integrity monitoring of all scripts loaded on payment pages, with tamper detection. Operationally significant for any e-commerce site using third-party scripts on the checkout page.
Required for many controls where v4.0 allows organization-defined timing or scope. TRA must be documented, approved, reviewed annually.
Internal scans must now be performed with credentials to detect issues that anonymous scans miss.
Service providers must perform segmentation testing every 6 months (was annually). Merchants remain annual. Critical for any architecture relying on segmentation to reduce CDE scope.
Our 5-Step PCI DSS Process
We deliver PCI DSS programs for merchants, service providers, and platforms across e-commerce, fintech, and SaaS. The process is built around scope reduction and audit-ready evidence collection from day one.
Scope & Gap Assessment
2–4 weeksWe map every cardholder data flow, define the CDE, identify all connected and impactful systems, and score every applicable PCI DSS requirement against your current state. The output is a control-by-control gap report and an explicit SAQ-type recommendation (or ROC scoping if Level 1).
Scope Reduction & Roadmap
1–3 weeksBefore remediation, we look for scope reduction opportunities — tokenization, hosted payment pages, P2PE, segmentation. Reducing the CDE often saves more cost than remediating its gaps. The roadmap then prioritises remaining gaps by risk and audit blocker.
Implementation
3–9 monthsWe work alongside your team to deploy required controls — segmentation, MFA across the CDE, logging and monitoring, secure config baselines, payment-page integrity monitoring (v4.0 Req 6.4.3 / 11.6.1), policies, and evidence collection automation.
Penetration Testing & Validation
2–4 weeksRequired external and internal penetration testing by our OSCP-led team (Req 11.4), segmentation testing (Req 11.4.5), authenticated internal vulnerability scans, and ASV scan coordination. Findings remediated and re-tested. The pentest report becomes formal PCI DSS evidence.
SAQ Submission or ROC Engagement
1–8 weeksFor SAQ paths, we complete the questionnaire and Attestation of Compliance with you and submit to your acquiring bank. For Level 1 ROC engagements, we prepare evidence packs, conduct mock audits, and coordinate directly with your chosen QSA throughout fieldwork.
Why SecurityWall for PCI DSS
PCI DSS is the rare compliance framework that explicitly mandates penetration testing — and the quality of that testing matters. A PCI pentest report from a generic compliance shop often won't hold up against scrutiny from a real attacker, or even a competent QSA. We build the security program AND test it ourselves.
Required pen testing in-house
Our team holds OSCP, OSWE, CISSP, and CREST certifications. Req 11.4 external and internal penetration testing, segmentation testing, and authenticated internal vulnerability scans — all delivered by the same team that built your controls. No outsourcing.
Scope reduction expertise
We've designed payment architectures across e-commerce, marketplaces, SaaS billing, and fintech platforms. Often the biggest cost savings come from reducing CDE scope before remediation begins — not after.
v4.0 expertise
We have run organizations through the v3.2.1 → v4.0 transition. We know which future-dated requirements bite hardest, how to interpret the customized approach, and how to operationalise payment-page integrity monitoring.
Audit-ready deliverables
Every policy, procedure, and report we produce is structured as PCI DSS evidence. We know what QSAs accept, what they push back on, and what auditors flag. ROC engagement support included.
vCISO and ongoing maintenance
PCI DSS is annual — and v4.0 introduces new continuous controls like payment-page integrity monitoring. We provide vCISO support and ongoing advisory to keep you compliant between assessments.
PCI DSS Alongside SOC 2 and ISO 27001
Most organizations needing PCI DSS also need SOC 2 (for enterprise customers) or ISO 27001 (for international markets). The control overlap is significant — many PCI DSS controls map directly to SOC 2 Common Criteria and ISO 27001 Annex A. Running them as separate programs duplicates effort. We deliver SOC 2, ISO 27001, and PCI DSS in a unified compliance program where each shared control is implemented and evidenced once across all three frameworks.
