The 12 PCI DSS Requirements

PCI DSS is organized into six goals containing 12 requirements. Each requirement decomposes into detailed sub-requirements with defined testing procedures — roughly 250 sub-requirements in v4.x, though how many apply to you depends on your validation type. Understanding the structure helps you plan your compliance program, allocate budget, and predict where an assessor will push hardest.

Two framing points before the walkthrough. First, in v4.x every requirement family begins with sub-requirements for governance: documented policies, defined roles and responsibilities, and — new since v4.0 — targeted risk analyses where the standard lets you set your own frequencies. Assessors check the paperwork as rigorously as the technology. Second, the requirements apply to your cardholder data environment and connected systems, not necessarily your whole company — which is why scoping and segmentation (covered later in this series) come before implementation.

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

Version 4.0 renamed this from "firewalls" to "network security controls" (NSCs) to cover cloud security groups, virtual firewalls, and container network policies alongside physical appliances. In practice you must:

• Define and document rules governing traffic between trusted and untrusted networks, and into and out of the CDE.
• Restrict inbound traffic to the CDE to only what is necessary, and deny everything else by default.
• Prevent direct public access between the internet and any system storing cardholder data.
• Review NSC rule sets at least every six months and remove stale rules.
• Maintain current network and data flow diagrams — assessors ask for these on day one, and outdated diagrams are among the most common findings.

Practical translation for cloud-native teams: your VPC design, security groups, and NACLs are your Requirement 1 evidence. Infrastructure-as-code with peer-reviewed changes makes the six-month rule review far easier to demonstrate.

Requirement 2: Apply Secure Configurations to All System Components

Vendor defaults are public knowledge. This requirement demands changing default passwords and accounts, hardening configurations against an accepted standard (CIS Benchmarks are the usual choice), removing unnecessary services and protocols, and running only one primary function per server where functions have different security levels. Wireless environments connected to the CDE get specific attention: default SNMP strings, default admin passwords, and default encryption keys must all change.

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data

The core discipline is don't store it unless you must. When you do store cardholder data:

• Keep storage to the minimum required, with documented retention and a quarterly (or risk-defined) purge process.
• Render the PAN unreadable anywhere it is stored — strong encryption, truncation, tokenization, or keyed cryptographic hashing. Plain (unkeyed) hashes of PANs are no longer sufficient under v4.x; hashes must be keyed.
• Mask PAN when displayed (at most the first 6 and last 4 digits, and only for roles with a need).
• Never store sensitive authentication data (full track, CVV, PIN) after authorization; if SAD is held pre-authorization, encrypt it.
• Manage cryptographic keys with a full lifecycle: generation, distribution, storage, rotation, retirement, and split knowledge/dual control for manual key operations. Disk-level or partition-level encryption alone no longer satisfies the PAN protection requirement for non-removable media — you need file, column, or field-level protection (or tokenization).

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Encrypt PAN over open, public networks with strong protocols — in practice TLS 1.2 or higher with strong cipher suites. Maintain an inventory of trusted keys and certificates, confirm certificates are valid and not expired, and never send unprotected PANs via end-user messaging (email, chat, SMS). The certificate inventory is a v4.0 addition that surprises teams: you need a documented list of the certs protecting PAN in transit.

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

Deploy anti-malware on all system components except those documented (via periodic evaluation) as not at risk. Keep it current, actively running, and generating audit logs. v4.x additions: a targeted risk analysis to define scan frequencies, controls for removable media, and — mandatory since March 2025 — anti-phishing mechanisms to detect and protect personnel against phishing attacks (DMARC, link scanning, and similar controls).

Requirement 6: Develop and Maintain Secure Systems and Software

This requirement covers both patching and secure development:

• Identify and rank vulnerabilities; patch critical/high issues within one month and others within a risk-defined window.
• Follow secure SDLC practices: developer security training, code review before release, separation of dev/test from production, and no live PANs in test environments.
• Protect public-facing web applications either by regular vulnerability assessment or — the practical norm since March 2025 — an automated technical solution (a WAF or equivalent) that actively blocks attacks, not just alerts.
• Manage all payment page scripts: inventory each script on pages that capture card data, authorize it, and assure its integrity. This (6.4.3, with its monitoring twin 11.6.1) is the standard's answer to Magecart-style skimming and is one of the heaviest new lifts for e-commerce merchants — including many SAQ A merchants.

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict Access by Business Need to Know

Least privilege, formally. Define access needs per role, grant access based on job classification, require documented approval, and review all user accounts and privileges at least every six months — a v4.x-mandated cadence that many organizations previously did annually or not at all.

Requirement 8: Identify Users and Authenticate Access

The authentication requirement grew substantially in v4.x:

• Unique IDs for every user; shared accounts only for documented exceptions.
• Passwords of at least 12 characters (up from 8) containing letters and numbers, changed every 90 days unless you continuously evaluate account security posture or use MFA for that access.
• MFA for all access into the CDE — not just remote access and not just administrators. Console access to CDE systems by any user now requires MFA, and MFA systems must be replay-resistant and not bypassable except by documented, time-limited exception.
• Lockout after at most 10 failed attempts; 15-minute session idle timeout re-authentication.
• Interactive login to system/application accounts prevented or tightly controlled, with those account passwords rotated on a risk-defined schedule.

If you budget for one big technical project in a v4.x uplift, the expanded MFA footprint is usually it.

Requirement 9: Restrict Physical Access to Cardholder Data

