PCI DSS Checklist 2026: All 12 Requirements Explained Simply

What Is PCI DSS and Why Does It Matter in India in 2026?

PCI DSS Merchant Levels: Where Do Indian Organisations Fit?

• Level 1: More than 6 million Visa or Mastercard transactions per year, or any merchant that has suffered a data breach. Requires an annual on-site QSA audit and quarterly network scan by an Approved Scanning Vendor (ASV).
• Level 2: 1 million to 6 million transactions per year. Requires annual SAQ or QSA assessment and quarterly ASV scan.
• Level 3: 20,000 to 1 million e-commerce transactions per year. Requires annual SAQ and quarterly ASV scan.
• Level 4: Fewer than 20,000 e-commerce transactions or up to 1 million total card transactions per year. Annual SAQ recommended; check with your acquiring bank for exact requirements.

• Level 1 Service Provider: Processes more than 300,000 transactions per year. Requires annual QSA audit and quarterly ASV scan.
• Level 2 Service Provider: Fewer than 300,000 transactions per year. Requires annual SAQ-D for service providers.

SAQ Types Explained for Indian Merchants

• SAQ A: For card-not-present merchants who have fully outsourced all cardholder data functions. Your website never touches card data; you use an iFrame or redirect to a PCI-compliant payment gateway. This is the simplest SAQ — around 22 requirements.
• SAQ A-EP: For e-commerce merchants who outsource payment processing but whose website could impact payment security. If your site loads JavaScript from third-party CDNs, uses custom checkout pages, or your server sits between the customer and the payment page, SAQ A-EP likely applies.
• SAQ B: For merchants with only imprint machines or standalone dial-up terminals. Rarely applicable to modern Indian merchants.
• SAQ B-IP: For merchants with standalone PTS-approved IP-connected terminals that do not store cardholder data.
• SAQ C: For merchants with payment application systems connected to the internet but no electronic cardholder data storage.
• SAQ C-VT: For merchants who process via web-based virtual terminals only.
• SAQ D (Merchant): The most comprehensive SAQ — applicable to merchants who store cardholder data electronically or who do not fit any other SAQ category.
• SAQ D (Service Provider): Required for all service providers eligible for self-assessment.

RuPay, Visa, and Mastercard PCI Requirements in India

PCI DSS v4.0 Overview: The 12 Requirements at a Glance

• Goal 1 — Build and Maintain a Secure Network: Requirement 1 (network security controls) and Requirement 2 (secure configurations)
• Goal 2 — Protect Account Data: Requirement 3 (protect stored data) and Requirement 4 (protect data in transit)
• Goal 3 — Maintain a Vulnerability Management Programme: Requirement 5 (anti-malware) and Requirement 6 (secure systems and software)
• Goal 4 — Implement Strong Access Control: Requirements 7 (access restriction), 8 (authentication), and 9 (physical access)
• Goal 5 — Regularly Monitor and Test Networks: Requirement 10 (logging and monitoring) and Requirement 11 (security testing)
• Goal 6 — Maintain an Information Security Policy: Requirement 12 (security policies and programmes)

Requirement 1: Install and Maintain Network Security Controls

• Define and document the Cardholder Data Environment (CDE) and all network connections into and out of it
• Implement network security controls at every CDE boundary (on-premises firewall, cloud security groups, WAF)
• Deny all traffic by default; allow only explicitly required flows
• Review firewall and router rules at least every six months and remove unnecessary rules
• Use DMZ architecture to segregate public-facing systems from internal CDE
• Document all permitted protocols and justify each; disable insecure protocols (Telnet, FTP, HTTP for sensitive data)
• Ensure wireless networks are isolated from the CDE or have equivalent controls

Requirement 2: Apply Secure Configurations to All System Components

