PCI DSS10 min read

PCI DSS Requirements Explained

PCI DSS v4.0 contains 12 high-level requirements organized into six control objectives. This guide breaks down each requirement, explains what it means in practice, and highlights the key sub-requirements that matter most for SaaS and fintech companies.

Understanding these requirements is essential for scoping your compliance program and knowing where to focus your efforts. While the full standard has over 250 specific requirements, this overview will help you grasp the structure and intent.

Key Takeaways

Point Summary
Structure 12 requirements grouped into 6 control objectives
Total requirements ~280 specific requirements, 330+ testing procedures in v4.0
Applicability Not all requirements apply to all organizations (depends on SAQ type)
New in v4.0 Customized approach allows alternative implementations
Focus areas Network security, data protection, access control, monitoring

Control Objective 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

This requirement focuses on protecting your network perimeter and internal network segments through firewalls, routers, and network security controls.

Key sub-requirements:

Requirement What It Means Practical Implementation
1.2 Document and implement network security controls Firewall rules documented, reviewed every 6 months
1.3 Restrict inbound traffic to the CDE Only necessary ports open, deny-all default
1.4 Restrict outbound traffic from the CDE Limit egress to business-justified destinations
1.5 Secure untrusted networks Additional controls for public-facing systems

What this looks like for SaaS:

  • Cloud security groups configured with least-privilege access
  • Network segmentation isolating payment systems
  • VPN or private connectivity for administrative access
  • Web Application Firewall (WAF) protecting public endpoints

Requirement 2: Apply Secure Configurations to All System Components

Default configurations are often insecure. This requirement mandates hardening all systems before deployment.

Key sub-requirements:

Requirement What It Means Practical Implementation
2.2 Develop configuration standards Documented baseline configs for all system types
2.2.1 Single purpose per server Don't mix web server and database on same host
2.2.7 Encrypt non-console administrative access SSH, HTTPS only for management
2.3 Secure wireless environments WPA3 or WPA2 Enterprise for corporate WiFi

Common findings:

  • Default passwords still in use
  • Unnecessary services running
  • Development tools on production systems
  • Missing security patches

Control Objective 2: Protect Account Data

Requirement 3: Protect Stored Account Data

If you store cardholder data, you must protect it. The best strategy: don't store it at all if you can avoid it.

Key sub-requirements:

Requirement What It Means Practical Implementation
3.2 Don't store sensitive authentication data Never store CVV, full track data, or PINs
3.3 Mask PAN when displayed Show only first 6 and last 4 digits
3.4 Render PAN unreadable anywhere stored Encryption, tokenization, truncation, or hashing
3.5 Protect cryptographic keys Key management procedures, split knowledge

Storage methods comparison:

Method Reduces Scope? Complexity Best For
Tokenization Yes Low Most SaaS applications
Encryption No High Systems requiring PAN access
Truncation Partial Low Display/logging purposes
Hashing No Medium Card identification only

Tokenization advantage: When you use Stripe or Adyen tokens instead of storing actual PANs, you significantly reduce your PCI DSS scope.

Requirement 4: Protect Cardholder Data During Transmission

Cardholder data must be encrypted when transmitted over open, public networks.

Key sub-requirements:

Requirement What It Means Practical Implementation
4.1 Use strong cryptography for transmission TLS 1.2+ for all card data transfers
4.2 Never send PAN via unprotected messaging No card numbers in email, SMS, or chat
4.2.1 PAN is secured if sent via messaging Encryption or secure channel required

What counts as "open network":

  • The internet (including APIs and webhooks)
  • Wireless networks
  • Mobile networks
  • Satellite communications

What doesn't count:

  • Properly secured internal networks
  • Private network links (leased lines, MPLS)

Control Objective 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems Against Malware

Malware protection is required on all systems commonly affected by malware.

Key sub-requirements:

Requirement What It Means Practical Implementation
5.2 Deploy anti-malware on all vulnerable systems Endpoint protection on workstations, servers
5.3 Anti-malware is active and cannot be disabled Centralized management, tamper protection
5.4 Anti-phishing mechanisms Email filtering, user awareness training

New in v4.0: Requirement 5.4 specifically addresses phishing attacks, requiring technical controls and training.

Linux/container exceptions: Systems not commonly affected by malware may be excluded with documented risk assessment, but this is increasingly scrutinized.

Requirement 6: Develop and Maintain Secure Systems and Software

This requirement covers secure software development and timely patching.

Key sub-requirements:

Requirement What It Means Practical Implementation
6.2 Maintain software inventory Know all software in your environment
6.3 Apply security patches promptly Critical patches within 1 month
6.4 Protect public-facing web applications WAF or vulnerability assessments
6.5 Secure development practices Secure coding training, code review

Patch timelines:

Severity Timeline
Critical Within 1 month
High Within 3 months
Medium/Low Risk-based timeline

Web application protection options:

  1. Web Application Firewall (WAF) actively monitoring and blocking
  2. Automated vulnerability scanning of web applications
  3. Manual penetration testing (at least annually)

Most organizations combine all three approaches.

Control Objective 4: Implement Strong Access Control Measures

Requirement 7: Restrict Access by Business Need to Know

Access to cardholder data must be limited to personnel whose job requires it.

Key sub-requirements:

Requirement What It Means Practical Implementation
7.2 Define access based on job function Documented access control policy
7.2.2 Assign access based on role Role-based access control (RBAC)
7.3 Deny access by default Explicit grants required

Access review requirements:

  • Review access privileges at least every 6 months
  • Remove access immediately upon termination
  • Document and approve all access changes

