PCI DSS Requirements: A Practical Checklist

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.

Work out which document you actually owe

Before any of the 12 requirements matter, establish what you are being asked to produce, because "PCI compliance" describes at least three different deliverables with very different price tags.

If you are a merchant, the card brands set levels by annual transaction volume, and the thresholds most acquirers work from follow Visa's: above six million transactions a year puts you at Level 1 and obliges a Report on Compliance produced by a Qualified Security Assessor or an internal auditor with signed management attestation. Below that, most merchants self-assess using a Self-Assessment Questionnaire and submit an Attestation of Compliance. If you are a service provider, meaning you handle or affect the security of cardholder data on behalf of others, the threshold is far lower and the scrutiny higher, with Level 1 service providers generally facing an annual assessment by a QSA and reporting obligations to every customer who asks.

The document your acquirer or your customer wants is the one that determines your cost. A Level 4 merchant running a hosted checkout may owe a short SAQ A and quarterly ASV scans. A Level 1 service provider owes a full Report on Compliance with hundreds of tested controls. Ask your acquirer, in writing, which SAQ type and which validation method they expect. We have seen companies budget for a full assessment when their acquirer would have accepted a self-assessment, and the reverse, which is worse.

SAQ A is no longer the free pass it used to be

E-commerce companies have long treated an iframe or full redirect to a hosted payment page as the end of the conversation. Version 4 closed that gap. Even where the payment fields never touch your servers, your page is what loads the payment iframe, and if an attacker can inject script into your page they can swap or overlay it. The standard now expects you to manage the scripts loaded on payment pages, maintain an inventory with written justification for each one, and detect unauthorized changes to script content and to HTTP headers on those pages.

In practice this means a content security policy, subresource integrity or an equivalent script integrity mechanism, an inventory document that names every tag manager, analytics script, chat widget, and A/B testing tool present on the checkout path, and a change detection mechanism with alerting at least weekly. The unglamorous part is the inventory, because marketing tooling is added constantly and nobody thinks of a chat widget as a payment page control. Put a gate in the release process for anything that ships script to a payment page and you have solved most of it.

The version 4 requirements that stopped being optional

Version 4.0 arrived with a long list of requirements marked as best practice until 31 March 2025. That date has passed, and they are now in force for every assessment. The ones that most often catch companies out are worth naming.

Authenticated internal vulnerability scanning. Internal scans must now run with credentials. Teams that were running unauthenticated internal sweeps see finding counts multiply the first time they switch, and the remediation backlog needs to be planned rather than discovered at assessment time.

Automated protection for public-facing web applications. The old option of annual manual application review is gone; you need an automated technical solution that detects and prevents web-based attacks, running continuously and generating alerts.

Password and authentication changes. Minimum length moved to twelve characters where the system supports it, multi-factor authentication is required for all access into the cardholder data environment rather than only administrative access, and the MFA implementation itself must resist replay and cannot be bypassable by any user including administrators.

Phishing controls and awareness content. Technical mechanisms to detect and protect personnel from phishing are required, and security awareness training must specifically cover phishing and social engineering.

Disk-level encryption limits. Full-disk encryption alone no longer satisfies the storage requirement on non-removable media; you need protection that works when the system is running, which usually means encryption at the file, column, or application layer.

Multi-tenant service provider obligations. If you are one, you must support your customers' requests for penetration testing evidence of segmentation between tenants.

Targeted risk analyses, the new paperwork nobody budgeted for

Version 4 introduced a documentation obligation that quietly consumes more time than any single technical control. Wherever a requirement lets you choose the frequency of an activity, you must produce a targeted risk analysis justifying that frequency, and review it at least annually. The same applies if you use the customized approach for any requirement.

Each analysis has a defined shape: identify the asset being protected, the threat the control addresses, the factors that contribute to likelihood and impact, the analysis that led to your chosen frequency, and the review date. A mid-size environment often ends up with somewhere between eight and fifteen of these covering things like log review cadence, malware scan frequency, and periodic access review timing. They are not difficult, but they are new, they are individually signed off, and an assessor will ask for each one by requirement number. Write them before the assessment window opens rather than during it.

