PCI DSS implementation plan: phases, owners, deliverables and a schedule you can adapt

What a PCI DSS implementation plan has to do

The plan answers one question: how does this organisation move from today's card data environment to a validated Attestation of Compliance, with named people doing named work in a known order? It is organised by phase rather than by requirement, because some early decisions change the size of everything that follows.

Before the plan starts, two things should already be settled: which validation route your acquirer or customers expect, and what the gap analysis found. Our PCI DSS gap analysis guide covers the second. The plan below assumes both are known and turns the findings into a sequence.

The six phases, and the decision that closes each one

Phase 1: scope reduction and segmentation

Shrinking the footprint first is the largest saving in the project: each system removed is one you no longer harden, patch, log and test. Typical moves are tokenisation, a hosted payment page, point-to-point encryption or segmentation. The phase closes when the sponsor signs off the target scope and the data-flow diagrams that describe it. The method itself is covered in PCI DSS scoping and segmentation: shrinking the CDE.

Phase 2: remediation of technical controls

With the scope fixed, the technical gaps are closed in order of risk and lead time. Items that need procurement or architectural change go first: multi-factor authentication into the environment, centralised logging with alerting, payment page script controls, encryption and key management. The decision point is a remediation tracker with every high-risk item either closed or carrying an approved date.

Phase 3: policies and procedures

Policy writing should start in parallel with remediation, not after it, because procedures describe how the new controls are operated. Tie each document to a control someone actually runs. The phase closes when policies are approved and the people who operate them have been briefed. What a QSA expects to read is set out in PCI DSS documentation: policies, procedures and the records a QSA asks for.

Phase 4: testing

Testing proves the remediated environment holds. It covers internal vulnerability scans, external scans by an Approved Scanning Vendor, penetration testing from inside and outside, and segmentation testing if segmentation is what keeps other networks out of scope. Schedule the first penetration test once the main technical changes are live.

Phase 5: evidence over time

A QSA does not only ask whether a control exists; it samples records showing that the control has operated. Quarterly scans, periodic access reviews, daily log review, rule reviews, training completions and provider monitoring all generate evidence on their own cycle. Its length is set by the longest cycle the assessor wants to see, and it starts the day each control goes live.

Phase 6: validation through a QSA or an SAQ

The last phase is an internal assessment of every applicable requirement against its evidence, followed by the validation itself: QSA fieldwork leading to a Report on Compliance and an Attestation of Compliance, or a self-assessment questionnaire with its attestation signed by an executive. The mechanics are explained in PCI DSS validation step by step: ROC, SAQ and AOC.

A phase-by-phase schedule you can adapt

The week ranges below are estimates for an illustrative mid-sized merchant or service provider heading for a Report on Compliance, with reasonable network documentation and a few technology purchases to make. A small SAQ scope compresses them; several payment channels, sites or legacy systems stretch them. The hub places most projects at three to nine months overall, and the separate PCI DSS timeline guide explains what moves each stage.

Roles: who owns what

Write these roles into the charter before phase 1.

• Executive sponsor. Approves the scope, funds the technology, clears blocked decisions and signs the attestation.
• PCI lead. Runs the plan, the tracker and the evidence library, and is the single contact for the QSA and the acquirer.
• Network owner. Segmentation, firewall rules, wireless, hardening, scans and segmentation tests.
• Application owner. Payment pages and their scripts, secure development, change control, patching of applications and payment software.
• HR owner. Screening, joiner and leaver processes that remove access on time, and records of awareness training.
• Third-party owner. The register of service providers, their AOCs, contracts and the matrix that shows which requirements each party is responsible for.

Internal assessors, whether your own staff, an Internal Security Assessor or Sterling in the internal assessment, check the work before validation. That role is covered in PCI DSS internal audit and the ISA: testing your own controls.

When to engage the QSA

Engage the QSA company in the first weeks, not the last. It can confirm your scope reasoning and your segmentation approach before you invest in them. It can tell you what it will sample and how much history it expects to see, which fixes the length of phase 5. And its fieldwork calendar is often booked well ahead, so a date agreed early anchors the whole plan.

Keep one line clear: the QSA company assessing you must stay independent of the work it assesses, so the design and remediation belong with your team and your consultant. If you are on the SAQ route, confirm the questionnaire type with your acquirer at mobilisation instead; the eligibility rules are in Which SAQ applies to you. How to compare assessors is covered in Choosing a QSA.

Design™ or Drive™: two ways to run the same plan

The phases do not change with the level of support; who carries the work does. The choice depends on how much capacity your control owners really have.

What stalls PCI DSS projects

• Remediating before the scope is fixed. Hardening and logging systems that later leave scope wastes weeks; fixing phase 1 first avoids it.
• Waiting for procurement. MFA, logging and tokenisation tools can take longer to procure than to configure. Raise purchase requests in the first month.
• A PCI lead with no time. When the lead is also running daily operations, the tracker goes quiet and deadlines slip unnoticed.
• Treating evidence as a final task. Records cannot be produced retrospectively; if the quarterly scan or access review did not happen, the gap shows.
• Service providers left to the end. Collecting AOCs and responsibility matrices depends on other organisations answering, so start in phase 1.
• Testing too early or too late. A penetration test before changes are finished must be repeated; one scheduled days before fieldwork leaves no time to fix findings.

PCI DSS implementation plan: questions buyers ask