PCI DSS Compliance Checklist: Understanding the 12 Requirements
We dive into each of the 12 requirements and offer a helpful PCI compliance checklist to reference as you embark on your compliance journey.
The Payment Card Industry Data Security Standard (PCI DSS) outlines a set of requirements for businesses that handle credit card transactions. If you store, process, or transmit cardholder data, PCI compliance is a baseline expectation from customers, partners, and payment processors.
However, PCI DSS v4.0 brings more than just technical controls. It introduces new obligations that require tighter access management, continuous monitoring, and documented security practices.
This guide delivers a step-by-step PCI DSS checklist aligned with v4.0 requirements, along with insights into how automation can reduce manual effort, improve visibility, and accelerate audit readiness. If you're building a business that accepts payments and scales fast, this is how you stay secure and move forward with confidence.
What is PCI DSS Compliance?
PCI DSS compliance means meeting a global set of security standards designed to protect credit card data. The standard was developed by the PCI Security Standards Council, a group founded by major credit card companies like Visa, Mastercard, and American Express.
These requirements apply to any business that stores, processes, or transmits cardholder data. The latter includes:
The primary account number
The cardholder name
The expiration date
The service code
Sensitive authentication data, which includes magnetic stripe or chip data and PINs
PCI DSS defines 12 technical and operational requirements that create a secure environment for handling cardholder data. They include controls like firewall management, encryption, access restrictions, and regular testing.
Who Needs PCI DSS Compliance?
PCI applies both to merchants and service providers. A merchant is any entity that accepts payment cards bearing the logos of any of the six members of the PCI Security Standards Council (SSC)—American Express, Discover, JCB, Mastercard, Visa, or UnionPay—as payment for goods and services. A service provider is a company that provides services that control or could impact the security of cardholder data.
While a vendor at your local farmers market and a big-box retailer both need to comply with PCI, the requirements will vary depending on the number of transactions the business processes in a year.
PCI organizes merchants into four levels, with Level 1 requiring more stringent compliance practices and Level 4 requiring the least stringent practices. Each payment brand sets their own reporting requirements.
For example, American Express outlines their merchant levels into the following categories:
Level 1: merchants that process more than 2.5 million transactions annually
Level 2: merchants or service providers that process 50,000 to 2.5 million transactions annually
Level 3: merchants that process 10,000 to 50,000 transactions annually
Level 4: merchants that process fewer than 10,000 transactions annually
For exact information on each payment brand's PCI reporting requirements, we encourage you to visit their website:
Why PCI DSS Compliance Matters
Non-compliance with PCI DSS is a business risk. A single breach involving cardholder data can trigger fines, lawsuits, contract termination, and mandatory forensic audits. Payment processors may revoke your ability to accept cards altogether.
The financial damage is only part of the impact. Security lapses erode customer trust, stall enterprise deals, and create friction with investors. For startups and scaleups, the cost of inaction often shows up as delayed revenue or lost opportunities.
Compliance doesn’t eliminate every risk, but it signals to customers and partners that your business takes data protection seriously. That credibility both opens doors and keeps them open.
What's New With PCI v4.0?
PCI DSS 4.0 updates the standard to reflect how modern businesses operate and how attackers behave. It asks organizations to prove that their security controls actually work, not just that they exist on paper.
These updates fall into four broad categories:
Evolving security needs: Version 4.0 adds new cybersecurity practices, including multi-factor authentication (MFA), strong PCI password practices, and ongoing defenses against phishing attacks.
Security as a continuous process: Because security attacks can come from any direction at any time, everyone in the organization must have clearly assigned and well-understood security responsibilities. Version 4.0 guides stakeholders as they make security a continuously improving process.
Flexibility to use different security methods: Version 4.0 adopts a risk-based approach that lets organizations create methods for protecting cardholder information that are appropriate for their business and risk tolerance.
Enhanced validation: PCI compliance assures cardholders, customers, and other stakeholders that an organization can protect cardholder information. Version 4.0 creates options for validation and reporting that deliver more granularity and transparency.
All organizations are now expected to comply with PCI DSS 4.0. The grace period for legacy controls ended in March 2025, so any business still using version 3.2.1 is officially out of alignment with the standard. That includes future-dated requirements like risk-based access controls, targeted risk assessments, and updated authentication practices. If your compliance program hasn’t already closed the gap, you’re late to the party.
PCI Compliance Checklist
The 12 PCI 4.0 Compliance Requirements
The PCI standard is comprised of 12 compliance requirements, organized under six objectives, which are:
Establish and maintain a secure network
Protect payment card and cardholder data
Maintain a vulnerability management program
Implement strong access control measures
Monitor and test networks regularly and evaluate their effectiveness
Maintain an information security policy
Below, we offer additional information on how to comply with the PCI compliance requirements.
1. Determine the Scope of Your Cardholder Data Environment (CDE)
PCI compliance starts with knowing what’s in scope. In plain terms, you have to identify all systems, tools, processes, and people that handle or could impact cardholder data. This collective footprint is your cardholder data environment (CDE), and it defines the boundaries of your compliance obligations.
Scoping also determines how you validate compliance, whether you’ll complete a Self-Assessment Questionnaire (SAQ) or undergo a full Report on Compliance (ROC).
A clear scope gives you control. Without it, requirements spill into areas they don’t belong, PCI audits drag on, and costs go up. The goal is to isolate systems that deal with payment data and segment them from the rest of your environment. Done well, scoping reduces complexity and accelerates compliance.
Systems can fall into three buckets:
In-scope: Systems that relate to, impact, or connect to the security of cardholder data
Connected: Systems not directly involved in processing of cardholder data but are connected to your CDE
Out-of-scope: Systems that do not interact with or connect to your CDE
Startups often discover they're accidentally pulling unrelated systems into scope (CI/CD pipelines, support tooling, staging environments). The earlier you define and enforce boundaries, the better.
Pro-tip: Drata automatically maps your systems, flags connected components, and gives you a real-time view of your compliance boundary. That visibility makes it easier to segment networks, limit access points, and stay focused on what matters.
Step 2: Install and Maintain Network Security Controls
Every system that stores or processes cardholder data is a potential target. PCI DSS requires organizations to limit exposure by controlling how data moves across their networks and preventing unauthorized traffic from ever reaching the cardholder data environment (CDE).
Firewalls are a major part of that defense. They inspect incoming and outgoing traffic, blocking anything that doesn’t meet defined security rules. While the concept hasn’t changed, the implementation has. Where organizations once relied on physical firewalls, many now use virtual devices, routing rules, cloud-native access controls, and software-defined networking to segment and protect systems.
What hasn’t changed is the need for proper setup and ongoing maintenance. You can’t just turn on a firewall; you’re expected to configure it, document it, and maintain it. That includes limiting public access and enforcing segmentation between the CDE and everything else. Development systems, internal tools, and third-party services shouldn’t have a direct path to sensitive infrastructure. If they do, your scope expands and so does your risk.
Misconfigurations are one of the most common (and preventable) sources of PCI violations. A permissive default rule or overlooked open port can bring your entire network into scope, or worse, leave it exposed to an attack.
Pro-tip: Drata connects directly to your cloud provider to monitor firewall rules and segmentation controls in real time. It flags gaps, tracks changes, and helps your team maintain secure boundaries without relying on manual reviews or reactive fixes.
3. Apply Secure Configurations to All System Components
Out-of-the-box settings aren’t built for security. Vendors prioritize accessibility and ease of setup, which often means shipping products with default credentials, open ports, unnecessary services, and permissive access controls. For your org to be PCI DSS compliant, every system in scope must be securely configured before it's deployed (and regularly reviewed after).
This encompasses operating systems, network devices, cloud instances, application frameworks, and any third-party software that connects to the CDE. You're expected to remove or disable insecure features, replace default passwords, close unused ports, and document configuration standards for every system type.
The reality is that many organizations never do. Vendor-supplied defaults go unnoticed and stay in place because they’re inherited, essentially leaving an org’s front door unlocked. Hackers know this. Lists of vendor-provided usernames and passwords are easy to find online.
That’s why applying secure configurations isn’t a one-time task. It’s a repeatable baseline that needs to be enforced at scale, tracked across updates, and integrated into how your infrastructure is built.
Pro-tip: Drata monitors your cloud assets, flags configuration drift, and checks for default settings across systems. It helps teams enforce hardening standards automatically and surfaces exceptions before they become security incidents or audit issues.
4. Encrypt Stored Account Data
Cardholder data is only as secure as its environment. Under PCI DSS, stored account data (such as the primary account number (PAN)) must be protected with strong encryption, so as to render it unreadable even if an attacker gains access.
The standard calls for strong cryptography to be applied to stored account data, and encryption keys to be protected, rotated, and managed with the same level of care, including everything from file-level encryption to tokenization, key vaults, and access logging.
It’s easy to underestimate how many places cardholder data ends up—databases, backups, logs, test environments. Without controls to detect and restrict data sprawl, sensitive information can surface in unexpected places, creating risk and expanding your PCI scope.
Pro-tip: Drata monitors your storage configurations and validates that encryption is enabled where required. This allows you to track systems that store cardholder data, surface potential exposure points, and keep key management policies aligned with PCI requirements.
5. Protect Cardholder Data With Strong Cryptography During Transmission Over Public Networks
Cardholder data needs protection at rest and in motion. Whenever it travels across public or unsecured networks, it should be encrypted using strong cryptography like TLS 1.2 or higher. Outdated protocols like SSL and early TLS are no longer acceptable.
Transmissions between your systems and customers, payment processors, APIs, or internal tools operating over cloud or hybrid networks are all included. Encryption should be enforced, not optional, and misconfigurations like weak cipher suites or expired certificates can quietly open the door to interception.
Pro-tip: Drata scans your environment for weak or missing encryption settings. It catches unsupported protocols, exposed endpoints, and insecure configurations before they create audit issues, or worse, security breaches.
6. Protect All Systems Against Malware
Malware (including viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links) doesn’t need a complex exploit to cause damage. All it takes is one unmonitored endpoint, an outdated dependency, or an overlooked phishing email. PCI DSS expects organizations to actively detect, prevent, and respond to malicious software across every environment where it's a risk.
Traditional antivirus software for workstations falls under that umbrella, and so do behavior-based tools for servers, cloud workloads, and developer machines. Automated PCI scans, threat detection, and alerting are part of the equation, but so is having an incident response plan when something gets through.
Pro-tip: Drata keeps tabs on malware defenses across your environment, flags gaps in coverage, and confirms that protections stay active and up to date.
7. Deploy and Maintain Secure Systems and Applications
Every new feature, update, or third-party tool introduces potential risk. PCI DSS calls for a proactive approach, building security into your systems from day one and maintaining it throughout their lifecycle. Code should be reviewed, systems patched, and known vulnerabilities addressed quickly.
Outdated software is a common entry point. The longer a vulnerability goes unaddressed, the more likely it is to be exploited. Your team needs a straightforward process for applying security updates, decommissioning outdated components, and vetting new tools before deployment.
Pro tip: Drata continuously monitors your assets and dependencies, alerting you to missing patches and outdated systems. You can maintain visibility across your stack, so nothing quietly drifts out of compliance.
8. Restrict Access to System Components and Cardholder Data on a Need-to-Know Basis
Not everyone needs access to cardholder data, and the more people who have it, the more you’re exposed. PCI DSS expects organizations to limit access to only those whose roles genuinely require it. The standard calls this “need to know,” and it applies to both systems and people.
Access controls should be role-based, reviewed regularly, and enforced through least privilege. If someone changes teams or leaves the company, their access should change too. Shared accounts, overly broad permissions, or access granted “just in case” are all red flags during an audit, and easy wins for an attacker.
Pro tip: Drata continuously monitors access levels across your systems, flags excessive permissions, and helps enforce least privilege policies. It also makes it easy to review and revoke access when roles change or employees are offboarded.
9. Identify Users and Authenticate Access to System Components
You can’t control what you can’t trace. PCI DSS requires that every user accessing systems involved in cardholder data be uniquely identified and authenticated. No shared logins, no mystery accounts, and no assumptions about who’s doing what.
Strong authentication protects against stolen credentials and insider threats. Every user should have a unique ID, and access should require more than just a password. Multi-factor authentication (MFA) is expected, especially for admin accounts or remote access.
Pro-tip: Drata integrates with your identity provider to track who has access to what, confirms MFA is enforced, and flags shared or orphaned accounts before they create risk.
10. Restrict Physical Access to Cardholder Data
Not all threats come through a network. PCI DSS also applies to the physical world. Offices, server rooms, and data centers where cardholder data is stored or accessed have to be protected from unauthorized entry.
Only approved personnel should have access to these areas, and that access needs to be logged, reviewed, and revoked when no longer needed. Paper records, removable media, and exposed terminals can all pull environments into scope if not properly secured.
Pro-tip: Drata helps track which personnel have access to physical systems tied to the cardholder data environment. It also assists in documenting controls and maintaining audit-ready records for site security, visitor logs, and hardware access.
11. Log and Monitor All Access to System Components and Cardholder Data
When something goes wrong, logs are often the only evidence of what happened. PCI DSS calls for detailed audit trails across your systems, tracking who accessed what, when, and from where. That data helps detect suspicious behavior and supports investigations when needed.
Speed matters. The faster you spot an issue, the faster you can respond. But with thousands of events flowing through your systems every hour, manual log review isn’t practical. That’s why automated monitoring is essential. Well-tuned alerts can surface unusual activity before it becomes a breach.
Pro-tip: Drata connects with your logging tools to confirm key events are being captured, stored securely, and retained as required. It also validates that alerting is in place, so your team stays ahead of emerging threats.
12. Test the Security of Systems and Networks Regularly
Security controls degrade over time. Software changes, new threats emerge, and yesterday’s configuration might not hold up tomorrow. You’re expected to test your defenses on a regular basis, not just during audit season.
This includes vulnerability scans, configuration reviews, and third-party PCI penetration tests. External testing provides an attacker’s perspective and helps uncover flaws that internal teams might miss. These tests should follow a consistent schedule and result in documented findings and remediation plans.
Pro-tip: Drata tracks the cadence of vulnerability scans and penetration tests across your systems. It documents results, assigns remediation tasks, and verifies that important findings are resolved before they become recurring issues.
13. Support Information Security With Organizational Policies and Programs
Security is a business-wide commitment, and as such, your organization should back its controls with policies, defined responsibilities, and ongoing education.
Everyone in the company has a role to play. Engineers secure systems, HR manages onboarding and offboarding, and employees handle data every day. A strong security program gives each team the guidance they need to make the right decisions, and holds them accountable when they don’t.
Pro-tip: Drata provides a library of auditor-approved policies, tracks employee acknowledgments, and automates security awareness training. It also links policies directly to controls, so your documentation stays aligned with how the business operates.
What to Avoid as You Implement Your PCI DSS Checklist
There’s always room for compliance to go sideways. As you implement your PCI DSS checklist, avoid these common mistakes that slow teams down, waste effort, or put audits at risk:
1. Treating compliance like an IT project. PCI DSS cuts across teams. Engineering may own infrastructure, but HR manages onboarding, Finance stores payment data, and Legal helps define vendor agreements. If compliance lives in a silo, it breaks. Build governance early, assign responsibilities, and make it a company-wide initiative.
2. Skipping a proper scoping process. Everything hinges on scope. If you don’t define which systems, teams, and workflows touch cardholder data, you’ll either miss important requirements or over-engineer your entire environment. More than a best practice, scoping is what makes PCI compliance manageable.
3. Choosing the wrong SAQ. The Self-Assessment Questionnaire (SAQ) you complete depends on how your organization handles cardholder data. Using the wrong version (either out of convenience or guesswork) can result in noncompliance. In some cases, it can delay sales or trigger a 90-day remediation window after a data compromise.
4. Treating vulnerability scans as a final stamp of approval. Passing a vulnerability scan doesn’t mean you’re PCI compliant. It’s one requirement among many, and some vendors overstate its significance by issuing "compliance badges," which is deceptive. Vulnerability scans support compliance, but they don’t replace it.
5. Ignoring third-party exposure. Just because a vendor handles card data doesn’t remove your responsibility. If your systems connect to theirs, or you transmit data through them, you're still accountable for ensuring proper controls are in place.
6. Waiting until a customer asks for a report. By the time a deal depends on PCI compliance, you're already behind. Getting compliant takes time, so start early and treat it as part of your go-to-market readiness.
Get PCI DSS Compliant Without Slowing Down
PCI DSS 4.0 raised the bar, and for good reason. Customers, partners, and regulators expect payment data to be protected with intention, not just checklists. Still, compliance doesn’t have to come at the cost of speed, flexibility, or focus.
Drata helps you implement, monitor, and maintain PCI controls automatically. From mapping your scope to collecting evidence, you’ll have a clear path forward, and more importantly, fewer hours sunk into spreadsheets, screenshots, and surprise gaps.
Book a demo to see how Drata simplifies PCI compliance and gets you audit-ready faster.
PCI DSS Compliance Checklist Frequently Asked Questions (FAQs)
Below, we answer the most common questions from startup and scaleup teams navigating PCI DSS standards and compliance for the first time. Here's what you need to know.
What Are the PCI Compliance Requirements?
PCI DSS includes 12 core requirements that define how organizations must protect cardholder data:
Install and maintain network security controls
Apply secure configurations to all system components
Protect stored account data
Protect cardholder data during transmission over open, public networks
Protect all systems and networks from malicious software
Develop and maintain secure systems and software
Restrict access to system components and cardholder data by business need to know
Identify users and authenticate access to system components
Restrict physical access to cardholder data
Log and monitor all access to system components and cardholder data
Test security of systems and networks regularly
Support information security with organizational policies and programs
Each requirement is mandatory and applies to all organizations that store, process, or transmit payment card information.
What is a PCI Checklist?
A PCI checklist is a practical breakdown of the actions and controls your organization needs to implement to align with the 12 PCI DSS requirements. It helps teams track what’s done, what’s missing, and what still needs attention, especially when preparing for an assessment.
A good checklist covers both technical tasks (like configuring firewalls or encrypting data) and operational requirements (like documenting policies or reviewing access regularly).
What are the Four Levels of PCI compliance?
Merchant levels are based on the number of card transactions processed annually and determine how your compliance is validated:
Level 1: Over 6 million transactions per year, or merchants designated Level 1 by card brands. Requires a Report on Compliance (ROC) from a Qualified Security Assessor (QSA).
Level 2: 1–6 million transactions annually. Typically validated with a Self-Assessment Questionnaire (SAQ).
Level 3: 20,000 to 1 million e-commerce transactions. SAQ required.
Level 4: Fewer than 20,000 e-commerce transactions or up to 1 million total transactions. SAQ required.
All levels must complete quarterly vulnerability scans from an Approved Scanning Vendor (ASV).
How Do I Validate PCI Compliance?
You’ll either complete a Self-Assessment Questionnaire (SAQ) or undergo a formal audit with a Qualified Security Assessor (QSA), depending on your merchant level. Validation also includes quarterly external vulnerability scans and, for Level 1 merchants, a full Report on Compliance (ROC) attestation.
Is PCI Compliance Free?
The PCI DSS documentation is free, but becoming compliant isn’t. Costs come from implementing controls, completing assessments, and maintaining secure systems. If you need a third-party QSA or compliance automation platform, that adds to your budget. However, failing to invest in compliance can cost far more in the long run.
What if I’m Not PCI Compliant?
Noncompliance puts your business at risk of data breaches, fines, lawsuits, and revoked ability to process card payments. In the event of a breach, you may be required to undergo a forensic investigation and achieve compliance within a short timeline, often 90 days. Reputational damage and lost revenue can follow just as quickly. The better move is to get ahead of it.
