the whole job
PCI DSS: the whole job, in order
Your acquirer, a payment provider or a customer asks you to prove that card data is protected. PCI DSS is a standard from the PCI Security Standards Council, and the payment brands and your acquirer decide what you must submit. An attestation shows what you declared, for the scope you described, on a date. It does not show that you are secure or that you comply with a law. This plan runs from the question of what you must submit to the yearly repeat, in five stages.
how to read this plan
PCI DSS is validated against a fixed list of twelve requirements, so most steps either shrink the scope or build one group of them. The standard was not read in full for this plan and the brands' and acquirers' rules were not read at all, which is why every step says practice and no sub-requirement is cited. Take the detail from the current standard and the form your acquirer names. One step cites GDPR, because card data about a person is personal data. The order follows dependencies. Under each step a small note names the basis.
- decide and documentchoices, policies and records that someone with authority signs
- build and configuresystems, settings and procedures that make the choice real
- prove and operatechecks, logs and records that show it keeps working
find out what you must prove, and for which card data
Learn what your acquirer requires, find every place card data goes and take out of scope what you can.
ask the acquirer what you must submit
Ask your acquirer or payment provider which form you must submit, for which card channels, how often, who signs and whether an assessor is required. Get the answer in writing, because the payment brands and the acquirer decide this and the Council does not.
- owner procurement
- decide and document
- what it produces
- a written statement of the validation you owe
- the proof it leaves
- the acquirer's answer, with its date and sender
basis working practice. No legal text sets this.
map where card data goes
List every place card data is stored, processed or sent, including the website, terminals, call recordings, paper, logs and the suppliers that touch it. Add the systems that connect to those places, because they are in scope too.
- owner head of IT
- build and configure
- what it produces
- a card data map: channels, systems, locations and suppliers
- the proof it leaves
- the map, with an owner and a date for each entry
basis working practice. No legal text sets this.
decide what to take out of scope
Decide which card data you can stop storing, whether to send customers to a payment page run by a provider, and which systems to separate from the rest of the network. Each system you remove is a set of requirements you no longer have to meet.
- owner board
- decide and document
- what it produces
- a scope decision that names what stays and what leaves
- the proof it leaves
- the decision, approved by management, and the revised map
basis working practice. No legal text sets this.
choose the route and get the current documents
Fix which form or report you will complete and put the current standard in the hands of the people doing the work.
confirm the form with the acquirer
Check, with the acquirer, which questionnaire fits the way you take cards after the scope decision, or whether an assessor's report is required. The Council advises asking the acquirer or the brands which form applies.
- owner legal or DPO
- decide and document
- what it produces
- the named form or report type, and who completes it
- the proof it leaves
- the acquirer's confirmation
basis working practice. No legal text sets this.
get the current documents
Download the current standard, the form and its instructions from the Council's document library, and check whether a newer version has been published. This plan read only the Council's public pages, so take every requirement from these documents.
- owner head of IT
- build and configure
- what it produces
- the current standard and form, held by the people doing the work
- the proof it leaves
- the version numbers and the download date
basis working practice. No legal text sets this.
decide whether an assessor helps
Decide whether to bring in a Qualified Security Assessor to test, to advise or not at all, unless the acquirer requires one. The forms record what an assessor did, so the role has to match what the assessor actually performed.
- owner board
- decide and document
- what it produces
- a decision on the assessor's role, if any
- the proof it leaves
- the decision and, where used, the engagement terms
basis working practice. No legal text sets this.
build the controls, requirement by requirement
Close the gaps in the twelve requirements for everything that stayed in scope.
set network controls and secure configurations
Decide what may connect to what and enforce it with network controls, then configure every in-scope system securely and remove vendor defaults. These are the first two requirements.
- owner head of IT
- build and configure
- what it produces
- network rules and hardened configurations for the scope
- the proof it leaves
- the rule sets, the configuration standards and the review records
the control: endpoint-management
basis working practice. No legal text sets this.
protect stored and transmitted card data
Hold as little card data as possible, protect what remains and encrypt it when it crosses open networks, with keys that have owners and a lifecycle. Card data about a person is personal data, so the GDPR duty to apply appropriate security measures applies alongside.
- owner head of IT
- build and configure
- what it produces
- a data retention rule and encryption for stored and sent card data
- the proof it leaves
- the retention rule, the encryption settings and the key owner list
basis GDPR Art. 32(1)
keep malware and vulnerabilities in check
Run protection against malicious software on in-scope systems and patch them on a rhythm you can show. Scan regularly, since the Council's pages mention external vulnerability scans among the documents an acquirer may ask for.
- owner head of IT
- build and configure
- what it produces
- malware protection, a patch rhythm and scan reports
- the proof it leaves
- the scan reports, the patch records and the exception list
the work pagethe control: vulnerability-management
basis working practice. No legal text sets this.
secure the software you build or commission
If you write software, or have it written for you, that touches card data, set the rules for how it is built, reviewed and changed. The Council's form says the secure coding requirements apply only where bespoke or custom software exists.
- owner head of IT
- build and configure
- what it produces
- secure development rules for in-scope software
- the proof it leaves
- the rules, the review records and the change log
the control: secure-development
basis working practice. No legal text sets this.
limit access to what the job needs
Give each person their own account and only the access the job needs to card data and in-scope systems, with strong authentication, and control physical access to places where card data sits. These are requirements 7 to 9.
- owner head of IT
- build and configure
- what it produces
- role-based access, individual accounts, strong authentication and physical access rules
- the proof it leaves
- the access lists, the authentication settings and the visitor and door records
the work pagethe control: privileged-access
basis working practice. No legal text sets this.
log and test
Log access to in-scope systems and card data, review the logs, and test the security of systems and networks on a schedule. These are requirements 10 and 11.
- owner head of IT
- build and configure
- what it produces
- logging that covers the scope, a review routine and a test schedule
- the proof it leaves
- the log samples, the review records and the test reports
the control: logging-monitoring
basis working practice. No legal text sets this.
write the policy, train people and control providers
Write the security policy and name who owns each requirement, train the people in scope and write down how you handle an incident. List every provider that stores, processes or transmits card data for you or can affect your environment, and put terms for each into the contract. The Council's form says the provider requirement applies to everyone on that list.
- owner board
- build and configure
- what it produces
- a signed policy, a training record, an incident procedure and a provider list with contract terms
- the proof it leaves
- the policy, the attendance record, the procedure and the signed terms
the work pagethe control: supplier-management
basis working practice. No legal text sets this.
complete the form and attest
Fill in the form from evidence, have an officer sign and send it to the party that asked.
check yourself against the form first
Go through the form with the people who run the systems, mark what is in place and what is not, and fix the gaps before the date you will sign. Answer each item from evidence you can open.
- owner head of IT
- prove and operate
- what it produces
- a pre-check of the form with findings and owners
- the proof it leaves
- the pre-check, dated, with the evidence reference for each answer
basis working practice. No legal text sets this.
complete the form and the scope description
Complete every part, including the payment channels, the environment description and the providers. Mark an item as not applicable only after you have confirmed that it does not apply, and mark it as not tested only if you left it out of the assessment.
- owner everyone
- prove and operate
- what it produces
- the completed form, with explanations for every not applicable and not tested item
- the proof it leaves
- the form and the explanations
basis working practice. No legal text sets this.
have an executive officer read and sign
The officer who signs says the form fairly represents the results and that the controls will be kept in place. Give that officer the scope description and the open gaps before they sign.
- owner board
- prove and operate
- what it produces
- the signed attestation
- the proof it leaves
- the attestation, with the signatory, the title and the date
basis working practice. No legal text sets this.
send it and keep what you sent
Send the form and any other documents asked for, such as scan reports, to the party that requested them, and record what you sent and when. Share the attestation only as the brands' rules and the acquirer allow.
- owner legal or DPO
- prove and operate
- what it produces
- a submission record
- the proof it leaves
- the sent documents, the recipient and the date
basis working practice. No legal text sets this.
say what the attestation covers
Write a short statement of what the attestation covers: the channels, the systems, the date and whether it was full or partial. Use it when a customer or a partner asks, and do not describe it as compliance with a law.
- owner legal or DPO
- decide and document
- what it produces
- a short statement for sales and legal
- the proof it leaves
- the statement, matched to the attestation
basis working practice. No legal text sets this.
keep it true each year
Run the controls through the year and repeat the validation when it is due or when the payment flow changes.
ask how often and when it is due
Ask the acquirer how often you must validate and by when, and put the dates in the same calendar as your scans and tests. This plan did not read the brands' rules on frequency.
- owner procurement
- decide and document
- what it produces
- a calendar of due dates, scans and tests
- the proof it leaves
- the acquirer's answer and the calendar
basis working practice. No legal text sets this.
confirm the scope again
Re-confirm the scope at least once a year and whenever you add a payment channel, a provider or a system that touches card data. The Council's pages list an annual scope check among the requirements that took effect on 31 March 2025.
- owner head of IT
- prove and operate
- what it produces
- a dated scope confirmation or an updated card data map
- the proof it leaves
- the confirmation, the map and the change record
basis working practice. No legal text sets this.
review who has access to card data
Review on a schedule who can reach card data and in-scope systems, and remove access that nobody needs. Record the review and what changed.
- owner head of IT
- prove and operate
- what it produces
- a recurring access review
- the proof it leaves
- the review records, dated, with removals listed
basis working practice. No legal text sets this.
watch for a new version
Check the Council's document library before each validation for a new version of the standard or the form, and for changes to dates. The Council retired v4.0 on 31 December 2024, so versions do change.
- owner head of IT
- decide and document
- what it produces
- a version check before each validation
- the proof it leaves
- the check, dated, with the version noted
basis working practice. No legal text sets this.
who carries what
The same steps, grouped by the person who has to act.
head of IT
- map where card data goes
- get the current documents
- set network controls and secure configurations
- protect stored and transmitted card data
- keep malware and vulnerabilities in check
- secure the software you build or commission
- limit access to what the job needs
- log and test
- check yourself against the form first
- confirm the scope again
- review who has access to card data
- watch for a new version
board
legal or DPO
controls you will need
Each control has its own page: what it is, what to look for, where it goes wrong and the proof it leaves.
check it yourself
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
your next step
Ask your acquirer or payment provider in writing which validation you must submit, for which card channels and how often, and file the answer.