PCI DSS Naleving voor Nederlandse Bedrijven: Een Praktische Gids voor v4.0
Elk Nederlands bedrijf dat betaalkaartgegevens accepteert, verwerkt, opslaat of doorstuurt, moet voldoen aan de Payment Card Industry Data Security Standard (PCI DSS). De PCI Security Standards Council heeft v3.2.1 in maart 2024 buiten gebruik gesteld; versie 4.0 is sindsdien de enige actieve versie en dekt elk betaalkanaal van een kaartterminal tot een online checkout. Dit artikel behandelt wat v4.0 vereist, welke zelfevaluatieroute bij uw bedrijf past, wat de nieuwe vereisten in de praktijk betekenen en hoe u uw compliancebereik kunt verkleinen.
- Elk Nederlands bedrijf dat kaartbetalingen accepteert is gebonden aan PCI DSS via het contract met de acquiring bank, niet via de wet
- PCI DSS v4.0 is de enige actieve versie vanaf maart 2024; alle beoordelingen gebruiken nu deze versie
- Uw merchant level bepaalt welke validatieroute van toepassing is; de meeste Nederlandse mkb-bedrijven zijn Level 3 of Level 4
- De meeste Nederlandse e-commerce mkb-bedrijven komen in aanmerking voor SAQ A als zij de betalingsverwerking volledig uitbesteden aan een gehoste pagina, met slechts 22 vereisten
- Bereikvermindering is de meest effectieve compliancestrategie: houd kaartgegevens buiten uw eigen servers via gehoste betaalpagina's, netwerksegmentatie en tokenisatie
- Boetes bij niet-naleving variëren van EUR 5.000 tot EUR 100.000 per maand; een datalek kan leiden tot aansprakelijkheid voor de volledige kosten van vervanging van alle getroffen kaarten
Wat is PCI DSS en wie handhaaft het?
PCI DSS is een private informatiebeveiligingnorm beheerd door de PCI Security Standards Council (PCI SSC), een organisatie opgericht in 2006 door Visa, Mastercard, American Express, Discover en JCB. Het is geen wet. Geen overheidsinstantie handhaaft het of legt boetes op bij niet-naleving. Uw contract met uw acquiring bank handhaaft het.
Door u aan te melden bij een acquirer om kaartbetalingen te accepteren, stemt u in met de naleving van PCI DSS als voorwaarde van die overeenkomst. Nederlandse acquirers zijn onder meer ING, Rabobank, ABN AMRO, Adyen, Mollie, Pay.nl en Buckaroo. Elke acquirer stelt zijn eigen complianceprogramma in: hoe vaak u documentatie moet indienen, of zij een gevalideerd Rapport van Naleving (RoC) of een Verklaring van Naleving (AOC) vereisen, en hoe zij omgaan met niet-conforme merchants.
Merchant levels bepalen welke validatieroute op u van toepassing is:
- Level 1: Meer dan 6 miljoen Visa- of Mastercardtransacties per jaar, of elke merchant die een kwalificerende inbreuk heeft meegemaakt. Vereist een jaarlijkse audit op locatie door een Qualified Security Assessor (QSA) en kwartaalscans door een Approved Scanning Vendor (ASV).
- Level 2: 1 miljoen tot 6 miljoen transacties per jaar. Jaarlijkse zelfevaluatievragenlijst (SAQ) plus kwartaal ASV-scans.
- Level 3: 20.000 tot 1 miljoen e-commercetransacties per jaar. Jaarlijkse SAQ plus kwartaal ASV-scans.
- Level 4: Minder dan 20.000 e-commercetransacties, of minder dan 1 miljoen totale transacties. Jaarlijkse SAQ; ASV-scan kan vereist zijn naar goeddunken van de acquirer.
De meeste Nederlandse mkb-bedrijven zijn Level 3 of Level 4. Uw acquirer bepaalt uw level op basis van de transactievolumes die u opgeeft.
Acquiring banken kunnen niet-conforme merchants beboeten met EUR 5.000 tot EUR 100.000 per maand. Bij een datalek kunnen kaartmerken u aansprakelijk stellen voor de volledige kosten van vervanging van alle getroffen kaarten, forensische onderzoekskosten en terugboekingen. Die aansprakelijkheid kan voor zelfs een bescheiden lek zes of zeven cijfers bereiken. Bovendien zijn kaarthoudersgegevens persoonsgegevens onder de AVG: als een lek de meldingsdrempel haalt, moet u de Autoriteit Persoonsgegevens (AP) binnen 72 uur informeren. DNB-gereguleerde instellingen staan onder aanvullend toezicht in het kader van operationele weerbaarheid.
De 12 PCI DSS-vereisten in een oogopslag
De PCI SSC heeft de norm opgebouwd rond 12 hoofdvereisten, elk met specifieke deelvereisten. Samen vormen zij een beveiligingsraamwerk dat netwerkscontroles, gegevensbescherming, toegangsbeheer, monitoring, testen en beleid omvat.
| # | Vereiste | Wat het in de praktijk betekent |
|---|---|---|
| 1 | Installeer en onderhoud netwerkbeveiligingscontroles | Firewallregels regelmatig geconfigureerd en beoordeeld; netwerksegmentatie tussen de kaarthoudersgegevensomgeving en andere systemen |
| 2 | Pas veilige configuraties toe op alle systeemcomponenten | Geen standaardwachtwoorden van leveranciers; systeemverhardingsnormen toegepast op alle in-scope apparaten en software |
| 3 | Bescherm opgeslagen accountgegevens | Sla CVV niet op na autorisatie; versleutel primaire accountnummers (PAN's) indien opgeslagen; duidelijke bewaarschema's voor kaartgegevens |
| 4 | Bescherm kaarthoudersgegevens tijdens verzending | TLS 1.2 of hoger op alle transmissieroutes; geen onversleutelde verzending van kaartgegevens via e-mail of berichten |
| 5 | Bescherm alle systemen tegen malware | Anti-malware of EDR op alle in-scope systemen; anti-phishingcontroles; regelmatige definitie-updates en scanschema's |
| 6 | Ontwikkel en onderhoud veilige systemen en software | Patchbeheerproces; OWASP Top 10 aangepakt voor webgerichte applicaties; codereviews voor aangepaste betaalsoftware |
| 7 | Beperk toegang tot kaarthoudersgegevens op basis van zakelijke noodzaak | Rolgebaseerde toegangscontrole; minimale rechten toegepast op alle accounts; toegang regelmatig beoordeeld en onmiddellijk ingetrokken bij rolwijziging |
| 8 | Identificeer gebruikers en authenticeer toegang tot systeemcomponenten | Unieke gebruikers-ID's voor elk individu; MFA vereist voor alle toegang tot de kaarthoudersgegevensomgeving (uitgebreid in v4.0) |
| 9 | Beperk fysieke toegang tot kaarthoudersgegevens | Fysieke toegangscontroles op locaties met in-scope systemen; controles op manipulatie van POS-apparaten; procedures voor verwijdering van media |
| 10 | Registreer en monitor alle toegang tot systeemcomponenten en kaarthoudersgegevens | Auditlogs 12 maanden bewaard met minimaal 3 maanden direct beschikbaar; waarschuwingen bij afwijkende toegangspatronen |
| 11 | Test regelmatig de beveiliging van systemen en netwerken | Kwartaalscans op interne en externe kwetsbaarheden; jaarlijkse penetratietest; bestandsintegriteitsmonitoring op in-scope systemen |
| 12 | Ondersteun informatiebeveiliging met organisatiebeleid | Schriftelijk informatiebeveiligingsbeleid; jaarlijkse risicobeoordeling; gedocumenteerd incidentresponsplan; beveiligingsbewustzijnstraining voor alle relevante medewerkers |
Nieuw in PCI DSS v4.0
PCI DSS v4.0 werd gepubliceerd in maart 2022. De PCI SSC heeft versie 3.2.1 op 31 maart 2024 buiten gebruik gesteld, waardoor v4.0 vanaf die datum de enige actieve versie is. Als uw laatste beoordeling op basis van v3.2.1 was, moet uw volgende beoordeling v4.0 gebruiken.
De release introduceerde 64 nieuwe vereisten. Dertien traden in werking bij adoptie. De overige 51 classificeerde de PCI SSC als aanbevolen praktijken tot 31 maart 2025, waarna zij verplicht werden. Als u nu beoordeelt, gelden alle 64.
De meest significante wijzigingen zijn:
- Aangepaste aanpak: v4.0 introduceert een tweede compliancepad naast de traditionele gedefinieerde aanpak. De aangepaste aanpak laat volwassen organisaties hun eigen controles ontwerpen om aan de vermelde beveiligingsdoelstelling van elke vereiste te voldoen, in plaats van de voorschrijvende implementatie te volgen. In de praktijk vereist deze optie uitgebreide documentatie en is zij het meest geschikt voor organisaties met ervaren beveiligingsteams. De meeste Nederlandse mkb-bedrijven blijven de gedefinieerde aanpak gebruiken.
- MFA uitgebreid: PCI DSS v4.0 vereist nu multifactorauthenticatie voor alle toegang tot de kaarthoudersgegevensomgeving. Zowel lokale als externe toegang vereist MFA. Dit is een harde vereiste.
- E-commerce scriptbeveiliging (Vereisten 6.4.3 en 11.6.1): Deze vereisten richten zich op het Magecart-aanvalspatroon, waarbij criminelen kwaadaardige scripts in betaalpagina's injecteren om kaartgegevens te onderscheppen terwijl klanten typen. U moet een inventaris bijhouden van elk script dat op betaalpagina's wordt geladen, een zakelijke rechtvaardiging voor elk documenteren en mechanismen voor integriteitscontrole gebruiken om ongeautoriseerde wijzigingen te detecteren. Als uw checkout-pagina scripts van derden laadt voor analyses, klantenondersteuning of A/B-testen, zijn deze vereisten op u van toepassing.
- Wachtwoordcomplexiteit: De minimale wachtwoordlengte voor accounts op in-scope systemen is verhoogd van 7 naar 12 tekens.
- Gerichte risicoanalyse: U moet nu de frequentie van verschillende periodieke activiteiten rechtvaardigen via een gedocumenteerde risicoanalyse die specifiek is voor uw omgeving, in plaats van een vast schema te volgen dat in de norm is vastgelegd.
Als u een v4.0-beoordeling voltooide vóór 31 maart 2025, heeft de assessor mogelijk de 51 best-practice-vereisten niet opgenomen. Uw volgende beoordeling omvat ze allemaal. Identificeer welke van de 51 nu verplichte vereisten uw assessor heeft uitgesteld en bevestig dat ze zijn behandeld vóór uw volgende indiening.
Welke SAQ is op uw bedrijf van toepassing?
Een zelfevaluatievragenlijst (SAQ) is een validatiemiddel waarmee in aanmerking komende merchants hun eigen PCI DSS-naleving kunnen beoordelen zonder een volledige QSA-audit. Er zijn negen SAQ-typen. Het juiste type hangt af van hoe uw bedrijf kaartbetalingen accepteert en verwerkt. Het kiezen van het verkeerde SAQ-type is op zichzelf al een nalevingsfout.
De meest voorkomende SAQ-typen voor Nederlandse merchants zijn:
- SAQ A: Voor card-not-present merchants die alle kaarthoudersgegevensfuncties volledig uitbesteden aan PCI DSS-conforme derde partijen, zonder elektronische opslag, verwerking of verzending van kaartgegevens op uw eigen systemen of locaties. Uw website moet klanten doorsturen naar een gehoste betaalpagina of een embedded iframe van de betalingsprovider gebruiken. Stripe Checkout, Mollie en vergelijkbare volledig gehoste pagina's kwalificeren zolang kaartgegevens nooit uw eigen systemen passeren. SAQ A omvat 22 vereisten en is het eenvoudigste beschikbare pad.
- SAQ A-EP: Voor e-commerce merchants wiens website doorverwijst naar een betaalpagina van een derde partij, maar wiens website betrokken is bij de betaalstroom voorbij een eenvoudige link of doorverwijzing, bijvoorbeeld door JavaScript te gebruiken dat interageert met het betaalformulier. De v4.0-scriptbeveiligingsvereisten zijn hier van toepassing.
- SAQ B-IP: Voor merchants die IP-verbonden betaalterminals gebruiken (zoals een toonbankapparaat voor chip-en-pin op breedbandverbinding) die niet gevirtualiseerd zijn en geen kaarthoudersgegevens opslaan. 83 vereisten.
- SAQ C: Voor merchants met een betalingsapplicatiesysteem verbonden met het internet dat geen kaarthoudersgegevens elektronisch opslaat. 160 vereisten.
- SAQ D: De meest uitgebreide SAQ, voor alle merchants en serviceproviders die niet in aanmerking komen voor A tot en met C-VT. Meer dan 300 vereisten.
"Als u in aanmerking kunt komen voor SAQ A door een volledig gehoste betaalpagina te gebruiken, doe dat dan. Overstappen van SAQ D naar SAQ A door over te schakelen op een gehoste checkout is de meest effectieve bereikverminderingsstap voor de meeste Nederlandse e-commerce bedrijven."
Uw acquiring bank bevestigt welk SAQ-type op uw omgeving van toepassing is. Als u het niet zeker weet, vraag het hen dan vóór het voltooien van een zelfevaluatie. Het indienen van een SAQ die niet overeenkomt met uw werkelijke betaalomgeving creëert nalevingsrisico in plaats van dit te verminderen.
Bereikvermindering: hoe u te beschermen omgeving verkleint
De kaarthoudersgegevensomgeving (CDE) is gedefinieerd als elk systeemcomponent dat kaarthoudersgegevens opslaat, verwerkt of verzenden, plus elk systeem dat verbinding kan maken met of invloed kan uitoefenen op de beveiliging van die componenten. Alles in bereik vereist documentatie, controles en testen. Hoe kleiner uw CDE, hoe minder u hoeft te beheren.
Vier strateën verkleinen het bereik:
- Gehoste betaalpagina's: Kaartgegevens ingevoerd op een betaalpagina gehost door een conforme betalingsprovider passeren nooit uw eigen servers of netwerk. Uw CDE krimpt tot bijna nul. Voor de meeste Nederlandse e-commerce merchants is dit de grootste beschikbare vermindering.
- Netwerksegmentatie: Als u systemen exploiteert die in bereik moeten zijn, isoleer ze dan van de rest van uw netwerk via een correct geconfigureerde firewall. Systemen aan de andere kant van die firewall die geen route hebben naar in-scope systemen, vallen buiten bereik. Zonder gedocumenteerde segmentatie moet elk systeem dat een in-scope systeem kan bereiken, zelf als in bereik worden behandeld.
- Tokenisatie: Vervang bij terugkerende facturering opgeslagen kaartnummers (PAN's) door tokens uitgegeven door uw betalingsprovider. Alleen de tokenkluis, onderhouden door de betalingsprovider, moet in bereik zijn.
- Sla niet op wat u niet nodig heeft: Vermijd opslag van kaartgegevens buiten wat een specifiek zakelijk doel vereist. U mag CVV2- en CVC2-codes nooit opslaan na autorisatie, zelfs niet in versleutelde vorm.
De bereikbeslissingen die u nam bij het instellen van betalingsverwerking weerspiegelen mogelijk niet langer uw werkelijke omgeving. Nieuwe integraties, nieuwe marketingtools die laden op betaalpagina's, wijzigingen in uw hosting en nieuwe betaalkanalen beïnvloeden allemaal uw CDE. Beoordeel uw bereik minimaal jaarlijks en wanneer u significante wijzigingen aanbrengt in uw betaalinfrastructuur.
Sleuteldata en vervolgstappen
PCI DSS v4.0 is de enige actieve versie sinds 31 maart 2024. De 51 vereisten die de PCI SSC als aanbevolen praktijken had aangemerkt, werden verplicht vanaf 31 maart 2025. Er zijn geen verdere pensionerings- of overgangsdata gepland op het moment van schrijven.
Als u achterloopt op compliance of een deadline van uw acquirer nadert, volg dan deze volgorde:
- Bevestig uw merchant level bij uw acquiring bank en stel vast welk SAQ-type van toepassing is op uw betaalomgeving.
- Voer een gap-analyse uit op de toepasselijke SAQ om vast te stellen welke controles u niet haalt of waarvoor u geen bewijs heeft.
- Herstel falende controles voordat u uw SAQ invult en indient.
- Als uw SAQ-type dit vereist, laat dan een Approved Scanning Vendor (ASV) een kwartaal externe netwerkscan uitvoeren. Uw nalevingsindiening vereist het eerste schone scanresultaat.
- Dien uw Attestation of Compliance (AOC) in bij uw acquirer binnen de door hen gestelde termijn.
Als u nog nooit een PCI DSS-beoordeling heeft voltooid, begin dan met een gap-analyse op uw relevante SAQ. Het toont waar u staat, wat er hersteld moet worden en hoe groot de hersteleffort is voordat u middelen inzet.
Hoe Cyvra PCI DSS-naleving ondersteunt
Cyvra werkt met Nederlandse merchants en serviceproviders in elke fase van PCI DSS-naleving. U kunt bij ons komen met een nalevingsdeadline van uw acquirer, of uw betaalkanalen uitbreiden en de PCI DSS-implicaties willen begrijpen voordat u bouwt.
Een typische opdracht omvat uw merchant level en het juiste SAQ-type, een gap-analyse, een herstelplan, ondersteuning bij implementatie van controles en de AOC-indiening voor uw acquirer.
Als u wijzigingen overweegt in uw betaalinfrastructuur, beoordeelt Cyvra de impact op het PCI DSS-bereik voordat het project begint. Bereikbeslissingen in de architectuurfase kosten veel minder dan het achteraf herstellen van compliancehiaten nadat systemen zijn gebouwd. Neem contact op voor een kort gesprek over uw betaalomgeving.
Veelgestelde vragen
Geldt PCI DSS als ik Stripe of Mollie gebruik?
Ja. Het gebruik van Stripe, Mollie of een andere betalingsprovider heft uw PCI DSS-verplichting niet op. Het verkleint wel uw bereik. Als u een volledig gehoste betaalpagina gebruikt waarbij kaartgegevens nooit uw servers bereiken, kunt u SAQ A voltooien, die 22 vereisten omvat. Als uw website meer doet dan doorverwijzen naar de betaalpagina, heeft u mogelijk SAQ A-EP of een uitgebreider SAQ-type nodig.
Hoe vaak moet ik mijn SAQ indienen?
In de meeste gevallen jaarlijks. Uw acquiring bank stelt het exacte schema in en stelt u op de hoogte wanneer uw nalevingsdocumentatie verschuldigd is. Sommige acquirers vereisen ook kwartaal ASV-scans als afzonderlijke indiening. Raadpleeg de complianceprogrammadocumentatie van uw acquirer voor hun specifieke vereisten, aangezien deze variëren tussen ING, Rabobank, Adyen en andere Nederlandse acquirers.
Wat is een ASV-scan en heb ik er een nodig?
Een ASV (Approved Scanning Vendor)-scan is een externe kwetsbaarheidsscan van uw internetgerichte IP-adressen, uitgevoerd door een door de PCI SSC goedgekeurde leverancier. De vereiste hangt af van uw SAQ-type. SAQ A-merchants vereisen geen ASV-scan. SAQ B-IP, SAQ C en SAQ D-merchants wel. Het complianceprogramma van uw acquirer specificeert de vereiste voor uw merchant level.
Is PCI DSS een wettelijke vereiste in Nederland?
Nee. PCI DSS is een contractuele vereiste, geen wettelijke. Uw acquiring bank handhaaft het via de voorwaarden van uw overeenkomst. Afzonderlijk, als een inbreuk op kaarthoudersgegevens optreedt, kunt u verplichtingen hebben onder de AVG (melding van een persoonsgegeven inbreuk aan de AP binnen 72 uur) en, voor DNB-gereguleerde instellingen, onder het operationele weersbaarheidsraamwerk. Niet-naleving van PCI DSS zelf is geen strafrechtelijk of regelgevend vergrijp, maar de financiële gevolgen van een inbreuk in een niet-conforme omgeving kunnen ernstig zijn.
Wat gebeurt er als ik een kaartgegevensinbreuk heb?
Een inbreuk activeert een forensisch onderzoek door een PCI Forensic Investigator (PFI), in opdracht van uw acquirer of de kaartmerken. Als het onderzoek aantoont dat u niet PCI DSS-conform was op het moment van de inbreuk, staat u voor boetes van uw acquirer, mogelijke aansprakelijkheid voor kaartvervanging, terugboekingsaansprakelijkheid en mogelijk verlies van uw vermogen om kaartbetalingen te accepteren. U moet ook beoordelen of de inbreuk meldingsplichtig is aan de AP onder de AVG. Compliant zijn op het moment van een inbreuk garandeert geen vrijwaring van alle sancties, maar beperkt uw blootstelling aanzienlijk.