• Change all vendor-supplied default passwords before deploying any system component
• Disable or remove all unnecessary services, protocols, and functions (e.g., disable SSH root login, remove unused web server modules)
• Develop configuration standards based on CIS Benchmarks or vendor hardening guides
• Apply configuration standards consistently using automation (Ansible, Chef, Terraform, AWS Systems Manager)
• Document all system components in inventory; include purpose and data classification
• Ensure non-console administrative access is encrypted (SSH, RDP over VPN)

Requirement 3: Protect Stored Account Data

• Audit all systems and data flows to identify where PAN or other account data is stored — including logs, databases, backups, and cache
• Delete any stored SAD immediately after authorisation; never log CVV, track data, or PIN
• If you must store PAN, use strong one-way hashing (SHA-256 with salt), tokenisation, or AES-256 encryption with robust key management
• Implement a data retention policy and automated deletion for card data beyond the retention period
• Render PAN unreadable on displays, printouts, and receipts — show maximum of first six and last four digits
• Document your encryption key management procedures: key generation, distribution, storage, rotation, and destruction
• Rotate cryptographic keys at least annually or when a custodian leaves

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

• Inventory all transmission channels where cardholder data flows, including API calls, webhooks, and batch file transfers
• Enforce TLS 1.2 minimum (TLS 1.3 preferred) on all endpoints that transmit card data
• Disable SSL, TLS 1.0, and TLS 1.1 on all servers — test using tools like SSLLabs or testssl.sh
• Use only trusted, valid TLS certificates from recognised Certificate Authorities
• Never send unencrypted PAN via email, SMS, WhatsApp, or messaging platforms — even internally
• Document all trusted keys and certificates used for data-in-transit encryption

Requirement 5: Protect All Systems and Networks from Malicious Software

• Deploy anti-malware software on all applicable system components — Windows, Linux, macOS endpoints and servers
• Ensure anti-malware definitions update automatically and at least daily
• Enable real-time scanning and log all malware detections; alert on detection
• Conduct periodic evaluations of systems not typically at risk from malware to confirm they remain low-risk
• Implement anti-phishing controls: email security gateways, DMARC/DKIM/SPF for your domain
• Protect users from malicious websites using DNS-layer security or web proxies

Requirement 6: Develop and Maintain Secure Systems and Software

• Maintain an inventory of all bespoke and custom software in the CDE
• Apply security patches: critical vulnerabilities within one month, others within three months of release
• Implement a formal change management process: test, approve, and document all changes before production deployment
• Train developers in secure coding practices — OWASP Top 10 is the baseline
• Conduct code reviews for all custom code before release to production; use SAST tools
• Deploy a Web Application Firewall (WAF) in front of all public-facing web applications that handle card data
• Implement a Content Security Policy (CSP) and inventory all payment page scripts (Requirement 6.4.3) — new in v4.0
• Confirm integrity of all scripts loaded on payment pages (SRI hashes or equivalent) — prevents Magecart/web-skimming attacks

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

• Define and document access control policies with role-based access profiles
• Grant access based on the least privilege principle — staff should not have access beyond what their role requires
• Review user access rights at least every six months and revoke unnecessary access
• Maintain an access control list for all CDE system components
• Ensure service accounts and API credentials are scoped to minimum required permissions
• Use group policies and identity management platforms (e.g., Azure AD, Okta, AWS IAM) to enforce access controls

Requirement 8: Identify Users and Authenticate Access to System Components

• Assign unique user IDs to every individual; never use shared or generic accounts in the CDE
• Enforce MFA for ALL access into the CDE — including from internal networks (new in v4.0)
• Use MFA for all administrative access and all remote access — hardware tokens, authenticator apps, or certificate-based authentication
• Set strong password policy: minimum 12 characters (increased from 7 in v3.2.1), complexity requirements, no reuse of last four passwords
• Lock accounts after six or fewer invalid access attempts
• Set session timeout: automatically lock idle sessions after 15 minutes of inactivity
• Prohibit group or shared authentication credentials
• Immediately revoke access for terminated employees — within 24 hours is best practice; immediately is required for high-risk terminations
• Maintain an inventory of all user accounts with access to CDE and review quarterly

