Heb je PCI SSF of PCI DSS nodig? Dit is het verschil

Simpel gezegd: PCI SSF is voor de software, en PCI DSS is voor al het andere.

Bouw of verkoop je betaalgerelateerde software, dan is PCI SSF op jou van toepassing. Sla je kaarthoudergegevens op, verwerk je ze, of raak je ze op welke manier dan ook aan (inclusief je website, server of hosting-stack), dan heb je te maken met PCI DSS-compliance.

Beide frameworks komen van hetzelfde orgaan (PCI SSC), maar ze pakken heel verschillende problemen in het ecosysteem aan.

De meeste mensen horen alleen over PCI DSS-vereisten, omdat dat het framework is dat merchants, SaaS-bedrijven en vrijwel iedereen met een betaalpagina raakt. Maar PCI SSF? Dat is bedoeld voor de bedrijven die de daadwerkelijke betaalsoftware schrijven die al die systemen aandrijft.

We leggen het stap voor stap uit.

Wat is PCI SSF?

PCI SSF staat voor Payment Card Industry Software Security Framework. Het is de nieuwere, flexibelere opvolger van PA-DSS, de oudere versie.

Waar PCI DSS zich richt op het beschermen van gegevens, draait PCI SSF volledig om het beschermen van de software die die gegevens aanraakt. Dat betekent de code die je kassasysteem, mobiele wallet-app of browsergebaseerde checkout-module aanstuurt.

PCI SSF bestaat uit twee standaarden:

• Secure Software Standard: Richt zich op de beveiliging van de software zelf. Is ze gehard? Beschermt ze kaarthoudergegevens? Zit er een degelijke toegangscontrole ingebouwd?
• Secure Software Lifecycle (Secure SLC): Kijkt naar hoe de software wordt gemaakt. Is je SDLC (software development lifecycle) veilig? Patch je kwetsbaarheden snel? Is beveiliging een volwaardig onderdeel van het proces?

Met andere woorden: PCI SSF gaat over hoe je software wordt geschreven, onderhouden en bijgewerkt. Is je codebase een rommeltje, dan kun je een SSF-assessment vergeten.

Voor wie is PCI SSF bedoeld?

Stel jezelf deze vragen:

• Verkoop of distribueer je betaaloplossingen?
• Verwerkt je software betalingen rechtstreeks (ook als ze nooit kaarthoudergegevens opslaat)?
• Wil je op de lijst van gevalideerde betaalsoftware van PCI SSC komen?

Als je één van deze vragen met ja beantwoordt, is PCI SSF vereist.

Welke software valt binnen de scope?

Bouw je tools die worden gedistribueerd en betrokken zijn bij de stroom van kaarthoudergegevens, dan val je waarschijnlijk binnen de scope.

Wat doorgaans in aanmerking komt:

• POS-systemen: Software die op fysieke kassaterminals is geïnstalleerd.
• Mobiele betaalapps: Apps die kaartbetalingen accepteren via een mobiele interface.
• Checkout-SDK's: Kant-en-klare betaalcomponenten of bibliotheken die merchants in hun sites of apps integreren.
• Thin clients: Lichtgewicht apps die transactierouting of gebruikersinvoer afhandelen, maar afhankelijk zijn van externe API's.
• Kiosk- of terminalsoftware: Alle code die publiek toegankelijke systemen aanstuurt die kaarten accepteren.

Wat doorgaans buiten de scope valt:

• Interne applicaties: Tools die zijn ontwikkeld voor en uitsluitend worden gebruikt binnen je eigen organisatie, zonder distributie.
• Back-officesystemen: ERP's of analysetools die de betaalstroom niet raken.
• Gehoste pagina's zonder ingebedde logica: Als je software alleen doorverwijst naar of een PCI-conforme gehoste pagina inlaadt, valt dat op zichzelf mogelijk niet onder SSF.

Wordt je software verkocht, white-labeled of gedistribueerd, en ondersteunt ze kaartbetalingen, dan is SSF vrijwel zeker van toepassing.

Voorbeelden van bedrijven waarvoor PCI SSF vereist is:

