Last Updated on February 9, 2026 by Narendra Sahoo
The Payment Card Industry Data Security Standard (PCI DSS) is the global security framework that governs how organizations protect cardholder data across payment environments. Established by the PCI Security Standards Council (PCI SSC), PCI DSS exists to reduce payment card fraud, prevent data breaches, and maintain trust across the payments ecosystem. Any organization that stores, processes, or transmits cardholder data is expected to comply, regardless of size, industry, or transaction volume.
At the core of PCI DSS are 12 security requirements that define how organizations must secure networks, protect cardholder data, control access, monitor activity, and maintain strong governance. With the transition to PCI DSS v4.0.x, these requirements now emphasize continuous risk management, accountability, and real-world security effectiveness rather than checkbox compliance.
In this guide, we explain each of the 12 PCI DSS requirements in a practical, audit-focused manner, highlighting what auditors expect, where organizations commonly fail, and how to implement controls correctly.
What Is PCI DSS
Here’s the thing most people don’t realize: PCI DSS wasn’t created by the government. It’s not a law. It’s a set of security standards created in 2006 by the major credit card companies—Visa, Mastercard, American Express, Discover, and JCB—who got tired of dealing with massive data breaches.
Think of it as the card brands saying: “If you want to accept our cards, these are the security controls you must have in place.”
The Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive framework designed to protect cardholder data throughout its entire lifecycle. It’s maintained by the PCI Security Standards Council (PCI SSC), an independent organization, but make no mistake—the card brands are the ones who enforce it.
📌 Unsure how PCI DSS requirements apply to your specific payment architecture or cloud environment?
Explore our PCI DSS Audit and Compliance Services to understand your scope and obligations before an audit.
Why Should You Care?
Because a single data breach can destroy your business. I’ve watched it happen. Beyond the immediate fines and forensic investigation costs, there’s the brand damage, the lawsuits, and the customers who never come back.
PCI DSS gives you a blueprint for security. Follow it, and you dramatically reduce your risk. Ignore it, and you’re playing Russian roulette with your business.
Who Needs to Comply with PCI DSS?
If you answered “yes” to any of these questions, you need PCI DSS compliance:
- Do you accept credit or debit cards as payment?
- Do you store card numbers in any system (even temporarily)?
- Do you process card transactions through your website or point-of-sale system?
- Do you transmit cardholder data to a payment processor?
- Do you provide services to companies that do any of the above?
“But I use Stripe/PayPal/Square. Don’t they handle compliance for me?”
Partially. Payment service providers handle compliance for their systems, but you’re still responsible for your piece of the transaction. If your website has a checkout page where customers enter card data, you have compliance responsibilities. If you store confirmation emails with partial card numbers, you have compliance responsibilities.
What are the 12 requirements of PCI DSS?
The 12 requirements outlined by the PCI Council for PCI DSS Compliance comprises technical and operational security measures that need to be implemented within the card environment. That said, it is important to note and understand that the primary focus of these PCI DSS 12 requirements is protecting sensitive card data. For organizations to implement these requirements it is essential that they first understand each of these requirements and know the purpose of implementing these security measures. So, read the explanation below to get a better perspective and understanding of the payment security standard.
PCI DSS Requirement 1 : Install and Maintain Network Security Controls
What this really means: Build a fortress around your cardholder data environment (CDE) using firewalls, routers, and network segmentation.
👉 Why This Matters
Your network is the front door to your cardholder data. Every day, automated bots and hackers scan the internet looking for misconfigured firewalls or open ports. I’ve seen breaches happen because someone left port 3389 (Remote Desktop) open to the world. Don’t be that person.
Firewalls act as gatekeepers, examining every packet of network traffic and deciding whether to allow or deny it based on predefined rules. But here’s the catch: a firewall is only as good as its configuration.
👉 What You Must Do
1.1-1.2: Document and justify all connections to/from the CDE – Create network diagrams showing every connection point – Identify all cardholder data flows – Document business justification for each connection – Review and update diagrams at least annually (or whenever the network changes)
1.3: Segment your network – Isolate your CDE from your general business network – Use VLANs, firewalls, or physical separation – Minimize the number of systems that can access cardholder data – Test segmentation effectiveness at least annually
1.4: Configure firewall rules properly – Default deny (only allow explicitly approved traffic) – Restrict inbound traffic to only necessary ports and protocols – Restrict outbound traffic from the CDE – Use stateful inspection where possible – Review firewall rules every six months
1.5: Protect wireless access – Change default SSID and passwords on all wireless devices – Use strong encryption (WPA2 or WPA3, never WEP) – Implement firewalls between wireless and CDE – Detect and alert on rogue wireless access points quarterly
👉 Common Mistakes I See All the Time
❌ “Our firewall came pre-configured, so we’re good” Vendor defaults are never acceptable. I’ve seen production systems with password “admin/admin” because nobody changed it.
❌ “We only have one network, so we don’t need segmentation” Wrong. Segmentation reduces your audit scope and limits breach impact. A flat network means EVERYTHING is in scope.
❌ “We documented our network two years ago” Networks change constantly. Your documentation must reflect current reality, or your auditor will fail you.
❌ “Firewall rules are IT’s job, not compliance” Firewall rules ARE compliance. Every rule needs business justification, and dangerous rules (like ANY/ANY) will fail you.
👉 How to Implement (Step-by-Step)
Month 1: 1. Map your current network completely (use tools like Visio, Lucidchart, or even pen and paper) 2. Identify all systems that store, process, or transmit cardholder data 3. Document all data flows between systems 4. Identify current firewall rules
Month 2: 5. Design network segmentation strategy 6. Create firewall rule standards (template for new rules) 7. Review existing rules against standards 8. Remove unnecessary rules
Month 3: 9. Implement network segmentation (may require hardware) 10. Configure firewalls according to new standards 11. Test all critical business functions still work 12. Document everything
Month 4: 13. Conduct penetration test to validate segmentation 14. Create process for firewall rule change management 15. Schedule six-month rule reviews 16. Train IT staff on standards
Requirement 2: Apply Secure Configurations to All System Components
What this really means: Harden every server, workstation, network device, and application in your CDE against known vulnerabilities.
👉 Why This Matters
Default configurations are designed for ease of setup, not security. Vendors ship products with default passwords like “admin/password” so anyone can set them up quickly. Hackers know this. They have databases of every default password for every device ever made.
In 2013, Target was breached through an HVAC vendor who used default credentials. That breach cost Target $18.5 million in settlements and immeasurable brand damage.
System hardening is your second line of defense after the firewall. It ensures that even if someone gets past your network controls, they can’t easily compromise your systems.
👉 What You Must Do
2.1: Change all vendor defaults before production – Passwords (every single one) – SNMP community strings – Default accounts (disable or remove) – Default encryption keys – Security parameters
2.2: Develop configuration standards – One function per server (don’t mix web server and database on same box) – Enable only necessary services and protocols – Remove unnecessary software and accounts – Disable insecure services (Telnet, FTP, early TLS) – Use secure admin protocols (SSH instead of Telnet, SFTP instead of FTP) – Patch and update all systems on regular schedule
2.3: Encrypt administrative access using strong cryptography – Use SSH, VPN, TLS 1.2+ – Never use Telnet, HTTP for admin access – Implement MFA for all admin access
2.4: Maintain inventory of system components – Every server, workstation, network device, application – Document role, function, location – Track configuration baseline for each – Update inventory when changes occur.
👉 Common Mistakes
❌ “We’ll change the password after we finish testing” I’ve lost count of how many “temporary” default passwords became permanent. Change them IMMEDIATELY.
❌ “Our server runs 15 different services—it’s more efficient” It’s also 15x more vulnerable. One compromised service can lead to complete system takeover. One service per server.
❌ “Configuration standards are too restrictive for our developers” Security exists to protect the business, not make developers’ lives easier. Non-negotiable standards save you from breaches.
❌ “We use the same configuration for everything” Every system should have configuration appropriate to its risk level and function. Web servers and database servers need different hardening.
👉 How to Implement
Week 1-2: Inventory 1. Create complete inventory of all systems in CDE 2. Document current OS, software versions, services running 3. Identify all default accounts and passwords 4. List all services and protocols enabled
Week 3-4: Develop Standards 5. Create hardening checklists for each OS type (Windows, Linux, network devices) 6. Leverage CIS Benchmarks or DISA STIGs as starting point 7. Customize for your environment 8. Get stakeholder buy-in
Month 2: Remediation 9. Change ALL default passwords and security parameters 10. Disable/remove unnecessary services and accounts 11. Apply configuration standards to all systems 12. Document configuration baseline for each system 13. Test that critical business functions still work
Month 3: Ongoing 14. Create process for configuring new systems to standard 15. Conduct quarterly configuration compliance scans 16. Update standards when new vulnerabilities discovered
Requirement 3: Protect Stored Account Data
What this really means: Minimize data retention, and encrypt what you absolutely must keep.
👉 Why This Matters
This is THE most critical requirement. Period.
If you don’t store cardholder data, attackers can’t steal it. It’s that simple. Every piece of cardholder data you store increases your risk, your scope, and your costs.
I’ve consulted with companies storing millions of full credit card numbers “just in case we need them later.” When I ask why, the answer is always vague. Don’t be that company.
And when you absolutely must store data, encryption is non-negotiable. Unencrypted PANs (Primary Account Numbers) are the #1 cause of catastrophic breaches.
Understanding Cardholder Data
Cardholder Data (CHD) – What you might need to store: – Primary Account Number (PAN) – the 13-19 digit card number – Cardholder name – Expiration date – Service code
Sensitive Authentication Data (SAD) – NEVER store these after authorization: – Full magnetic stripe data – CAV2/CVC2/CVV2/CID (the 3-4 digit security code) – PIN or PIN block
The golden rule: If you don’t have a documented business need to store it, DON’T STORE IT.
👉 What You Must Do
3.1: Minimize data retention – Only store what you absolutely need – Document business justification for retention – Define and enforce retention periods – Securely delete data when no longer needed – Conduct quarterly reviews of stored data
3.2: Don’t store sensitive authentication data after authorization – Never store CVV2/CVC2 – Never store full magnetic stripe – Never store PIN – Implement automated processes to prevent storage
3.3: Mask PAN when displayed – Show maximum of first 6 and last 4 digits – Applies to screens, reports, receipts, etc. – Only authorized personnel with business need can see full PAN
3.4: Make PAN unreadable everywhere it’s stored – Encrypt using strong cryptography (AES-256, RSA 2048+) – Use one-way hashes (SHA-256+) – Use truncation – Use tokenization
3.5-3.6: Encryption key management – Keys must be as strong as the data encryption – Store keys separately from encrypted data – Change keys at least annually – Restrict access to encryption keys – Destroy keys when no longer needed
3.7: Ensure security features are documented and understood – Document encryption architecture – Document key management procedures – Train personnel on proper handling
👉 Common Mistakes (These Cause Breaches)
❌ Storing cardholder data in unexpected places: – Application logs – Web server logs – Database backups – Development/test systems – Email confirmations – Support tickets – Spreadsheets
I find unencrypted PANs in these locations ALL THE TIME. Run a card data discovery scan—you’ll be shocked what you find.
❌ “We encrypted the database, so we’re good” If your application can read the data to process it, encryption isn’t protecting it at rest. You need field-level encryption or tokenization.
❌ “We use MD5 hashing” MD5 is broken. SHA-1 is broken. Use SHA-256 minimum. Better yet, use bcrypt or PBKDF2 with salt.
❌ “Our developers need access to production data for testing” NO. Absolutely not. Use masked or synthetic data for testing. Production data in test environments is a recipe for disaster.
❌ “We store CVV2 for customer convenience” That’s illegal under PCI DSS. No exceptions. Ever. If you’re doing this, stop immediately.
👉 How to Implement
Week 1: Discovery 1. Run comprehensive card data discovery scan across ALL systems 2. Document every location where cardholder data exists 3. Identify data you didn’t know you had
Week 2: Minimize 4. Delete unnecessary cardholder data (after confirming no legal retention requirements) 5. Document business justification for data you’re keeping 6. Define retention periods for each data type 7. Implement automated purging processes
Week 3-4: Encrypt 8. Choose encryption method (database encryption, application-level, tokenization) 9. Implement encryption for all stored PANs 10. Test that applications still function 11. Verify data is truly encrypted
Week 5: Key Management 12. Implement secure key storage (HSM or key management service) 13. Document key management procedures 14. Restrict access to encryption keys 15. Schedule annual key rotation
Ongoing: 16. Run quarterly card data discovery scans 17. Monitor for new cardholder data 18. Review and purge data per retention policy
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission
What this really means: Encrypt cardholder data whenever it travels over networks, especially the internet.
👉 Why This Matters
Unencrypted data in transit is like mailing cash in a transparent envelope. Anyone between point A and point B can grab it.
This includes: – Card data sent from customer’s browser to your server – Data transmitted to payment processors – Data sent between internal systems – Data accessed by remote administrators – Data sent to third parties
Attackers use “man-in-the-middle” attacks to intercept unencrypted transmissions. I’ve seen breaches where hackers literally sat in coffee shop parking lots capturing wireless traffic.
👉 What You Must Do
4.1: Use strong cryptography for transmissions over open/public networks – TLS 1.2 or 1.3 for websites and APIs (TLS 1.0 and 1.1 are RETIRED) – IPSec VPN for site-to-site connections – SSH for administrative access – Ensure certificates are valid and properly configured
4.2: Never send unprotected PANs via end-user messaging – No cardholder data via email (even internal) – No cardholder data via SMS or chat – No cardholder data via collaboration tools (Slack, Teams, etc.)
If you must send cardholder data electronically, use encrypted channels with strong authentication.
👉 Common Mistakes
❌ Using self-signed certificates While technically encrypted, self-signed certs train users to ignore browser warnings. Use properly issued certificates from trusted CAs.
❌ “HTTPS is just for the checkout page” Your entire site should use HTTPS. Mixed content (HTTP and HTTPS) creates vulnerabilities.
❌ Allowing old TLS versions “for compatibility” TLS 1.0 and 1.1 have known vulnerabilities. They’re retired. If you have ancient systems that can’t use TLS 1.2+, replace those systems.
❌ Emailing card numbers “securely” with password-protected PDFs Passwords sent via email defeat the purpose. Use purpose-built secure file transfer solutions.
❌ Weak cipher suites Your server may support strong encryption, but if you allow weak ciphers for “compatibility,” attackers will force downgrade attacks.
👉 How to Implement
Week 1: 1. Inventory all transmission points for cardholder data 2. Document current encryption methods and versions 3. Identify any unencrypted transmissions 4. Check TLS/SSL configuration on all web servers
Week 2: 5. Upgrade to TLS 1.2 or 1.3 on all systems 6. Disable TLS 1.0 and 1.1 7. Configure strong cipher suites only 8. Update all certificates (no self-signed, no expired)
Week 3: 9. Implement VPNs for remote access 10. Configure encrypted email or secure file transfer (if needed) 11. Update applications to use encrypted APIs 12. Test all integrations still work
Week 4: 13. Scan for weak SSL/TLS configurations 14. Fix any vulnerabilities identified 15. Document encryption standards 16. Train staff on secure data transmission
PCI DSS Requirement 5: Protect All Systems from Malware and Regularly Update Anti-Malware Software
What this really means: Deploy, maintain, and monitor antivirus/anti-malware protection across your environment.
👉 Why This Matters
Malware is the delivery mechanism for most data breaches. Keyloggers capture card data as it’s typed. Trojans open backdoors for remote access. Ransomware encrypts your data and demands payment.
I’ve investigated breaches that started with a single employee clicking a malicious email attachment. That click cost the company $2 million in forensics, fines, and remediation.
👉 What You Must Do
5.1: Deploy anti-malware on all systems commonly affected by malware – All Windows systems (workstations and servers) – Mac systems (yes, Macs get malware too) – Linux systems where appropriate – Systems that don’t support anti-malware must be evaluated annually for malware susceptibility
5.2: Ensure anti-malware is current and actively running – Automatic signature updates (daily minimum) – Real-time scanning enabled – Periodic full scans conducted – Anti-malware cannot be disabled by users
5.3: Ensure anti-malware is tamper-resistant – Users cannot disable or alter configuration – Alerts generated if stopped or disabled – Logs maintained and reviewed
5.4: Keep anti-malware current and able to detect threats – Evaluate new threats quarterly – Update to new anti-malware versions as needed – Deploy additional tools for new attack vectors
👉 Common Mistakes
❌ “We only install anti-malware on workstations, not servers” Servers need protection too. In fact, they’re often higher-value targets.
❌ “Our Linux systems don’t need antivirus” While less common, Linux malware exists. More importantly, Linux systems can host Windows malware files. Scan them.
❌ “Users complained it slowed down their computers, so we disabled real-time scanning” Then you’ve essentially disabled your anti-malware. Performance issues need different solutions (better hardware, different AV product).
❌ “The free version is good enough” Free antivirus lacks centralized management, reporting, and advanced features you need for PCI compliance. Pay for enterprise solutions.
❌ “We installed it three years ago, so we’re good” Is it still running? Getting updates? Configured correctly? I’ve seen environments where half the endpoints had disabled or outdated AV.
👉 How to Implement
Week 1: 1. Inventory all systems in CDE (servers, workstations, mobile devices) 2. Identify systems currently without anti-malware 3. Check current anti-malware is active and updating 4. Review anti-malware configuration and policies
Week 2: 5. Select enterprise anti-malware solution (if you don’t have one) 6. Deploy to all systems requiring protection 7. Configure for automatic updates and scanning 8. Ensure real-time protection enabled
Week 3: 9. Configure centralized management and logging 10. Set up alerts for disabled/outdated anti-malware 11. Test that protection is working (use EICAR test file) 12. Document exceptions for systems that cannot run anti-malware
Week 4: 13. Implement process for evaluating new malware threats quarterly 14. Schedule regular reviews of anti-malware effectiveness 15. Train users not to disable protection 16. Create incident response process for malware detection
Requirement 6: Develop and Maintain Secure Systems and Software
What this really means: Patch your systems, secure your code, and fix vulnerabilities before hackers exploit them.
👉 Why This Matters
Vulnerability management is a race. Software vendors discover flaws and release patches. Security researchers publish exploits. Hackers weaponize those exploits. If you patch faster than attackers can exploit, you win. If not, you get breached.
Equifax waited 145 days to patch a known Apache Struts vulnerability. That delay cost them $575 million in settlement and immeasurable brand damage.
This requirement also covers secure coding practices. Most breaches I investigate involve exploitation of custom application vulnerabilities—SQL injection, cross-site scripting, authentication bypasses.
👉 What You Must Do
6.1: Establish a process to identify security vulnerabilities – Monitor security bulletins (NIST NVD, vendor advisories) – Subscribe to threat intelligence feeds – Track vulnerabilities in your inventory – Assign risk rankings (Critical, High, Medium, Low)
6.2: Deploy security patches within one month of release – Critical patches within 30 days (industry standard) – Some organizations require critical patches within 7-14 days – Document if patches cannot be deployed (with compensating controls) – Test patches before production deployment
6.3: Develop software securely – Follow secure coding guidelines (OWASP) – Separate development, test, and production environments – Remove test data and accounts before production – Review code for vulnerabilities before release – Track security vulnerabilities in custom code
6.4: Implement change control processes – Document all changes to system components – Get approval before implementation – Test functionality and security – Back out plan if issues occur
6.5: Address common coding vulnerabilities – SQL injection – Cross-site scripting (XSS) – Insecure authentication – Broken access control – Security misconfiguration – Sensitive data exposure
(v4.0 introduces 6.4.3: Scripts on payment pages must have integrity checking)
👉 Common Mistakes (These Get Exploited)
❌ “We’ll patch during the next maintenance window… in three months” Three months is an eternity. Critical vulnerabilities need patches within weeks, not months.
❌ “We don’t have a test environment, so we patch directly in production” This is how you break critical systems. Build a test environment, even if it’s just a VM.
❌ “Our developers test for functionality, not security” Functional testing doesn’t find SQL injection. You need security testing (static analysis, dynamic analysis, penetration testing).
❌ “We do penetration tests, so we don’t need code review” Pentests find what’s exploitable now. Code review finds what could be exploitable. You need both.
❌ “Security slows down development” Short-term, maybe. Long-term, security vulnerabilities slow you down far more when you’re dealing with breach response.
❌ “We use a WAF, so our code doesn’t need to be secure” Web Application Firewalls (WAFs) are defense in depth, not a substitute for secure code. WAFs can be bypassed.
👉 How to Implement
Month 1: Process Setup 1. Create vulnerability management policy 2. Assign roles and responsibilities 3. Subscribe to vulnerability feeds 4. Inventory all software and versions in use 5. Establish patching timelines and procedures
Month 2: Catch Up on Patches 6. Scan for missing patches across environment 7. Prioritize critical and high vulnerabilities 8. Test patches in lab environment 9. Deploy patches to production 10. Verify patches installed successfully
Month 3: Secure Development 11. Adopt secure coding standards (use OWASP ASVS) 12. Implement code review process 13. Deploy static analysis tools (SAST) 14. Deploy dynamic analysis tools (DAST) 15. Train developers on secure coding
Month 4: Ongoing 16. Monthly patch reviews and deployments 17. Quarterly application security testing 18. Annual penetration testing 19. Continuous monitoring of vulnerability feeds
PCI DSS Requirement 7 : Restrict Access to Cardholder Data by Business Need-to-Know
What this really means: Implement role-based access control (RBAC) so users can only access the data they need for their jobs.
👉 Why This Matters
The principle of least privilege is foundational to security. If someone doesn’t need access to cardholder data, they shouldn’t have it. Period.
Every person with access is a potential risk—not because they’re malicious, but because they’re human. Humans get phished. Humans make mistakes. Humans can be socially engineered.
Insider threats (malicious or accidental) account for over 30% of breaches. Access controls limit damage when credentials are compromised.
👉 What You Must Do
7.1: Limit access based on need-to-know – Define roles and data access requirements for each role – Grant access based on job function – Default deny (only grant access when specifically needed) – Document access requirements for each role
7.2: Implement access control systems – Use role-based access control (RBAC) or similar – Cover all system components – Deny all unless specifically allowed
7.3: Ensure access control policies are understood – Document policies and procedures – Train personnel on access controls – Review and update annually
👉 Common Mistakes
❌ “Everyone on the team needs database access” No they don’t. Developers need access to development databases. Admins need access to production. Separate these roles.
❌ “We’ll set up access controls after we go live” Access controls should be designed from day one, not bolted on later.
❌ “It’s easier to just give everyone admin rights” It’s also easier to get breached. Principle of least privilege isn’t optional.
❌ “We removed Joe from the system when he left the company” Did you remove his individual account, or just the shared account he was using? Shared accounts make access revocation impossible.
👉 How to Implement
Week 1: 1. Document all roles in your organization 2. Define data access needs for each role 3. Identify current access rights for all users 4. Find discrepancies (users with excessive access)
Week 2: 5. Design role-based access control model 6. Create security groups/roles in access control systems 7. Document access requirements for each role 8. Get management approval
Week 3: 9. Implement access controls in Active Directory, databases, applications 10. Migrate users to role-based access 11. Remove excessive privileges 12. Test that users can perform job functions
Week 4: 13. Document access control policies 14. Create process for requesting access 15. Create process for reviewing access quarterly 16. Train users and managers on access procedures
PCI DSS Requirement 8: Identify Users and Authenticate Access to System Components
What this really means: Every user gets a unique ID, strong authentication, and you track what they do.
👉 Why This Matters
Accountability requires identification. If ten people share the “admin” account, and cardholder data gets stolen, who did it? You’ll never know.
Unique user IDs, combined with strong authentication and logging, create an audit trail. When something goes wrong (and it will), you need to know who, what, when, where, and how.
👉 What You Must Do
8.1: Define and implement policies for user identification – Assign unique ID to each user – No shared accounts or generic IDs – No group or shared passwords
8.2: Ensure strong authentication for all users – Passwords minimum 12 characters (up from 8 in v3.2.1) – Complexity requirements (mix of letters, numbers, special characters) – Cannot reuse last 4 passwords – Change passwords every 90 days (or implement MFA) – Lock account after 6 failed login attempts
8.3: Secure all remote access with multi-factor authentication (MFA) – VPN connections – Admin access to systems in CDE – Remote desktop
(v4.0: MFA required for ALL access to CDE, not just remote)
8.4: Authenticate using multiple factors for console access – Something you know (password) – Something you have (token, smart card) – Something you are (biometric)
8.5: Do not use group or shared accounts – Every person has unique credentials – Service accounts documented and managed – Default accounts disabled or removed
8.6: For other authentication mechanisms (tokens, smart cards, certificates) – Ensure they’re assigned to individual users – Implement physical/logical controls
👉 Common Mistakes
❌ “Our passwords are 8 characters, which was compliant before” Not anymore. PCI DSS v4.0 requires 12+ characters. Update your policies now.
❌ “MFA is too inconvenient for our admins” The inconvenience of MFA is nothing compared to the inconvenience of a breach. No exceptions.
❌ “We have a shared ‘developer’ account for the team” Shared accounts violate Requirement 8. Every developer gets their own credentials.
❌ “We force password changes every 30 days for security” Frequent password changes encourage weak passwords and password reuse. 90 days is sufficient if you have MFA.
❌ “We allow ‘123456’ as a password because it meets length requirements” Length without complexity is useless. Enforce both, or use passphrases (4+ random words).
👉 How to Implement
Week 1: 1. Audit all user accounts across systems 2. Identify shared or generic accounts 3. Check password policies on all systems 4. Assess current MFA implementation
Week 2: 5. Update password policies to 12+ characters 6. Enable password complexity requirements 7. Configure account lockout after 6 failed attempts 8. Ensure password history prevents reuse
Week 3: 9. Implement MFA for all CDE access 10. Create unique accounts for all users 11. Disable shared accounts 12. Configure session timeouts (15 minutes for POS/systems, 30 minutes for workstations)
Week 4: 13. Document authentication policies 14. Train users on new password and MFA requirements 15. Create process for new user provisioning 16. Create process for deprovisioning (removing access when users leave)
PCI DSS Requirement 9: Restrict Physical Access to Cardholder Data
What this really means: Lock the doors to your data centers and server rooms. Control who gets in.
👉 Why This Matters
All the network security in the world doesn’t matter if someone can walk into your server room, plug in a USB drive, and copy your database.
Physical security is often overlooked because it’s not sexy like penetration testing. But physical breaches happen. I’ve investigated incidents where contractors left server room doors propped open, cleaning crews had unrestricted access, and “secure” facilities had no visitor logging.
👉 What You Must Do
9.1: Use facility entry controls – Badge readers, biometric scanners, or locked doors – Video cameras monitoring entry/exit points – Escort visitors at all times – Distinguish between employees and visitors (badges, different colored lanyards)
9.2: Implement procedures for identifying and authorizing visitors – Visitor log with name, company, date/time, purpose – Require photo ID – Assign visitor badges that expire – Visitor badges must be visibly different from employee badges
9.3: Secure physical access for personnel – Access granted only to authorized personnel – Access revoked immediately when employment terminates – Review and update access lists quarterly – Return all physical access devices (badges, keys) when no longer needed
9.4: Log and monitor physical access – Visitor logs retained for 90 days minimum – Video recording retained for 90 days minimum – Review physical access logs regularly – Protect logs from tampering
9.5: Physically secure all media – Backup tapes, hard drives, paper printouts – Store in locked cabinets or rooms – Strict check-out procedures – Inventory media periodically
9.6: Maintain strict control over distribution of media – Classify media by sensitivity – Send via secure courier with tracking – Management approval required
9.7: Maintain strict control over storage and accessibility of media – Inventory media annually – Media stored in secure locations
9.8: Destroy media when no longer needed – Shred paper – Degauss or physically destroy magnetic media – Pulverize hard drives – Secure deletion for SSDs – Certificate of destruction for sensitive media
9.9: Protect devices that capture payment card data – Maintain list of all POS terminals and devices – Inspect devices regularly for tampering – Train personnel to recognize tampering – Provide tamper-evident seals if appropriate
👉 Common Mistakes
❌ “Our office is secure, so we don’t need controls on the server closet” Wrong. The server closet needs ADDITIONAL controls beyond office access.
❌ “The cleaning crew works after hours, so they need badge access everywhere” Cleaning crews should be escorted or restricted to non-sensitive areas.
❌ “We just throw old hard drives in the trash” That’s how credit card data ends up on eBay. Destroy media properly.
❌ “Visitor logs? We’re a small company, we know everyone” Auditors don’t care. Document visitor access even in small environments.
❌ “We have cameras, but the recording system hasn’t worked in a year” Broken cameras are security theater, not actual security. Fix them.
👉 How to Implement
Month 1: 1. Identify all locations where cardholder data is stored or processed 2. Assess current physical security controls 3. Install badge readers or locks on sensitive areas if not present 4. Install video cameras covering entry/exit points
Month 2: 5. Implement visitor management process 6. Create visitor log (physical or digital) 7. Create/order visitor badges 8. Train reception/security on procedures
Month 3: 9. Audit who has physical access to sensitive areas 10. Revoke unnecessary access 11. Document access authorization for all personnel 12. Create quarterly access review process
Month 4: 13. Inventory all media containing cardholder data 14. Implement secure storage for media 15. Create media destruction procedures 16. Purchase shredders, degaussers, or contract destruction service
PCI DSS Requirement 10 : Log and Monitor All Access to System Components and Cardholder Data
What this really means: Track who does what, when, and where. Review those logs. Investigate anomalies.
👉 Why This Matters
Logs are your “black box” for security incidents. Without logs, you’re flying blind. When a breach happens (note I said “when,” not “if”), logs tell you: – How the attacker got in – What they accessed – When the breach started – What data was compromised
I’ve investigated dozens of breaches. The companies with good logging could contain and remediate quickly. The companies without logging spent months trying to figure out what happened—and often never knew the full extent
👉 What You Must Do
10.1: Implement audit trail for all access to cardholder data – User identification – Type of event – Date and time – Success or failure – Origination of event – Identity of affected data, system component, or resource
10.2: Log these events minimum: – All individual user access to cardholder data – All actions by users with admin privileges – All access to audit trails – Invalid logical access attempts – Changes to authentication mechanisms – Initialization, stopping, or pausing of audit logs – Creation and deletion of system-level objects
10.3: Record log entries with sufficient detail – Minimum: User ID, event type, date/time, success/failure, origination, identity/name of affected resource
10.4: Using time-synchronization technology – Keep all system clocks synchronized – Use NTP or similar – Time data is protected from unauthorized modification
10.5: Secure audit trails – Protect from unauthorized modification – Backup logs regularly – Write logs to centralized server or read-only media
10.6: Review logs daily – Review logs of critical systems daily – Implement automated tools to assist – Follow up on exceptions and anomalies
10.7: Retain audit trail history for one year – Minimum three months immediately available for analysis – Remainder can be archived offline
👉 Common Mistakes
❌ “We enabled logging, so we’re good” Enabling logging is step one. Are you reviewing those logs? Are they centralized? Are they secured?
❌ “We review logs when something seems wrong” That’s reactive, not proactive. Daily log review catches issues before they become breaches.
❌ “Our logs are spread across 47 different systems” Decentralized logs are nearly useless. Implement a SIEM or centralized log management.
❌ “We don’t log database queries because it impacts performance” Then you can’t detect SQL injection attacks or unauthorized data access. Find a different solution.
❌ “Our log server ran out of space six months ago” Logs aren’t optional. Provision adequate storage and implement log rotation.
👉 How to Implement
Month 1: Assess Current State 1. Identify all systems that require logging 2. Verify logging is enabled on each 3. Document what’s being logged 4. Identify gaps in logging coverage
Month 2: Centralize Logs 5. Select SIEM or log management solution 6. Configure log forwarding from all systems to central server 7. Ensure time synchronization across all systems 8. Test that logs are being received
Month 3: Secure and Analyze 9. Implement access controls on log server 10. Configure log retention (1 year) 11. Create automated alerts for critical events 12. Set up daily log review procedures
Month 4: Ongoing 13. Daily log reviews by security/IT staff 14. Weekly summary reports to management 15. Monthly review of logging configuration 16. Quarterly testing of log integrity
Requirement 11: Test Security of Systems and Networks Regularly
What this really means: Don’t assume your security controls work. Test them. Regularly
👉 Why This Matters
Security is not “set and forget.” Your environment changes constantly—new systems, new applications, new users, new configurations. Each change can introduce vulnerabilities.
Testing validates that your security controls are actually working. I’ve seen companies spend millions on firewalls, encryption, and access controls, only to fail basic penetration tests because nobody verified the controls were configured correctly.
👉 What You Must Do
11.1: Implement processes to test for wireless access points – Automated tools scan for wireless APs quarterly – Detect authorized and unauthorized wireless – Maintain inventory of authorized wireless APs – Investigate unauthorized wireless immediately
11.2: Run internal and external network vulnerability scans
External scans (internet-facing systems): – Quarterly minimum – After significant changes – By PCI SSC Approved Scanning Vendor (ASV) – Must achieve “passing” scan (no vulnerabilities rated 4.0+ CVSS)
Internal scans: – Quarterly minimum – After significant changes – Can be performed by qualified internal staff or external vendor – Must remediate high and critical vulnerabilities
11.3: Perform external and internal penetration testing – At least annually – After significant infrastructure or application changes – Test network layer and application layer – If segmentation is used, validate it’s effective – Address findings and retest
11.4: Implement intrusion detection/prevention systems – Monitor all traffic at perimeter of CDE – Monitor all traffic at critical points within CDE – Keep IDS/IPS signatures current – Generate alerts for suspicious activity
11.5: Implement file integrity monitoring (FIM) – Monitor critical files for unauthorized modification – Includes system files, configuration files, content files – Alert on changes – Review alerts at least weekly
11.6: Ensure security policies and procedures are updated – Review and update annually minimum – Review after significant changes – Ensure all personnel are aware of and follow security procedures
👉 Common Mistakes
❌ “We did a penetration test three years ago” Three years is ancient history in security. Annual testing is mandatory, more frequent is better.
❌ “We failed our ASV scan, but we’re working on it” You can’t submit failed scans for compliance. You must remediate and achieve passing scans.
❌ “Internal vulnerability scans are good enough; we don’t need penetration testing” Scans find known vulnerabilities. Pentests find unknown vulnerabilities and test exploit chains. Both are required.
❌ “Our IDS has 10,000 alerts per day, so we ignore them” Then your IDS is useless. Tune it to reduce false positives, or investigate why you’re getting so many real alerts.
❌ “File integrity monitoring slows down our servers” Use a lightweight FIM solution or monitor only critical files. Not optional.
❌ “We segment our network, but we’ve never tested if it actually works” Segmentation without validation is wishful thinking. Test it with penetration testing.
👉 How to Implement
Month 1: Wireless and Scanning 1. Deploy wireless detection tools 2. Scan for unauthorized wireless access points 3. Document authorized wireless 4. Sign up with PCI ASV for external scans 5. Run initial external vulnerability scan
Month 2: Internal Scanning 6. Deploy internal vulnerability scanning tool 7. Run baseline internal vulnerability scan 8. Prioritize findings by severity 9. Create remediation plan for high/critical
Month 3: IDS/IPS and FIM 10. Deploy IDS/IPS at network perimeter 11. Configure IDS/IPS rules and signatures 12. Deploy file integrity monitoring on critical systems 13. Baseline FIM (capture current state of files)
Month 4: Testing and Remediation 14. Engage penetration testing firm 15. Conduct annual penetration test 16. Review findings 17. Remediate identified vulnerabilities 18. Retest to validate remediation
Ongoing: 19. Quarterly ASV external scans 20. Quarterly internal vulnerability scans 21. Quarterly wireless scans 22. Annual penetration testing 23. Weekly FIM alert reviews
PCI DSS Requirement 12 :Support Information Security with Organizational Policies and Programs
What this really means: Security starts with people, not technology. Create policies, train staff, manage risk.
👉 Why This Matters
You can have the best firewalls, encryption, and monitoring in the world, but if your employees don’t know (or don’t care) about security, you will get breached.
Requirement 12 is about building a security culture. It’s the most overlooked requirement because it’s not technical—but it’s arguably the most important.
Every breach I’ve investigated involved human error at some point: – Someone clicked a phishing email – Someone used a weak password – Someone ignored a security alert – Someone didn’t follow procedures
Security awareness is your last line of defense.
👉 What You Must Do
12.1: Establish information security policy – Published and maintained – Disseminated to all users and relevant parties – Reviewed annually (minimum) – Updated as needed when environment changes
12.2: Implement a risk assessment process – Conduct formal risk assessment at least annually – Identify critical assets, threats, and vulnerabilities – Assess likelihood and impact – Document results – Update risk assessment when environment changes significantly
12.3: Develop usage policies for critical technologies – Clear policies for acceptable use of technology – Remote access policy – Wireless policy – Mobile device policy – Email and internet usage – Consequences for violations
12.4: Ensure security responsibilities are formally assigned – Define roles and responsibilities for security – Senior management responsible for security program – Information Security Officer or equivalent designated – Responsibilities documented and communicated
12.5: Assign security management responsibilities – Management of security policies and procedures – Monitoring security alerts and distributing to appropriate personnel – Creating escalation procedures for security incidents
12.6: Implement a formal security awareness program – Upon hire – At least annually thereafter – Make personnel aware of importance of security – Train on how to protect cardholder data – Educate on threats (phishing, social engineering, etc.)
12.7: Screen potential employees – Background checks prior to hire (where permitted by law) – Check references – Screen for positions with access to cardholder data
12.8: Maintain and implement policies for service providers – Maintain list of all service providers – Written agreement acknowledging service providers’ security responsibilities – Due diligence before engagement – Monitor service providers’ PCI DSS compliance annually
12.9: Document that service providers acknowledge security responsibilities – Written agreement – Service providers maintain their own PCI DSS compliance (if they store, process, transmit CHD)
12.10: Implement an incident response plan – Prepare to respond to security breach – Define roles, responsibilities, communication – Contact information for reporting incidents – Procedures for containment, investigation, remediation – Test incident response plan annually
(v4.0 adds 12.3.1: Roles and responsibilities for all personnel, documented and communicated)
👉 Common Mistakes
❌ “We have an information security policy… somewhere” If nobody knows where it is or what’s in it, it doesn’t exist. Publish it. Make it accessible.
❌ “We did security training during onboarding three years ago” Annual training is mandatory. Security threats evolve, training must too.
❌ “Risk assessments are just paperwork exercises” If you’re treating them that way, you’re wasting time. Risk assessments should drive security investments and priorities.
❌ “Our incident response plan is to call the PCI consultant if something happens” That’s not a plan. You need documented procedures, assigned roles, and practiced response.
❌ “We don’t have an Information Security Officer because we’re small” Somebody needs to own security. Title doesn’t matter. Accountability does.
❌ “Background checks? We trust our employees” Trust, but verify. This is especially important for positions with privileged access.
👉 How to Implement
Month 1: Policy Development 1. Create or update Information Security Policy 2. Create usage policies (remote access, mobile devices, acceptable use) 3. Define security roles and responsibilities 4. Get executive approval for policies 5. Publish policies to company intranet/shared drive
Month 2: Risk Assessment 6. Identify critical assets in CDE 7. Identify threats (external attackers, malware, insiders, etc.) 8. Identify vulnerabilities (missing patches, weak configs, etc.) 9. Assess likelihood and impact for each risk 10. Document risk assessment 11. Develop risk treatment plan
Month 3: Training and Awareness 12. Develop security awareness training program 13. Create training materials (videos, presentations, quizzes) 14. Schedule training for all personnel 15. Track completion 16. Plan for annual refresher training
Month 4: Incident Response 17. Create incident response plan 18. Define incident response team roles 19. Document escalation procedures 20. Create communication templates 21. Test incident response plan (tabletop exercise)
Ongoing: 22. Annual risk assessments 23. Annual policy reviews 24. Annual security awareness training 25. Annual incident response plan testing 26. Quarterly review of service provider compliance
Final Thought
PCI DSS compliance is a daunting task for organizations to meet, especially when the requirements are so detailed and elaborate. Even companies having the best of resources and genuine intent falter in the process and find it challenging to constantly maintain the standard.
Despite how difficult it is companies should strive to achieve PCI DSS Compliance by meeting all the 12 requirements outlined by the council. This is to prevent breaches and suffering significant consequences. Understanding each of the requirements and also referring to the compliance checklist shared by us in our blogs, organizations can surely achieve and continue to maintain compliance.
You can also watch the expert video on PCI DSS Requirements
Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.