Kaartgegevens zijn een bekende aansprakelijkheid voor ondernemingen. De wereldwijde gemiddelde kosten van een datalek waren $ 4,44 miljoen in 2025. Elke server, elk logbestand en elke back-up waarin een primair accountnummer (PAN) wordt opgeslagen, maakt deel uit van wat de Payment Card Industry Data Security Standard (PCI DSS) de cardholder data environment (CDE) noemt, en elk aspect van die omgeving is onderworpen aan compliance-vereisten.

Tokenisatie verandert wat er daadwerkelijk in die omgeving staat door de PAN te vervangen door een vervangende waarde die op zichzelf geen uitbuitbare waarde heeft. Als je tokenisatie goed implementeert, kun je jouw compliance-verplichtingen terugbrengen tot een fractie van wat ze anders zouden zijn. Hieronder bespreken we hoe PCI-compliance tokenisatie werkt, de grenzen van de bescherming ervan, waar andere beveiligingsmaatregelen moeten worden geïmplementeerd en wat de PCI Security Standards Council eist van een compliant tokensysteem.

Belangrijkste inzichten

• Tokenisatie kan hele systemen uit de compliance-scope van de Payment Card Industry Data Security Standard (PCI DSS) halen, maar alleen als de bedieningselementen voor tokengeneratie, kluisbeveiliging en detokenisatie voldoen aan specifieke technische normen.

• Encryptie en tokenisatie beschermen betaalkaartgegevens onder de PCI DSS anders en veel compliant architecturen vertrouwen op beide in plaats van voor de een of de ander te kiezen.

• Kwalificeren voor de eenvoudigste PCI-compliance-vragenlijst voor zelfbeoordeling hangt af van hoe kaartgegevens door een integratie stromen, in plaats van alleen of tokenisatie ergens in het systeem aanwezig is.

Wat is PCI DSS-compliance?

PCI DSS-compliance betekent dat wordt voldaan aan de beveiligingsvereisten die door de PCI Security Standards Council zijn opgesteld voor elke onderneming die gegevens van kaarthouders opslaat, verwerkt of verstuurt. De standaard omvat 12 kernvereisten voor netwerkbeveiliging, toegangsbeheer, encryptie en controle. Het is van toepassing, ongeacht of je maar één betaalterminal beheert of miljoenen transacties per jaar verwerkt.

Wat zegt de PCI DSS over tokenisatie?

In de PCI DSS-richtlijnen voor tokenisatie staat dat, als een token geen waarde heeft buiten het systeem dat het heeft aangemaakt, en als dat systeem op de juiste manier is geïsoleerd en beveiligd, de omgevingen waarin het token zich bevindt niet hoeven te worden beoordeeld alsof ze de gegevens van de echte betaalkaart bevatten. Elk PAN bestaat nog wel ergens, meestal in een versleutelde kluis, maar dankzij tokenisatie bestaat het alleen op die ene locatie, en niet verdeeld over systemen.

Hoe tokenisatie de reikwijdte van PCI-compliance beperkt

Tokenisatie beperkt de reikwijdte van de PCI-compliance door het aantal plaatsen te beperken waar leesbare betaalkaartgegevens worden opgeslagen of verzonden. Dit geldt zolang de tokens niet door iemand buiten het systeem voor tokenisatie kunnen worden teruggezet naar het oorspronkelijke PAN. Als iemand het PAN aan de hand van bekende logica uit het token kan berekenen, verkleint het token de reikwijdte niet.

PCI DSS-richtlijnen voor tokenisatie en vereisten voor beperking van de reikwijdte

De richtlijnen van de PCI Security Standards Council bevatten specifieke technische verwachtingen voor elk systeem dat beweert de reikwijdte te verkleinen. Deze vallen uiteen in twee hoofdcategorieën: generatie van tokens en tokenkluizen.

Genereren van tokens

Generatie van tokens moet bestand zijn tegen 'reverse engineering' (nabouwen of reverse-engineeren). Indelingbehoudende tokens die de lengte en structuur van een bepaald kaartnummer nabootsen, zijn veilig zolang de vervanging op zich onvoorspelbaar is en niet is afgeleid met een omkeerbare formule.

Tokens die via een eenrichtingsproces zijn aangemaakt, zodat er geen wiskundige omkeerfunctie is, komen beter in aanmerking voor een beperkte reikwijdte dan tokens die via encryptie met een herstelbare sleutel zijn gegenereerd. Versleutelde waarden worden volgens de PCI DSS-definities nog steeds als kaarthoudergegevens beschouwd, zelfs als ze als tokens zijn geformatteerd. De manier waarop tokens worden gegenereerd, bepaalt hoe een beoordelaar het systeem classificeert. De PCI DSS-richtlijnen gaan ook in op de weerstand tegen inbraak door het uitproberen van wachtwoorden (brute-force aanvallen). Als het algoritme voor tokenisatie kan worden geraden of omgekeerd door herhaalde pogingen, komt het token niet in aanmerking voor beperking van de reikwijdte, ongeacht hoe het wordt gegenereerd.

