PCI DSS webshop: wat 4.0.1 voor jouw checkout betekent

Je webshop gebruikt iDEAL via Mollie, Adyen of Stripe. Je ziet zelf nooit een kaartnummer. Toch stuurt je acquirer of PSP een PCI-vragenlijst en noemt die "PCI DSS 4.0". Wat moet je dan echt doen?

Het korte antwoord: meestal vul je een SAQ A in. Maar sinds PCI DSS 4.0.1 hangt die SAQ A aan een extra voorwaarde over scripts op je site. Dat is waar de meeste webshops nu over struikelen.

Dit artikel legt uit wat er is veranderd, welke vragenlijst bij jouw checkout hoort en welke maatregelen je als webshop kunt nemen. Dit is geen juridisch advies en geen vervanging van een compliance-adviseur of je acquirer.

Wat is PCI DSS 4.0.1 in één alinea?

PCI DSS is de beveiligingsstandaard van de kaartschema's (Visa, Mastercard en andere), beheerd door de PCI Security Standards Council. Versie 4.0.1 is op 11 juni 2024 gepubliceerd. Het is een beperkte revisie: geen nieuwe of geschrapte eisen, wel verduidelijkingen en correcties.

Versie 4.0 is op 31 december 2024 ingetrokken. 4.0.1 is dus de versie die telt.

De "toekomstgerichte" eisen uit 4.0 werden op 31 maart 2025 verplicht. Vanaf dat moment worden ze meegenomen in assessments. Bronnen noemen verschillende aantallen (meestal 51). Het exacte aantal doet er voor jou niet toe. De twee die voor webshops het meest tellen wel.

De twee eisen die webshops raken: 6.4.3 en 11.6.1

Beide gaan over scripts op de betaalpagina. Dat is de aanvalsroute van Magecart-skimmers: kwaadaardige JavaScript die kaartgegevens uit het formulier haalt. Meer over die aanval lees je in onze gids over een Magecart-skimmer detecteren en verwijderen.

Let op: het exacte eisnummer en de formulering staan in de standaard zelf. Lees die tekst op pcisecuritystandards.org na voor je een audit ingaat. Wij geven hier de strekking weer.

Welke vragenlijst (SAQ) hoort bij jouw checkout?

De SAQ die je invult, hangt af van hoe je betaalpagina technisch is opgebouwd. Dit is de gangbare indeling.

Twee kanttekeningen. Eén: de uiteindelijke indeling bepaalt je acquirer of PSP, niet wij en niet een blog. Twee: de grens tussen SAQ A en SAQ A-EP bij een JavaScript-integratie is in de praktijk een grijs gebied. Vraag je PSP expliciet welke SAQ zij voor jouw integratie verwachten.

Wat veranderde er voor SAQ A?

In de herziene SAQ A zijn 6.4.3 en 11.6.1 geen vragen meer. Dat betekent niet dat het probleem is verdwenen. Ze zijn vervangen door twee voorwaarden om SAQ A te mogen gebruiken:

• Alle elementen van de betaalpagina komen alleen en rechtstreeks van een PCI DSS-compliant payment processor of dienstverlener.
• Jij hebt bevestigd dat je site niet kwetsbaar is voor aanvallen met scripts die je e-commerce-omgeving kunnen raken.

Die tweede voorwaarde is breder dan alleen de betaalpagina. Het gaat om je hele site. Hoe je dat "bevestigt", beschrijft de PCI SSC in een FAQ. Volgens secundaire bronnen zijn er twee routes: maatregelen in de geest van 6.4.3 en 11.6.1 zelf nemen, of schriftelijke bevestiging krijgen van een compliant provider dat diens oplossing de betaalpagina beschermt. Controleer de actuele FAQ-tekst en de actuele SAQ A zelf.

Wat wij niet hebben kunnen verifiëren

Eerlijk is eerlijk. Wat we hier beschrijven komt uit het openbare zoekwerk, grotendeels via leveranciers en adviseurs. Niet uit de primaire PCI-documenten zelf.

• Het FAQ-nummer (genoemd wordt 1588) en de exacte formulering ervan.
• De publicatiedata van de herziene SAQ A. Bronnen noemen eind januari en eind februari 2025, en spreken elkaar op details tegen.
• Het precieze aantal toekomstgerichte eisen.
• Of jouw specifieke integratie (bijvoorbeeld een Hyvä-checkout met een PSP-SDK) onder SAQ A of SAQ A-EP valt.

Voor die punten is je acquirer of een QSA de juiste instantie. Niet dit artikel.

De rol van je PSP en acquirer

Je PSP neemt de zwaarste last weg. Kaartgegevens gaan rechtstreeks van de klant naar hen. Maar de verantwoordelijkheid voor jouw pagina blijft bij jou.

• Je PSP is zelf PCI DSS-gecertificeerd. Dat dekt hun omgeving, niet jouw website.
• Je acquirer (of PSP namens hen) vraagt bij jou het bewijs van compliance op. Vaak via een portal met een jaarlijkse SAQ.
• Wat je moet indienen, hoe vaak, en wat de gevolgen van niet-naleving zijn, regelen jullie contractueel. Vraag het na.

Gebruik je meerdere betaalmethoden of PSP's? Dan is elk daarvan een eigen vraag. Een overzicht van gangbare koppelingen vind je op onze pagina over Magento payment providers.

Praktische checklist voor webshops

Deze maatregelen zijn goed te doen en verlagen het Magecart-risico, ongeacht welke SAQ je invult.

1. Maak een script-inventaris van je betaalpagina

Open de checkout in een browser en kijk in de Network-tab welke JavaScript er laadt. Noteer per script:

• de bron (eigen domein of derde partij);
• waarom het er staat (betaling, analytics, A/B-test, chat);
• wie het goedkeurde en wanneer;
• of het echt nodig is op de betaalpagina.

Dit is de kern van 6.4.3. Meestal blijkt dat tag-manager-scripts, chatwidgets en tracking-pixels op de betaalstap niets te zoeken hebben. Haal ze weg.

2. Beperk wat er mag laden met een Content Security Policy

Een CSP vertelt de browser van welke domeinen scripts mogen komen. Begin in Content-Security-Policy-Report-Only zodat je eerst ziet wat breekt. Zet daarna door naar blokkeren op checkout-routes.

• Gebruik een script-src met een korte whitelist.
• Vermijd unsafe-inline waar het kan, werk met nonces of hashes.
• Verzamel overtredingen via een report-uri of report-to endpoint.

Op Magento is dit lastig, omdat modules inline scripts toevoegen. Magento heeft zelf CSP-ondersteuning. Test per checkout-stap. Meer algemene hardening staat in onze Magento 2 security-checklist.

3. Gebruik Subresource Integrity voor externe scripts

Met SRI zet je een hash in de