ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A PCI DSS compliance checklist is a structured list of the tasks you must complete to protect payment card data and to prove it, from defining scope to collecting the evidence an assessor or acquirer will ask for. PCI DSS v4.0.1 is the current version of the standard, published in June 2024, and it replaced v4.0, which was retired at the end of 2024.
The checklist below follows the twelve principal requirements. It is a planning and readiness tool, not a substitute for the standard itself or for your acquirer’s instructions, so always work from the current documents published by the PCI Security Standards Council.
Timelines and cost figures vary widely. Treat any examples as illustrative and confirm your validation level with your acquirer or payment provider.
Free gap assessment
How much of PCI DSS v4 is actually in place?
Score all twelve requirements at sub-requirement level, free, including the ones that stopped being future-dated in 2025.
Run the free PCI DSS 4.0 gap assessment → or View premium report sample
Every PCI DSS task depends on scope. Scope covers the people, processes and technology that store, process or transmit cardholder data, plus any system that can affect the security of those systems. If you misjudge scope, you either miss controls or waste money protecting systems that do not matter.
Draw a data flow diagram that follows a card from the moment it is captured to the moment it is settled or deleted. Include web pages, payment terminals, call center tools, logs, backups and third-party services. Then list every system in the path and the systems connected to them. The guide in PCI DSS scope explains how segmentation can shrink the area you must protect.
Reduce scope where you can. Using a validated payment provider that captures card data on its hosted page, or point-to-point encrypted terminals, often removes most systems from direct scope. The checklist is shorter when the data never touches your network.
Requirement one calls for network security controls. Check that you have documented and reviewed firewall or equivalent rules, that the cardholder data environment is separated from untrusted networks and that every allowed connection has a business reason. Requirement two calls for secure configurations: remove vendor default accounts and passwords, apply hardening standards and disable unneeded services.
Collect evidence as you go: network diagrams, rule review records with dates, configuration standards and screenshots showing defaults were changed. Assessors sample systems, so your standard has to match what is actually deployed.
Create a rule: no system joins the cardholder data environment without a build that follows the standard. This single habit prevents much of the drift that causes findings later.
| Requirement | Theme | Typical evidence |
|---|---|---|
| 1-2 | Network security and secure configuration | Firewall rules, hardening standards |
| 3-4 | Protect stored and transmitted account data | Data retention policy, encryption settings |
| 5-6 | Malware protection and secure development | Anti-malware logs, code review records |
| 7-9 | Access control and physical security | Access reviews, MFA, visitor logs |
| 10-11 | Logging, monitoring and testing | Log reviews, scan and pen test reports |
| 12 | Policies and risk management | Policies, risk analysis, training records |
Requirement three is about stored account data. Check that you keep only what you need, for only as long as you need, and that sensitive authentication data, such as the card verification code, is never stored after authorization. Stored primary account numbers must be rendered unreadable, and masks apply when displaying them.
Requirement four covers transmission. Confirm strong cryptography and trusted certificates protect card data over open, public networks, and that you have an inventory of the keys and certificates in use.
Search for stray data. Card numbers turn up in spreadsheets, support tickets, call recordings and logs. A discovery scan before the assessment lets you fix problems on your terms instead of in the assessor’s report.
Requirement five expects anti-malware protection on in-scope systems, with updates, scans and logs, plus controls against phishing. Requirement six covers secure development and maintenance: patch management, a vulnerability identification process, secure coding practices and change control.
Version 4.0.1 gives particular attention to web pages that load scripts in the customer’s browser. If you run your own payment page, you must manage and authorize scripts and detect changes, as discussed in PCI DSS payment page scripts.
Keep proof of patching cycles, code review results and testing before release. Screenshots help, but exports from the tools with dates are stronger.
Requirement seven limits access to what each person needs for their job. Requirement eight requires unique IDs, strong authentication and multi-factor authentication for access into the cardholder data environment. Requirement nine covers physical access to systems and media, including visitor control and secure storage.
Run an access review before the assessment. List who has access to in-scope systems, compare it with job roles and remove what is not needed. Record the review with a date and an approver.
Check third-party access too. Support vendors with remote access should use approved tools, unique credentials and logging, and their access should be enabled only when needed.
Requirement ten calls for logging of access and activity, time synchronization, and review of logs. Requirement eleven calls for regular testing: internal and external vulnerability scans, penetration testing, detection of unauthorized wireless access and change detection on critical files.
Set a testing calendar. Quarterly scans, annual penetration tests and tests after major changes should all appear, with owners and dates. Keep reports and the evidence that findings were fixed and rescanned.
Logging is the place where many teams discover gaps late. Confirm that logs from every in-scope system reach the same place, are protected from tampering and are retained for the required period.
Requirement twelve ties everything together. It expects an information security policy, a risk assessment process, security awareness training, an incident response plan and management of service providers. Version 4.0 introduced targeted risk analyses for several requirements, which is covered in PCI DSS targeted risk analysis.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Write policies and procedures that match what you actually do. Assessors compare the document with the behavior, and a beautifully written policy nobody follows is a finding. The overview in PCI DSS documentation lists which documents to keep.
Keep a responsibility matrix for each requirement, stating who owns it, who performs it and who evidences it. It helps with the assessment and makes handovers easier.
How you prove compliance depends on your merchant or service provider level and on what your acquirer requires. Smaller merchants typically complete a self-assessment questionnaire and an attestation, while larger ones undergo an assessment by a qualified assessor and produce a report on compliance. See PCI DSS merchant levels and PCI DSS SAQ for the options.
Confirm the requirements with your acquirer early, since the card brands set validation rules and deadlines. Details are in PCI DSS validation. The Council publishes the standard and supporting documents at PCI Security Standards Council.
Expect costs to vary with scope, size and preparation. The analysis in PCI DSS compliance cost breaks down the main factors.
Six to eight weeks before your assessment or attestation, run a readiness review. Walk through each requirement with its owner, ask for the evidence and mark every item as complete, partial or missing. Partial items are the dangerous ones, because they feel done. A firewall review that happened in January but not since is partial, and an assessor will say so.
Produce a gap list with an owner and a date for each item, then track it weekly. Give the most time to items that need procurement or engineering effort, such as multi-factor authentication or log centralization, and less to document updates. In the final two weeks, freeze changes to the in-scope environment where possible and collect evidence in one organized folder. Assessors notice when evidence is ready, and the sampling goes faster.
A worked example: a mid-sized online retailer finds that 40 percent of its checklist items are partial, mostly around log review and access recertification. Two months of focused work, scheduled reviews and a central log tool move the number below five percent. The figures are invented, but the approach is typical.
Compliance is not an annual event. Many requirements are recurring: quarterly scans, semiannual rule reviews, annual training and penetration tests, and continuous log monitoring. Put each on a calendar with a named owner, and have the owner save the evidence at the time, not at audit time.
Review scope after every significant change, such as a new payment channel, a new vendor or a migration to a new platform. Update the data flow diagram and the checklist together. Report status monthly to management using a simple count of items on track and items overdue, so problems surface while there is time to fix them.
Turning the checklist into policies, procedures and evidence trackers takes time. A set of ready documents gives you a structure to edit instead of a blank page.
The PCI DSS Toolkit provides more than 180 templates aligned to PCI DSS v4.0.1, in editable format, so your team can tailor them to your environment and keep the evidence organized. Start with scope and requirement twelve, since they shape everything else.
For the wider context of how the standard relates to other frameworks, see PCI DSS vs ISO 27001. Check PCI DSS v4.0 compliance for the changes introduced in the current version.
PCI DSS v4.0.1 is the current version, published in June 2024. It replaced v4.0, which was retired at the end of 2024.
Yes, any organization that stores, processes or transmits cardholder data must follow PCI DSS, although validation requirements depend on level and acquirer rules.
It depends on scope and starting point, from a few weeks for a small merchant using a hosted payment page to many months for a complex environment.
Often yes, through a validated payment provider, tokenization, point-to-point encryption and network segmentation.
A qualified assessor for larger organizations, or a self-assessment attested by the merchant, depending on level and acquirer rules.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026