PCI DSS SAQ A: wat het is, wie het moet invullen en hoe u zich kwalificeert

De PCI DSS SAQ A (Self-Assessment Questionnaire A) is de eenvoudigste vorm van de PCI DSS-zelfbeoordeling: hij bevat slechts 22 vragen en is bedoeld voor handelaren die hun betaalpagina volledig hebben uitbesteed aan een gecertificeerde derde partij. Kwalificeren voor SAQ A betekent niet alleen minder papierwerk; het betekent dat het volledige interne systeem van de handelaar buiten de CDE valt. Veel handelaren die zich voor SAQ D kwalificeren en honderden controles beheren, zouden zich in plaats daarvan met een eenvoudige architectuurwijziging voor SAQ A kunnen kwalificeren.

Wat SAQ A is en wat het vereist

PCI SSC heeft meerdere SAQ-typen gedefinieerd die zijn afgestemd op verschillende handelaarsacceptatiescenario's. SAQ A geldt voor handelaren die kaartgegevens volledig hebben uitbesteed aan een PCI DSS-gecertificeerde derde partij en zelf geen kaartgegevens in welke vorm dan ook opslaan, verwerken of verzenden. In dit scenario heeft de handelaar geen CDE-systemen: alle kaartgegevens worden verwerkt door de derde partij.

De vereisten van SAQ A zijn opzettelijk beperkt en richten zich voornamelijk op:

• de beveiliging van de website waarop het betaalformulier van de derde partij wordt weergegeven
• verificatie dat de pagina uitsluitend HTTPS gebruikt en niet kwetsbaar is voor skimming via scriptinjectie
• bewijs dat de derde partij PCI DSS-gecertificeerd is
• fysieke beveiliging van de omgevingen die de website hosten

SAQ A in PCI DSS v4 heeft ten opzichte van v3.2.1 nieuwe vereisten ontvangen voor de beveiliging van scripts op de betaalpagina (vereiste 6.4.3), om scriptinjectieaanvallen zoals Magecart te voorkomen. De handelaar moet alle JavaScript-scripts die op de betaalpagina worden geladen, autoriseren en inventariseren.

Toelatingsvoorwaarden voor SAQ A

Om zich voor SAQ A te kwalificeren, moet een handelaar aan alle volgende voorwaarden voldoen:

• alle ontvangst van kaartgegevens is uitsluitend uitbesteed aan PCI DSS-gecertificeerde derde partijen
• de handelaar slaat geen kaartgegevens op, verwerkt ze niet en verzend ze niet via eigen systemen of bedrijfsruimten
• alle kaartacceptatiekanalen zijn volledig uitbesteed (geen telefonische ontvangst van kaartgegevens, geen invoer van kaarten in interne systemen)
• de website van de handelaar mag zelf geen kaartgegevens ontvangen (het betaalformulier laadt in een frame of op een pagina van de derde partij)
• de handelaar is geen directe contractpartner voor het kaartacceptatiesysteem (hij is niet verbonden via een eigen PCI DSS-gecertificeerd datacenter)

Een belangrijke verduidelijking: niet alle iFrame-gebaseerde oplossingen voldoen aan de SAQ A-vereisten. De betaalpagina moet volledig worden gerenderd op het domein van de derde partij (hosted payment page), of het frame moet zo zijn geïmplementeerd dat de handelaar nooit PAN-gegevens uit het frame kan onderscheppen. Wanneer de website JavaScript bevat dat gegevens uit het frame zou kunnen extraheren, verliest de handelaar de SAQ A-kwalificatie.

Tokenisatie als weg naar SAQ A

Voor handelaren die momenteel SAQ C, SAQ D of SAQ C-VT invullen, is tokenisatie de directe weg naar SAQ A. Wanneer alle betalingsstromen worden gerouteerd via een gecertificeerde derde partij (zoals PCI Proxy EU) die de kaartgegevens tokeniseert voordat ze interne systemen bereiken, verlaat de handelaar de CDE. De interne systemen zien alleen tokens, geen PAN's.

Concreet betekent dit:

• online checkout: hosted payment page of veilig iFrame dat PAN's rechtstreeks naar de kluis stuurt
• telefoonkanaal: MOTO-tokenisatielink die naar de klant wordt verzonden, in plaats van verbale kaartinvoer
• backend: CRM, ERP en boekhouding werken uitsluitend met tokens

Na deze transformatie slaat de handelaar geen kaartgegevens meer op, verwerkt ze niet en verzend ze niet: hij kwalificeert zich voor SAQ A. In plaats van honderden PCI DSS-controles te beheren, beantwoordt hij 22 vragen en gebruikt hij de PCI DSS-certificering van PCI Proxy EU voor al het overige.

SAQ A vs. SAQ A-EP: het verschil kennen

PCI DSS heeft ook SAQ A-EP (A-Extended Perimeter) voor handelaren die betaalpagina's hebben geïmplementeerd via iFrame of JavaScript-redirect, maar directe invloed hebben op de weergave van de pagina. SAQ A-EP bevat ongeveer 140 vragen en is aanzienlijk uitgebreider dan SAQ A. Het onderscheid is technisch:

• SAQ A: de betaalpagina laadt volledig op het domein van de derde partij (hosted payment page), de handelaar bepaalt niet hoe het formulier wordt weergegeven
• SAQ A-EP: de handelaar beheert delen van de weergave van de betaalpagina (eigen JavaScript laadt voor het betaalformulier), ook wanneer kaartgegevens rechtstreeks naar de derde partij gaan

Het doel is SAQ A, niet SAQ A-EP. Hiervoor moet de betaalpagina-integratie volledig aan de derde partij worden overgelaten, zonder eigen JavaScript op de betaalpagina.

Veelgestelde vragen

SAQ A is het doel: met PCI Proxy EU-tokenisatie kwalificeert u zich en reduceert u uw jaarlijkse PCI DSS-nalevingslast van honderden naar 22 vragen. Ontdek PCI Proxy EU.

---