Tokenkluizen

Het systeem voor het opslaan van tokens wordt een kluis genoemd. De tokenkluis moet in een gesegmenteerde netwerkzone staan, strikt toegangsbeheer op basis van rollen toepassen op gegevens die tokens terugkoppelen naar het oorspronkelijke PAN, en elke detokenisatie met voldoende details in een logboek vastleggen om een forensische evaluatie te ondersteunen. De beoordelaars van de PCI DSS houden over het algemeen de norm aan dat detokenisatie zeldzaam, bewust en controleerbaar moet zijn. In de richtlijnen staat ook dat de leverancier van tokenisatie, of dit nu een intern team is of een externe leverancier, een eigen PCI DSS-beoordeling moet ondergaan. Een in gevaar gebrachte kluis ontneemt het doel van tokenisatie.

De documentatie moet de bewering over de beperking van de reikwijdte bewijzen aan beoordelaars en moet een gegevensstroomdiagram bevatten dat precies laat zien waar PAN's voorkomen als platte tekst (d.w.z. leesbare gegevens die niet zijn versleuteld), waar tokenisatie plaatsvindt en waar tokens het overnemen in je systemen. Het diagram moet worden bijgewerkt telkens wanneer een nieuw systeem wordt toegevoegd aan de stroom van betalingen. Zo niet, dan komt de claim van beperking van de reikwijdte niet meer overeen met de werkelijkheid, zelfs als er verder niets is veranderd.

Hoe tokenisatie zich verhoudt tot encryptie onder de PCI DSS

Zowel tokenisatie als encryptie beschermen dezelfde onderliggende gegevens, maar de PCI DSS behandelt ze heel anders als het gaat om reikwijdte. Een versleuteld PAN blijft over het algemeen binnen de reikwijdte, tenzij het systeem waarin de gegevens zijn opgeslagen geen toegang heeft tot de decryptiesleutels die nodig zijn om de cijfertekst (het versleutelde formaat) te lezen. Het systeem dat de cijfertekst bevat, moet voldoen aan dezelfde vereisten voor toegangsbeheer, registratie van activiteiten en beheer van kwetsbaarheden als een systeem dat het PAN in platte tekst opslaat, ook al is het praktische risico lager.

Bij tokenisatie is er geen sleutel te beschermen. Wanneer een token wordt gegenereerd via een correct geïmplementeerd proces in één richting, kan dit niet wiskundig worden omgekeerd, wat betekent dat de systemen die het token bevatten, zich buiten de CDE bevinden.

In de praktijk gebruiken veel PCI-compliante architecturen zowel encryptie als tokenisatie, omdat ze allebei andere veiligheidsmaatregelen toevoegen. Encryptie beschermt het PAN in de kluis voor autorisatie en vereffening, terwijl tokenisatie het PAN overal elders beschermt, zoals in de systemen die moeten verwijzen naar een transactie, een terugbetaling moeten verwerken of de laatste vier cijfers aan een klant moeten laten zien, zonder ooit het daadwerkelijke nummer nodig te hebben. Uiteindelijk beschermt encryptie bruikbare gegevens en verwijdert tokenisatie deze volledig uit een systeem.

Wie is verantwoordelijk voor het onderhouden van compliance door middel van tokenisatie na de implementatie?

Voor de PCI DSS-compliance is voortdurende goedkeuring vereist, en tokenisatie voegt een eigen onderhoud toe bovenop de gebruikelijke cyclus van controle en patching (d.w.z. het toepassen van veiligheidsupdates) van de standaard. Als je gebruikmaakt van een externe aanbieder van tokenisatie, ben je er nog steeds verantwoordelijk voor om te bevestigen dat de aanbieder zijn eigen PCI DSS-goedkeuring handhaaft en om hun Attestation of Compliance (bewijs van conformiteit) elk jaar te controleren. Een verlopen certificering aan de kant van de leverancier brengt je eigen claim op beperking van de reikwijdte in gevaar, zelfs als er aan jouw kant niets veranderd is.

