Als uw webshop ook maar één script van een derde partij laadt op de pagina die een betalingsformulier aanraakt, kunt u er niet langer van uitgaan dat de eenvoudigste versie van PCI-naleving op u van toepassing is. Die ene regel, verborgen in de FAQ voor PCI DSS v4.0.1, heeft de nalevingskaart voor honderdduizenden kleine handelaren in 2026 stilletjes hertekend — en velen van hen zullen dit pas beseffen wanneer hun acquirer vraagt om bewijsmateriaal dat ze niet kunnen leveren.
PCI DSS v4.0.1 is geen lichte update. De 64 nieuwe of bijgewerkte vereisten zijn verplicht sinds 31 maart 2025, elke beoordeling in 2026 vindt plaats volgens de nieuwe standaard, en de deelnameregels voor de meest toegankelijke zelfevaluatievragenlijst zijn aangescherpt op manieren die de meeste uitbestede e-commerce winkels zullen verrassen. Het goede nieuws is dat de standaard nog steeds navigeerbaar is voor een klein bedrijf met een helder hoofd en een checklist. Het slechte nieuws is dat "we gebruiken Stripe Checkout, dus we zitten goed" niet langer een automatisch antwoord is.
Deze gids bespreekt wat er is veranderd, welke vragenlijst uw bedrijf daadwerkelijk nodig heeft, de twee nieuwe vereisten (6.4.3 en 11.6.1) die de oude SAQ A hebben opgeslokt, de authenticatieregels die kleine teams vaak over het hoofd zien, en de realistische kosten als dit misgaat.
De stand van zaken van PCI DSS in 2026
De Payment Card Industry Data Security Standard is het contractuele regelboek dat de grote kaartmerken — Visa, Mastercard, American Express, Discover, JCB — opleggen aan elk bedrijf dat gegevens van kaarthouders opslaat, verwerkt of verzendt. U dient dit niet in "bij de overheid". Uw acquirer (de bank of verwerker die u in staat stelt kaarten te accepteren) handhaaft dit via uw handelsovereenkomst, en zij zijn degenen die de boetes innen als er iets misgaat.
PCI DSS v4.0 werd gepubliceerd in maart 2022. Versie 4.0.1 — een release met verduidelijkingen in plaats van een volledig nieuwe standaard — werd de actieve versie in medio 2024. De overgangstermijn eindigde op 31 maart 2025: vanaf die datum zijn alle 51 toekomstgerichte vereisten van kracht zonder uitstelperiode, en elke beoordeling die in 2026 wordt uitgevoerd, gebeurt tegen v4.0.1. Er is geen v3.2.1-optie meer om op terug te vallen.
De 12 hoofdgroepen van vereisten blijven hetzelfde, georganiseerd in zes controledoelstellingen:
- Bouw en onderhoud een veilig netwerk: firewalls en standaardinstellingen van leveranciers (Vereisten 1–2)
- Bescherm gegevens van kaarthouders: opgeslagen gegevens en gegevens tijdens verzending (Vereisten 3–4)
- Onderhoud een programma voor kwetsbaarheidsbeheer: anti-malware en veilige ontwikkeling (Vereisten 5–6)
- Implementeer sterke toegangscontrole: "need-to-know", identificatie, fysieke toegang (Vereisten 7–9)
- Controleer en test netwerken regelmatig: logging en testen (Vereisten 10–11)
- Onderhoud een informatiebeveiligingsbeleid: governance (Vereiste 12)
Wat er in v4.0.1 is veranderd, is de diepgang, niet de breedte. De standaard verwacht nu dat u nadenkt over hoe scripts worden uitgevoerd op betaalpagina's, hoe vaak u uw eigen controles herziet, hoe u beheerders authenticeert en of het wachtwoord dat uw boekhouder vijf jaar geleden heeft gekozen nog steeds acceptabel is.
Handelaarsniveaus: Waar de meeste kleine bedrijven zich bevinden
De kaartmerken delen elke handelaar in een van de vier niveaus in op basis van het jaarlijkse transactievolume. Het niveau bepaalt hoe de naleving wordt gevalideerd, niet of de standaard van toepassing is.
- Niveau 1: meer dan 6 miljoen kaarttransacties per jaar, of elke handelaar die te maken heeft gehad met een bevestigd lek van accountgegevens. Vereist een jaarlijkse beoordeling ter plaatse door een Qualified Security Assessor (QSA) en een driemaandelijkse scan door een Approved Scanning Vendor (ASV).
- Niveau 2: 1 miljoen tot 6 miljoen transacties per jaar. Meestal een jaarlijkse SAQ of een QSA-beoordeling ter plaatse, afhankelijk van het merk.
- Niveau 3: 20.000 tot 1 miljoen e-commerce transacties per jaar. Jaarlijkse SAQ plus driemaandelijkse ASV-scans.
- Niveau 4: minder dan 20.000 e-commerce transacties per jaar, of tot 1 miljoen totale transacties over alle kanalen. Jaarlijkse SAQ en, voor de meeste kanalen, driemaandelijkse ASV-scans.
Als u een online boetiek, een SaaS-facturatiestroom, een regionaal servicebedrijf of een restaurant op één locatie runt, bent u vrijwel zeker Niveau 4. Dat is de overgrote meerderheid van de handelaren wereldwijd. Validatie is eenvoudiger, maar de onderliggende standaard is identiek — een gelekt kaartnummer van een handelaar met 200 transacties per jaar wordt op dezelfde manier behandeld als een lek bij een grote onderneming.
Zelfevaluatievragenlijsten: Kies de juiste
De Self-Assessment Questionnaire (SAQ) is de manier waarop handelaren van Niveau 2–4 hun naleving bevestigen. De PCI Council onderhoudt negen SAQ's, en de juiste keuze hangt af van hoe uw betalingsgegevens precies stromen. Het kiezen van de verkeerde SAQ is de meest gemaakte fout door kleine handelaren.
- SAQ A: e-commerce of postorder/telefonische handelaren die alle functies voor kaarthoudergegevens volledig uitbesteden aan door PCI DSS gevalideerde derde partijen. Dit was vroeger de gemakkelijke optie voor Shopify-, Stripe Checkout- en PayPal-handelaren — maar zie de volgende sectie, want de deelnameregels zijn aangescherpt.
- SAQ A-EP: e-commerce handelaren die de betalingsverwerking gedeeltelijk uitbesteden, maar wier website nog steeds invloed heeft op de beveiliging van de transactie (bijvoorbeeld sites die hun eigen betaalpagina bouwen en een betalings-API aanroepen).
- SAQ B: handelaren die alleen afdrukapparaten of stand-alone inbel-terminals gebruiken. Er is geen internetverbinding die kaartgegevens aanraakt.
- SAQ B-IP: handelaren die stand-alone IP-verbonden betalingsterminals gebruiken (de meeste moderne toonbankterminals).
- SAQ C-VT: handelaren die kaartgegevens invoeren via een virtuele terminal op een geïsoleerd werkstation.
- SAQ C: handelaren met een betalingsapplicatie verbonden met internet, waarbij gegevens niet worden opgeslagen.
- SAQ P2PE: handelaren die een gevalideerde point-to-point encryptie-oplossing gebruiken.
- SAQ D-Handelaar: de restcategorie voor handelaren die niet in een andere SAQ passen — en verreweg de langste.
- SAQ D-Serviceprovider: voor serviceproviders die in aanmerking komen voor zelfevaluatie.
Elke SAQ stelt alleen de subset van de ruim 300 controles die relevant zijn voor dat acceptatiemodel. SAQ A heeft minder dan 30 vragen; SAQ D-Handelaar heeft er meer dan 250. Het verschil in inspanning is enorm, en daarom willen handelaren zich waar mogelijk legitiem kwalificeren voor SAQ A.
De valkuil van de SAQ A-geschiktheid
De grootste verandering die kleine e-commerce-merchants in 2026 moeten begrijpen, is wie er daadwerkelijk in aanmerking komt voor SAQ A. De PCI Security Standards Council publiceerde begin 2025 FAQ 1588 en heeft de criteria aanzienlijk aangescherpt.
Onder v4.0.1 is SAQ A alleen beschikbaar als u kunt bevestigen dat uw e-commercepagina's — inclusief de pagina met uw ingebedde betalings-iframe of redirect — niet vatbaar zijn voor aanvallen van scripts die uw betalingsomgeving kunnen beïnvloeden. Dit is een reactie op de golf van digital skimming-aanvallen (vaak "Magecart" genoemd), waarbij aanvallers een JavaScript-bibliotheek van derden compromitteren en kaartgegevens ontvreemden, zelfs van sites die dachten dat ze alles hadden uitbesteed.
In de praktijk kunt u hier op twee manieren aan voldoen:
- Implementeer zelf de scriptbeveiligingen in Vereisten 6.4.3 en 11.6.1. Inventariseer elk script dat op uw betalingspagina wordt geladen, autoriseer elk script, motiveer waarom het nodig is en implementeer een detectiemechanisme voor wijzigingen en manipulatie dat u waarschuwt wanneer een HTTP-header of pagina-inhoud onverwacht verandert. Het mechanisme moet de betalingspagina ten minste elke zeven dagen evalueren, of met een frequentie die u motiveert via een gerichte risicoanalyse.
- Vraag een schriftelijke bevestiging van uw betalingsverwerker dat hun ingebedde oplossing namens u ingebouwde beveiligingen bevat tegen op scripts gebaseerde aanvallen.
Het tweede pad is wat de meeste kleine merchants zullen volgen, maar dit gaat niet automatisch. U heeft een gedocumenteerde verklaring van de verwerker nodig — geen marketingpagina. Veel Stripe-, Adyen-, Braintree- en Square-merchants zullen merken dat hun verwerker een verklaring van overeenstemming (attestation) heeft gepubliceerd; sommige kleinere gateways hebben dit niet gedaan. Als uw verwerker u die bevestiging niet schriftelijk kan geven, bent u aangewezen op SAQ A-EP of moet u de controles zelf bouwen.
Als uw "uitbestede" checkout in feite door de merchant beheerde JavaScript laadt die het betalingsformulier zou kunnen beïnvloeden — zoals analytics, A/B-testen, chat-widgets, tag-managers — is de conservatieve interpretatie dat u niet langer in aanmerking komt voor SAQ A, ongeacht wat uw verwerker zegt.
Authenticatie: De twee regels die kleine teams treffen
Welke SAQ ook van toepassing is, twee wijzigingen in toegangsbeheer in v4.0.1 verrassen bijna elk klein bedrijf.
Vereiste 8.3.6: wachtwoorden moeten minimaal 12 tekens lang zijn. Als het systeem slechts 8 tekens ondersteunt, kunt u op 8 blijven, maar alles wat meer aankan, moet worden verhoogd. Wachtwoorden moeten zowel numerieke als alfabetische tekens bevatten. Het oude minimum van 7 tekens uit v3.2.1 is vervallen.
Vereiste 8.4.2: multifactorauthenticatie voor alle toegang tot de kaarthoudergegevensomgeving. Voorheen was MFA alleen vereist voor externe toegang door beheerders. Onder v4.0.1 heeft iedereen — beheerder, ontwikkelaar, externe ondersteuning, uzelf — MFA nodig bij elke toegang tot een systeemcomponent binnen de kaarthoudergegevensomgeving, niet alleen bij verbinding van buiten het netwerk. De MFA zelf moet bestand zijn tegen replay-aanvallen en minimaal twee van de volgende vereisen: iets wat u weet, iets wat u heeft, iets wat u bent.
Voor een kleine merchant is de praktische vertaling: schakel MFA in op uw verwerkersportaal, uw hosting-controlepaneel, uw domeinregistrar, uw DNS-provider, uw e-commerce-beheeromgeving, de backoffice van uw verkooppunt (POS) en elke laptop die deze systemen aanraakt. Gebruik een authenticator-app of hardwarematige beveiligingssleutel — op SMS gebaseerde MFA wordt steeds vaker als onvoldoende beschouwd, ook al staat de standaard dit technisch gezien nog steeds toe.
Gerichte risicoanalyse: Het document dat u waarschijnlijk nodig heeft
PCI DSS v4.x introduceert de gerichte risicoanalyse (Targeted Risk Analysis - TRA) — een korte, gedocumenteerde analyse waarmee u kunt rechtvaardigen hoe vaak u bepaalde controles uitvoert. Ongeveer een dozijn vereisten bevatten de optie "frequentie gedefinieerd in de gerichte risicoanalyse van de entiteit".
Vereiste 12.3.1 beschrijft wat een TRA moet bevatten: identificatie van het actief (asset) dat wordt beschermd, de dreiging die wordt beperkt, de factoren die de waarschijnlijkheid en impact beïnvloeden, en de onderbouwing voor de gekozen frequentie. De PCI Council publiceert een sjabloon in Bijlage E2 van de standaard.
Voor een Level 4 merchant is dit meestal een document van één pagina per controle. De fout die u moet vermijden, is het volledig overslaan ervan. Als uw beoordelaar of acquirer u vraagt waarom u uw betalingspagina elke 30 dagen scant op manipulatie in plaats van elke 7 dagen, is "we dachten dat het genoeg was" geen acceptabel antwoord; "hier is onze TRA gedateerd 14 januari 2026, ondertekend door de eigenaar" is dat wel.
Blijf weg van de aangepaste aanpak (customized approach) van v4.0. Deze is bedoeld voor risico-volwassen ondernemingen met toegewijde beveiligingsteams; voor kleine merchants is de gedefinieerde aanpak (defined approach) met zijn expliciete checklist sneller, goedkoper en gemakkelijker te verdedigen.
Wat niet-naleving daadwerkelijk kost
Kleine merchants onderschatten de financiële blootstelling omdat de boetes hypothetisch aanvoelen totdat ze dat niet meer zijn. De cijfers, verzameld uit schema's van acquirers en sectorrapportages, zijn ontnuchterend.
Routineuze niet-naleving — het niet indienen van een SAQ, verlopen ASV-scans — leidt doorgaans tot maandelijkse boetes van uw acquirer, beginnend bij 10.000 per maand. Na drie tot zes maanden van niet-naleving lopen die boetes gewoonlijk op naar 50.000 per maand, en bij chronische overtredingen kunnen ze oplopen tot meer dan 100.000 per maand. De acquirer kan ook uw verwerkingskosten per transactie verhogen of het merchant-account beëindigen, wat vaak schadelijker is dan de boetes.
Een bevestigd datalek is van een heel andere orde. Kaartmerken leggen boetes op van ongeveer 90 per gecompromitteerd record, bovenop verplichte kosten voor forensisch onderzoek ( 150.000 tot 3.000 per jaar, terwijl een enkel lek de winst van een heel decennium teniet kan doen.
Wetten van staten en de FTC dragen ook bij aan de lasten. Meldingskosten, advocatenhonoraria, blootstelling aan collectieve rechtszaken (class-action) en vervolgonderzoeken door toezichthouders overtreffen routinematig de boetes van de kaartmerken zelf.
Een praktische checklist voor 2026-naleving voor kleine handelaren
De standaard is als geheel intimiderend, maar de checklist voor een typische kleine e-commerce- of servicehandelaar is overzichtelijk. Doorloop deze in deze volgorde.
- Bevestig uw handelsniveau schriftelijk bij uw acquirer. Niveaus worden per acquirer-relatie toegewezen, niet wereldwijd.
- Breng de gegevensstroom van uw kaarthouders in kaart. Teken een diagram dat laat zien waar kaartgegevens binnenkomen, waar ze naartoe gaan en waar ze het systeem verlaten. Als kaartgegevens ooit op uw servers terechtkomen, wordt de scope enorm vergroot.
- Selecteer de juiste SAQ. Lees elke optie zorgvuldig door. Als u een e-commercehandelaar bent die SAQ A claimt, controleer dan uw geschiktheid aan de hand van FAQ 1588.
- Vraag een schriftelijke bevestiging aan uw betalingsverwerker over de bescherming tegen scriptaanvallen in hun embedded oplossing. Voeg dit toe aan uw nalevingsdocumentatie.
- Inventariseer elk script op uw betaalpagina's. Als u geen bevestiging van de verwerker kunt krijgen, bereid u dan voor op de implementatie van Vereiste 6.4.3 (geautoriseerde scripts) en 11.6.1 (detectie van manipulatie).
- Schakel MFA overal in waar een beheerder toegang heeft tot betalingssystemen. Gebruik een authenticator-app, geen sms.
- Verhoog wachtwoorden naar minimaal 12 tekens met een mix van cijfers en letters.
- Plan driemaandelijkse ASV-scans in als uw SAQ dit vereist (de meeste vereisen dit voor systemen met internetverbinding).
- Documenteer een gerichte risicoanalyse voor elke controle waarbij u zelf de frequentie bepaalt.
- Schrijf een informatiebeveiligingsbeleid (Vereiste 12). Een eenvoudig document van één pagina over acceptabel gebruik, contactpersonen voor incidentrespons en een jaarlijks evaluatieschema volstaat als basis voor een kleine handelaar.
- Train elke werknemer die met betalingen te maken heeft jaarlijks. Bewaar presentielijsten of e-learning-gegevens.
- Dien de SAQ en Attest van Naleving (AoC) in bij uw acquirer volgens schema. Zet het in de agenda.
Zelfs op dit detailniveau dekt een geconcentreerd weekend werk plus een paar honderd dollar voor een ASV-scan de meeste kleine handelaren.
Het verband tussen boekhouding en naleving
PCI-naleving is niet alleen een beveiligingsoefening — het heeft directe boekhoudkundige gevolgen. Nalevingskosten (SAQ-tools, ASV-scans, MFA-hardware, tamper-detectiediensten), verwerkingskosten die variëren afhankelijk van uw nalevingsstatus, en eventuele boetes of herstelkosten vloeien allemaal door uw boeken. Dat geldt ook voor de omzeteffecten van een datalek: chargebacks, terugbetalingen, kosten voor het opnieuw uitgeven van kaarten die door uw acquirer worden doorberekend, en gemiste verkopen tijdens de respons op incidenten.
Het bijhouden van een zuivere boekhouding op regelniveau voor elke betalingsgerelateerde uitgave — onderverdeeld per verwerker, beveiligingstools en nalevingsdiensten — loont op drie manieren. Het documenteert dat er investeringen in naleving worden gedaan (handig wanneer een acquirer of verzekeraar hierom vraagt). Het brengt de werkelijke kosten van elk acceptatiekanaal in kaart, wat u helpt bij het onderhandelen over verwerkingstarieven. En mocht er toch een datalek optreden, dan biedt het uw forensisch accountant een duidelijk spoor om de schade te kwantificeren voor verzekeringsclaims.
Houd uw nalevingsrecords klaar voor een audit
Of u nu reageert op een vragenlijst van een acquirer, een acceptant van een cyberverzekering of een forensisch accountant na een datalek, de handelaren die PCI-gebeurtenissen goed doorstaan, zijn degenen wier boeken en records een duidelijk verhaal vertellen. Beancount.io biedt plain-text, versiebeheerde boekhouding die u een transparant, van tijdstempels voorzien spoor geeft van elke verwerkingsvergoeding, beveiligingstool en nalevingsuitgave — geen black boxes, geen vendor lock-in en klaar voor het tijdperk van AI-ondersteunde financiën. Begin gratis en combineer uw nalevingswerk met een boekhouding die standhoudt bij controle.