Requirement 9: Restrict Physical Access to Cardholder Data

• Restrict physical access to server rooms and network equipment rooms with badge access, biometric controls, or key locks
• Maintain a visitor log for any physical access to sensitive areas; verify and log all visitors
• Use video surveillance (CCTV) at all entry points to sensitive areas and retain footage for at least 90 days
• Secure all physical media (backup tapes, USB drives, paper records) containing cardholder data in locked storage
• Classify and label physical media; track all media movements with a chain-of-custody log
• Destroy media securely when no longer needed: shred paper, degauss or physically destroy hard drives
• Inspect POS terminals at least once every three months for evidence of tampering or skimming devices
• Train staff to recognise skimming devices and report suspicious tampering immediately

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

• Enable audit logging on all CDE system components: operating systems, databases, applications, network devices, firewalls
• Log all individual user access to cardholder data, all administrative actions, all access to audit logs, invalid access attempts, use of privilege escalation, and changes to audit log configuration
• Synchronise all system clocks using NTP to ensure log correlation is accurate
• Protect audit logs from unauthorised modification: write to a separate log server, use WORM storage, or use a SIEM
• Retain logs for at least 12 months; minimum three months must be immediately available for analysis (aligns with CERT-In's 180-day retention)
• Review logs daily — use automated alerting in a SIEM (Splunk, Microsoft Sentinel, Wazuh) to identify anomalies
• Investigate and respond to all exceptions and anomalies detected in daily log reviews

Requirement 11: Test Security of Systems and Networks Regularly

• Conduct quarterly internal vulnerability scans using approved scanning tools; remediate critical and high vulnerabilities promptly
• Conduct quarterly external vulnerability scans using a PCI SSC Approved Scanning Vendor (ASV); achieve a passing scan
• Perform annual penetration testing — both network and application layers — using a qualified penetration tester
• Perform penetration testing after significant infrastructure changes or application upgrades
• Use segmentation penetration testing every six months (or annually with a QSA, if segmentation is used to reduce PCI scope)
• Deploy Intrusion Detection/Prevention Systems (IDS/IPS) at the CDE perimeter
• Implement a change-detection mechanism (file integrity monitoring) on critical files, configuration files, and application executables in the CDE
• Review IDS/IPS alerts daily; investigate and document all alerts

Requirement 12: Support Information Security with Organisational Policies and Programmes

• Publish and maintain a comprehensive information security policy reviewed and updated at least annually
• Conduct an annual risk assessment to identify threats, vulnerabilities, and their potential impact on the CDE
• Maintain an inventory of all third-party service providers (TPSPs) that handle cardholder data
• Execute written agreements with each TPSP confirming their PCI DSS compliance obligations
• Monitor TPSP compliance status at least annually — obtain their Attestation of Compliance (AOC) or ensure they are listed on Visa's GPRS
• Run a security awareness programme: train all staff on their security responsibilities before access is granted and at least annually thereafter
• Include social engineering and phishing awareness in training — particularly relevant given the frequency of vishing attacks targeting Indian fintech employees
• Maintain an incident response plan; test it at least annually
• Establish a responsible disclosure / vulnerability reporting mechanism
• Define roles and responsibilities for PCI DSS compliance and assign a named individual responsible for the programme

Common PCI DSS Compliance Gaps Found in Indian Organisations

• Incomplete CDE scoping: Many organisations underestimate the CDE scope, particularly when cloud services, third-party integrations, and internal analytics tools inadvertently touch card data
• Weak key management: Encryption keys stored in application config files, source code repositories, or shared across environments without rotation
• Missing MFA on internal CDE access: MFA enforced only on VPN but not on direct SSH/RDP access to production servers — now non-compliant under v4.0
• Uncontrolled third-party scripts on payment pages: GTM containers, ad pixels, and chat widgets loaded on checkout pages without script inventory or integrity verification (Requirement 6.4.3 gap)
• Insufficient log retention: Logs deleted after 30 or 90 days rather than the required 12 months
• Shared admin credentials: Database or server admin passwords shared across teams via WhatsApp or internal wikis
• No formal vendor risk management: TPSPs used without written agreements or annual compliance verification
• Patch lag: Critical vulnerabilities left unpatched for three to six months because change management processes are slow
• Inadequate penetration testing: Automated vulnerability scans submitted instead of manual penetration testing by a qualified professional

QSA Assessment vs Self-Assessment: Which Does Your Organisation Need?

Typical PCI DSS Compliance Timeline for Indian Fintechs

• Month 1 — Scoping and Gap Assessment: Define CDE scope, identify all data flows, conduct gap assessment against PCI DSS v4.0 requirements, produce a prioritised remediation roadmap
• Month 2-3 — Quick Wins and Critical Remediations: Implement MFA on all CDE access, rotate default credentials, enable comprehensive logging, segment CDE from non-CDE networks, deploy WAF
• Month 3-4 — Policy and Process Development: Write or update information security policy, risk assessment, incident response plan, vendor management framework, and change management procedures
• Month 4-5 — Technical Controls and Testing: Complete patch cycle, implement file integrity monitoring, deploy IDS/IPS, conduct internal vulnerability scan, engage ASV for external scan
• Month 5-6 — Penetration Testing and Remediation: Conduct full penetration test, remediate critical findings, validate remediation, conduct security awareness training
• Month 6 — Assessment and Attestation: Complete ROC with QSA (Level 1) or complete SAQ (Level 2-4), obtain passing ASV scan, submit Attestation of Compliance (AOC) to acquiring bank

PCI DSS v4.0 New Requirements to Watch in 2026

• Requirement 3.3.3: Prohibition on storing SAD even in encrypted form — close any gaps where your systems retain CVV or track data post-authorisation
• Requirement 6.4.3: Inventory, authorisation, and integrity verification of all scripts on payment pages — requires technical implementation, not just documentation
• Requirement 8.3.6: Minimum password length increased to 12 characters — update your identity management platform and password policies
• Requirement 8.4.2: MFA required for all access to the CDE, including from within trusted networks — a significant expansion from v3.2.1
• Requirement 10.7.2: Failures of critical security controls must be detected, alerted, and addressed promptly — requires automated monitoring of your security tooling
• Requirement 11.6.1: Implement a change-detection mechanism for payment page HTTP headers and script content — targets web-skimming attack detection
• Requirement 12.3.2: Targeted Risk Analysis (TRA) required to justify deviations from standard control frequencies — document and justify any customised approaches

Why Choose CyberSigma for PCI DSS Compliance?

• PCI DSS Gap Assessment: Comprehensive assessment against all 12 requirements of PCI DSS v4.0, with a prioritised remediation roadmap tailored to your technology stack
• CDE Scoping and Architecture Review: Help you accurately define and minimise your cardholder data environment to reduce compliance scope and cost
• Penetration Testing: Network and web application penetration testing by CERT-In empanelled testers with specific experience in payment application security
• Vulnerability Assessment and Management: Quarterly internal vulnerability assessments and coordination with approved ASVs for external scans
• QSA Readiness Programme: Pre-assessment preparation to ensure your organisation passes the QSA audit on the first attempt, saving time and re-assessment costs
• Managed Compliance Monitoring: Ongoing monitoring services to maintain compliance between annual assessments, including log review, patch management, and control validation
• Security Awareness Training: Custom training programmes for fintech teams covering PCI DSS obligations, social engineering, phishing, and secure coding practices

Frequently Asked Questions

Authored By

Naveen Kumar

CyberSigma is a CERT-In empanelled cybersecurity firm helping Indian businesses with VAPT, ISO 27001, PCI DSS, SOC 2 and DPDP compliance — delivered by senior auditors.