PCI DSS

Companies usually meet PCI DSS when an acquirer, a payment provider or a customer asks for proof that card data is protected. It is a standard written by the PCI Security Standards Council, which the major card brands founded and belong to. The Council’s pages describe a standard and compliance programmes run by the payment brands. They do not describe a law.

The practical point is who decides. The Council writes the standard and the forms. The brands and your acquirer decide whether you have to validate, how, and what you send them. So the first question is never “what does the standard say” but “what has my acquirer asked me to submit”.

The Council says the standard is for all entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. Cardholder data includes the card number, the cardholder name, the expiry date and the service code. Sensitive authentication data includes full track data, the card verification code and PINs. Together they are account data.

That reaches further than the shop that takes the payment. A company that runs the website, hosts the server, answers the phone for orders or manages a network that touches the payment systems can be in scope. A service provider that handles card data for others is in scope for that service. Whether you must validate, and at what level, is set by your acquirer and the brands. This page did not read their rules on levels or thresholds.

The Council’s document library features PCI DSS v4.0.1 on 2 November 2026. It was announced on 11 June 2024 as a limited revision of v4.0: errors fixed and some intent clarified, with no requirements added or removed. The Council retired v4.0 on 31 December 2024, so v4.0.1 is the supported version. Of the 64 requirements that v4.x added, 51 were dated in the future, and the Council gives 31 March 2025 as the date they took effect. That date has passed, so an assessment today includes them.

Check the document library for a newer version before you start, because this page cannot tell you what is published after the date above.

The Council groups twelve principal requirements under six goals. The titles below are the Council’s, followed by what they mean for a company without a security team.

Build and maintain a secure network and systems

1. Install and maintain network security controls. Decide what may talk to what, and put firewalls or equivalents in between.
2. Apply secure configurations to all system components. Remove vendor defaults and switch off what you do not use.

Protect account data 3. Protect stored account data. Keep as little as you can, and protect what you keep. 4. Protect cardholder data with strong cryptography during transmission over open, public networks. Encrypt card data when it crosses the internet.

Maintain a vulnerability management program 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software. Patch, and build or buy software that is written safely.

Implement strong access control measures 7. Restrict access to system components and cardholder data by business need to know. 8. Identify users and authenticate access to system components. Every person has their own account, and strong authentication. 9. Restrict physical access to cardholder data.

Regularly monitor and test networks 10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly. Scan, test and check for changes.

Maintain an information security policy 12. Support information security with organisational policies and programs. Written policy, named owners, training, incident response and control of service providers.

Each requirement has many sub-requirements. This page did not read the standard’s full text, so use the current document and your acquirer’s chosen form for the detail.

There are two routes, and your acquirer or the brand decides which one you take.

A self-assessment questionnaire. The Council publishes several versions for different ways of taking cards, such as a website that sends the customer to a payment provider, a standalone card terminal, or a merchant who falls under none of the shorter forms. The Council advises asking your acquirer, the brands or another compliance body which one applies, and the longest form, SAQ D, is for merchants that meet no other form’s criteria. Service providers that qualify for a self-assessment use their own version of SAQ D.

A report on compliance. An assessor tests your environment against the standard and writes a report. The Council’s forms record whether a Qualified Security Assessor or an internal assessor took part and what they did. Whether you need one is a question for the brands and your acquirer.

Both routes end in an attestation of compliance, signed by an executive officer of the company. It states whether the assessment was full or partial and gives one of three results: compliant, non-compliant, or compliant with a legal exception. A questionnaire answer is one of six: in place; in place with a compensating control; in place with remediation; not applicable; not tested; or not in place. Anything marked not tested makes the assessment partial. You send the form and any other documents asked for, such as external vulnerability scan reports, to the organisation that requested them.

The Council says the attestation is meant to be shared with the entities that ask for it, under the brands’ rules.

Every system that stores, processes or transmits card data, and every system that can affect those systems, is in scope. The Council’s scoping guidance starts from the assumption that everything is in scope until verified otherwise. The cheapest control is the system you take out of scope.

Three moves do most of the work. Stop storing card data you do not need, because requirements on stored data fall away when you hold none. Send customers to a payment page run by a service provider, so that card data never reaches your servers. Separate the systems that touch card data from the rest of your network, so that the rest stays out. The Council describes segmentation as a way to reduce the systems in scope, and its guidance asks you to verify that the systems left outside cannot reach those inside.

Two cautions. Using a service provider does not remove the duty: you still have to manage that provider, and the standard says so for every provider on your list. And the scope has to be confirmed again at least once a year and when the environment changes.

An attestation shows that the signing officers declared, on a date, that the assessment was completed according to the instructions and fairly represents the results. In an assessor’s report it also shows what the assessor tested. It shows the scope you described: the payment channels, the systems and the service providers listed. A partial assessment shows only the requirements that were tested.

It does not show that your systems are secure today, or that they were secure the day after the date on the form. A self-assessment is your own account of yourself unless an assessor took part. It does not cover a payment channel that was left out of the scope, or a service provider that was not listed. It does not show compliance with GDPR: card data about a person is personal data, and the GDPR duty to apply appropriate security measures stands on its own. Last, the attestation is only as useful as the acquirer’s rule that asked for it.

The order that holds up is scope first, build second, prove last. The implementation plan sets out the steps. In short:

1. Ask. Get your acquirer’s requirement in writing: which form, which channels, how often, who signs.
2. Map the card data. Find every place card data is stored, processed or sent, including paper, call recordings and logs. This is the asset inventory with a card data column.
3. Reduce. Remove what you can from scope, as described above.
4. Build, requirement by requirement. Network and configuration (requirements 1 and 2) with endpoint management; stored and sent data (3 and 4) with encryption keys; malware, patches and software (5 and 6) with vulnerability management and secure development; access (7 to 9) with privileged access and MFA; logs and tests (10 and 11) with logging and monitoring; policy, people, incidents and providers (12) with supplier management and awareness training.
5. Prove. Fill in the form from evidence, have the officer who signs read it, and send it.
6. Repeat. Re-confirm scope each year and whenever a payment flow changes.

The standard itself is a Council document that has to be downloaded. This page read the Council’s public pages, FAQs, blog posts and one questionnaire form with its attestation. It did not read the full requirements and testing procedures, the assessor and acquirer programme guides, the brands’ own rules, validation levels or any contract with an acquirer. Sub-requirement numbers are cited only where a Council page shows them. Check the current standard and ask your acquirer before you commit to a route.