Defined approach versus customized approach

Version 4 lets you meet the objective of a requirement with a control of your own design instead of the stated one. That flexibility is genuinely useful for cloud-native architectures where the prescribed control assumes hardware you do not have. It is also a commitment. The customized approach requires you to document the control, document how it meets the stated objective, perform and document a targeted risk analysis, and then have the assessor design bespoke testing procedures for it. Self-assessment is not available for customized controls; you need a QSA.

The honest guidance is to use the defined approach for everything you can, and reserve the customized approach for the two or three places where your architecture genuinely cannot accommodate the prescribed control. Companies that reach for it broadly end up paying for assessor time to invent test procedures, which is the most expensive way to buy flexibility.

Third parties and the responsibility matrix

Requirement 12.8 covers the service providers you rely on, and it is where cloud-heavy companies lose time. You need a current list of every third party with which cardholder data is shared, or that could affect the security of the cardholder data environment, their PCI DSS compliance status with evidence, and a written agreement acknowledging their responsibility for the data they hold. You also need a documented responsibility matrix showing, requirement by requirement, which controls are yours, which are theirs, and which are shared.

Your cloud provider publishes an Attestation of Compliance and a shared responsibility document, and both need to be in your evidence set with the collection date recorded. The matrix is the artefact assessors ask for most often and companies have least often. Building it once takes a day or two and it pays for itself every year afterwards, because it is also the document that answers your customers' vendor questionnaires.

Segmentation testing, and how scope creeps back in

Scope reduction only counts if it holds. Where segmentation is used to keep systems out of scope, penetration testing of the segmentation controls is required at least every twelve months for merchants and every six months for service providers, plus after any change to segmentation controls. The test has to demonstrate that the controls are operational and effective, and that the out-of-scope networks genuinely cannot reach the cardholder data environment.

Scope creeps back in ways that are easy to miss. A monitoring agent gets deployed everywhere including the CDE, so the monitoring platform is now connected-to. A jump host gets a second network interface for convenience. A CI runner gains deploy access into the CDE. A support tool gets read access to a database that holds truncated PAN alongside other fields. Each of these pulls a new system into the assessment boundary. Requiring an annual documented scope confirmation, every six months for service providers, is the standard's answer to this, and it works only if the person doing it looks at network reality rather than the last diagram.

Where assessments actually stall

Beyond the requirements themselves, a few practical things reliably derail timelines. Evidence sampling is one: assessors select samples across the assessment period, so a control implemented two months before the assessment cannot demonstrate a year of operation, and the assessment either shifts or the finding stands. Log retention is another, because twelve months of retained logs with three months immediately available means you cannot start collecting in month ten. Call recordings catch contact centres by surprise, since recordings that capture card numbers or security codes are stored cardholder data with all the protection that implies. And change management records are frequently the weakest evidence in the pack, because engineering teams approve changes in a chat thread that produces no retrievable audit trail.

When you should not buy PCI DSS work from us

A meaningful share of the companies who contact us about PCI DSS should spend less money than they expect, and sometimes none with us at all.

If you take payments entirely through a hosted checkout that a validated processor operates, and no card data ever reaches your infrastructure, your obligation may be a short SAQ, quarterly ASV scans, and script controls on the payment page. That is a few days of internal work with a template, not a consulting engagement. Ask your processor for their SAQ guidance first; several publish good material and it is free.

If you are storing card numbers today because a feature required it three years ago, the highest-value work is not compliance advisory, it is engineering: move to tokenization with your processor and delete the stored data. Doing that removes most of requirement 3 and shrinks nearly every other requirement. Pay a developer to do it and come back afterwards with a smaller problem.

And if you are already engaged with a QSA who has scoped you correctly and your gaps are known, you may not need a second firm in the room. What is worth buying at that point is remediation help on the specific gaps, or the required testing, rather than a parallel readiness assessment that restates the QSA's findings. Our fixed-scope pricing exists so you can buy the piece you need, and if continuous scope confirmation and evidence upkeep is the real gap, a retainer is the honest recommendation over a one-off project.