Enkele voorbeelden. We hebben geen zakelijke relatie met de onderstaande bedrijven:

1. Leveranciers van POS-systemen

Voorbeeld: Toast, Lightspeed, Square (hardware-softwarestack).

• Ze maken gedistribueerde software die op fysieke apparaten in retail- en horecaomgevingen wordt geïnstalleerd.
• De software accepteert kaartbetalingen en communiceert rechtstreeks met kaartlezers.
• Valt doorgaans onder de Secure Software Standard.

2. Ontwikkelaars van mobiele betaalapps

Voorbeeld: SumUp, Zettle (by PayPal), Revolut Business.

• Mobiele apps waarmee kleine bedrijven of particulieren kaartbetalingen kunnen accepteren.
• Vaak betrokken bij Bluetooth-kaartlezers en verwerking van kaartgegevens via telefoon of tablet.
• De softwarebeveiliging in deze apps moet end-to-end worden geverifieerd.

3. Aanbieders van checkout-SDK's of betaalbibliotheken

Voorbeeld:

• Deze bedrijven leveren insluitbare componenten die merchants gebruiken om betalingen te accepteren.
• Ook al worden kaartgegevens snel getokeniseerd, de SDK verwerkt nog steeds gevoelige logica.
• Validatie bewijst dat de SDK geen nieuwe aanvalsoppervlakken creëert.

4. Commerceplatforms met geïntegreerde betalingen

Voorbeeld: Shopify, BigCommerce, Ecwid.

• Platforms die ingebedde checkout-modules aanbieden die merchants kant-en-klaar gebruiken.
• De onderliggende software die die checkout mogelijk maakt, heeft vaak SSF-validatie nodig als ze wordt gedistribueerd.

5. Kiosk- en terminalsoftwarebedrijven

Voorbeeld: Nayax, Ingenico, Verifone (voor aangepaste softwarebuilds)

• Gebruikt in automaten, ticketkiosken en zelfscankassa's.
• Software moet voldoen aan vereisten voor manipulatiebestendigheid, update-integriteit en beveiligde communicatie.
• Deze omgevingen zijn vaak "onbemand", wat SSF extra relevant maakt.

6. White-label gateway-oplossingen

Voorbeeld: Payrix, BlueSnap, Corepay

