Introduction
If your business touches payment card data, PCI DSS isn't optional — it's the baseline. The Payment Card Industry Data Security Standard governs how cardholder data must be protected, and failing to meet it carries real consequences: a data breach costs an average of $4.44 million globally, plus contractual penalties from card brands and potential loss of processing privileges.
For fintechs and payments companies, the exposure runs deeper. Regulatory scrutiny under laws like GDPR, damaged customer trust, and strained sponsor bank relationships can follow a single compliance failure.
This guide covers what PCI DSS is, who it applies to, the 12 core requirements, validation methods, and the consequences of non-compliance. The current standard is PCI DSS v4.0.1, released in June 2024.
TLDR
- PCI DSS is a global security standard created by Visa, Mastercard, Amex, Discover, and JCB to protect cardholder data during storage, processing, and transmission
- All businesses that accept, process, or transmit payment card data must comply — regardless of size or transaction volume
- Four merchant levels based on annual transaction volume determine each business's validation requirements
- Twelve requirements across 6 control objectives cover network security, data protection, and incident response
- Non-compliance triggers fines of $5,000–$100,000 per month, higher transaction fees, and potential loss of card processing privileges
What Is PCI DSS Compliance?
PCI DSS (Payment Card Industry Data Security Standard) is a global set of security requirements governing how organizations handle cardholder data (CHD) and sensitive authentication data (SAD).
Established in December 2004, it unified previously separate security programs from five major card brands — Visa, Mastercard, American Express, Discover, and JCB — into a single framework administered by the PCI Security Standards Council (PCI SSC).
What Data Is Protected
Cardholder Data (CHD) includes:
- Primary Account Number (PAN)
- Cardholder name
- Expiration date
- Service code
Sensitive Authentication Data (SAD) includes:
- Full magnetic stripe or chip data
- Card verification values (CVV, CVV2, CVC2, CID)
- PINs and PIN blocks
The critical distinction: Sensitive Authentication Data can never be stored after authorization, even if encrypted. Cardholder data like PANs can be stored with proper encryption and security controls.
Current Version: PCI DSS v4.0.1
PCI DSS v4.0.1 was published in June 2024 as a limited revision to v4.0, which was the most substantial structural revision since the standard's founding. Version 4.0.1 made minor clarifying revisions addressing formatting, typographical errors, and requirement intent — with no new or deleted requirements.
Version 4.0 introduced three meaningful shifts from prior versions:
- Expanded MFA requirements — broader coverage across more system access points
- E-skimming protections — new controls targeting payment page script attacks
- Flexible compliance demonstration — more options for showing how security objectives are met
Who Needs to Be PCI DSS Compliant?
Any entity that stores, processes, or transmits cardholder data — or that can impact the security of a cardholder data environment — must comply. This includes:
- Merchants — any business accepting card payments for goods or services
- Payment processors — companies processing transactions on behalf of merchants
- Acquiring banks — financial institutions maintaining merchant relationships
- Payment gateways and facilitators — platforms routing payment transactions
- Independent Sales Organizations (ISOs) — intermediaries that sell payment processing services to merchants
- SaaS providers — software platforms that touch or can access card data
- Third-party service providers — any vendor that can affect CDE security
Compliance applies regardless of company size, transaction volume, or payment channel — in-person, online, or mail order/telephone order (MOTO).
Common Misconception: Third-Party Processors
Using a PCI-compliant processor like Stripe, Square, or PayPal reduces but does not eliminate your compliance obligations. The merchant remains responsible for ensuring their own systems and third-party relationships do not create vulnerabilities. Not storing card data reduces scope, but merchants must validate compliance through the appropriate Self-Assessment Questionnaire (SAQ) based on their integration method.
Why Fintechs Face Expanding PCI Scope
As fintechs scale, PCI compliance scope expands quickly. Each new capability that touches cardholder data — mobile wallets, embedded checkout, card issuing, or new banking rail integrations — can pull additional systems into scope and trigger a reassessment of your compliance level or validation method.
Growth moves fast. Compliance scope needs to keep pace.
PCI DSS Compliance Levels Explained
Not every business faces the same compliance burden. Your merchant level determines which validation requirements apply — and knowing where you fall is the first step toward building a scoped, manageable compliance program.
Four Merchant Levels
Compliance levels are primarily based on annual transaction volume, with slight variations by card brand. Merchants must confirm their level with their acquiring bank.
| Level | Annual Transaction Volume | Validation Requirements |
|---|---|---|
| Level 1 | Over 6 million transactions (or following a breach) | Annual on-site audit (ROC) by QSA; Quarterly ASV scans; AOC |
| Level 2 | 1–6 million transactions | Annual SAQ; Quarterly ASV scans; AOC |
| Level 3 | 20,000–1 million e-commerce transactions | Annual SAQ; Quarterly ASV scans; AOC |
| Level 4 | Under 20,000 e-commerce or up to 1 million total | Annual SAQ (recommended); Quarterly ASV scans (if applicable); AOC |
Service providers follow a separate two-tier structure: Level 1 (over 300,000 transactions annually) requires a full ROC; Level 2 (under 300,000 transactions) may complete an SAQ.
Key Terminology
- QSA (Qualified Security Assessor) — PCI SSC-certified third-party auditor authorized to conduct compliance assessments
- ISA (Internal Security Assessor) — Certified internal employee authorized to conduct self-assessments
- SAQ (Self-Assessment Questionnaire) — Self-validation tool for smaller merchants, with multiple types (A, A-EP, B, C, D, etc.) based on integration method
- ROC (Report on Compliance) — Formal audit report documenting compliance status
- AOC (Attestation of Compliance) — Signed declaration of compliant status
SAQ Types by Integration Method
Your integration method determines which SAQ applies:
- SAQ A — Fully outsourced via hosted payment pages or iframes (simplest, ~20 controls)
- SAQ A-EP — Partially outsourced with scripts loading on merchant website
- SAQ D — Direct API integrations or any storage of card data (most complex, 300+ controls)
- SAQ P2PE — PCI-validated Point-to-Point Encryption solution
- SAQ C-VT — Manual entry via virtual terminal only
Choosing a lower-scope integration path — such as a fully hosted checkout page — is one of the most effective ways to reduce your SAQ burden before compliance work even begins.
The 12 PCI DSS Requirements
The 12 requirements form an integrated security framework organized under 6 control objectives: network security, data protection, vulnerability management, access control, monitoring, and security policy. Every requirement applies to any system component that stores, processes, or transmits cardholder data — or that can affect its security.
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain network security controls
- Deploy and continuously test firewalls protecting the cardholder data environment (CDE)
- Restrict inbound and outbound traffic to only necessary connections
- Document and maintain network diagrams
Requirement 2: Apply secure configurations to all system components
- Change default passwords on all network devices and software
- Disable unnecessary services and protocols
- Harden configurations to minimize attack surface
- Implement configuration standards for all systems
Protect Account Data
Requirement 3: Protect stored account data
- Encrypt stored PANs using strong cryptography
- Never store sensitive authentication data post-authorization (CVV, PIN cannot be stored even if encrypted)
- Minimize data retention — store only what's needed
- Implement data masking where needed (display only last four digits)
Requirement 4: Protect cardholder data during transmission
- Use strong cryptography (TLS 1.2 or higher) for data in transit over open, public networks
- Never send full card data via email or unencrypted channels
- Ensure wireless transmissions are encrypted
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems from malicious software
- Deploy and regularly update anti-malware on all systems
- Address e-skimming risks by monitoring scripts on payment pages (new emphasis in v4.0)
- Ensure anti-malware mechanisms are actively running and generating logs
Requirement 6: Develop and maintain secure systems and software
- Apply security patches promptly (critical patches within one month)
- Follow secure coding practices for payment applications
- Conduct code reviews and web application security testing
- Maintain an inventory of system components and software
Implement Strong Access Control Measures
Requirement 7: Restrict access by business need to know
- Limit system and cardholder data access to only those with documented business need
- Implement role-based access controls (RBAC)
- Review access privileges regularly
Requirement 8: Identify users and authenticate access
- Assign unique IDs to all users with system access
- Implement multi-factor authentication (MFA) for all access to the CDE (significantly expanded in v4.0)
- Prohibit shared credentials and generic accounts
- Enforce strong password policies
Requirement 9: Restrict physical access to cardholder data
- Secure physical access to cardholder data and systems
- Protect point-of-interaction (POI) terminals from tampering
- Maintain visitor access logs and badge systems
- Destroy physical media containing cardholder data when no longer needed
Regularly Monitor and Test Networks
Requirement 10: Log and monitor all access
- Maintain detailed audit logs of all access to system components and cardholder data
- Retain logs for at least 12 months, with 3 months immediately available
- Detect and alert on anomalies
- Protect log data from alteration
Requirement 11: Test security of systems and networks regularly
- Conduct quarterly external vulnerability scans by an Approved Scanning Vendor (ASV)
- Perform internal authenticated scans regularly
- Conduct annual penetration testing
- Monitor for unauthorized wireless access points
- Deploy file-integrity monitoring on critical systems
Maintain an Information Security Policy
Requirement 12: Support information security with organizational policies
- Maintain a formal information security policy
- Conduct annual security awareness training for all personnel
- Manage third-party service provider risks through vendor due diligence
- Maintain and test an incident response plan
For fintechs and payments companies, Requirement 12 carries particular weight: regulators increasingly expect your vendor due diligence process and incident response plan to align with — not operate separately from — your broader financial crime compliance program.
How to Achieve and Validate PCI DSS Compliance
Step 1: Define Your Scope
Identify all system components, networks, and personnel that store, process, or transmit cardholder data, or that can affect CDE security. Create a cardholder data flow diagram mapping where card data enters, moves through, and exits your environment.
Scope reduction is often the most effective compliance strategy. Using tokenization or outsourcing card data handling to a PCI-validated processor dramatically simplifies obligations.
Step 2: Assess Current Security Posture
Conduct a gap analysis against the 12 PCI DSS requirements to identify deficiencies.
- Level 1 merchants and service providers: Engage a Qualified Security Assessor (QSA)
- Smaller organizations: Complete the appropriate SAQ type based on integration method
SAQ A (fully hosted checkout) covers ~20 controls, while SAQ D (direct integrations) covers 300+ controls.
Step 3: Remediate Gaps and Implement Controls
Address identified deficiencies by implementing required security controls across:
- Network security (firewalls, segmentation)
- Encryption (data at rest and in transit)
- Access management (MFA, role-based controls)
- Vulnerability management (patching, scanning)
- Policy and governance
Remediation requires cross-functional coordination across IT, security, operations, and compliance teams. Fintechs and payments companies navigating rapid growth or regulatory scrutiny often benefit from external advisory support to build audit-ready programs — Pillars FinCrime Advisory specializes in exactly this kind of structured, scalable compliance buildout.
Step 4: Validate and Report Compliance
Once controls are implemented, formal validation confirms your program meets PCI DSS requirements. The process varies by merchant level:
- Level 1 merchants: Require an on-site assessment by a QSA, resulting in a Report on Compliance (ROC)
- Level 2–4 merchants: Complete the applicable SAQ and may require an Attestation of Compliance (AOC)
- All merchants: Must use an Approved Scanning Vendor (ASV) for quarterly external vulnerability scans
Submit your AOC, SAQ, and scan reports to your acquiring bank or payment brand as required. Validation is annual — calendar it as a recurring obligation, not a one-time event.