Requirement 8: Identify Users and Authenticate Access

Every user must have a unique ID, and strong authentication must be enforced.

Key sub-requirements:

Requirement What It Means Practical Implementation
8.2 Unique user identification No shared accounts
8.3 Strong authentication for users Password requirements or MFA
8.4 MFA for CDE access Required for all administrative access
8.5 MFA for remote access Required for all remote network access
8.6 Manage application and system accounts Documented, regularly reviewed

Password requirements (when MFA is NOT used):

  • Minimum 12 characters (up from 7 in v3.2.1)
  • Include numeric and alphabetic characters
  • Changed at least every 90 days
  • Cannot reuse last 4 passwords

Password requirements (when MFA IS used):

  • Minimum 8 characters
  • Include numeric and alphabetic characters
  • Other requirements may be relaxed per Requirement 8.3.6

v4.0 MFA expansion: MFA is now required for all non-console administrative access into the CDE, not just remote access. This is a significant change from v3.2.1.

Requirement 9: Restrict Physical Access to Cardholder Data

Physical security controls protect systems and media containing cardholder data.

Key sub-requirements:

Requirement What It Means Practical Implementation
9.2 Physical access controls Badges, locks, cameras
9.3 Control visitor access Sign-in, escort, badge distinction
9.4 Protect media containing CHD Secure storage, controlled distribution
9.5 Protect point-of-interaction devices Tamper protection, inspection

For cloud-hosted SaaS: Physical security requirements largely transfer to your cloud provider (AWS, GCP, Azure). Their SOC 2 reports and PCI attestations can support your compliance.

Control Objective 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access

Comprehensive logging enables detection and investigation of security events.

Key sub-requirements:

Requirement What It Means Practical Implementation
10.2 Audit logs capture all access User logins, data access, admin actions
10.3 Logs include required details User ID, timestamp, event type, outcome
10.4 Synchronize clocks NTP configured on all systems
10.5 Secure audit logs Tamper-evident storage, retention
10.7 Detect and respond to security events SIEM, alerting, incident response

Log retention: Minimum 12 months, with at least 3 months immediately available for analysis.

Required log events:

  • User access to cardholder data
  • Administrative actions
  • Access to audit logs
  • Authentication attempts (success and failure)
  • Changes to identification and authentication mechanisms

Requirement 11: Test Security of Systems and Networks Regularly

Regular testing validates that security controls are working effectively.

Key sub-requirements:

Requirement What It Means Practical Implementation
11.2 Wireless access point detection Quarterly scans or monitoring
11.3 Vulnerability scanning Internal and external quarterly scans
11.4 Penetration testing At least annually and after significant changes
11.5 Change detection mechanisms File integrity monitoring on critical files
11.6 Detect unauthorized changes Monitor for tampering of payment pages

Vulnerability scanning requirements:

Scan Type Frequency Who Can Perform
External Quarterly PCI Approved Scanning Vendor (ASV)
Internal Quarterly Internal team or external provider
After significant changes As needed Internal or external

Penetration testing requirements:

  • At least annually
  • After significant infrastructure or application changes
  • Must include network-layer and application-layer tests
  • Must test segmentation controls

Control Objective 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Policies and Programs

This requirement establishes the governance framework for your security program.

Key sub-requirements:

Requirement What It Means Practical Implementation
12.1 Information security policy Documented, reviewed annually
12.2 Acceptable use policies Define proper technology usage
12.3 Risk assessment Formal assessment at least annually
12.4 PCI DSS responsibilities assigned Documented roles for compliance
12.5 Security responsibilities defined Job descriptions, accountability
12.6 Security awareness training Annual training for all personnel
12.8 Manage service providers Contracts, due diligence, monitoring
12.10 Incident response plan Documented plan, tested annually

Service provider management:

  • Written agreement acknowledging PCI DSS responsibilities
  • Annual review of service provider compliance status
  • Maintain list of all service providers with their PCI compliance status

Applying Requirements: SAQ Mapping

Not all requirements apply to every organization. Your applicable SAQ determines your scope:

SAQ Type Approximate Requirements Common Scenario
SAQ A ~27 questions (v4.0) E-commerce with iframe/redirect
SAQ A-EP ~191 questions (v4.0) E-commerce with website integration
SAQ B ~41 requirements Imprint machines or dial-out terminals
SAQ C ~160 requirements Internet-connected payment terminals
SAQ D (Merchant) 330+ questions (v4.0) Merchants not qualifying for other SAQs
SAQ D (SP) 330+ questions (v4.0) Service providers

Key insight: By using tokenization and hosted payment forms (like Stripe Elements), you can qualify for SAQ A, reducing your compliance burden by roughly 90%.

Frequently Asked Questions

Which requirements are hardest to implement?

Requirements 10 (logging) and 11 (testing) typically require the most effort because they demand ongoing operational activities rather than one-time implementations. Logging infrastructure, SIEM configuration, and regular penetration testing require sustained investment.

Can we use a third-party service to meet requirements?

Yes, but you remain responsible for compliance. If you use a cloud provider for infrastructure, their physical security controls (Requirement 9) can support your compliance, but you must verify their compliance status and document the arrangement per Requirement 12.8.

What changed most between v3.2.1 and v4.0?

The biggest changes are: expanded MFA requirements (Requirement 8.4), new phishing protection requirements (5.4), stricter password requirements (8.3), and the introduction of the "customized approach" that allows alternative implementations.

Need help understanding which requirements apply to your specific setup? Talk to our team

Sources

← PreviousWhat is PCI DSS?Next →PCI DSS vs SOC 2: Differences Explained
Back to PCI DSS guides