Facility entry controls, badge and visitor management, distinguishing personnel from visitors, securing media (classification, secure storage, destruction when no longer needed), and — critical for retail — point-of-interaction (POI) device controls: maintain a device inventory, periodically inspect terminals for tampering or skimmers, and train staff to spot substitution attempts. For cloud-hosted CDEs, most of Requirement 9 is inherited from your IaaS provider's AOC, but your offices still count if card data is handled there (think call centers).

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Capture audit logs for all access to cardholder data, all administrative actions, authentication events, and log-integrity events. Synchronize clocks (NTP against reliable sources), protect logs from tampering, retain logs for 12 months with 3 months immediately available, and review logs daily — with automated mechanisms required for daily review since March 2025. Practically, that means a SIEM or log platform with alerting; manual daily log reading does not scale and no longer satisfies the requirement for most environments. You also need processes to detect and respond to failures of critical security control systems.

Requirement 11: Test Security of Systems and Networks Regularly

The testing cadence is prescriptive and worth internalizing:

Add change-detection/file-integrity monitoring on critical files and intrusion detection/prevention at the CDE perimeter and critical points.

Requirement 12: Support Information Security with Organizational Policies and Programs

The governance umbrella: an information security policy reviewed annually, an executive-assigned responsibility for security, an annual formal scope confirmation exercise (every six months for service providers), security awareness training including phishing and acceptable use, personnel screening, a third-party service provider (TPSP) management program with AOC tracking and responsibility matrices, and a tested incident response plan that specifically addresses cardholder data incidents.

Prioritizing Implementation

Not all requirements carry equal breach-prevention weight. A pragmatic sequencing for a team starting from scratch:

1. Scope reduction first (not a numbered requirement, but the highest-leverage move): outsource card capture, tokenize, segment.
2. Requirements 3 and 4 — if stored and transmitted data is protected and SAD is never retained, a breach yields little of value.
3. Requirements 7 and 8 — access control and MFA close the most common intrusion paths (credential theft).
4. Requirements 1, 2, and 6 — hardened, patched, well-bounded systems.
5. Requirements 10 and 11 — you cannot prove or detect anything without logging and testing.
6. Requirements 5, 9, and 12 — necessary, but usually faster to stand up.

Implementation Checklist

• Current network and cardholder data flow diagrams exist and match reality
• Default-deny NSC rules into/out of the CDE; rule review scheduled every 6 months
• Hardening standard (e.g., CIS) adopted and applied to all in-scope components
• Data retention policy defined; scheduled purge of PAN beyond retention; SAD storage confirmed absent
• PAN unreadable at rest (tokenization/encryption at field level) and masked on display
• TLS 1.2+ everywhere PAN transits open networks; certificate inventory maintained
• Anti-malware deployed with logging; anti-phishing controls active
• Patch SLAs defined and met; WAF actively blocking on public payment applications
• Payment page script inventory, authorization, and integrity controls in place (6.4.3/11.6.1)
• MFA enforced for all CDE access and all remote access; 12-character password policy
• Access reviews every 6 months with documented outcomes
• Centralized logging, 12-month retention, automated daily review and alerting
• Quarterly internal (authenticated) and external ASV scans passing; annual pen test scheduled
• POI device inventory and inspection program (if card-present)
• Security policy, training, TPSP tracking, and tested incident response plan in place

Frequently Asked Questions

Do all 12 requirements apply to every organization?

The 12 requirements apply to every in-scope environment, but the sub-requirements you must validate depend on your SAQ type. SAQ A merchants answer roughly 30 questions; SAQ D covers the full set. A QSA-assessed entity tests everything applicable to its environment, with "not applicable" justifications documented per control.

Which requirements cause the most audit findings?

Consistently: Requirement 10 (incomplete log coverage and no real daily review), Requirement 8 (MFA gaps and service accounts with interactive login), Requirement 11 (missed quarterly scans — one missed quarter breaks the year), Requirement 1 (stale diagrams and firewall rules), and since v4.0, Requirement 6.4.3 payment page script inventories that simply don't exist.

What changed most between v3.2.1 and v4.x in the 12 requirements?

The requirement numbering and goals stayed stable, but v4.x added: MFA for all CDE access, 12-character passwords, authenticated internal scans, automated log review, payment page script management and tamper detection, anti-phishing controls, mandatory WAF-style blocking for public web apps, keyed hashes for PAN, and targeted risk analyses to justify self-defined frequencies. The dedicated v4 lesson at the end of this series covers the transition in detail.

Can compensating controls cover a requirement we can't meet?

Yes — where a legitimate technical or business constraint prevents meeting a requirement as stated, you can document a compensating control that meets the intent and rigor of the original, goes above and beyond other requirements, and is validated annually. v4.x also offers the customized approach as a more formal alternative for mature organizations. Neither is a shortcut; both require more documentation than just meeting the requirement.

Do these requirements apply to our corporate network too?

Only if it is in scope — meaning it stores, processes, or transmits cardholder data, is connected to the CDE, or can impact its security. This is exactly why segmentation matters, and why the annual scoping exercise in Requirement 12 exists: scope creep quietly pulls corporate systems into the assessment.

How do we handle requirements our cloud provider or payment processor covers?

Through a shared responsibility matrix. Collect each provider's AOC, document which requirements they cover, which you cover, and which are shared. Requirement 12.8/12.9 makes managing this documentation an explicit obligation for both sides.

In the next lesson, we will cover Self-Assessment Questionnaires.

Meeting the 12 requirements is far easier with the right tooling for scanning, logging, and evidence collection. AuditXYZ helps you compare compliance automation platforms and auditors so you can see which tools map controls to PCI DSS v4.x out of the box.