• Bieden betaalinfrastructuur die andere platforms integreren of doorverkopen.
• Het gedistribueerde softwarecomponent (hosted fields, SDK's, plugins) heeft vaak validatie nodig.
• Helpt ook enterprise-klanten bij het verkleinen van hun eigen PCI-scope.

7. Beveiligingsgerichte betaaltools

Voorbeeld: Very Good Security (VGS), Basis Theory, TokenEx

• Deze bedrijven verwerken gevoelige gegevens in proxy-achtige omgevingen of vaults.
• Hun client-side SDK's of browserbibliotheken kunnen SSF-validatie vereisen, afhankelijk van hoe kaartgegevens stromen.

Wat vereist PCI SSF concreet?

PCI SSF-compliant zijn gaat niet alleen over nette code of goede bedoelingen. Het framework stelt duidelijke beveiligingsdoelstellingen waaraan je software moet voldoen. En die worden geverifieerd via een assessment.

Enkele belangrijke verwachtingen:

• Geen opslag van gevoelige gegevens: De software mag nooit volledige kaartnummers, CVV-codes of magneetstreepgegevens in plaintext opslaan.
• Correcte cryptografie: Branche-geaccepteerde algoritmen met goed sleutelbeheer zijn vereist.
• Update-integriteit: Software-updates moeten worden geverifieerd en ondertekend om manipulatie te voorkomen.
• Veilige standaardinstellingen: Beheerderswachtwoorden, configuratie-instellingen en toegangsbeleid moeten in een geharde staat worden geleverd.
• Manipulatiebeveiliging: Je app moet pogingen om het runtimegedrag te wijzigen detecteren en erop reageren (bijv. injectie, geheugenscanning).
• Toegangscontrole: Rollen en rechten moeten duidelijk zijn gedefinieerd, afgedwongen en gelogd.
• Logging en traceerbaarheid: Auditlogs moeten beschikbaar, beveiligd en bestand tegen wijziging zijn.
• Gedocumenteerde SDLC: Je ontwikkelproces moet aantonen dat beveiliging er van begin tot eind in is verankerd. Van ontwerp tot oplevering.

Kortom: assessors verwachten dat je kunt bewijzen dat beveiliging geen bijzaak is.

Hoe ziet het validatieproces eruit?

PCI SSF-validatie is formeel en gestructureerd. Het wordt uitgevoerd door een Secure Software Assessor (SSA). Geen zelfbeoordeling! Het resultaat is dat je product op de website van PCI SSC wordt vermeld.

Een globaal overzicht van het proces:

• Scoping: Bepaal welke producten of componenten worden ingediend. Je moet verduidelijken welke functionaliteit binnen de scope valt en hoe die past in de betaalstroom.

• Gap-analyse (optioneel): Sommige leveranciers beginnen met een pre-assessment om grote hiaten te identificeren voordat het formele proces begint. Dit is niet verplicht, maar kan later tijd besparen.

• Formele assessment: De assessor beoordeelt je:

• Herstelmaatregelen (indien nodig): Als er problemen worden gevonden, los je ze op, werk je de documentatie bij en dien je bewijs van de wijzigingen in.

• Indiening bij PCI SSC: Zodra de assessor tevreden is, dient hij een rapport in bij PCI SSC ter beoordeling.

• Vermelding: Na goedkeuring wordt je software gepubliceerd op de officiële lijst van gevalideerde betaaloplossingen.

De doorlooptijd varieert, maar de meeste assessments duren enkele weken tot een paar maanden, afhankelijk van de scope, de volwassenheid van de codebase en de duidelijkheid van de documentatie.

Wat is PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) is het framework dat de meesten waarschijnlijk kennen en is gericht op alle andere bedrijven die transacties op hun site verwerken.

De kern van PCI DSS:

Als je kaarthoudergegevens aanraakt, moet je ze beschermen, ..., en hier zijn 12 manieren hoe.

En als je onze uitgebreide analyse van PCI DSS 4.0.1 hebt gelezen, weet je dat die 12 manieren niet bepaald "even een vinkje zetten" zijn. We hebben het over:

• Netwerkbeveiligingscontroles
• Bescherming tegen malware
• Kwetsbaarheidsbeheer
• Monitoring en logging
• Veilige softwareontwikkeling
• Scriptinventarisatie (hoi, PCI 6.4.3 👋)
• Beveiliging van betaalheaders (hallo, 11.6.1 👋)

Of je nu een merchant bent met SAQ A, een serviceprovider, of een Shopify-app-ontwikkelaar die hosted fields gebruikt: PCI DSS is het framework dat van toepassing is op je live, kaartverwerking-omgeving.

Hier zijn links naar eerdere informatie die we over PCI DSS hebben geschreven, in de volgorde waarin je ze het beste kunt lezen:

• Hoe voldoe je aan PCI 6.4.3 en 11.6.1
• De grote PCI DSS-update van januari 2025
• De volledige PCI DSS 4.0.1-uiteenzetting
• Hoe word je een SAQ A-bedrijf?
• Het risico van alleen je betaalpagina's beveiligen

Wat is dan het verschil?

Een overzicht naast elkaar:

Kan een bedrijf onder beide vallen?

Absoluut. Stel dat je een checkout-plugin bouwt en verkoopt (PCI SSF), maar die plugin ook gebruikt op je eigen e-commercesite (PCI DSS). Dan moet je beide aanpakken: je codebase beveiligen én je infrastructuur beveiligen.

Zelfs als je kaartgegevens niet rechtstreeks verwerkt (bijv. SAQ A-merchants die Stripe of concurrenten met hosted fields gebruiken), val je nog steeds onder PCI DSS. Waarschijnlijk versie 4.0-vereisten zoals 6.4.3 en 11.6.1, die je verantwoordelijk maken voor scripts van derden en DOM-integriteit.