Meeting PCI DSS requirements is essential for any organisation that stores, processes, or transmits cardholder data. The Payment Card Industry Data Security Standard defines a comprehensive set of security controls designed to protect card data throughout its lifecycle, but navigating the path from initial scoping to validated compliance can be daunting without a structured approach.
This checklist breaks PCI DSS compliance into fifteen actionable steps across three phases. Whether you are a merchant preparing your first Self-Assessment Questionnaire or a service provider gearing up for a full Qualified Security Assessor engagement, this guide provides practical direction at each stage. Use it to assign ownership, track progress, and ensure that nothing is overlooked before your validation deadline.
Phase 1: Scoping and Discovery
Scoping is the most consequential phase of any PCI DSS programme. Errors here cascade through every subsequent step, inflating costs, extending timelines, and creating blind spots that auditors will eventually find. The goal is to establish a precise, defensible boundary around your cardholder data environment before any remediation work begins.
Step 1: Map cardholder data flows
Begin by tracing the complete journey of cardholder data through your organisation. Identify every point where primary account numbers (PANs), expiration dates, cardholder names, or sensitive authentication data are received, transmitted, processed, or stored. Document entry points such as e-commerce payment pages, point-of-sale terminals, call centre systems, and paper-based processes. Follow the data through middleware, APIs, databases, backup systems, and any third-party integrations.
Create a detailed data flow diagram for each payment channel. Include system names, network zones, transmission protocols, and storage locations. Pay close attention to unexpected data resting points — log files, debugging outputs, email inboxes, and spreadsheets are common places where cardholder data appears without the organisation’s knowledge. This diagram becomes a living document that underpins every scoping decision and will be requested by your QSA or used to validate your Self-Assessment Questionnaire.
Step 2: Define the CDE boundary
With data flows mapped, draw a clear boundary around your cardholder data environment (CDE). The CDE encompasses every system component that stores, processes, or transmits cardholder data, plus any system directly attached to the same network segment. Every component inside this boundary must comply with every applicable PCI DSS requirement, so precision matters.
Document the boundary formally with network diagrams showing CDE zones, demilitarised zones, and out-of-scope areas. Label each component with its role and the data it handles. This boundary definition should be reviewed and approved by both technical leadership and the compliance programme owner. If the boundary is too broad, remediation costs escalate unnecessarily. If it is too narrow, you risk assessment findings and potential non-compliance. Revisit this boundary whenever new systems are added or payment flows change.
Step 3: Identify connected and security-impacting systems
PCI DSS distinguishes between systems within the CDE, connected systems that communicate with the CDE, and security-impacting systems that could affect CDE security even without a direct data path. All three categories are in scope for compliance. Connected systems include jump servers, management consoles, and monitoring tools that have network connectivity to CDE components. Security-impacting systems include authentication servers, DNS, NTP, and any system providing security services to the CDE.
Build a comprehensive inventory that categorises each system component into one of these three groups. For each system, record the owner, operating system, function, data classification, and network connectivity. This inventory drives your gap assessment and helps you allocate remediation resources effectively. Overlooking connected or security-impacting systems is one of the most common reasons organisations receive findings during QSA assessments, so take a conservative approach — if you are uncertain whether a system is in scope, treat it as in scope until you can definitively prove otherwise.
Step 4: Explore scope reduction through tokenisation, P2PE, and segmentation
Before remediating, evaluate whether you can reduce scope first. Scope reduction is almost always more cost-effective than hardening additional systems. Three primary strategies exist: tokenisation, point-to-point encryption (P2PE), and network segmentation.
Tokenisation replaces cardholder data with non-sensitive tokens, removing systems that only handle tokens from CDE scope. If you use a PCI-listed P2PE solution, terminal-to-decryption point encryption can remove most of your in-store infrastructure from scope. Network segmentation isolates the CDE from the broader network, ensuring that a compromise of out-of-scope systems cannot reach cardholder data. Evaluate each strategy against your payment channels and architecture. Many organisations combine all three to achieve the smallest possible CDE. Document your scope-reduction decisions and the technical controls supporting them, as your assessor will need to validate that they are correctly implemented and operating effectively.
Phase 2: Gap Analysis and Remediation
With a clearly defined scope, the next phase is identifying where your current controls fall short of PCI DSS requirements and systematically closing those gaps. Remediation is typically the longest and most resource-intensive phase, so prioritisation and planning are critical.
Step 5: Conduct a gap assessment
Perform a thorough gap assessment by mapping your current security controls against every applicable PCI DSS requirement. Use the official PCI DSS requirements document (version 4.0.1 as of the current standard) as your reference. For each of the twelve requirement families, evaluate whether your organisation has a documented policy, an implemented control, evidence of control operation, and any known deficiencies.
Record findings in a structured format that captures the requirement number, current state, gap description, remediation action, owner, and target completion date. This gap assessment serves as your remediation project plan and provides traceability from identified weakness to resolution. Where possible, use automated tools to assess technical controls — configuration scanners, access reviews, and log analysis can accelerate the process and reduce the risk of human error. A thorough gap assessment prevents surprises late in the programme when remediation timelines are tightest.
Step 6: Prioritise remediation based on risk
Not all gaps carry equal risk. Prioritise remediation efforts by considering the severity of each gap, the likelihood of exploitation, and the potential impact on cardholder data confidentiality. Critical items — such as unencrypted PAN storage, missing multi-factor authentication, or absent logging — should be addressed first because they represent the highest risk and are the most likely to result in assessment findings.
Group remaining gaps into categories: high, medium, and low priority. Assign realistic timelines and dedicated owners for each remediation task. Build dependencies into your plan — for example, network segmentation must be in place before you can meaningfully reduce the scope of subsequent remediations. Report progress to leadership regularly and escalate blockers promptly. Organisations that treat remediation as a phased, risk-prioritised programme rather than a single monolithic effort consistently achieve compliance faster and with fewer last-minute crises.
Step 7: Implement network segmentation and firewall rules
Effective network segmentation is the foundation of a manageable PCI DSS programme. Design your network architecture so that the CDE resides in one or more isolated segments with tightly controlled ingress and egress. Deploy firewalls or equivalent filtering technologies at every boundary between the CDE and other network zones, including internal corporate networks, development environments, and guest wireless networks.
Configure firewall rules using a deny-all default posture, permitting only explicitly authorised traffic flows. Document every rule with a business justification and review the rule set at least every six months. Implement stateful inspection and ensure that anti-spoofing measures are active. Test segmentation controls by attempting to reach CDE systems from out-of-scope network zones — if any unauthorised path exists, segmentation is not effective and the broader network remains in scope. PCI DSS 4.0 specifically requires segmentation testing at least every six months for service providers and annually for merchants.
Step 8: Deploy encryption for data at rest and in transit
PCI DSS requires that stored PANs are rendered unreadable using strong cryptographic methods. Acceptable approaches include AES-256 encryption, one-way hashing with a strong cryptographic hash, truncation, or tokenisation. Whichever method you choose, implement robust key management procedures covering key generation, distribution, storage, rotation, and destruction. Keys must never be stored alongside the data they protect.
For data in transit, enforce TLS 1.2 or later on all connections that carry cardholder data, including internal network links between CDE components. Disable older protocols such as SSL and early TLS versions. Ensure that wildcard certificates are not used in ways that extend CDE scope unnecessarily. Validate encryption configurations using scanning tools and check certificate validity, cipher suite strength, and protocol negotiation. Document your cryptographic architecture, including key custodians and rotation schedules, as this documentation is a standard assessment deliverable.
Step 9: Implement access controls and multi-factor authentication
Restrict access to cardholder data and CDE systems to only those individuals whose job responsibilities require it. Implement role-based access controls with the principle of least privilege — each user account should have the minimum permissions necessary and nothing more. Maintain a formal access provisioning and de-provisioning process, and review all access rights at least every six months.
PCI DSS 4.0 requires multi-factor authentication (MFA) for all access into the CDE, not just remote access. This applies to administrators, developers, and any personnel accessing CDE systems from any network, including the internal corporate network. Deploy MFA using at least two of the three authentication factors: something you know, something you have, and something you are. Ensure that shared and generic accounts are eliminated or, where absolutely unavoidable, individually tracked. Enforce strong password policies with minimum length and complexity requirements, and implement automatic account lockout after repeated failed attempts.
Step 10: Establish logging and monitoring
Deploy centralised logging across all CDE systems, connected systems, and security-impacting systems. Capture logs for authentication events, access to cardholder data, administrative actions, changes to system configurations, firewall and security tool activity, and all access to audit trails. Synchronise clocks across all systems using NTP to ensure log correlation is accurate.
Implement a security information and event management (SIEM) platform or equivalent solution to aggregate, correlate, and alert on suspicious activity. Define alert thresholds for critical events such as multiple failed login attempts, new administrative accounts, unexpected outbound connections, and changes to logging configurations. Review logs daily — PCI DSS explicitly requires daily log reviews, which can be achieved through automated alerting supplemented by human analysis of flagged events. Retain audit logs for at least twelve months, with a minimum of three months immediately available for analysis.
Phase 3: Testing and Validation
The final phase confirms that your controls work as designed, identifies any remaining weaknesses, and produces the formal documentation required by your acquiring bank and the payment brands. Rigorous testing before validation prevents costly re-work and delays.
Step 11: Run internal and external vulnerability scans
Conduct internal vulnerability scans at least quarterly using a qualified internal resource or a third-party scanner. Scans must cover all in-scope systems and address any vulnerabilities rated 4.0 or higher on the CVSS scale. Rescan after remediation to confirm that vulnerabilities have been resolved.
External vulnerability scans must be performed quarterly by a PCI SSC-approved Approved Scanning Vendor (ASV). The ASV scans your internet-facing systems and issues a pass or fail result. A passing scan requires no vulnerabilities at CVSS 4.0 or above and no automatic-fail conditions such as DNS zone transfers, unrestricted directory listings, or the use of unsupported software. If your scan fails, remediate the identified issues and request a rescan. Maintain records of all scan results — both passing and failing — as evidence for your assessment. Ensure that scanning covers all externally accessible IP addresses and domain names associated with the CDE.
Step 12: Conduct penetration testing
Engage a qualified penetration testing firm to perform both external and internal penetration tests against your CDE. The methodology must follow an industry-accepted approach such as PTES, OWASP, or NIST SP 800-115. Tests must cover network-layer vulnerabilities, application-layer vulnerabilities (including the OWASP Top 10 for web applications), and any segmentation controls that define your CDE boundary.
Penetration tests are required at least annually and after any significant infrastructure or application change. Segmentation penetration tests must be conducted every six months for service providers. Document the scope, methodology, findings, and remediation actions for each test. Ensure that critical and high-severity findings are remediated and retested before proceeding to formal validation. The penetration test report is a key assessment deliverable — your QSA will review it in detail, so ensure that testing coverage is thorough and that the report clearly demonstrates the effectiveness of your segmentation and defensive controls.
Step 13: Perform a security policy review
Review and update your information security policy and all supporting procedures, standards, and guidelines. PCI DSS Requirement 12 mandates a comprehensive security policy that addresses all twelve requirement families, is reviewed at least annually, and is disseminated to all relevant personnel. Ensure that policies reflect your current environment, technologies, and organisational structure.
Verify that supporting documents are in place: an acceptable use policy, an incident response plan, a risk assessment methodology, a vendor management programme, and a security awareness training programme. Confirm that all personnel with access to CDE systems have completed security awareness training within the last twelve months and that training content covers current threats, social engineering, and the organisation’s specific security policies. Policy documentation is one of the most heavily scrutinised areas during a QSA assessment — gaps here frequently result in findings even when technical controls are strong.
Step 14: Complete the appropriate SAQ or prepare for QSA assessment
Your validation method depends on your merchant or service provider level and the payment brands you work with. Most Level 2, 3, and 4 merchants validate by completing a Self-Assessment Questionnaire (SAQ). Select the correct SAQ type based on your payment acceptance channels: SAQ A for e-commerce merchants that fully outsource payment processing, SAQ B for merchants using standalone terminals, SAQ C for merchants with payment applications connected to the internet, or SAQ D for all others.
For Level 1 merchants and all service providers, a full on-site assessment by a Qualified Security Assessor is required. Prepare for the QSA engagement by organising all evidence into a structured repository: policies, procedures, system inventories, data flow diagrams, scan results, penetration test reports, training records, access reviews, change management logs, and incident response documentation. Conduct a pre-assessment readiness review — either internally or with a QSA in a consulting capacity — to identify any remaining gaps before the formal assessment begins. Addressing issues before the QSA arrives is far more efficient than discovering them during the assessment itself.
Step 15: Submit the AOC and maintain ongoing compliance
Once your SAQ is complete or your QSA has issued a Report on Compliance (ROC), submit the Attestation of Compliance (AOC) to your acquiring bank and any payment brands that require it. The AOC is the formal declaration that your organisation meets PCI DSS requirements. Confirm submission deadlines with your acquirer, as these vary by payment brand and merchant level.
Compliance does not end with validation. PCI DSS is a continuous obligation, and your AOC is valid only for the period it covers. Establish an ongoing compliance programme that includes quarterly ASV scans, quarterly internal vulnerability scans, annual penetration tests, semi-annual firewall rule reviews, annual policy reviews, annual risk assessments, and continuous log monitoring. Track control effectiveness using a GRC platform such as Prova to automate evidence collection, monitor compliance posture in real time, and ensure that nothing lapses between assessment cycles. Organisations that treat PCI DSS as a continuous programme rather than an annual project consistently spend less time and money on each subsequent validation cycle.