Key Takeaways
- PCI DSS compliance is defined around 12 security requirements grouped under 6 security goals. Each requirement is mapped to a control that organizations must implement and maintain.
- The current active version is PCI DSS 4.0, which went live in March 2025.
- There are 4 merchant compliance levels, determined by annual card transaction volume.
- Self-Assessment Questionnaires (SAQs) must be completed annually or after major changes.
- External audits by a Qualified Security Assessor (QSA) are required for Level 1 merchants.
- Non-compliance can result in fines, increased transaction fees, and loss of card processing privileges.
Financial infrastructure continues to be a prime target for malicious actors due to card data and sensitive PII. A single breach can result in massive financial losses, heavy regulatory fines, loss of customer trust, and even business-ending consequences.
Despite its critical importance, achieving and maintaining PCI DSS compliance has become increasingly difficult.
Today’s payment systems are built on dynamic cloud architectures, containerized applications, microservices, and rapid CI/CD pipelines. Mapping the 12 PCI DSS requirements to these modern environments often feels complex, ambiguous, and time-consuming for both security and engineering teams.
That’s exactly why we created this PCI DSS Compliance Checklist.
What is PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) is a global security standard established by major card brands (Visa, Mastercard, American Express, Discover, and JCB) to ensure that all organizations that process, store, or transmit cardholder data maintain a secure environment.
First released in 2004 and now in version 4.0.1, PCI DSS defines 12 core security requirements that focus on protecting the confidentiality, integrity, and availability of cardholder data.
Whether you’re a fintech startup, e-commerce platform, or large enterprise, if you handle credit or debit card data, PCI DSS applies to you.
PCI DSS Compliance Checklist: 12 Steps to Avoid Penalties
Achieving PCI DSS compliance is about translating the 12 requirements into living, automated, and verifiable security controls that secure cardholder data in a modern, dynamic infrastructure.
| S. No | Requirement | What it covers |
|---|---|---|
| 1 | Install and maintain network security | Establish and maintain a network perimeter with strong security measures |
| 2 | Apply secure config to all system components | Remove vendor defaults and insecure configs |
| 3 | Protect cardholder data | Minimize and securely store cardholder data |
| 4 | Secure cardholder data during transit | Encrypt cardholder data in transit over public networks |
| 5 | Protect all systems and networks from malicious software | Deploy and maintain an anti-malware solution |
| 6 | Develop and maintain secure systems and software | Implement patches and manage systems properly |
| 7 | Restrict access to cardholder data | Follow “need-to-know” principle |
| 8 | Identify users and authenticate access to data | Use strong identification and authentication practices |
| 9 | Restrict physical access to cardholder data | Control physical access to the Cardholder data environment |
| 10 | Log and monitor the network resources and cardholder data | Track all access to systems and cardholder data |
| 11 | Test the security of systems and networks | Regularly pentest and monitor for vulnerabilities |
| 12 | Support infosecurity with policies and programs | Maintain an effective information security policy and program |
This checklist takes a pragmatic, implementation-first approach, focusing on the intent behind each requirement, the real-world technical challenges teams face today, and modern implementation patterns that help pass QSA audits while keeping pace with rapid infrastructure changes.
1. Install and maintain network security controls
Proper network security is the primary boundary separating your cardholder data environment (CDE) from external networks. PCI DSS requires both stateful packet inspection at the perimeter and internal network segmentation to isolate CDE from the rest of the network.
PCI DSS requires merchants to properly implement firewalls and other network security measures to ensure network security.
What it requires in practice
- Document all network connections to the CDE
- Restrict inbound and outbound traffic to what is necessary.
- Implement controls between trusted and untrusted networks.
- Review firewall and router rule sets at least every six months.
- Prohibit direct public access between the internet and the CDE
| Common Gaps | PCI reference | Implementation |
|---|---|---|
| Firewall rules never reviewed | 1.3.2 | Schedule bi-annual rule reviews with a named owner |
| Network diagrams are outdated or fail to reflect new changes | 1.2.4 | Maintain diagrams in a version-controlled tool, so any CDE-touching change triggers a diagram review |
| CDE systems have unrestricted outbound internet access | 1.3.4 | Implement egress filtering on all CDE systems and whitelist only known, approved destinations |
| Wireless networks are not segmented from the CDE | 1.3.3 | Treat all wireless traffic as untrusted until authenticated and authorized |
2. Discarding vendor default settings for enhanced security
Default configurations supplied by vendors for systems and apps are often insecure, making them an easy target for attackers. To abide by PCI DSS, businesses must not use vendor-provided defaults for system passwords and other security parameters.
This step in the PCI DSS checklist necessitates altering default credentials, configurations, and settings for all devices, hardware, and software applications utilized within your organization. In addition, organizations need to uphold documentation delineating their security configuration practices.
What it requires in practice
- Change default usernames, passwords, and security settings.
- Remove or disable unnecessary accounts, services, features, and protocols.
- Maintain a proper inventory of security configuration standards for all system components.
| Common Gaps | PCI reference | Implementation |
|---|---|---|
| Default vendor credentials left unchanged | 2.1.1 | Enforce credential rotation as part of build/deployment checklists |
| Unnecessary services (FTP, Telnet, HTTP) are still running on CDE systems | 2.2.4 | Use configuration scanning tools to detect and report any active service not on an approved whitelist |
3. Safe storage of cardholder data
The heart of the PCI DSS compliance checklist is protecting cardholder information. Organizations need to minimize the cardholder data they retain for legitimate purposes and implement strong protection to keep it secure.
PCI DSS requirement 3 mandates that organizations render PAM unreadable through tokenization or other approved methods if they must be retained.
Sensitive authentication data (SAD) (e.g., full track data, CVV/CVC codes) must never be stored after authorization under any circumstances.
What it requires in practice
- Define and enforce a data retention policy.
- Never store sensitive authentication data after authorization.
- Mask PANs when displayed.
- Implement a formal key management process.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| Sensitive authentication data (CVV, full track) stored in logs or databases post-authorization | 3.2.1 | Implement data loss prevention (DLP) rules and filters to block SAD from being written to persistent storage |
| Encryption keys are stored alongside the data they protect | 3.7.1 | Store keys in a dedicated HSM or key management service (e.g., AWS KMS, Azure Key Vault) separate from the encrypted data; |
| No formal key rotation schedule | 3.7.4 | Retiring keys after a specific period and documenting all rotation events |
4. Safe transmission of cardholder data
This step in the PCI DSS requirements checklist centers on the risk of cardholder data being intercepted while traveling across open, public networks.
Data exchanged between systems, such as between a retailer and a payment processor, can become a prime target for cybercriminals. Therefore, businesses must ensure that cardholder data is properly encrypted before transmission.
What it requires in practice
- Use strong cryptography for all PAN transmissions over open networks.
- Never send unprotected PANs via end-user messaging technologies.
- Disable weak or deprecated cipher suites
- Validate server certificates on the receiving end.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| TLS 1.0 or 1.1 still enabled on payment-facing endpoints for backward compatibility | 4.2.1 | configure web servers to reject TLS below 1.2 and enforce via load balancer or WAF policy |
| Weak cipher suites (RC4, 3DES, NULL) still advertised by servers | 4.2.1 | Apply recommended TLS configurations |
| PANs are transmitted via email or messaging for customer service or internal purposes | 4.2.2 | Train staff on prohibited transmission methods and implement DLP policies to block PAN-containing emails |
5. Protect all systems and networks from malicious software
Merely installing antivirus software does not fulfill this step of the PCI compliance checklist. Regular updates and patches for antivirus software are essential to protect against malware and other threats that could compromise the integrity of the system and cardholder data. This step in the PCI checklist ensures that your defensive mechanisms are up to date and prepared to combat emerging cybersecurity threats.
The antivirus software should operate across the entire IT infrastructure, including servers, workstations, and employee devices.
What it requires in practice
- Deploy anti-malware solutions on all applicable system components.
- Ensure anti-malware performs ongoing or periodic scans.
- Prevent anti-malware from being disabled or altered by users.
- Evaluate systems not commonly affected by malware on a periodic basis.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| Anti-malware signature out of date on CDE systems due to poor update policies | 5.2.2 | Configure anti-malware solutions to update signatures automatically at least daily |
| Linux and Unix CDE servers are excluded from anti-malware with no formal risk evaluation | 5.2.3 | If Linux malware risks are deemed acceptable, retain written justification signed by a responsible executive |
| No phishing controls in place | 5.4.1 | Implement DMARC, DKIM, and SPF on all mail domains |
6. Secure systems and applications deployment
This step in the PCI compliance checklist involves identifying and categorizing risks before deploying any technology used to process or handle sensitive payment card information. Businesses must conduct a comprehensive risk assessment to understand their current systems’ and applications’ threat landscape and vulnerabilities.
Once risks have been evaluated, businesses can then introduce necessary equipment and software in compliance with PCI standards. Timely patching is also a critical component of this step, ensuring databases, point-of-sale terminals, and operating systems are up-to-date, thereby minimizing the risk of breaches due to known vulnerabilities.
What it requires in practice
- Apply security patches as soon as possible.
- Conduct risk assessments before deploying a new tool or technology in CDE.
- For public-facing web apps, conduct pentesting with a PCI ASV vendor like Astra Security.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| Payment page scripts are not inventoried, and third-party scripts are loaded without oversight | 6.4.3 | Implement a Content Security Policy (CSP) on all payment pages |
7. Necessary restriction of cardholder data
This step in the PCI DSS checklist stipulates that access to sensitive data should be granted only on a need-to-know basis to avoid unnecessary exposure.
As per PCI DSS requirement 7, access to cardholder data should be granted only to individuals who need it to perform their job functions.
Organizations must maintain a detailed access control policy, outlining who has access to cardholder data, to what extent, and for what reason. This includes documenting the access levels each user has and ensuring they stay updated.
What it requires in practice
- Define access control policies based on the business need-to-know.
- Implement role-based or attribute-based access controls.
- Review user access rights at least every six months.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| Users have far more access than their role requires | 7.2.1 | Revoke any access that cannot be tied to a current business need |
| Service and application accounts with excessive privileges are used for multiple purposes | 7.2.6 | Audit all non-human accounts and restrict each service account to the minimum privileges needed for its specific function |
| Access is not revoked promptly when employees change roles or leave the organization | 7.2.4 | Integrate access provisioning with HR systems so that role changes and terminations automatically trigger access modification workflows |
8. Unique user access identification
PCI DSS requirement 8 mandates that every user in a system must have a unique identifier. Shared or group usernames or passwords should never be used, as they complicate tracking user activities and heighten security risks. Each user’s unique access credentials should be complex enough to discourage unauthorized access.
Unique access identifiers serve two purposes. They not only deter unauthorized access but also enable traceability in the event of a data breach. User activities can be traced back to specific users, aiding incident response and future preventive measures. For enhanced security, the PCI DSS also advocates the use of multi-factor authentication.
What it requires in practice
- Assign unique IDs to all users.
- Require MFA for all access to the CDE.
- Enforce strong password and passphrase policies.
- Lock out accounts after no more than 10 failed authentication attempts.
- Manage all authentication factors securely.
- Terminate idle sessions after not more than 15 minutes of inactivity.
| Common Gaps | PCI Reference | Implementation | ||
|---|---|---|---|---|
| Weak password policies allowing short or simple passwords | 8.3.6 | Enforce minimum 12-character passwords via Group Policy, PAM, or IdP settings | ||
| Inactive or terminated user accounts are not disabled promptly | 8.2.6 | Automatically disable accounts inactive for more than 90 days |
9. Physical access restrictions to data
Physical security is as important as digital security. Unauthorized physical access to servers, point-of-sale terminals, or paper records containing cardholder data can lead to breaches that no software control can prevent.res.
What it requires in practice
- Enforce no physical entry to the CDE for authorized individuals.
- Distinguish and manage physical access for visitors.
- Render cardholder data on media unrecoverable when no longer needed.
- Protect point-of-interaction devices from tampering and substitution.
- Train staff to identify and report suspicious POI behavior.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| POI device inventory is not maintained | 9.5.1 | Create and maintain a POI device register with serial number, make/model, location, and assigned custodian |
| Media destruction not documented as decommissioned drives may retain cardholder data | 9.4.6 | Obtain and retain certificates of destruction for every decommissioned storage device; include media destruction in asset retirement procedures |
| Visitor access logs are not maintained or reviewed, and visitors enter unescorted | 9.3.1 | Implement a digital visitor management system at all CDE entry points |
10. Continuous monitoring of network access
Given the ongoing threat landscape, businesses must continuously monitor their network access points. This includes both physical and wireless networks, all of which need consistent protection and surveillance. To fulfill this step in the PCI DSS requirements checklist, businesses should maintain a comprehensive record of network activity, providing a foundation for security audits and investigations.
Businesses can utilize Security Information and Event Management (SIEM) tools to help log system activity and alert to any potential security anomalies. According to the PCI compliance requirement 10, these audit trail records must be maintained and synchronized for at least one year.
What it requires in practice
- Log all access to system components, including failed attempts.
- Retain audit logs for at least a year.
| Common Gaps | PCI reference | Implementation |
|---|---|---|
| Logs are stored locally on the systems they record, so admins can delete their own activity logs | 10.3.3 | Forward all logs to a centralized SIEM in real time and configure write-once or immutable log storage |
| System clocks are not synchronized, causing timestamp gaps that break log correlation during investigations | 10.6.1 | Enforce NTP synchronization and monitor clock drift for deviating by more than one second |
11. Regular testing of systems and processes
Pentesting identifies vulnerabilities before attackers can exploit them. PCI DSS mandates a structured cadence for both automated scans and manual penetration testing.
11.3 and 11.4 of PCI DSS require organizations to conduct vulnerability scans and penetration tests regularly to identify potential security gaps and address them proactively.
What it requires in practice
- Perform wireless access point scans quarterly.
- Conduct internal and external vulnerability scans at least quarterly.
- Perform penetration testing at least annually and after significant changes.
- Use intrusion detection and intrusion prevention systems.
- Test change-related impacts before deploying to production.
- Monitor for unauthorized files and software.
| Common gaps | PCI reference | Implementations |
|---|---|---|
| Quarterly vulnerability scans missed or not remediated | 11.3.1 | Use automated vulnerability platforms like Astra Security’s Orbitx |
| Penetration tests | 11.4.1 | Engage a qualified external penetration testing firm at least annually and ensure the test scope covers all CDE entry points, both network and application layers. |
| IDS/IPS signatures not updated; alerts not reviewed or acted upon | 11.5.1 | Enable automatic signature updates on all IDS/IPS sensors |
No other pentest product combines automated scanning + expert guidance like we do.
Discuss your security
needs & get started today!
12. Establishment of an information security policy
This step in the PCI compliance checklist is to build, implement, and consistently update a broad information security policy. Technical controls are only as strong as the organizational structures, policies, and human behaviors that support their implementation.
Requirement 12 mandates a comprehensive information security policy, a formal risk assessment process, a vendor management program, and a strong incident response plan, all of which are reviewed and updated regularly to remain relevant as the threat landscape and business environment evolve.
What it requires in practice
- Establish and publish a comprehensive information security policy.
- Perform a formal risk assessment at least annually.
- Implement a security awareness program for all personnel.
- Manage third-party service providers formally.
- Maintain an incident response plan and test it annually.
- Assign responsibility for PCI DSS compliance to a named individual or team.
| Common Gaps | PCI Reference | Implementation |
|---|---|---|
| Security policy exists, but is outdated and not reviewed regularly | 12.1.1 | Set annual review reminders to update the security policy based on the threats |
| Risks are identified ad hoc without documentation or prioritization | 12.3.1 | Adopt a structured risk assessment methodology (ISO 27005, NIST SP 800-30) and conduct assessments annually and after major environmental changes |
| TPSP inventory not maintained. | 12.8.1 | Build a vendor register with PCI DSS scope for each TPSP |
| Staff are unaware of their IR roles | 12.10.2 | Conduct an annual IR tabletop exercise covering a realistic breach scenario to ensure all CDE-touching staff know who to contact if they suspect a breach |
What are PCI DSS self-assessment questionnaires (SAQs)?
A Self-Assessment Questionnaire (SAQ) is a validation tool provided by the PCI Security Standards Council. Merchants and service providers use SAQs to self-report their compliance status when they are not required to engage a Qualified Security Assessor (QSA).
Each SAQ comprises a sequence of yes-or-no queries concerning the security controls installed throughout your cardholder data environment. These queries map directly to the PCI DSS requisites, simplifying the process for businesses to exhibit their compliance status.
There are eight SAQ types (SAQ A through SAQ D), each designed for a specific payment environment:
| SAQ A | All cardholder data functions are fully outsourced |
|---|---|
| SAQ A-EP | E-commerce merchants using a third-party payment page, but with a website that could impact security |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals; no electronic cardholder data storage |
| SAQ B-IP | Merchants using standalone PTS-approved payment terminals with an IP connection |
| SAQ C-VT | Merchants using web-based virtual terminals on an isolated computer |
| SAQ C | Merchants using payment applications connected to the internet |
| SAQ P2PE | Merchants using PCI SSC-listed point-to-point encryption (P2PE) solutions |
| SAQ D | All other merchants and service providers not covered by SAQ A–P2PE |
SAQs must be completed annually or whenever significant changes occur in your payment processing environment.
Do you need external assessments and routine audits for PCI DSS compliance?
Despite possessing a firm grasp of PCI DSS requisites and diligently fulfilling Self-Assessment Questionnaires (SAQs), external evaluations and regular audits remain indispensable facets of PCI DSS compliance. The necessity for these stems from the perpetually evolving threats, the intricate nature of payment systems, and the vital role independent scrutiny plays in maintaining the integrity of compliance.
External evaluations, carried out by a Qualified Security Assessor (QSA), offer an unbiased perspective on an organization’s compliance stance. QSAs are autonomous security entities accredited by the PCI Security Standards Council to execute PCI DSS assessments.
Regular audits empower organizations to identify potential non-compliance matters early and initiate remedial measures, thereby nurturing continuous enhancement in their security posture.
Consequently, a sturdy PCI DSS compliance program interweaves both self-evaluations (SAQs) and external assessments, bolstered by periodic audits. This multifaceted strategy ensures that an organization’s compliance is never stagnant but perpetually adapts to shifting threats and business landscapes.
How can Astra Security help your organization?
Astra Security serves as a PCI Approved Scanning Vendor (ASV) and delivers automated external vulnerability scanning that fully satisfies PCI DSS Requirement 11.3.1 for quarterly external scans of internet-facing systems in scope. Our platform is purpose-built for modern environments, including cloud infrastructure (AWS, Azure, GCP), containerized workloads, APIs, and authenticated web applications.
Beyond ASV scanning, Astra’s continuous penetration testing platform directly supports Requirement 11.3.2 (external penetration testing) and Requirement 11.4 (internal penetration testing). Security engineers manually validate every finding, significantly reducing false positives and providing accurate, actionable results.
Astra Security offers:
- Two free rescans per cycle to verify remediation before final reporting.
- PCI ASV-compliant reports generated in the official format
- Public Trust Center for easy report sharing with QSAs and stakeholders
- Native integrations with CI/CD pipelines (GitHub, GitLab, Jenkins) and ticketing tools (Jira, Linear)
- Centralized compliance dashboard for tracking scan history, vulnerability status, and remediation progress across all assets.
This allows engineering and security teams to embed PCI DSS compliance directly into their development workflow instead of treating it as a separate, disruptive process.
Final Thoughts
Payment card transactions are an integral part of daily commerce, and PCI DSS compliance is an essential security responsibility. The 12-point PCI compliance checklist effectively and efficiently manages cardholder data.
Choosing the right PCI QSA company is paramount in safeguarding the security and compliance of your organization’s web resources. It is highly recommended that you forge a partnership with industry-leading PCI QSA companies, such as Astra or the others mentioned in this article. You can tap into their expertise and gain invaluable insights into your current security posture.
To discover the full range of benefits of partnering with PCI QSA companies and to explore how they can tailor their solutions to your specific needs, we invite you to schedule a free consultation with the team of experts at Astra. Don’t leave your security to chance – consult with us today!
Frequently Asked Questions
What are the changes in PCI?
Improved account security regarding passwords and user authentication. Requiring stronger and more robust discovery and monitoring of sensitive data. Expanding the scope of entities to whom PCI DSS applies.
What is the latest version of PCI compliance?
The PCI SSC released version 4.0 at the end of March 2022, although PCI DSS v3. 2.1 will remain active for two years through March 2024. PCI 4.0 will go live in March 2025.
What are the PCI 4 levels?
Level 1: Merchants that process over 6 million card transactions annually.
Level 2: Merchants that process 1 to 6 million transactions annually.
Level 3: Merchants that process 20,000 to 1 million transactions annually.
Level 4: Merchants that process fewer than 20,000 transactions annually.
