Let's Be Honest About PCI Audits
Nobody looks forward to a PCI DSS audit. But here's the thing: The audit itself isn't the problem. The problem is showing up unprepared.
I've sat in rooms where someone sketched a network diagram on a whiteboard that had zero connection to what was actually running in their environment. I've sat through meetings where nobody could answer basic questions about where card data actually lives. That's not an audit problem. That's a preparation problem.
The pressure's on in India more than ever. Since March 31, 2025, PCI DSS v4.0.1 has been the only version that counts. RBI guidelines now require Payment Aggregators to ensure their merchants comply with PCI DSS. NPCI expects it from UPI and IMPS participants. Visa and Mastercard enforce it through acquiring banks. This checklist covers exactly what you need to do before the auditor arrives. No fluff. No theory. Just practical steps that work.
 Pre-Assessment Guide for PCI DSS v4.0.1 Compliance, Security Controls & Audit Readiness.jpg)
The 12 PCI DSS Requirements at a Glance
Before we get into the nitty-gritty, here's your high-level map. These 12 requirements apply to everything in your Cardholder Data Environment. No exceptions.
| # | What It Covers | In Plain English |
|---|---|---|
| 1 | Network security controls | Firewalls, routers, segmentation — keep the bad guys out |
| 2 | Secure configurations | Default passwords? Change 'em. Default settings? Change 'em. |
| 3 | Protect stored data | Got data you don't actually need? Then don't hang onto it. Simple. |
| 4 | Protect data in transit | Encryption over public networks. Non-negotiable. |
| 5 | Anti-malware | AV, EDR, whatever works — just have it and update it. |
| 6 | Secure development | Patch your stuff. Write secure code. Test it. |
| 7 | Access restriction | Need-to-know only. Everyone else stays out. |
| 8 | Authentication | Strong passwords + MFA. No shortcuts. |
| 9 | Physical security | Who can walk into your server room? Track it. |
| 10 | Logging | Know who did what, when, and where. |
| 11 | Testing | Scan, test, repeat. Quarterly and annually. |
| 12 | Policies | Write it down. Train your people. Follow it. |
Step 1: Understand Your Scope
Before you do anything else, figure out what's actually in scope.
What This Means:Your Cardholder Data Environment (CDE) covers every system, network, and application that comes anywhere near card data. If it stores, processes, or transmits card info, it's in scope. Period.
What to Document:
- Point-of-sale systems and payment terminals
- Payment gateways and processors
- Web servers and application servers
- Databases storing card data
- Network devices (firewalls, routers, switches) connecting to the CDE
- Domain controllers authenticating users in the CDE
- Log management and SIEM systems
- Key management and encryption systems
- Backup servers
- Cloud environments and third-party connections
Common Mistake:Teams forget about domain controllers. A domain controller might not store card data directly, but if it controls access to systems that do, it's in scope. Same with backup servers. Even if you don't store card data in production, backups might.
Step 2: Network Security & Access Controls (Requirements 1-2)
Firewall Configuration: Document all firewalls protecting your CDE. Verify that firewall rules are documented and tested. Pull your firewall ruleset and have it ready for the auditor to go through.
Default Credentials Removal: Run a sweep across every system — routers, switches, databases — hunting for default credentials. Shut down any unused default accounts right away.
Network Diagrams:Create a current, detailed network diagram showing your CDE boundaries, DMZs, and data flows. Mark each system's role — POS terminals, payment gateways, and databases.
Wireless Networks: If you have wireless networks, confirm WPA2/WPA3 encryption, strong passphrases (minimum 20 characters), and isolation from CDE systems.
Access Control Lists (ACLs): Review and update ACLs on all systems. Ensure a deny-all-by-default approach with explicit allow rules.
Network Segmentation: Verify that payment systems are isolated from guest and public networks. Test firewall rules blocking unauthorized CDE access. Proper segmentation reduces your compliance scope and saves money.
Step 3: Securing Data Through Encryption (Requirements 3 & 4)
Cardholder Data Inventory:List every system storing, processing, or transmitting card data — full PAN, CVV, expiry. Identify systems that shouldn't hold this data and plan remediation.
Encryption in Transit: Confirm TLS 1.2 or higher for all card data transmission. Test SSL/TLS certificates for validity, proper cipher suites, and no downgrade vulnerabilities. TLS 1.1 is no longer acceptable under v4.0.1.
Encryption at Rest: Verify strong encryption (AES-256 minimum) for stored card data. Document your encryption key management — no hardcoded keys allowed.
PAN Truncation/Tokenization: Confirm that Primary Account Numbers are masked on receipts, logs, and screens. Implement tokenization where possible to reduce your compliance scope.
Password Hashing: Ensure user passwords are hashed — never encrypted — using PBKDF2, bcrypt, or Argon2.
Step 4: Access Management & Identity (Requirements 5-8)
User Access Inventory: Generate reports of all active user accounts with access to the CDE. Flag shared accounts, service accounts, and unused credentials for removal.
Multi-Factor Authentication (MFA): MFA is no longer optional. Implement MFA for all remote and administrative access to the CDE. Confirm MFA is enabled for all privileged users. Under v4.0.1, MFA requirements have expanded beyond just administrators. All non-console access into the CDE now requires MFA.
Role-Based Access Control (RBAC): Map user roles to actual business functions. Ensure the least-privilege principle applies everywhere.
Password Policy Audit: Verify minimum 12 characters, complexity requirements, 90-day rotation, and prevention of reuse. Test policy enforcement on all systems.
Access Review Documentation:Keep a log of every quarterly access review you do. Flag any accounts tied to employees who've left, people who've switched roles, or anyone whose access no longer makes sense. Shut those down.
Anti-Malware Protection:Every system needs an active antivirus. Make sure it's installed, turned on, and actually working. Check when updates are pushed and when the last scan ran.
Step 5: Vulnerability Management & Monitoring (Requirements 6-10)
Patch Management Schedule: Document patch testing and deployment timelines. Critical patches must be applied within 30 days. Standard patches can be done quarterly.
Vulnerability Scans: Run internal and external vulnerability scans quarterly. Address critical and high findings immediately. Document remediation or risk acceptance with sign-off.
Penetration Testing:You're required under PCI DSS 11.3 to run penetration tests every year. That means both external and internal. And if you roll out major changes to your infrastructure, plan for extra tests.
System Hardening Baseline: Check that every unnecessary service and port is shut down. Make sure host-based firewalls, antivirus, and hardening follow the CIS Benchmarks.
Change Management Process: Document change control procedures. Gather evidence of approval, testing, and deployment for recent CDE changes (last 3-6 months).
Logging & Log Retention:Verify all systems' log access to the CDE. Confirm logs are centralized, protected, and retained for 12 months. Test log integrity — no deletion or modification allowed.
Client-Side Script Monitoring (6.4.3 & 11.6.1):
This is new in v4.0.1. You're now responsible for tracking every single script that runs on your payment pages. Authorizing them, monitoring them, and making sure nothing unauthorized sneaks in.
This requirement exists because of attacks like Magecart — where attackers slip malicious JavaScript into payment pages and steal card data right from the browser. Server-side security never detects it.
What this means practically:
- A complete inventory of every script on payment pages.
- Business justification for each script.
- Integrity monitoring to detect unauthorized changes.
- Using tools like Content Security Policy (CSP) headers and Subresource Integrity (SRI) checks.
Step 6: Compliance & Governance (Requirements 11-12)
Risk Assessment Documentation: Complete an annual risk assessment identifying threats, vulnerabilities, and likelihood. Document mitigation strategies. RBI expects this for all Indian payment processors.
Information Security Policy: Maintain a formal, board-approved security policy covering all 12 PCI DSS areas. Ensure all employees acknowledge receipt annually.
Incident Response Plan: Document detection, investigation, and response procedures for data breaches. Ensure legal counsel and notification protocols align with the DPDP Act and RBI guidelines.
Vendor Management: Maintain a list of all third-party vendors with CDE access — cloud providers, integrators, payment gateways. Confirm their PCI compliance status via attestation letters or audit reports.
Security Awareness Training: Track completion of annual PCI DSS security training for all staff. Maintain certificates for 12 months.
Testing Schedule: Compile evidence of quarterly internal network scans, annual external vulnerability scans, annual penetration testing, and annual risk assessments.
Quick Readiness Checklist
Interactive checklist. Track your organization's pre-assessment status:
Pre-Audit Timeline
What Actually Goes Wrong
Scope Creep
This one gets teams every time. You define your CDE too tightly, miss a system here, overlook a connection there. Then the QSA shows up and finds it. Scope doubles. Costs explode. Deadlines slip.
Fix: Trace every data path. Talk to every department. Never assume — always verify.WAF Misconfiguration
You've got a WAF. Great. But is it actually set up for your apps? Default rules rarely work. Logging is off. Alerts are sitting in inboxes nobody checks.
Fix: Run tests. Try to crack it. Patch it up. Do this before your auditor does.Quarterly Scan Neglect
You're treating quarterly scans like a yearly task. Big mistake. If you miss a quarter, you break the continuous compliance chain.
Fix: Set up automation. Get a managed service. Stay on top of every requirement.Poor Documentation
Your controls exist, but can you prove it? If you can't show it with logs, configs, or signatures, to the auditor it doesn't count.
Fix: Set up a central compliance evidence hub. Keep it updated throughout the year.How ARM Innovations Helps Indian Businesses
Here's the thing about PCI DSS compliance in 2026. It's technically demanding — more than any previous version. And with RBI guidelines, NPCI requirements, and DPDP Act obligations, Indian businesses have more to navigate than ever.
What ARM Innovations Offers:
ARM Innovationscombines human intelligence with automated rigor. Their pentesters don't just scan — they actively try to bypass your security controls. You fix holes before the official assessment. When you choose them, you're not just hiring a PCI DSS consultant. You're getting a partner who stays with you through the whole process — from readiness assessment to post-audit maintenance.
About the Author
ARM Innovations is a CERT-In empanelled cybersecurity company providing PCI DSS audit services, penetration testing, vulnerability assessment, secure code review, and compliance services across 7 countries, including India. Their QSA-led team combines human intelligence with automated rigor to deliver depth that scanners can't match. With expertise in both global standards and Indian regulatory requirements, they help organizations achieve and maintain compliance with confidence.