# What are Payment Card Data Security Standards (PCI DSS)? Source: https://keepnetlabs.com/blog/what-are-payment-card-data-security-standards-pci-dss Published: 2025-08-15 Updated: 2026-10-15 Author: Ozan Ucar, Founder and CEO of Keepnet Category: Human Risk Management > Your no-fluff PCI DSS guide for 2025. Learn the six goals, 12 requirements, SAQs, and the big v4.0/v4.0.1 changes. Practical steps. Real examples. Less stress. **PCI DSS stands for (pci dss stands for) Payment Card Industry Data Security Standard**. The **PCI DSS meaning** is simple: a global baseline of technical and operational controls that protect cardholder data wherever it’s stored, processed, or transmitted. It’s managed by the **PCI Security Standards Council (PCI SSC**), formed by the major card brands. It isn’t a government law; it’s a **contractual requirement** tied to your ability to accept card payments. Version **4.0** launched on **March 31, 2022**, replacing v3.2.1, which was retired on **March 31, 2024**. A clarifying update, **v4.0.1**, was released in June 2024. All future-dated v4 requirements became **mandatory on March 31, 2025**. If you’ve been delaying measures like **stronger MFA, 12-character passwords, and Targeted Risk Analysis (TRA**), 2025 is the year you must close those gaps. **In this blog, you’ll learn what PCI DSS is and how Keepnet helps you meet practical PCI DSS 4.0 requirements**, reducing human-factor risk with awareness and phishing simulations, and automating evidence collection, reporting, and auditor-friendly workflows. ## PCI-DSS 101: Definition **PCI-DSS, which stands for Payment Card Industry Data Security Standard**, is a set of security rules created by the major credit card companies (like Visa, Mastercard, etc.) working together as the PCI Security Standards Council. If your business accepts, stores, processes, or transmits credit or debit card information in any way, you've got to follow these rules. The primary objective is to ensure that sensitive card details, such as the cardholder's name, card number, expiration date, and security code, are safeguarded from hackers and thieves throughout the entire payment process, thereby protecting both customers and businesses handling their payments. Using a secure [payment gateway](https://noda.live/articles/what-is-a-payment-gateway-and-how-it-works) helps encrypt and transmit this information safely, adding an extra layer of protection against fraud. ### What PCI-DSS Covers The standard has **12 requirements** grouped under **six security goals**. They focus on protecting **account data**. That means **cardholder data (CHD**) like the **PAN** (Primary Account Number), and **sensitive authentication data (SAD**) like full track data, CVV/CVC, or PIN data. Controls span networks, data protection, [vulnerability management](https://keepnetlabs.com/blog/vulnerability-management-guide), access control, monitoring/testing, and policy. ***Editor's Note: This article was updated on March 12, 2026***. Video: ### Who Must Comply with PCI-DSS? **Any entity that touches card data must comply**. That includes **merchants, service providers, payment processors, gateways**, and **hosting/cloud providers** that could affect the **cardholder data environment (CDE**). If your systems can **impact the security of CHD**, you are in scope, even if you outsource payments. Your acquirer and the brands enforce it through contracts and program rules. ### Key Terms that Matter for PCI-DSS - **PAN**: the number printed on the card. If a system stores or transmits PAN, it’s usually in scope. - **CHD vs SAD: CHD** includes PAN (plus name, expiration, service code). **SAD** includes CVV/CVC, track data, and PIN/blocks. **Never store SAD after authorization**. Even encrypted. Ever. If you must keep CHD, make it unreadable using **tokenization, truncation, hashing, or strong encryption with proper key management**. ## The Six Goals and 12 Requirements for PCI-DSS PCI-DSS is built upon a framework of six high-level goals. These goals are further broken down into 12 detailed requirements that organizations must implement and maintain. Here is the breakdown of goals and requirements: ### Goal 1: Network Security **1. Install and maintain network** [**security controls**](https://keepnetlabs.com/blog/do-your-security-controls-work) Strong [network security controls](https://keepnetlabs.com/blog/guide-to-building-a-secure-network-for-your-business) are the front door of your . Use firewalls, WAF, and segmentation to separate the CDE from the rest of your network. Only allow the ports and services you truly need. Document rules. Review them often. This is the backbone of any **PCI DSS compliance checklist**. **2. Apply secure configurations to all system components** Default settings are attacker candy. Harden servers, endpoints, databases, POS, and cloud services with **secure configuration baselines**. Remove or disable **default passwords**, guest accounts, and unneeded services. Track changes with configuration management. This reduces easy wins for threat actors and helps you pass **PCI DSS audits** without drama. ### Goal 2: Data Protection **3. Protect stored account data** Keep less data. If you must store **PAN**, make it unreadable using tokenization, truncation, hashing, or strong encryption with sound **key management**. Never keep **sensitive authentication data (SAD**) after authorization. Clean up backups and logs too. Many breaches start with forgotten test data or debug files, don’t be that case study. **4. Protect cardholder data in transit** When data moves, attackers listen. Use **TLS** and modern cipher suites for any open, public, or untrusted network. Enforce HTTPS everywhere. Disable weak protocols and ciphers. This protects web checkout flows, APIs, and third-party integrations in your **e-commerce PCI compliance** program. ### Goal 3: Vulnerability Management 5.Protect systems and networks from malware Malware finds weak endpoints fast. Deploy EDR/AV, keep definitions current, and scan removable media. Lock down admin rights. Use application allow-listing in high-risk areas like POS. Monitor alerts and respond quickly. This is basic [malware](https://keepnetlabs.com/blog/3-most-common-examples-of-malware-attacks) [protection for PCI](https://keepnetlabs.com/blog/3-most-common-examples-of-malware-attacks) and a must for retail. **6.Develop and maintain secure systems and software** Patch known bugs before criminals do. Prioritize critical patches on internet-facing apps and payment touchpoints. Shift left with a **secure SDLC**: code reviews, dependency checks, SAST/DAST, and secrets management. Treat third-party libraries like code you wrote. This keeps your **PCI DSS vulnerability management** program real, not just a checkbox. ### Goal 4: Access Control **7.Restrict access by business need-to-know** No one gets blanket access to the CDE. Implement **least privilege** with [role-based access control (RBAC)](https://keepnetlabs.com/blog/what-is-access-control-a-cybersecurity-guide-for-2025). Separate duties so one person cannot request, approve, and execute risky changes. Review access regularly and remove it when people change roles. This limits blast radius if an account is compromised. **8. Identify users and authenticate access** Prove “who you are” every time. Use unique IDs, strong passwords, and [multi-factor authentication (MFA)](https://keepnetlabs.com/blog/how-to-run-an-mfa-phishing-simulation-a-simple-guide-for-it-professionals) for admins, remote access, and access to the CDE. Aim for phishing-resistant factors where possible. Log authentication events and investigate anomalies. This is one of the biggest upgrades in **PCI DSS 4.0**. **9. Restrict physical access to cardholder data** Digital controls fail if someone can walk out with a server. Protect data centers, network closets, and POS devices with locks, badges, cameras, and visitor logs. Inventory and secure media and paper with **cardholder data (CHD**). Train staff to challenge tailgating. Physical security is still cyber security. ### Goal 5: Monitoring & Testing **10. Log and monitor all access** You cannot fix what you cannot see. Centralize logs from systems, apps, databases, and security tools into a SIEM. Keep **time sync** reliable. Alert on suspicious events like failed logins, privilege changes, and access to PAN. Good logging shortens dwell time and helps during incident response and **PCI assessments**. **11.Test security of systems and networks regularly** Scan. Fix. Verify. Run **ASV external scans**, internal vulnerability scans, and **penetration testing** at least annually and after significant changes. Validate segmentation so your scope stays small. Track remediation SLAs and retest to closure. This turns **PCI DSS vulnerability scanning** into a continuous habit, not a once-a-year panic. ### Goal 6: Policy & Governance **12. Support information security with policies and programs** Write it down and live it daily. Maintain an [information security policy](https://keepnetlabs.com/blog/what-is-information-security-program), define roles and responsibilities, and run [security awareness training](https://keepnetlabs.com/products/security-awareness-training) (including social engineering and incident reporting). Use **Targeted Risk Analysis (TRA**) in v4 to set smart frequencies for activities. Review your program at least annually. This creates the culture that keeps you compliant between audits. ## What Changed in v4.0 / v4.0.1 PCI DSS and Why it Matters Now PCI DSS v4.0 modernizes payment security: broader MFA (for all access into the CDE), clearer “network security controls” (beyond firewalls), and flexible options like the Customized Approach plus Targeted Risk Analyses (TRA) to set smart, risk-based frequencies. v4.0.1 is a tidy-up release, clarifications only, no new requirements or date changes. The SAQs were refreshed too (e.g., SAQ A now expects stronger website script protections when you embed third-party payment forms). Bottom line: v3.2.1 retired on March 31, 2024, and the future-dated v4 controls are mandatory from March 31, 2025, so tighten authentication, review passwords/passphrases, and put TRA-backed processes in place now. ### Stronger Authentication & Passwords **Passwords got longer**. A minimum of **12 characters** is the new baseline. You can use **8 characters only on legacy systems** that cannot support 12 characters. Plan to phase those out. This requirement became **mandatory as of March 31, 2025**. **Where does forced rotation apply**? The 90-day rule is **no longer universal**. It applies **only when you use single-factor auth** (password-only). If you’re on **MFA**, 8.3.9 doesn’t apply; for **service providers**, 8.3.10.1 mirrors this for customer access. **MFA expectations clarified**. v4.0.1 adds guidance notes. **Phishing-resistant authentication alone is insufficient to meet the key MFA requirements (8.4.1, 8.4.3); it must be one factor in a multi-factor authentication** flow. ### Customized Approach & Targeted Risk Analyses (TRA) **Two ways to comply**. You can follow the **Defined Approach** (classic controls as written) or use the **Customized Approach**, proving you meet the **control objective** with alternate controls. It’s flexible, but it requires solid evidence and documentation. **When to use a TRA**. v4.x introduces **Targeted Risk Analyses** for two cases: - to **set the frequency** of certain recurring activities (e.g., how often to review logs/alerts, run tasks), and - to **justify** a customized control. PCI SSC published **sample TRA templates**, use them. Quick examples. - You choose **tokenization + strict monitoring** instead of a legacy encryption method; document how it meets the objective (Customized Approach + TRA). - You set **scan review** to a risk-based cadence (e.g., weekly vs. daily) with a **TRA for frequency** and evidence of detection/response. ### SAQ Updates in v4.0.1 (big for e-commerce) - **SAQ A eligibility tightened**. You must confirm your **entire site** (not just payment pages) is **not susceptible to script-based attacks**. There’s an official FAQ that explains how merchants can confirm this (e.g., controls to manage third-party scripts). - **Where to get the latest SAQs**. Download the **v4.0.1 SAQ pack and instructions** from the PCI SSC **Document Library**; PCI SSC also issued a bulletin announcing availability. ### Dates that Bite (Don’t Miss These) - **v3.2.1 retired: March 31, 2024**. Only v4.0 / v4.0.1 are active now. - **Future-dated v4 controls mandatory: March 31, 2025** (that includes the 12-char password rule and many others). - **v4.0.1 is a clarification release: it doesn’t add or delete requirements**; it mainly fixes wording and intent. **What this means for you in 2025**: move to **12-character passwords**, ensure **MFA** is correctly applied, use **TRA** where the standard expects risk-based frequencies, and if you’re e-commerce on **SAQ A**, harden **scripts across the whole site**, not just checkout. This is how you stay compliant and safer. Scoping: What’s “in Scope” for PCI and How to Shrink It **Scoping** for PCI-DSS defines the people, processes, and technology that store, process, or transmit cardholder data, as well as any connected components that could impact the security of that data. Essentially, anything in the Cardholder Data Environment (CDE) is "in scope." The goal is to identify all these elements to ensure they meet the PCI-DSS requirements. To **shrink the scope**, you can implement strategies like **tokenization** or **point-to-point encryption (P2PE**). These methods replace cardholder data with a non-sensitive equivalent or encrypt it from the point of entry, effectively removing systems from the CDE and, therefore, from the scope of PCI-DSS requirements. Another approach is to isolate systems that handle cardholder data from the rest of the network, creating a more contained and manageable CDE. ### CDE Basics Your **cardholder data environment (CDE**) includes any system that **stores, processes, or transmits PAN**, plus any system **connected to** or that can **impact** the CDE. A safe starting point: assume **everything is in scope** until you prove otherwise. Draw **data-flow diagrams** and **asset inventories**first. This is how you find where PAN actually moves and which systems can influence it. ### Modern Architectures PCI’s 2024 **Scoping & Segmentation for Modern Network Architectures** guide explains how **cloud**, [zero-trust](https://keepnetlabs.com/blog/what-is-zero-trust-architecture), **micro-segmentation**, and **multi-cloud** technologies change scoping. Assessors expect you to define clear **scope boundaries**, maintain an **asset inventory** even for **ephemeral microservices**, and **verify that** [segmentation](https://keepnetlabs.com/blog/what-is-security-awareness) works as designed. Treat segmentation as a control you must **test and evidence**, not just a diagram. ### Shrink scope with smart tactics. - **Outsource** processing to **PCI DSS–compliant providers so that your systems never directly handle PANs**. - Use **network segmentation** to isolate the CDE from the rest of your environment. - Adopt **tokenization** so applications use tokens, not PAN (see PCI’s **Token Service Provider** standard for aligned practices). - Prefer **PCI-validated P2PE** at the point of interaction; listed solutions **reduce PCI DSS validation effort** and come with clear implementation guidance. Always check the **official PCI SSC listings** when selecting providers. ## What You Can (and Cannot) Store Do **not** store **Sensitive Authentication Data (SAD**) after authorization. Not in databases. Not in logs. Not in call recordings. Not even **encrypted**. This ban applies even if you don’t keep PAN in the same environment. **If storage is unavoidable, make PAN unreadable**. Use **truncation** (e.g., show only the last 4), **tokenization** (replace PAN with a token), **hashing** (with salt; one-way), or **strong encryption** plus sound **key management**. Clean up **backups, debug dumps**, and **analytics exports**. Many breaches begin there. For voice teams: if calls capture PAN/SAD, **pause-and-resume** or **redact** immediately; don’t keep SAD at all. See the standard and the classic “Data Storage Do’s & Don’ts.” ## How Compliance is Validated (Merchants & Service Providers) **Merchant levels (1–4**). Card brands classify you by **annual transaction volume**. Thresholds vary by brand, but common patterns look like this: **Level 1** (>6M/yr or compromised) → **ROC** by a QSA; **Levels 2–4** use the appropriate **SAQ** plus **ASV scans**. Always confirm with your **acquirer** and brand program rules. ### SAQs (Quick Chooser) - **SAQ A**: Outsourced e-commerce or MOTO; no electronic storage/processing/transmission on your systems. - **SAQ A-EP**: E-commerce where your site **influences** the payment page (e.g., scripts). - **SAQ B / B-IP**: Standalone dial-out terminals or IP-connected imprint devices. - **SAQ C-VT**: Virtual terminals only. - **SAQ C**: Internet-connected payment apps without electronic storage. - **SAQ D (Merchant or Service Provider**): Everything else / complex environments. - **SAQ P2PE**: Using PCI-validated P2PE only. - **SAQ SPoC/CPoC**: COTS/mobile solutions (as applicable). Download the **official v4.0.1 SAQ pack + instructions** from the PCI SSC **Document Library**; PCI also issued a bulletin announcing availability. ### Ongoing Testing (Where It Sits in the 12 Requirements) - **ASV external scans (quarterly**) → Requirement **11**; must be performed by a PCI-approved ASV. - **Internal scans and penetration testing** (annual and after significant changes) → Requirement 11. - **Continuous logging/monitoring** → Requirement **10**. See the **ASV Program Guide** and the official **ASV listings** for vendors. ## The Controls Readers Care About Most in 2025 With the release of PCI DSS v4.0, the focus on specific controls has intensified, reflecting a shift towards more proactive and risk-based security practices. While all 12 requirements are critical, five key areas have emerged as particularly important for organizations to prioritize. These controls are not just about compliance; they are foundational to a robust security posture in the face of evolving threats. ### MFA Everywhere It Counts Enforce **multi-factor authentication** for **admin, remote**, and **CDE** access. Aim for **phishing-resistant** options where possible, but remember: a phishing-resistant method by itself isn’t “MFA” unless it’s one of the **factors** in a multi-factor flow. ### Passwords & SSO Move to **12-character** minimums (8 only for true legacy edge cases). Pair with **SSO/IdP**, lock down password reset flows, and monitor for credential stuffing. This is a v4 must-do. ### Vulnerability Management with TRA Patch with **risk-based** cadence. Use **Targeted Risk Analyses (TRA**) where v4 lets you set activity frequency (for example, how often you review certain alerts). Keep evidence for the assessor. See the v4.x TRA guidance/templates. ### Logging & Monitoring that Actually Detects Centralize logs, sync time, alert on spikes in **failed logins, privilege changes**, and **PAN access**. Requirement **10** gives you the backbone; tune it to your environment. ### Security Awareness That Sticks Requirement **12.6** expects **training**on social engineering, phishing, handling PAN, and reporting incidents, plus**records** that prove it happened. Map modules to 12.6 and refresh annually (or more for high-risk roles). ## E-commerce patterns that change your SAQ **Hosted fields/iFrames/redirects (SAQ A) vs merchant-managed pages or scripts (SAQ A-EP**). If **your site** hosts or controls scripts that touch the payment experience, you’re usually in **A-EP. With v4.0.1**, **SAQ A eligibility tightened**: merchants must confirm their entire site is protected from **malicious script** attacks, not just the payment page. PCI SSC published updates and an FAQ to clarify what “entire site script security” means in practice. ### Mini Decision Helper - Fully outsourced checkout via **redirect/iFrame/hosted fields**, and your site **does not** load risky scripts into the payment journey → start with **SAQ A**. - Your site hosts payment pages or **controls** scripts that can modify them → likely **SAQ A-EP**. When in doubt, check the **SAQ instructions** and talk to your **acquirer/QSA**. Roadmap: A Prioritized, Realistic Path to Compliance **Use the PCI “Prioritized Approach**.” PCI SSC provides a **v4.0.1 Prioritized Approach** and a **tool** that groups controls into six **risk-based milestones**. It helps you achieve quick wins, mitigate real risks early, and demonstrate progress to stakeholders. ### 90-day Starter Plan - **Week 1–2**: Map **data flows**; define scope and **segment** the CDE. Kill **SAD** storage; reduce PAN footprint. - **Week 3–6**: Enforce **MFA**; raise **password** minimums; fix high-risk vulnerabilities; enable central **logging**. - **Week 7–12**: Choose your **SAQ/ROC** path; schedule **ASV scans**; draft **policy set** and **training** mapped to 12.6; document **TRAs** where needed. ### 12-Month BAU Loop Quarterly **ASV scans** and remediation; semiannual **access reviews**; annual **pen tests, training**, and **scope re-check** before renewal. Track evidence as you go so the assessment is a **no-drama** exercise. ## PCI-DSS vs ISO 27001 vs SOC 2 (and Privacy Laws) **PCI-DSS is prescriptive** and **scope-bound to payment account data**. It tells you what controls to implement to protect PAN/SAD in your **CDE. ISO 27001** and **SOC 2** define broader **information security** programs and control frameworks across your org, not only payments. In practice, many companies run ISO or SOC 2 for the company-wide ISMS and use **PCI-DSS** to harden the **payments slice**. For privacy laws like **GDPR/CCPA**, PCI complements them: PCI focuses on security of card data, while privacy laws focus on **rights, notices, and lawful processing**. When writing policies, link back to the **12 PCI requirements** so your governance connects to operating controls. ## How Keepnet Helps (Practical PCI DSS v4.0 support) [Keepnet](https://keepnetlabs.com/)’s secure behaviour management platform focuses on the human layer of PCI. It builds skills, tests real behavior, and reinforces policy, exactly where **v4.0** raised the bar (training, social engineering, incident response, and risk analysis). The one-page reference (page 1) maps these capabilities to PCI **Requirement 12** areas. ![How Keepnet HRM Helps PCI DSS Compliance](https://timely-benefit-e63d540317.media.strapiapp.com/How_Keepnet_HRM_Helps_PCI_DSS_Compliance_87aab142ae.png) *Picture 1: How Keepnet HRM Helps PCI DSS Compliance* ### Security Awareness Training → Req. 12.6 Regular, [role-based security awareness training](https://keepnetlabs.com/products/security-awareness-training) on **phishing, social engineering**, handling **cardholder data (CHD**), and **incident reporting**. You get evidence of completion for your SAQ/ROC. ### Phishing Simulation → Req. 12.6 (Education & Testing) [Realistic phishing simulations to](https://keepnetlabs.com/products/phishing-simulator) teach recognition and reporting. Covers email, SMS (smishing), voice (vishing), QR (quishing), and MFA phishing, the modern threats auditors ask about. ### Social Engineering Prevention → Req. 12 (Program) & 12.6 (Awareness) Campaigns that probe help desks and business processes, then coach staff. This hardens people and procedures that can impact the **CDE**. ### Incident Response & Reporting → Req. 12.10 Tools and workflows that prepare teams to [respond fast to suspected phishing](https://keepnetlabs.com/products/incident-responder) or data access attempts. Supports documented roles, escalation, and response drills. ### Policy & Procedure Reinforcement → Req. 12 Targeted simulations + follow-up training that make access-control and acceptable-use rules stick. This turns policy into daily habits. ### Risk Assessment & Management → Req. 12.2 (and TRA in v4) Simulations reveal human-centric vulnerabilities and feed your **risk assessments**. Useful inputs for **Targeted Risk Analysis (TRA**) frequencies under v4. **Why it matters**: v4.0/v4.0.1 put more weight on **people, process**, and **response**. Keepnet gives you the training, testing, and evidence to prove it, plus a faster path to closing real phishing and social-engineering risk. Start small (awareness + phishing tests), then expand to incident drills and TRA-informed improvements. ## How to Make This Work in Practice Payment Card Data Security Standards ? becomes effective when policies are simple enough to apply during normal work. Teams struggle when the rules are too abstract, too broad, or disconnected from the moments where people actually handle sensitive data, approvals, or customer information. A stronger model connects governance to action. People should know what the rule means, which decisions trigger extra review, and how the control supports the business instead of creating confusion around every edge case. Keepnet teams usually see better compliance outcomes when examples are tied to daily workflows instead of policy language alone. For most organizations, the practical test is whether people can apply payment card data security standards ? correctly without stopping work to ask for interpretation. ### Governance Checklist - Use plain language examples so teams can apply the rule without guesswork. - Tie the policy to the workflows that create the highest legal or business exposure. - Define escalation paths for unusual requests, exceptions, or repeated mistakes. - Review where users struggle and improve the guidance, not only the policy wording. ## Frequently Asked Questions ### What is PCI DSS? The Payment Card Industry Data Security Standard is a set of requirements for any organisation that stores, processes or transmits cardholder data. It is enforced by the card brands through acquiring banks rather than by a government regulator. ### Who must comply with PCI DSS? Any merchant or service provider that handles payment card data, regardless of size. The validation effort scales with transaction volume, but the requirements themselves apply from the first transaction. ### What are the six goals of PCI DSS? Build and maintain a secure network, protect cardholder data, maintain a vulnerability management programme, implement strong access control, monitor and test networks regularly, and maintain an information security policy. The twelve requirements sit underneath these six goals. ### Does PCI DSS require security awareness training? Yes. The standard requires a formal awareness programme for personnel who handle cardholder data, delivered on hiring and at least annually, with records showing who completed it. ### Is annual training enough? It satisfies the requirement and rarely changes behaviour. Compliance training answers an auditor, behaviour measurement answers a board, and most organisations need both while buying as though they need one. ### What happens if you fail PCI DSS? Consequences range from higher transaction fees and remediation deadlines to fines and, in serious cases, losing the ability to process card payments. A breach involving card data also triggers a forensic investigation at the merchant's cost.