Kort samengevat: wat is PCI DSS
- Twaalf beveiligingsvereisten van de PCI Security Standards Council voor iedereen die kaarthouder-gegevens opslaat, verwerkt of verzendt.
- Huidige versie is 4.0.1. Vereisten 6.4.3 (scriptinventaris) en 11.6.1 (betaalpagina-tamperdetectie) gehandhaafd vanaf 31 maart 2025.
- Non-compliance betekent boetes, mogelijk verlies van kaartmerkacceptatie en volledige aansprakelijkheid voor breachkosten.
Wat PCI DSS is en wie het beheert
De standaard wordt gepubliceerd door de PCI Security Standards Council, een entiteit die in 2006 werd opgericht door American Express, Discover, JCB, Mastercard en Visa om de beveiliging van kaartgegevens binnen het betaalecosysteem te standaardiseren. Vóór de council had elk kaartmerk zijn eigen beveiligingsprogramma. Door ze samen te voegen in PCI DSS konden handelaren en serviceproviders zich op één kader richten in plaats van vijf.
PCI DSS is geen wet, maar wordt contractueel verplicht door elk kaartmerk en elke acquirer waarmee je kaarten kunt accepteren. Non-compliance kan leiden tot boetes, hogere verwerkingstarieven, kosten voor forensisch onderzoek na een inbreuk, en het volledig verliezen van de mogelijkheid om kaartbetalingen te verwerken.
Wie moet voldoen
Elk bedrijf dat betaalkaartgegevens accepteert, opslaat, verwerkt of verzendt. De verplichting geldt op verschillende niveaus, afhankelijk van het transactievolume:
| Handelaarsniveau | Transactievolume | Validatie |
|---|---|---|
| 1 | Meer dan 6M/jaar (Visa/Mastercard) | Jaarlijkse RoC ondertekend door QSA |
| 2 | 1M-6M/jaar | Jaarlijkse SAQ (meestal SAQ D) + ASV-scans |
| 3 | 20K-1M e-commerce/jaar | Jaarlijkse SAQ + ASV-scans |
| 4 | Minder dan 20K e-commerce of 1M totaal | Jaarlijkse SAQ, ASV-scans indien vereist |
| Serviceprovider | Elke entiteit die kaartgegevens voor anderen verwerkt | Jaarlijkse RoC ondertekend door QSA |
De specifieke SAQ-variant hangt af van hoe je kaartgegevens verwerkt. Voor de verschillen zie onze SAQ D-gids en onze gids over het PCI DSS Report on Compliance.
De 12 vereisten
PCI DSS 4.0.1 ordent zijn controles onder zes doelen die samen 12 vereisten bevatten:
Doel 1: Bouw en onderhoud een beveiligd netwerk en beveiligde systemen
- Vereiste 1: Installeer en onderhoud netwerkbeveiligingscontroles
- Vereiste 2: Pas beveiligde configuraties toe op alle systeemcomponenten
Doel 2: Bescherm accountgegevens
- Vereiste 3: Bescherm opgeslagen accountgegevens
- Vereiste 4: Bescherm kaarthoudergegevens met sterke cryptografie tijdens de verzending
Doel 3: Onderhoud een programma voor kwetsbaarhedenbeheer
- Vereiste 5: Bescherm alle systemen en netwerken tegen kwaadaardige software
- Vereiste 6: Ontwikkel en onderhoud beveiligde systemen en software
Doel 4: Implementeer sterke toegangscontrolemaatregelen
- Vereiste 7: Beperk toegang op basis van zakelijke noodzaak (need to know)
- Vereiste 8: Identificeer gebruikers en authenticeer toegang
- Vereiste 9: Beperk fysieke toegang tot kaarthoudergegevens
Doel 5: Monitor en test netwerken regelmatig
- Vereiste 10: Registreer en monitor alle toegang
- Vereiste 11: Test de beveiliging van systemen en netwerken regelmatig
Doel 6: Onderhoud een informatiebeveiligingsbeleid
- Vereiste 12: Ondersteun informatiebeveiliging met organisatorisch beleid en programma's
Elke vereiste heeft meerdere subvereisten. De volledige standaard beslaat honderden pagina's.
Wat er veranderde in PCI DSS 4.0.1
Versie 4.0.1 verving PCI DSS 3.2.1 als verplichte standaard op 31 maart 2025. De belangrijkste toevoegingen ten opzichte van 3.2.1 draaien om client-side beveiliging:
- Vereiste 6.4.3: houd een scriptinventaris bij op betaalpagina's, documenteer de zakelijke rechtvaardiging, verifieer de integriteit, detecteer ongeautoriseerde wijzigingen
- Vereiste 11.6.1: monitor HTTP-headers op betaalpagina's, detecteer ongeautoriseerde wijzigingen en waarschuw erover
- Vereiste 8.3.6: strengere eisen aan wachtwoordcomplexiteit
- Vereiste 8.4.2: MFA vereist voor alle niet-console-beheertoegang tot de kaarthoudergegevensomgeving
- Vereiste 12.3.3: inventaris van cryptografische ciphers en protocollen
- Vereiste 10.7.2/3: uitgebreidere logging en monitoring
De client-side-toevoegingen zijn het belangrijkst omdat ze een gat dichten dat traditionele beveiligingstools niet dekken. Aanvallen zoals Magecart-achtige script skimming spelen zich volledig in de browser af, en tot 4.0.1 bestond er geen expliciete PCI DSS-vereiste om ze te detecteren.
Voor de uitgebreide uitleg zie onze complete gids voor PCI DSS 4.0 en de samenvatting van de 4.0.1-implementatiewebinar.
Veelgemaakte fouten bij PCI DSS-compliance
Bij handelaren die hun eerste 4.0.1-beoordeling doorlopen, duiken telkens dezelfde tekortkomingen op:
- Geen scriptinventaris op betaalpagina's: vereist door 6.4.3, afwezig in de meeste omgevingen vóór 2025
- Geen monitoring van HTTP-headers: vereist door 11.6.1
- De scope onderschatten: ervan uitgaan dat SAQ A van toepassing is terwijl eigenlijk SAQ A-EP of SAQ D vereist is
- Handmatig bewijsmateriaal verzamelen: QSA's hebben doorlopend bewijs nodig, geen screenshots die tijdens de beoordeling worden gemaakt
- Compenserende controles zonder formele documentatie: QSA's accepteren geen ongedocumenteerde compenserende controles
- Certificeringen van leveranciers als jouw compliance beschouwen: dat je betaalverwerker PCI-compliant is, maakt jou nog niet PCI-compliant
Waar cside past
Vereisten 6.4.3 en 11.6.1 zijn de twee gebieden waarop de meeste PCI DSS-beoordelingen het slechtst zijn voorbereid. cside levert doorlopende scriptinventaris, integriteitsmonitoring, monitoring van HTTP-headers en een geschiedenis van wijzigingsmeldingen, precies het bewijs dat een QSA nodig heeft om die vereisten goed te keuren.
Voor de praktische implementatiegids zie hoe je voldoet aan PCI 6.4.3 en de QSA-gids voor 6.4.3 en 11.6.1.
Aan de slag
Als PCI DSS nieuw voor je is, ziet de volgorde er zo uit:
- Bepaal je handelaarsniveau en welke SAQ (of RoC) van toepassing is
- Maak een scope-diagram dat elk systeem omvat dat kaartgegevens opslaat, verwerkt of verzendt
- Voer een gap-analyse uit ten opzichte van de toepasselijke vereisten
- Verhelp de tekortkomingen en geef prioriteit aan alles wat de transactieverwerking blokkeert
- Vul de SAQ in of schakel een QSA in voor de RoC
- Houd doorlopend bewijsmateriaal bij voor de volgende jaarlijkse cyclus
Compliance is een doorlopend programma, geen eenmalig project. Handelaren die het als continu behandelen, zijn uiteindelijk per cyclus minder tijd en geld kwijt dan handelaren die elk jaar hun bewijsmateriaal opnieuw moeten samenstellen.