Intern moet iemand verantwoordelijk zijn voor het gegevensstroomdiagram en het bijwerken ervan telkens wanneer er een nieuw systeem aan de stroom van de betaling wordt toegevoegd. Het beperken van de reikwijdte kan ongemerkt in verval raken wanneer bijvoorbeeld een nieuwe analytische tool wordt gekoppeld of een ondersteuningsteam transactiegegevens exporteert naar een spreadsheet voor het oplossen van problemen en een PAN in platte tekst tegenkomt waar tijdens de laatste controle geen rekening mee was gehouden. De toegangslogboeken tot de kluis moeten ook regelmatig worden gecontroleerd om verzoeken tot detokenisatie op te sporen die niet overeenkomen met de verwachte werkwijzen van de onderneming.

In veel middelgrote ondernemingen valt dit onder de verantwoordelijkheid van degene die de betaalinfrastructuur beheert (vaak iemand van Finance of Engineering), die in de jaarlijkse beoordelingscyclus met een Qualified Security Assessor (QSA) samenwerkt. Voor kleinere ondernemingen die gebruikmaken van een betaalprovider die het proces van de tokenisatie integraal afhandelt, is dit minder omslachtig, maar zij moeten wel bevestigen dat zij geen PAN's in hun eigen systemen hebben teruggebracht via export, schermafbeeldingen of workflows van de klantenservice die buiten de oorspronkelijke beperkte reikwijdte vielen.

Is tokenisatie op zichzelf genoeg om de PCI DSS-compliance te garanderen?

Tokenisatie verkleint de reikwijdte, maar neemt de complianceverplichtingen niet weg voor de systemen die nog steeds binnen de reikwijdte vallen. De kluis moet nog steeds volledig in compliance zijn: de generatielogica, de gegevens van de toewijzing van het token aan een PAN en de regelingen voor detokenisatie moeten allemaal aan de volledige PCI DSS-standaarden voldoen.

Raakpunten van vóór de tokenisatie moeten ook binnen de reikwijdte blijven. Elk systeem dat een PAN verwerkt voordat dit in een token wordt omgezet, zoals een betaalpagina of een POS-systeem (point-of-sale), vereist encryptie tijdens de verwerking, segmentatie van het netwerk en scans naar kwetsbaarheden.

De geschiktheidskloof bij de zelfbeoordelingsvragenlijst (SAQ)

Veel ondernemingen gaan ervan uit dat elke oplossing voor tokenisatie hen kwalificeert voor het gebruik van Zelfbeoordelingsvragenlijst A (SAQ A), de eenvoudigste zelfbeoordelingsvragenlijst. Maar dat is alleen het geval als het systeem voor de tokenisatie voorkomt dat de onderneming ooit PAN's verwerkt, verstuurt of opslaat, meestal via een gehoste betaalpagina of een geïntegreerd onderdeel waar de gegevens van een betaalkaart rechtstreeks van de browser van de klant naar de betaalprovider gaan. Bij een werkwijze met tokenisatie waarbij onbewerkte kaartgegevens nog steeds, al is het maar kort, via de eigen server van de onderneming lopen voordat ze in een token worden omgezet, blijft die server binnen een bredere reikwijdte vallen, hoe sterk de tokenisatie vanaf dat moment ook is.

Hoe Stripe Payments kan helpen

Stripe Payments biedt een gebundelde, wereldwijde betaaloplossing die elke onderneming, van groeiende start-ups tot wereldwijde ondernemingen, helpt om online, fysiek en wereldwijd betalingen te ontvangen.

Stripe Payments kan je helpen:

• Optimaliseer je afrekenproces: creëer een soepele klantervaring en bespaar de tijd van de technici met vooraf geconfigureerde betalings-UI's, toegang tot 125+ betaalmethoden en Link, een wallet gebouwd door Stripe.

• Sneller uit te breiden naar nieuwe markten: bereik klanten over de hele wereld en verminder de complexiteit en kosten van multivalutabeheer met grensoverschrijdende betaalopties, beschikbaar in 195 landen in 135+ valuta.

• Fysieke en online betalingen samen te voegen: bouw een unified commerce-ervaring op via online en fysieke kanalen om interacties te personaliseren, loyaliteit te belonen en inkomsten te laten groeien.

• De betaalprestaties te verbeteren: verhoog inkomsten met een reeks aanpasbare, eenvoudig te configureren betaaltools, waaronder no code-fraudebescherming en geavanceerde mogelijkheden om autorisatiepercentages te verbeteren.

• Sneller te werken met een flexibel, betrouwbaar platform voor groei: bouw voort op een platform dat is ontworpen om met jou mee te groeien, met een historische uptime van 99,999% en toonaangevende betrouwbaarheid.

Lees meer over hoe Stripe Payments je online en fysieke betalingen kan ondersteunen of ga vandaag nog aan de slag.