In dit artikel8
Wat is PCI DSS?
PCI DSS is ontwikkeld om de beveiliging van betaalkaartgegevens (payment card account data) te bevorderen en te verbeteren. De standaard geeft een basislijn van technische en operationele eisen om betaalrekeninggegevens te beschermen. Als security engineer kom je de eisen tegen als concrete taken in netwerk, toegang en logging.
De PCI Security Standards Council (PCI SSC) beheert de standaard. Hij is in 2006 opgericht door American Express, Discover, JCB International, MasterCard en Visa Inc. De taak van de Council is standaarden ontwikkelen en onderhouden. Hij dwingt naleving niet af en houdt geen toezicht op de implementatie.
PCI DSS is dus geen wet, maar een standaard van de betaalbranche. Of naleving verplicht is, bepalen de organisaties die nalevingsprogramma's beheren, zoals een betaalmerk of een acquirer. In de praktijk merk je de verplichting via het contract met je acquirer of betaalmerk. Wie wil weten waar hij aan moet voldoen, begint daarom bij de vraag wie zijn contractpartner is.
Welke versie van PCI DSS geldt nu?
PCI SSC heeft PCI DSS v3.2.1 per 31 maart 2024 officieel ingetrokken. Op 11 juni 2024 publiceerde PCI SSC v4.0.1. Die versie is een beperkte herziening ("limited revision") van v4.0. Ze corrigeert opmaak- en typfouten en verduidelijkt het doel van enkele eisen en de bijbehorende richtlijnen. PCI SSC schrijft dat er in deze herziening geen extra of verwijderde eisen zitten.
PCI SSC schreef dat v4.0 op 31 december 2024 is ingetrokken. Sindsdien is v4.0.1 de enige actieve versie. Van 3 juni tot en met 20 juli 2026 hield PCI SSC een Request for Comments (RFC) over v4.0.1, "the currently-published version of the standard". Die RFC moet bepalen of en hoe v4.0.1 wordt herzien. Ook vraagt de RFC of PCI DSS beter kan aansluiten op andere standaarden van PCI SSC en of eisen aandacht nodig hebben vanwege de impact van AI en mobiel. Of en wanneer er een nieuwe versie komt, staat niet vast.
Controleer de actuele versie altijd in de Document Library van PCI SSC.
Voor wie geldt PCI DSS?
PCI DSS geldt voor entiteiten die kaarthoudergegevens (cardholder data, CHD) opslaan, verwerken of doorgeven. PCI SSC noemt daarbij alle partijen die betrokken zijn bij het verwerken van betaalkaarten: merchants, processors, acquirers, issuers en serviceproviders. De standaard is ook bedoeld voor entiteiten die de beveiliging van de cardholder data environment (CDE) kunnen beïnvloeden.
Account data bestaat uit kaarthoudergegevens en gevoelige authenticatiegegevens (sensitive authentication data, SAD). Tot de kaarthoudergegevens behoren het primary account number (PAN), de naam van de kaarthouder, de vervaldatum en de service code. Tot de gevoelige authenticatiegegevens behoren de volledige trackdata (van de magneetstrip of het gelijkwaardige op de chip), de kaartverificatiecode en pincodes of pinblokken.
Wat voor jou geldt, bepaalt vooral de partij met wie je het contract hebt. Een webwinkel die betalingen uitbesteedt, kan daarom toch eisen hebben. Uitbesteden kan de scope verkleinen, maar de merchant blijft verantwoordelijk voor zijn deel van de keten. Vraag je acquirer wat dat voor jou betekent. Ook acquirers en betaalinstellingen en retailers komen met de standaard in aanraking, elk op een eigen plek in de keten.
Kaarthoudergegevens zijn doorgaans ook persoonsgegevens. Naast PCI DSS kan daarom de AVG gelden. PCI DSS is een branchestandaard, de AVG is wetgeving. Lees meer over de AVG voor privacy-professionals of bekijk de vacatures met AVG-kennis.
Wat zijn de twaalf hoofdeisen van PCI DSS?
De twaalf hoofdeisen staan onder zes doelen. De tabel geeft per eis het doel en het gebied dat die eis in de praktijk raakt. De titels komen uit het PCI DSS v4.0-document voor merchants.
Eis | Doel | Wat het in de praktijk raakt |
|---|---|---|
1. Install and Maintain Network Security Controls | Netwerk en systemen | Netwerkbeveiligingsmaatregelen. Zie netwerkbeveiliging. |
2. Apply Secure Configurations to All System Components | Netwerk en systemen | Veilige standaardinstellingen voor systemen, apparaten en software. |
3. Protect Stored Account Data | Accountdata | Welke accountgegevens je bewaart en hoe je opgeslagen gegevens onleesbaar maakt. |
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Accountdata | Sterke versleuteling als kaarthoudergegevens over open of publieke netwerken worden verstuurd. Zie cryptografie. |
5. Protect All Systems and Networks from Malicious Software | Kwetsbaarheden | Bescherming tegen malware op systemen en netwerken. Zie vulnerability management. |
6. Develop and Maintain Secure Systems and Software | Kwetsbaarheden | Veilig ontwikkelen en patchen van systemen en software. Zie applicatiebeveiliging. |
7. Restrict Access to System Components and Cardholder Data by Business Need to Know | Toegang | Toegang tot systemen en kaarthoudergegevens beperken tot wat iemand voor zijn werk nodig heeft. Zie identity en access management. |
8. Identify Users and Authenticate Access to System Components | Toegang | Hoe gebruikers zich identificeren en authenticeren bij systemen. Zie identity en access management. |
9. Restrict Physical Access to Cardholder Data | Toegang | Fysieke toegang tot kaarthoudergegevens. |
10. Log and Monitor All Access to System Components and Cardholder Data | Monitoren en testen | Logging en monitoring van toegang tot systemen en kaarthoudergegevens. Zie security monitoring. |
11. Test Security of Systems and Networks Regularly | Monitoren en testen | Regelmatig testen van de beveiliging, zoals scans en penetratietests. Zie security testing. |
12. Support Information Security with Organizational Policies and Programs | Beleid | Beleid, verantwoordelijkheden en programma's die de technische maatregelen dragen. |
Versie v4.0.1 houdt dezelfde twaalf hoofdeisen. PCI SSC schrijft dat die herziening geen eisen toevoegt of verwijdert.
Scope is het eerste werk. Je stelt vast welke systemen kaarthoudergegevens opslaan, verwerken of doorgeven, en welke systemen daarmee verbonden zijn. Hoe kleiner en scherper de omgeving is afgebakend, hoe minder systemen onder de eisen vallen. De exacte scoperegels staan in de standaard, en het is verstandig die vooraf met je acquirer of de partij waaraan je rapporteert te bespreken.
Wat veranderde er met PCI DSS v4.0 en v4.0.1?
PCI DSS v4.0 introduceerde twee manieren om de eisen te implementeren en te valideren: de defined approach en de customized approach. Bevestig bij de partij waaraan je rapporteert welke validatie- en rapportagevereisten voor jou gelden.
Verder bevat v4.0 64 nieuwe eisen. Daarvan zijn er 51 "future-dated" met ingangsdatum 31 maart 2025. Tot die datum golden ze als best practice. Sindsdien zijn ze verplicht en moeten ze volledig worden meegenomen bij een PCI DSS-assessment. De herziening naar v4.0.1 verandert die datum niet.
Twee van die future-dated eisen gaan over scripts op betaalpagina's: 6.4.3 en 11.6.1. Ze vragen dat scripts op de betaalpagina zijn geautoriseerd, dat hun integriteit is gecontroleerd en dat ze worden gemonitord op manipulatie. Een webwinkel kan scripts van derden laden op de pagina waar een klant betaalt. Daarom zijn deze eisen een thema voor webwinkels en voor security engineers met applicatiekennis. Je moet weten welke scripts er staan en je moet wijzigingen opmerken.
Versie v4.0.1 bevat naast correcties ook enkele wijzigingen. Twee voorbeelden: bij eis 6 is de beperking tot "critical vulnerabilities" voor de verwachting om binnen 30 dagen te patchen hersteld naar de formulering van v3.2.1. Bij eis 8 staat nu een opmerking dat de MFA-eis voor niet-beheerders met toegang tot de CDE niet geldt voor accounts die alleen met phishing-resistente factoren zijn geauthenticeerd. Lees de exacte formulering altijd in de standaard zelf en niet alleen in een samenvatting.
Hoe valideer je PCI DSS? SAQ, ROC en QSA
Validatie is het bewijs dat je aan de eisen voldoet. Een Self-Assessment Questionnaire (SAQ) is het instrument waarmee in aanmerking komende merchants en serviceproviders hun PCI DSS-zelfbeoordeling uitvoeren en rapporteren. PCI SSC publiceerde de SAQ's voor v4.0.1 op 15 oktober 2024. Genoemde SAQ-types zijn A, A-EP, C, C-VT en D.
SAQ D is voor merchants die een SAQ mogen invullen maar aan de criteria van geen enkel ander SAQ-type voldoen. Voorbeelden zijn e-commerce-merchants die kaarthoudergegevens op hun site accepteren en merchants die kaarthoudergegevens elektronisch opslaan. Voordat je begint, bevestig je dat je aan de geschiktheidscriteria van de SAQ voldoet. PCI SSC adviseert ook om eerst contact op te nemen met de entiteit waaraan de SAQ wordt ingediend.
Per eis kies je in de SAQ een van deze antwoorden: In Place, In Place with CCW (Compensating Controls Worksheet), In Place with Remediation, Not Applicable, Not Tested of Not in Place. Bij Not Applicable en Not Tested is een onderbouwing nodig.
Een Qualified Security Assessor (QSA) is een bedrijf dat de Council heeft gekwalificeerd om PCI DSS-naleving te beoordelen. PCI SSC noemt QSA's "independent security organizations" die "validate an entity's adherence to PCI DSS". Medewerkers van zo'n bedrijf heten QSA Employees. PCI SSC keurt deze aanbieders niet goed. Een QSA is een externe partij die je inschakelt, geen functietitel.
Een Report on Compliance (ROC) is de andere vorm van rapportage. De SAQ is bedoeld voor merchants en serviceproviders die hun naleving zelf beoordelen en niet verplicht zijn een ROC in te dienen. PCI SSC publiceert voor v4.0.1 een ROC Template. Welk bewijs nodig is en bij wie je het indient, bepalen de betaalmerken en acquirers, en PCI SSC adviseert merchants om altijd contact met die partijen op te nemen. Bij twijfel vraag je dus eerst je acquirer welke validatie hij van je verwacht. Voor het actuele proces verwijs je naar PCI SSC en naar de partij waaraan je rapporteert.
Welke rollen werken met PCI DSS?
PCI DSS is geen functietitel. Verschillende rollen werken ermee.
- Security engineer. Je richt de technische maatregelen in, zoals segmentatie, hardening, logging, patching en toegangsbeheer, en je levert het bewijs daarvoor aan. Op de werkgeverspagina voor security engineers zie je welke werkgevers deze functie hebben.
- GRC consultant. Je helpt met de scope, met het kiezen van de juiste validatieroute (SAQ of ROC), met het verzamelen van bewijs en met het bijhouden van een jaarcyclus. Bij sommige organisaties doet een interne compliancefunctie dit werk. Zie GRC consultant.
- IT-auditor. Je toetst of maatregelen bestaan en werken, soms namens het bedrijf als interne auditor. Zie IT-auditor.
Een QSA is, zoals gezegd, een extern bedrijf dat de Council heeft gekwalificeerd. Wie op het gebied van compliance en privacy werkt, komt PCI DSS tegen in de bewijsvoering rond validatie.
Hoe verhoudt PCI DSS zich tot andere kaders?
PCI SSC publiceerde op 23 juli 2026 een mapping van PCI DSS v4.0.1 naar het NIST Cybersecurity Framework 2.0. Een medewerker van PCI SSC schrijft dat PCI DSS en de NIST CSF niet uitwisselbaar zijn en dat geen van beide de ander vervangt. Lees voor het kader zelf het artikel over het NIST Cybersecurity Framework.
ISO/IEC 27001 is een aparte norm van ISO en IEC. Zie het artikel over ISO 27001 voor wat die norm is. PCI DSS is specifiek voor betaalkaartgegevens, terwijl de NIST CSF en ISO/IEC 27001 breder zijn. Het zijn verschillende soorten documenten met een eigen doel. Meer over kaders vind je in de kennisbank.
Welke versie van PCI DSS geldt nu?
De actieve versie is PCI DSS v4.0.1, een beperkte herziening van v4.0 die op 11 juni 2024 is gepubliceerd. v3.2.1 is per 31 maart 2024 ingetrokken en v4.0 per 31 december 2024. In 2026 hield PCI SSC een RFC over v4.0.1, maar of en wanneer er een nieuwe versie komt, staat nog niet vast.
Wat zijn de twaalf eisen van PCI DSS?
De twaalf eisen zijn: 1 Install and Maintain Network Security Controls, 2 Apply Secure Configurations to All System Components, 3 Protect Stored Account Data, 4 Protect Cardholder 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, 7 Restrict Access to System Components and Cardholder Data by Business Need to Know, 8 Identify Users and Authenticate Access to System Components, 9 Restrict Physical Access to Cardholder Data, 10 Log and Monitor All Access to System Components and Cardholder Data, 11 Test Security of Systems and Networks Regularly en 12 Support Information Security with Organizational Policies and Programs. Ze vallen onder zes doelen, van netwerk en systemen tot beleid.
Voor wie geldt PCI DSS?
PCI DSS geldt voor alle entiteiten die kaarthoudergegevens opslaan, verwerken of doorgeven. PCI SSC noemt daarbij merchants, processors, acquirers, issuers en serviceproviders. Ook een webwinkel die betalingen uitbesteedt, kan eisen hebben, want de merchant blijft verantwoordelijk voor zijn deel van de keten.
Is PCI DSS verplicht?
PCI DSS is geen wet, maar een standaard van de betaalbranche. In de praktijk merk je de verplichting via het contract met je acquirer of betaalmerk. De PCI Security Standards Council beheert de standaard en dwingt naleving niet af, dus de partij waarmee je contracteert bepaalt wat voor jou geldt.
Wat is het verschil tussen een SAQ en een QSA?
Een SAQ is een zelfbeoordelingsvragenlijst voor in aanmerking komende merchants en serviceproviders, en de SAQ-types zijn A, A-EP, C, C-VT en D. Een QSA is een extern bedrijf dat door PCI SSC is gekwalificeerd om de naleving te beoordelen. Een ROC is een andere vorm van rapportage, en welke van de twee voor jou geldt, bepaalt je acquirer of het betaalmerk.