If your business stores, processes, or transmits cardholder data, PCI DSS applies to you, regardless of size. The Payment Card Industry Data Security Standard is built around 12 core requirements, and most of the confusion we see from clients isn't about what the requirements say. It's about what actually applies to their environment and how much work each one really takes. This checklist walks through all 12, in plain language, so you can gauge your own exposure before you talk to an assessor.
Before the checklist: figure out your scope
The single biggest lever you have on PCI DSS cost and timeline is scope. Every system that stores, processes, transmits, or is connected to cardholder data falls inside the assessment boundary. Most companies that try to tackle PCI DSS without reducing scope first end up applying all 12 requirements to their entire network, which is expensive and slow.
The fix is architectural, not procedural. Segment the cardholder data environment (CDE) from the rest of your network, route payment collection through a validated third-party processor where possible, and tokenize stored card data so raw PAN never touches your systems. Do this first, and the checklist below gets a lot shorter. We cover this in more depth in our guide to PCI DSS compliance for SaaS companies, which is the more common starting point for the businesses we work with.
The 12 PCI DSS requirements
1. Install and maintain network security controls
Firewalls and equivalent network security controls need to sit between the cardholder data environment and everything else, including your corporate network. Rules must be documented, reviewed regularly, and default-deny by design.
2. Apply secure configurations to all system components
No vendor default passwords, no unnecessary services running, no default SNMP community strings. Every system in the CDE needs a documented hardening standard, and you need evidence you're actually following it.
3. Protect stored account data
If you store cardholder data, it needs to be encrypted, truncated, tokenized, or hashed, and you need a documented retention and disposal policy. The simplest way to satisfy this requirement is to not store the data at all.
4. Protect cardholder data with strong cryptography during transmission
Card data moving across open, public networks must be encrypted with strong, current TLS. No cardholder data in unencrypted emails, chat tools, or logs.
5. Protect all systems and networks from malicious software
Anti-malware controls on applicable systems, kept current, with logging and alerting. Cloud-native and container environments have some flexibility here, but you still need a documented rationale for how you address the risk.
6. Develop and maintain secure systems and software
This is the requirement with the most day-to-day engineering impact. It covers secure coding practices, a documented change management process, and a patch management program with defined timelines for critical vulnerabilities. It's also where the PCI DSS penetration test requirement lives for public-facing applications, alongside vulnerability scanning.
7. Restrict access to system components and cardholder data by business need to know
Access control based on job role, not convenience. If someone doesn't need access to cardholder data to do their job, they shouldn't have it. This needs to be documented and reviewed, not just true in practice.
8. Identify users and authenticate access
Unique IDs for every user with access to system components, no shared accounts, multi-factor authentication for all access into the CDE, and strong password policies. This is one of the most commonly failed requirements during assessment, usually because of shared service accounts or MFA gaps on administrative access.
9. Restrict physical access to cardholder data
Applies to on-premises data centres, offices, and any physical media containing cardholder data. Most SaaS companies satisfy this largely through their cloud provider's compliance attestations, but you still need to address physical media handling and visitor access on your own premises.
10. Log and monitor all access to system components and cardholder data
Centralized logging, log retention (typically 12 months, with 3 months immediately available), and a process for reviewing logs for anomalies. Logs need to be protected from tampering.
11. Test the security of systems and networks regularly
This is where the required penetration test lives. PCI DSS mandates internal and external penetration testing at least annually and after any significant change, plus quarterly vulnerability scans (with ASV scans for the external-facing environment) and, for larger merchants, segmentation testing to confirm your scope reduction actually holds up under attack. This is a hard requirement, not a recommendation, and it's the piece most companies underestimate on timeline.
12. Support information security with organizational policies and programs
A documented information security policy, a risk assessment process, security awareness training, and an incident response plan that's actually been tested. Assessors will ask for evidence this program runs continuously, not that it exists on paper.
Where companies actually get stuck
In our experience, the requirements that read as straightforward on paper (network security, encryption) are rarely where projects stall. The friction shows up in requirement 6 (patch and change management discipline), requirement 8 (MFA coverage gaps on admin and third-party access), and requirement 11 (companies discover late that the penetration test needs a qualified, independent tester and can't be done in-house if you're a Level 1 merchant or want assessor credibility). Building in the scoping work up front avoids most of this.
How traztech approaches PCI DSS
We start with scope reduction, because it's the fastest way to cut both cost and audit fatigue. From there we run a readiness assessment against all 12 requirements, close the gaps that are actually blocking you, and deliver the required penetration test as part of the engagement rather than handing you off to a third party mid-project. If you want a deeper look at how this applies specifically to SaaS architectures, our PCI DSS for SaaS companies guide covers the common patterns we see with hosted platforms and payment integrations. For a broader view of how PCI DSS fits alongside other frameworks you might be pursuing, see our compliance solutions overview.
If you're not sure where your PCI DSS scope actually starts and ends, that's the right first conversation to have before committing to a timeline or budget. Get in touch and we'll walk through your environment and tell you plainly what's required and what isn't.