Requirement 3.5.1 noemt vier manieren om het primaire kaartnummer onleesbaar te maken: een eenwegshash over het volledige nummer met een sleutel, truncatie, een indextoken, of sterke cryptografie met bijbehorend sleutelbeheer. Elke route deelt één zwakke plek. De vertaaltabel die tokens terugvoert naar kaartnummers maakt de hele maatregel in één stap ongedaan. De norm waarschuwt daarnaast dat een gehashte en een afgeknotte versie van hetzelfde nummer samen het origineel kunnen reconstrueren. De AVG redeneert identiek: art. 4 lid 5 noemt gegevens pas gepseudonimiseerd wanneer de aanvullende gegevens apart worden bewaard en beveiligd. Een tabel die met de tokens meereist, haalt die voorwaarde onderuit.
Wanneer dit van toepassing is
Een ontwikkelteam vraagt een testset uit de productieomgeving. De export bevat getokeniseerde transacties én de vertaaltabel, omdat die in dezelfde database stond. Op de testomgeving zou daarmee elk kaartnummer opnieuw leesbaar worden.
Hoe anonym.plus dit afhandelt
- Open de export of de tabeluitdraai in de toepassing op uw eigen apparaat.
- De herkenning markeert kaartnummers, tokens en hashwaarden afzonderlijk.
- Verwijder de kolom die tokens aan kaartnummers koppelt volledig.
- Controleer of er geen tweede afgeleide vorm van hetzelfde nummer overblijft.
- Behoud het token, het bedrag, het tijdstip en de statuscode.
- Sla de geschoonde testset lokaal op en lever die aan de ontwikkelomgeving.
Wat u moet aanleveren
- De tabel of export als CSV, SQL-dump, XLSX of rapport-PDF.
- Een actie: weglakken, vervangen of gedeeltelijk maskeren.
- Optioneel: een kolomlijst met velden die de testset nodig heeft.
Entiteitstypen die in financiele documenten worden gedetecteerd
| Categorie | anonym.plus-entiteitstype | Voorbeeld |
|---|---|---|
| Kaart | CREDIT_CARD | 4111 1111 1111 1111 → [VERWIJDERD] |
| Indextoken | ID | TKN-9F42-6C18 → blijft staan |
| Hashwaarde | ID | sha256:9c1f…a740 → [VERWIJDERD] |
| Vertaalregel | REFERENCE_NUMBER | MAP-2026-0031 → [VERWIJDERD] |
| Beheerder | PERSON | Joost Brouwer → [BEHEERDER] |
| Vastlegging | DATE_TIME | 2026-01-08 → blijft staan |
Bereikte naleving
- Bewaakt de vier routes waarmee PCI DSS v4.0 Req. 3.5.1 een kaartnummer onleesbaar maakt, door de vertaaltabel buiten de kopie te houden.
- Voorkomt de reconstructie waar de norm expliciet voor waarschuwt: een gehashte en een afgeknotte vorm van hetzelfde nummer naast elkaar.
- Voldoet aan de voorwaarde uit AVG art. 4 lid 5 dat de aanvullende gegevens apart worden bewaard en technisch beveiligd blijven.
- Houdt de testset bruikbaar: token, bedrag, tijdstip en statuscode blijven staan voor functionele proeven.
Anonimiseer tokenisatietabellen offline — bekijk abonnementen & begin gratis →
Beperkingen & aandachtspunten
Zonder tabel blijft een token stabiel en dus koppelbaar over records heen. De testset is daarmee gepseudonimiseerd, niet geanonimiseerd, en blijft onder de privacyregels vallen.
Veelgestelde vragen
Welke methoden noemt Req. 3.5.1?
Een eenwegshash over het volledige nummer met een sleutel, truncatie, een indextoken met veilig opgeslagen tabel, en sterke cryptografie met bijbehorend sleutelbeheer.
Waarom is een hash naast een afgeknot nummer riskant?
Omdat de afgeknotte cijfers de zoekruimte verkleinen en de hash daarna te verifiëren is. De norm verlangt daarom extra maatregelen zodra beide vormen in dezelfde omgeving staan.
Mag de vertaaltabel in dezelfde database staan?
Alleen met aanvullende scheiding en toegangsbeperking. Voor een testset of analysekopie hoort de tabel er domweg niet bij.