Kort samengevat: SAQ D-zelfevaluatiescope voor e-commerce merchants
- Elke merchant wil op SAQ A staan. De meesten horen op SAQ D en weten dat niet. Laadt je site een script dat een betaalveld kan raken, dan sta je niet op het korte formulier, wat de salesdeck ook zegt.
- SAQ D dekt alle 12 PCI DSS-vereisten en telt meer dan 90 pagina's om in te vullen. Sinds PCI DSS 4.0.1 in maart 2025 verplicht werd, vallen 6.4.3 en 11.6.1 binnen de scope van elke SAQ D-merchant, en de SAQ A-vrijstellingen van januari 2025 gelden niet.
- Aanvaard je kaartgegevens op systemen die je beheert, meng je betaalmethoden of sla je kaarthoudergegevens op, vul dan SAQ D in en bouw nu de 6.4.3-scriptinventaris plus 11.6.1-headermonitoring. Is een volledig gehost iframe je enige integratie en kan geen first-party script eraan komen, bevestig dan met je acquirer of SAQ A past.
SAQ D is de zelfevaluatievragenlijst die alles dekt wat de kortere SAQ's niet dekken. Hij geldt voor merchants en serviceproviders met een betaalomgeving die te breed is voor de striktere vragenlijsten. Als je bedrijf kaartgegevens rechtstreeks accepteert op een systeem dat je zelf beheert, is SAQ D waarschijnlijk het formulier dat je elk jaar invult.
Wie moet SAQ D invullen
De PCI Security Standards Council publiceert meerdere SAQ-varianten, elk voor een specifiek merchantprofiel:
| SAQ | Geldt voor |
|---|---|
| A | Volledig uitbestede e-commerce; kaartgegevens raken nooit de systemen van de merchant; alleen gehoste iframe of redirect |
| A-EP | E-commercemerchant van wie de website de beveiliging van de betaalpagina beïnvloedt (laadt scripts, iframes met same-origin scripttoegang) |
| B | Afdrukmachines of standalone inbelterminals, geen elektronische opslag |
| B-IP | Standalone IP-verbonden terminals, geen elektronische opslag |
| C | Betaalapplicatie verbonden met internet, geen elektronische opslag |
| C-VT | Virtuele terminals benaderd via een browser, geen elektronische opslag |
| P2PE | Alleen op de PCI-lijst opgenomen P2PE-hardwarebetaalterminals |
| D | Iedereen die niet in aanmerking komt voor het bovenstaande |
In die laatste rij belandt de meeste e-commerce. Elke merchant die kaartgegevens op de eigen systemen accepteert, een mix van betaalmethoden gebruikt of kaarthoudergegevens opslaat, vult SAQ D in. Serviceproviders onder Level 1 gebruiken ook SAQ D.
Wat SAQ D dekt
SAQ D omvat alle 12 PCI DSS-vereisten volledig:
- Installeer en onderhoud netwerkbeveiligingscontroles
- Pas veilige configuraties toe op alle systeemcomponenten
- Bescherm opgeslagen accountgegevens
- Bescherm kaarthoudergegevens met sterke cryptografie tijdens verzending
- Bescherm alle systemen en netwerken tegen kwaadaardige software
- Ontwikkel en onderhoud veilige systemen en software
- Beperk toegang tot systeemcomponenten en kaarthoudergegevens op basis van business need-to-know
- Identificeer gebruikers en authenticeer toegang tot systeemcomponenten
- Beperk fysieke toegang tot kaarthoudergegevens
- Log en monitor alle toegang tot systeemcomponenten en kaarthoudergegevens
- Test regelmatig de beveiliging van systemen en netwerken
- Ondersteun informatiebeveiliging met organisatorisch beleid en programma's
Elke vereiste heeft meerdere subvereisten en bewijsverwachtingen. De huidige SAQ D-template beslaat alleen al voor het invullen meer dan 90 pagina's.
Waar SAQ D lastig wordt: client-sidecontroles
Vereisten 6.4.3 en 11.6.1 werden verplicht met PCI DSS 4.0.1 in maart 2025. Beide zijn onverkort van toepassing op SAQ D-merchants en gaan over het beheer van client-sidescripts op betaalpagina's:
- 6.4.3: houd een inventaris bij van elk script dat op betaalpagina's wordt geladen, documenteer voor elk de zakelijke rechtvaardiging, verifieer de integriteit en detecteer ongeautoriseerde wijzigingen
- 11.6.1: monitor HTTP-headers op betaalpagina's, detecteer ongeautoriseerde wijzigingen en waarschuw erover
De meeste merchants die SAQ D voor het eerst onder 4.0.1 invullen, hebben voor geen van beide vereisten artefacten. Onze praktische gids om te voldoen aan PCI 6.4.3 en 11.6.1 loopt door hoe het bewijs eruit moet zien.
De update van januari 2025 voor SAQ A introduceerde zeer beperkte uitzonderingen op 6.4.3 en 11.6.1, maar die uitzonderingen gelden niet voor SAQ D. Zit je op SAQ D, dan vallen beide vereisten binnen de scope.
Hoe SAQ D verschilt van SAQ A
SAQ A is kort (minder dan 30 pagina's) omdat hij ervan uitgaat dat kaartgegevens nooit je systemen raken. SAQ D is lang omdat hij die aanname niet maakt. Weet je niet zeker op welke SAQ je hoort, dan loopt onze gids hoe je een PCI DSS SAQ A-bedrijf wordt door de criteria voor het striktere formulier. Kun je er niet aan allemaal voldoen, dan is SAQ D het antwoord.
Een checklist voordat je met SAQ D begint
- Bevestig dat SAQ D echt het juiste formulier is voor jouw omgeving (overleg met je acquirer als je twijfelt)
- Maak je scopediagram af dat elk systeem dekt dat kaarthoudergegevens opslaat, verwerkt of verzendt
- Bouw de scriptinventaris voor elke betaalpagina (6.4.3)
- Zet HTTP-headermonitoring op voor betaalpagina's (11.6.1)
- Verzamel bewijs voor elk van de 12 vereisten: configuratie-exports, screenshots, logvoorbeelden, beleidsdocumenten
- Plan tijd in voor interne review vóór de definitieve verklaring
Waar cside past
cside levert het bewijs voor 6.4.3 en 11.6.1 rechtstreeks. Continue scriptinventaris, tagging van de zakelijke rechtvaardiging, integriteitsmonitoring, detectie van headerwijzigingen en waarschuwingsgeschiedenis komen van het platform, zodat die twee vereisten verschuiven van "we zijn van plan om te voldoen" naar "hier is het bewijs".
Voor een diepere uitleg van wat het compliancedashboard oplevert en hoe het aansluit op de SAQ D-vragen, zie de compliancegids voor PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1.
