The 12 Core PCI DSS Compliance Requirements
The foundation of PCI DSS lies in its 12 core requirements. It’s a set of actionable controls designed to protect cardholder data and strengthen payment security.
Every organization that stores, processes, or transmits card information must follow these requirements to meet PCI DSS v4.0.1 standards.
Each control supports a specific security objective that helps prevent breaches, detect suspicious activity, and ensure consistent protection across payment environments.
The PCI DSS 12 Requirements Explained
1. Install and Maintain Network Security Controls
Network security controls, including firewalls, safeguard your cardholder data environment by managing network traffic between trusted and untrusted networks. They block unauthorized access while allowing legitimate business communication.
2. Apply Secure Configurations to All System Components
Default passwords and vendor settings are easy entry points for attackers. Replace them before deployment and harden system configurations to meet security best practices.
3. Protect Stored Account Data
Keep account data storage to a strict minimum. Use strong cryptography and key management, and never retain sensitive authentication data after authorization.
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Use robust encryption protocols such as TLS 1.2 or higher to protect data in transit. This prevents interception and tampering as cardholder data moves through public or unsecured networks.
5. Protect All Systems and Networks from Malicious Software
Implement and update anti-malware tools to detect, contain, and remove threats. Regular scans and automated updates help prevent infection and reduce the risk of data exposure.
6. Develop and Maintain Secure Systems and Software
Keep systems updated with current patches and incorporate security checks throughout the software development lifecycle. Regular vulnerability testing helps stop issues before they’re exploited.
7. Restrict Access to System Components and Cardholder Data by Business Need to Know
Limit access strictly to users who need it to perform their roles. Use role-based access control to minimize exposure and enforce accountability.
8. Identify Users and Authenticate Access to System Components
Assign a unique ID to every user and enforce multi-factor authentication (MFA) for all system access. This ensures accountability and protects critical environments from unauthorized use.
9. Restrict Physical Access to Cardholder Data
Control who can physically reach devices, systems, or media that handle payment data. Use entry controls, visitor logs, and surveillance to protect these areas.
10. Log and Monitor All Access to System Components and Cardholder Data
Enable centralized logging and monitor activity continuously. A timely review of logs helps detect unauthorized access, policy violations, or security incidents early.
11. Test Security of Systems and Networks Regularly
Run vulnerability scans, penetration tests, and intrusion detection assessments on a consistent schedule. Testing validates that your controls are effective and operating as intended.
12. Support Information Security with Organizational Policies and Programs
Maintain a documented, enforceable information security program. It should define roles, responsibilities, and procedures that keep your entire organization aligned with PCI DSS objectives.
How Requirements Map to Key Security Objectives
|
PCI DSS Security Objective / Goal
|
PCI DSS v4.0.1 Requirements
|
What this achieves
|
|---|---|---|
|
Build and Maintain a Secure Network and Systems
|
1. Install and Maintain Network Security Controls; 2. Apply Secure Configurations to All System Components
|
Establishes a hardened network and system baseline that blocks unauthorized access and misconfigurations.
|
|
Protect Account Data
|
3. Protect Stored Account Data; 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
|
Keeps cardholder and other account data confidential at rest and in transit using strong cryptography and strict retention.
|
|
Maintain a Vulnerability Management Program
|
5. Protect All Systems and Networks from Malicious Software; 6. Develop and Maintain Secure Systems and Software
|
Reduces exposure by preventing malware, patching quickly, and building security into the SDLC.
|
|
Implement Strong Access Control Measures
|
7. Restrict Access by Business Need to Know; 8. Identify Users and Authenticate Access; 9. Restrict Physical Access to Cardholder Data
|
Ensures only authorized users and personnel can reach sensitive systems and data, with strong authentication and physical safeguards.
|
|
Regularly Monitor and Test Systems and Networks
|
10. Log and Monitor All Access to System Components and Cardholder Data; 11. Test Security of Systems and Networks Regularly
|
Provides continuous visibility and validation that controls work as intended.
|
|
Maintain an Information Security Policy and Program
|
12. Support Information Security with Organizational Policies and Programs
|
Defines governance, roles, and ongoing responsibilities for PCI DSS compliance.
|
Determining Your PCI DSS Compliance Level
Every organization handling cardholder data must validate PCI DSS compliance. The method of validation depends largely on your merchant level, determined by annual transaction volume and channel mix.
Merchant Levels (typical thresholds):
|
Merchant Level
|
Annual Transaction Volume
|
Validation Requirement
|
|---|---|---|
|
Level 1
|
More than 6 million transactions per year (all channels)
|
Annual Report on Compliance (RoC) by a Qualified Security Assessor (QSA) or certified internal auditor, plus quarterly ASV scans.
|
|
Level 2
|
1 million – 6 million transactions per year
|
Annual Self-Assessment Questionnaire (SAQ) or RoC if required by your acquiring bank, plus quarterly ASV scans.
|
|
Level 3
|
20,000 – 1 million eCommerce transactions per year
|
Annual SAQ (type depends on environment) and quarterly ASV scans.
|
|
Level 4
|
Fewer than 20,000 eCommerce transactions per year or up to 1 million total transactions
|
Annual SAQ and quarterly ASV scans, with specific validation requirements determined by the acquiring bank.
|
Note: Payment brands and acquirers may adjust levels or validation requirements based on risk factors, processing methods, or breach history.
Validation Methods: RoC vs. SAQ
Report on Compliance (RoC):
A comprehensive, independent assessment performed by a Qualified Security Assessor (QSA) or trained internal auditor. Required for Level 1 merchants and service providers, or for any business designated as high-risk.
Self-Assessment Questionnaire (SAQ):
A self-validation used by Levels 2–4. The SAQ type varies depending on how cardholder data is processed or stored (e.g., SAQ A for fully outsourced eCommerce, SAQ D for complex environments).
Both validation methods aim to confirm that your controls meet PCI DSS requirements and that your cardholder data environment is properly secured.
What Counts as Cardholder Data (CHD) Under PCI DSS
What is Cardholder Data (CHD)?
Cardholder Data (CHD) identifies a payment card account. The defining element is the Primary Account Number (PAN) — a 16 digits number embossed or printed on the card.
If the PAN is present, the data falls within the PCI DSS scope. CHD may also include any combination of the following elements when stored, processed, or transmitted alongside the PAN:
- Cardholder name
- Expiration date
- Service code
If these elements appear without the PAN, they’re not classified as CHD under PCI DSS.
Examples of CHD in practice:
- A POS database storing the full PAN and expiration date
- An eCommerce system transmitting PAN and cardholder name through a payment API
- A receipt showing the last four digits of a PAN (allowed if properly masked)
When stored, CHD, such as PAN, must be rendered unreadable using strong encryption, tokenization, hashing, or truncation.
What is Sensitive Authentication Data (SAD)?
When stored, CHD, such as PAN, must be rendered unreadable using strong encryption, tokenization, hashing, or truncation.
What is Sensitive Authentication Data (SAD)?
Sensitive Authentication Data (SAD) refers to information used to authenticate a card transaction during authorization.
PCI DSS explicitly prohibits storing SAD after authorization, even if the data is encrypted.
SAD includes:
- Full magnetic stripe or equivalent chip data (Track 1 or Track 2)
- Card Verification Values/Codes (CVV, CVC, CAV2, CID)
- Personal Identification Numbers (PINs) and encrypted PIN blocks
SAD may exist temporarily while a transaction is being authorized, but once the process is complete, the data must be securely deleted.
Examples of improper SAD storage:
- Log files capturing full CVV values during payment processing
- Databases retaining encrypted magnetic stripe data after settlement
- Backups containing raw PIN or CVV information
CHD vs. SAD at a Glance
SAD may exist temporarily while a transaction is being authorized, but once the process is complete, the data must be securely deleted.
Examples of improper SAD storage:
- Log files capturing full CVV values during payment processing
- Databases retaining encrypted magnetic stripe data after settlement
- Backups containing raw PIN or CVV information
|
Data Type
|
Examples
|
Storage After Authorization
|
In PCI DSS Scope
|
|---|---|---|---|
|
Cardholder Data (CHD)
|
PAN, cardholder name, expiration date, service code
|
Allowed if secured and rendered unreadable
|
✅ Yes
|
|
Sensitive Authentication Data (SAD)
|
CVV/CVC, PIN, magnetic stripe, or chip data
|
❌ Never permitted after authorization
|
✅ Yes (only during processing)
|
Key Takeaways & Next Steps
PCI DSS v4.0.1 is a framework for protecting your business and the customers who trust you. The challenge for most organizations isn’t knowing what to do but knowing where to start. That’s where TrustNet comes in.
Partnering with TrustNet
As a PCI Qualified Security Assessor Company (QSAC), TrustNet brings proven experience across industries, from global merchants to cloud service providers. Our consultants translate PCI DSS requirements into clear, practical steps that make sense for your environment.
What sets us apart:
- Readiness Assessments that reveal exactly where you stand and how to meet PCI DSS v4.0.1 standards.
- Validation Expertise for both SAQs and RoCs, ensuring evidence is accurate, complete, and audit-ready.
- Remediation & Advisory Services that prioritize high-impact fixes and reduce overall compliance effort.
- Continuous Compliance Programs that keep you aligned with evolving payment-security expectations year-round.
Every engagement is led by senior TrustNet PCI DSS experts who understand that compliance should enhance security, not create unnecessary red tape.
Your Next Step
If your organization handles payment card data, now’s the time to strengthen your PCI compliance readiness. Protecting cardholder data is a shared responsibility — but you don’t have to tackle it alone.
Schedule a consultation with a TrustNet PCI DSS expert to discuss your environment and compliance objectives, or download our PCI DSS v4.0.1 Readiness Checklist to see how close you are to full compliance.