What is PCI DSS?
PCI DSS is a set of technical and organisational requirements protecting cardholder data — primarily the card number (PAN) and sensitive authentication data (magnetic stripe or chip contents, CVV/CVC codes, PIN). The standard is not a law but a contractual requirement: the compliance obligation flows from agreements with payment brands and acquirers, and violations can lead to contractual fines, increased fees and, in extreme cases, losing the ability to accept cards.
The current major version is PCI DSS v4.0, published in March 2022 and refined in June 2024 as v4.0.1. Version 3.2.1 was retired on 31 March 2024, and the v4.0 requirements marked as "future-dated" became mandatory on 31 March 2025 — including multi-factor authentication for all access into the cardholder data environment, authenticated internal scans, and protection of payment page scripts against web skimming attacks.
Who does it apply to?
PCI DSS applies to all participants in the card payment chain: merchants — from an online shop to a retail chain — and service providers who handle card data on behalf of others, such as payment processors, payment gateways, hosting providers and data centres. The key concept is the cardholder data environment (CDE): the systems that store, process or transmit card data, plus all systems that can affect their security. Well-designed network segmentation can radically reduce the assessment scope — and therefore its cost.
Payment brands classify merchants into levels (Level 1-4) by annual transaction volume, and service providers into levels 1-2. The level determines how compliance is validated: the largest undergo an annual external assessment, while smaller ones complete a self-assessment questionnaire.
The 12 requirements
PCI DSS v4.0 groups more than 250 detailed requirements into 12 principal requirements, organised under six control objectives.
- 1. Install and maintain network security controls (firewalls, NSCs).
- 2. Apply secure configurations to all system components (no vendor defaults).
- 3. Protect stored account data (retention, PAN masking, encryption, no SAD storage after authorisation).
- 4. Protect card data with strong cryptography during transmission over open, public networks.
- 5. Protect all systems and networks from malicious software.
- 6. Develop and maintain secure systems and software (patching, secure SDLC, payment page protection).
- 7. Restrict access to data by business need to know.
- 8. Identify users and authenticate access (unique IDs, MFA).
- 9. Restrict physical access to cardholder data (server rooms, media, POI terminals).
- 10. Log and monitor all access to system components and cardholder data.
- 11. Test the security of systems and networks regularly (vulnerability scans, ASV scans, penetration tests).
- 12. Support information security with organisational policies and programmes (risk, awareness, suppliers, incident response).
SAQ or a QSA assessment with a ROC?
PCI DSS compliance is validated in one of two ways. Smaller entities complete a Self-Assessment Questionnaire (SAQ) — its type depends on the acceptance channel: SAQ A covers e-commerce with payment fully redirected to a third-party provider, SAQ B covers terminals with no electronic data storage, and SAQ D — the most extensive — covers entities that store or process card data themselves, as well as service providers. Choosing the correct SAQ type is critical: the wrong type means the validation is invalid.
The largest merchants (Level 1, above 6 million annual transactions with the major payment brands) and Level 1 service providers undergo an annual on-site assessment by a Qualified Security Assessor (QSA) or an ISA internal assessor, resulting in a Report on Compliance (ROC). Whichever path applies, the outcome is confirmed by an Attestation of Compliance (AOC) submitted to the acquirer. In addition, most entities must pass quarterly external vulnerability scans performed by an Approved Scanning Vendor (ASV) from the PCI SSC list.
What happens without compliance?
PCI DSS is enforced by the payment brands through acquirers. The consequences of non-compliance include monthly contractual fines charged to the merchant (escalating the longer non-compliance lasts), higher interchange rates, and after a data breach — forensic investigation (PFI) costs, card reissuance and fraud recovery charges, and possible termination of the merchant agreement. In the European Union a card data breach is usually also a personal data breach under GDPR, adding the risk of administrative fines and the duty to notify the supervisory authority.
Remember that once-a-year validation is not operationally sufficient: v4.0 emphasises "security as a continuous process" — controls must operate all year round, and many requirements have defined frequencies (daily log review, quarterly scans, semi-annual access reviews, annual penetration tests and training).
How does Guardiso help?
Guardiso turns hundreds of detailed PCI DSS requirements into an organised, measurable programme — and keeps track of the frequencies that determine whether compliance holds between assessments.
- PCI DSS v4.0 requirements seeded as controls when you enable the standard — with implementation statuses, owners and evidence.
- Recurring tasks mirroring the standard’s rhythm: quarterly scans, semi-annual access reviews, annual tests, training and policy reviews — with reminders before deadlines pass.
- A third-party service provider (TPSP) register tracking AOC validity, with a responsibility matrix.
- Policies and procedures generated from templates: security policy, key management, incident response plan.
- A risk register supporting the targeted risk analyses required by v4.0.
- An evidence repository ready for assessment: scan reports, pentest results, training and review records — all in one place for the QSA.
- Cross-mapping to ISO 27001, SOC 2 and NIS 2 — controls implemented for PCI DSS satisfy the overlapping requirements of other frameworks.