Een uitgebreide gids voor het bereiken en behouden van PCI DSS-naleving

Gepubliceerd: 16 december 2024. Bijgewerkt: augustus 2026. Beoordeeld door het Compliance Advisory-team van Encryption Consulting.

Wanneer een klant zijn of haar kaart overhandigt, vertrouwt hij of zij erop dat uw systemen – en niet alleen uw bedrijf – die gegevens veilig bewaren. Alleen al in 2024 werden wereldwijd meer dan 26 miljard gegevens blootgelegd door datalekken , en betaalkaartgegevens blijven een van de meest waardevolle doelwitten voor aanvallers, omdat ze direct omgezet kunnen worden in fraude. PCI DSS is er om die kloof te dichten tussen "wij verwerken kaarten" en "wij kunnen bewijzen dat onze systemen veilig genoeg zijn om aan die kaarten te worden toevertrouwd".

Deze handleiding beschrijft wat PCI DSS daadwerkelijk vereist, met name de cryptografische controles die de meeste organisaties in de problemen brengen: hoe te kiezen tussen encryptie en tokenisatie, welke TLS-versie te gebruiken, hoe de MFA-vereisten in 2025 zijn gewijzigd en hoe een sleutelbeheerprogramma op te zetten dat de vragen van een auditor kan doorstaan. De handleiding sluit af met het concrete, genummerde pad naar certificering en de beperkingen waar u rekening mee moet houden voordat u begint.

Wat is PCI DSS-naleving en voor wie is het van toepassing?

PCI DSS-conformiteit betekent dat een organisatie de technische en operationele controles die vereist zijn door de Payment Card Industry Data Security Standard ( PCI DSS) heeft geïmplementeerd en kan aantonen , om kaartgegevens van klanten gedurende hun hele levenscyclus te beschermen: van vastlegging en verzending tot opslag en verwijdering. De standaard wordt beheerd door de PCI Security Standards Council (PCI SSC), een instantie die in 2006 is opgericht door Visa, Mastercard, American Express, Discover en JCB om de lappendeken van merkspecifieke beveiligingsprogramma's die eraan voorafgingen te vervangen.

PCI DSS is van toepassing op elke entiteit die kaartgegevens of gevoelige authenticatiegegevens opslaat, verwerkt of verzendt, of die de beveiliging van die gegevens kan beïnvloeden, ongeacht het transactievolume of de omvang van het bedrijf. Zowel een café met één vestiging en een betaalterminal als een multinationaal e-commerceplatform vallen onder de PCI DSS-standaard; het verschil zit hem in de hoeveelheid validatiewerk die elk bedrijf moet verrichten, niet in de vraag of de standaard van toepassing is.

Een aantal termen komen in deze handleiding en in elke PCI DSS-beoordeling terug, daarom is het de moeite waard om ze eens duidelijk te definiëren:

• CDE (Cardholder Data Environment)Dit omvat de mensen, processen en technologie die kaartgegevens of gevoelige authenticatiegegevens opslaan, verwerken of verzenden, plus alle verbonden systemen die de beveiliging van die gegevens kunnen beïnvloeden. Het verkleinen van de voetafdruk van de CDE door middel van netwerksegmentatie is de belangrijkste manier om de omvang en kosten van de beoordeling te verlagen.
• QSA (Gekwalificeerd Beveiligingsbeoordelaar)Een persoon die door de PCI SSC is gecertificeerd om PCI DSS-beoordelingen op locatie uit te voeren voor organisaties, doorgaans Level 1-handelaren en dienstverleners.
• SAQ (Zelfbeoordelingsvragenlijst)Een validatietool die winkeliers gebruiken om zelf hun naleving te rapporteren in plaats van een volledige audit door een QSA te ondergaan. Welk type SAQ van toepassing is, hangt af van hoe de winkelier kaartgegevens accepteert en verwerkt.
• ROC (Rapport over naleving): het gedetailleerde rapport dat een QSA opstelt na een beoordeling ter plaatse, waarin wordt gedocumenteerd hoe aan elke vereiste is voldaan en hoe deze is gevalideerd. Vereist voor Level 1-leveranciers en de meeste dienstverleners.
• AOC (Verklaring van naleving)Een ondertekende samenvatting met de uitkomst van de beoordeling, die wordt ingediend bij de acquirerende bank of betaalmerk als formeel bewijs van naleving. Elke handelaar en dienstverlener dient een AOC in, ongeacht of deze een ROC of een SAQ volgt.

PCI DSS-conformiteit is geen loutere wettelijke formaliteit. Het is een contractuele verplichting die wordt afgedwongen door de acquirerende bank en de kaartmerken via de merchantovereenkomst. Niet-naleving die na een overtreding wordt ontdekt, leidt doorgaans tot boetes, hogere transactiekosten en in ernstige gevallen zelfs tot het volledig verliezen van de mogelijkheid om kaartbetalingen te accepteren.

Wat zijn de 12 PCI DSS-vereisten?

PCI DSS v4.0.1 organiseert zijn beheersmaatregelen in 12 vereisten, gegroepeerd onder zes beheerdoelstellingen: een veilig netwerk bouwen en onderhouden, accountgegevens beschermen, een programma voor kwetsbaarheidsbeheer onderhouden, sterke toegangscontrole implementeren, netwerken regelmatig monitoren en testen, en een informatiebeveiligingsbeleid handhaven. Elke beoordeling, of het nu een SAQ of een volledige QSA-audit is, wordt getoetst aan deze 12 vereisten.

1. Installeer en onderhoud netwerkbeveiligingscontrolesFirewalls en vergelijkbare beveiligingsmaatregelen scheiden de CDE af van onbetrouwbare netwerken en beperken het verkeer tot wat de bedrijfsprocessen vereisen.
2. Pas beveiligde configuraties toe op alle systeemcomponenten.De standaardwachtwoorden, accounts en instellingen van de leverancier worden gewijzigd voordat een systeem de CDE benadert.
3. Bescherm opgeslagen accountgegevensKaartgegevens van kaarthouders worden onleesbaar gemaakt door middel van sterke cryptografie of tokenisatie, en de bewaring ervan wordt beperkt tot wat zakelijk gerechtvaardigd is. Hieronder wordt dit uitgebreid besproken.
4. Bescherm kaarthoudergegevens met sterke cryptografie tijdens de overdracht via open, openbare netwerkenTLS 1.2 of hoger beveiligt elke overdracht van kaartgegevens via internet of andere onbetrouwbare netwerken. Hieronder wordt dit uitgebreid besproken.
5. Bescherm alle systemen en netwerken tegen schadelijke softwareAntimalwaremaatregelen worden geïmplementeerd, actueel gehouden en actief gemonitord op alle relevante systemen.
6. Ontwikkel en onderhoud veilige systemen en softwareRegelmatige patching, veilige ontwikkelmethoden en wijzigingsbeheer voorkomen dat bekende kwetsbaarheden in de productieomgeving blijven bestaan.
7. Beperk de toegang tot systeemcomponenten en kaartgegevens op basis van de noodzaak voor de bedrijfsvoering.Modellen met minimale toegangsrechten beperken wie toegang heeft tot kaartgegevens tot alleen de rollen die daar behoefte aan hebben.
8. Identificeer gebruikers en authenticeer toegang tot systeemcomponentenElke gebruiker en beheerder wordt uniek geïdentificeerd en er wordt multifactorauthenticatie toegepast voor toegang tot de CDE. Dit wordt hieronder uitgebreid besproken.
9. Beperk de fysieke toegang tot kaarthoudergegevensFaciliteiten, media en apparaten die kaartgegevens bevatten, zijn fysiek beveiligd en de toegang ertoe wordt geregistreerd.
10. Registreer en controleer alle toegang tot systeemcomponenten en kaarthoudergegevensAuditlogboeken leggen vast wie wanneer toegang had tot welke gegevens, en de logboeken worden regelmatig gecontroleerd op afwijkingen.
11. Test regelmatig de beveiliging van systemen en netwerken.Driemaandelijkse ASV-kwetsbaarheidsscans, jaarlijkse penetratietests en continue validatie van de reikwijdte bevestigen dat de beveiligingsmaatregelen daadwerkelijk effectief zijn.
12. Ondersteun informatiebeveiliging met organisatiebeleid en -programma'sEen gedocumenteerd en gecommuniceerd informatiebeveiligingsbeleid en een incidentresponsplan bieden de overige 11 vereisten een solide basis voor goed bestuur.

Vereisten 3, 4 en 8 zijn de plekken waar de beslissingen over cryptografie en authenticatietechniek vallen, en waar de meeste organisaties ofwel te veel geld uitgeven aan de verkeerde beveiligingsmaatregel, ofwel een wezenlijke lacune onopgelost laten. De rest van deze handleiding richt zich daarop.

Wat zijn de cryptografische vereisten van PCI DSS?

De cryptografische vereisten van PCI DSS hebben betrekking op drie afzonderlijke problemen: het onleesbaar maken van opgeslagen kaartgegevens (vereiste 3), het beschermen van kaartgegevens tijdens de overdracht (vereiste 4) en het beheren van de sleutels die beide controles betrouwbaar maken (vereisten 3.6 en 3.7). Elk probleem kent zijn eigen dreigingsmodel, en door ze te behandelen als één algemene optie "alles versleutelen" krijgen organisaties uiteindelijk controles die weliswaar een audit doorstaan, maar in de praktijk tekortschieten.

Vereiste 3: Versleuteling versus tokenisatie voor opgeslagen kaarthoudergegevens

Vereiste 3 vereist dat het primaire rekeningnummer (PAN) onleesbaar wordt gemaakt, waar het ook wordt opgeslagen, door gebruik te maken van sterke cryptografie, afkapping, indextokens met een veilig opgeslagen pad, of eenrichtingshashing van het volledige PAN. In de praktijk komt dit neer op een keuze tussen het ter plaatse versleutelen van het PAN of het vervangen ervan door een token en het opslaan van de werkelijke waarde ergens volledig buiten het bereik van de beveiliging.

Dreigingsmodel. Opgeslagen kaartgegevens worden aangevallen via datalekken, misbruik door medewerkers, blootstelling van back-ups en logbestanden, en laterale verplaatsing vanuit een minder gevoelig systeem naar de gegevensopslag. De beveiliging moet bestand zijn tegen een aanvaller die al leesrechten heeft op de opslaglaag. Daarom wordt "de database heeft toegangscontroles" op zichzelf nooit als voldoende beschouwd.

Algoritmekeuze. Waar encryptie wordt gebruikt, is AES-256 de de facto standaard voor PCI DSS-omgevingen; het is snel in hardware, heeft geen bekende praktische cryptanalytische zwakheden bij die sleutelgrootte en wordt expliciet erkend als sterke cryptografie door de PCI SSC. AES-256-GCM heeft over het algemeen de voorkeur boven CBC-modus voor nieuwe implementaties, omdat het geauthenticeerde encryptie biedt, waarbij manipulatie wordt gedetecteerd en de gegevens worden verborgen, tegen vergelijkbare prestatiekosten op moderne CPU's met AES-NI-acceleratie.

Afwegingen tussen prestaties en interoperabiliteit. Versleuteling zorgt ervoor dat het formaat van de PAN omkeerbaar en behouden blijft, wat handig is wanneer downstream-systemen (loyaliteitsprogramma's, terugboekingen, terugkerende facturering) de oorspronkelijke waarde nog moeten reconstrueren. Tokenisatie verwijdert de echte PAN volledig uit uw omgeving, wat de reikwijdte van PCI DSS daadwerkelijk verkleint, maar dit is afhankelijk van de beschikbaarheid en bereikbaarheid van een tokenisatiekluis van een derde partij of een centrale kluis voor elk systeem dat moet detokeniseren. Formaatbehoudende tokenisatie voorkomt wijzigingen in downstream-applicaties, maar voegt een extra netwerkcommunicatie toe voor elke detokenisatieoproep, wat van belang is bij een hoog transactievolume.

Implementatievoorbeelden. Een betalingsgateway tokeniseert het PAN (Primary Account Number) doorgaans op het moment van vastlegging en slaat alleen het token op in zijn eigen database. De tokenkluis zelf is het enige systeem dat volledig onder de PCI DSS-regelgeving valt. Een traditioneel on-premises facturatiesysteem dat het echte PAN moet bewaren voor terugkerende kosten, maakt vaker gebruik van kolomniveau- of transparante dataversleuteling (TDE) met AES-256, ondersteund door een HSM-beveiligde sleutel, omdat het vervangen van het PAN door een token de facturatielogica zou verstoren.

Afhankelijkheid van sleutelbeheer. Geen van beide benaderingen is veilig zonder de sleutelbeheercontroles in vereisten 3.6 en 3.7, die hieronder worden besproken. Een met AES-256 versleutelde databasekolom met een sleutel die is opgeslagen in een configuratiebestand ernaast, biedt in feite geen echte bescherming en is een veelvoorkomende bevinding bij mislukte beoordelingen.

Beslissingsfactor	Kies encryptie (AES-256)	Kies voor tokenisatie
Vertakkingssystemen hebben het echte PAN-nummer nodig (terugkerende facturering, terugboekingen).	Ja, versleuteling zorgt ervoor dat de waarde herstelbaar blijft.	Nee, tenzij elk systeem de detokenisatieservice kan aanroepen.
Het doel is om de omvang van de PCI DSS-beoordeling te verkleinen.	Versleutelde dataopslagsystemen blijven doorgaans binnen het toepassingsgebied.	Ja, het verwijderen van het echte PAN-nummer kan ertoe leiden dat systemen buiten het toepassingsgebied vallen.
Hoog transactievolume met gevoeligheid voor latentie	Lokale decryptie, minimale extra latentie.	Er is een extra netwerkroundtrip toegevoegd per detokenisatie-aanroep.
Verouderde applicaties die niet opnieuw ontworpen kunnen worden.	Eenvoudiger achteraf aan te passen op het opslagniveau.	Vaak zijn er applicatiewijzigingen nodig om de kluis aan te roepen.
Meerdere bedrijfsonderdelen of derden hebben toegang nodig.	Vereist sleuteldistributie en toegangscontrole per gebruiker.	Centraliseert de controle in één kluis, wat de audit vereenvoudigt.

Vereiste 4: TLS voor kaarthoudergegevens tijdens transport

Vereiste 4 vereist dat kaartgegevens worden beschermd met sterke cryptografie wanneer deze worden verzonden via openbare netwerken. PCI DSS noemt geen specifieke verplichte protocolversie in de tekst van de standaard, maar de eigen richtlijnen en het PCI SSC-bulletin ' Migrating from SSL and Early TLS' stellen expliciet dat SSL en vroege TLS-versies (TLS 1.0 en 1.1) niet voldoen aan de definitie van sterke cryptografie. In de praktijk betekent dit dat TLS 1.2 het verplichte minimum is, waarbij TLS 1.3 de voorkeur heeft voor nieuwe implementaties.

Dreigingsmodel. Gegevens die worden verzonden, zijn kwetsbaar voor man-in-the-middle-aanvallen, protocol-downgrade-aanvallen en bekende exploits op cipher-niveau, zoals POODLE en BEAST, die specifiek gericht zijn op SSL en vroege TLS-versies. Een assessor die deze controle test, scant op elke listener die nog steeds een verouderde protocolversie accepteert, en controleert niet alleen of TLS is ingeschakeld.

Richtlijnen voor protocolselectie. Schakel SSL 2.0, SSL 3.0, TLS 1.0 en TLS 1.1 uit op alle systeemcomponenten die de CDE (Cardholder Data Environment) gebruiken, inclusief interne loadbalancers en legacy point-of-sale-integraties. Configureer de voorkeur voor cipher suites zodanig dat forward-secrecy suites (op ECDHE gebaseerd) de voorkeur krijgen boven statische RSA-sleuteluitwisseling, en vermijd symmetrische cipher suites met blokgroottes kleiner dan 128 bits. De PCI SSC verwijst naar NIST SP 800-52 als referentie voor het beveiligen van TLS-configuraties.

Afwegingen tussen prestaties en interoperabiliteit. TLS 1.3 verwijdert een aantal verouderde handshake-rondes en biedt geen ondersteuning meer voor bekende zwakke cipher suites, wat zowel de verbindingslatentie als het risico op configuratiefouten vermindert. De keerzijde is dat sommige oudere kassaterminals, betaal-SDK's en embedded apparaten nog steeds alleen TLS 1.2 ondersteunen. Daarom blijft TLS 1.2 de praktische minimale basisstandaard in plaats van TLS 1.3; een gefaseerd upgradepad waarbij TLS 1.2-hardware volgens een vast schema wordt uitgefaseerd, is een realistischer plan dan een onmiddellijke overstap.

Implementatievoorbeeld. Een veelvoorkomend patroon is TLS-terminatie bij een load balancer of API gateway die is geconfigureerd voor minimaal TLS 1.2 en bij voorkeur TLS 1.3, met herversleuteling (niet in platte tekst) op het interne segment tussen de gateway en de applicatielaag, zodat kaartgegevens nooit onversleuteld worden verzonden, zelfs niet binnen het eigen netwerk van de organisatie.

Vereisten 3.6 en 3.7: De sleutelbeheerlevenscyclus

Versleuteling is slechts zo sterk als de sleutels die erachter zitten. Daarom wijdt PCI DSS twee volledige families van vereisten aan sleutelbescherming en levenscyclusbeheer. Vereiste 3.6 beschrijft hoe sleutels worden beschermd tijdens gebruik, en vereiste 3.7 definieert de levenscyclus die een sleutel moet doorlopen, van creatie tot vernietiging.

Vereiste 3.6 vereist dat cryptografische sleutels die worden gebruikt om opgeslagen accountgegevens te beschermen, zelf ook beschermd zijn. Dit kan door ze te versleutelen met een aparte sleutelversleutelingssleutel, op te slaan in een beveiligd cryptografisch apparaat zoals een HSM, of op te splitsen in componenten die onder dubbel beheer vallen. De toegang tot de onversleutelde sleutelcomponenten is beperkt tot het minimaal noodzakelijke aantal beheerders en het aantal locaties voor sleutelopslag is geminimaliseerd.

Vereiste 3.7 vereist gedocumenteerde procedures voor de volledige levenscyclus van sleutels: sterke sleutelgeneratie, veilige distributie, veilige opslag, rotatie aan het einde van een gedefinieerde cryptoperiode en het buiten gebruik stellen, vervangen of vernietigen van sleutels die gecompromitteerd zijn, buiten gebruik zijn gesteld of het einde van hun cryptoperiode naderen. Het vereist tevens gedeelde kennis en dubbele controle voor alle handmatige sleutelbeheerhandelingen, het voorkomen van ongeautoriseerde sleutelvervanging en een formele, ondertekende bevestiging van sleutelbeheerders dat zij hun verantwoordelijkheden begrijpen en aanvaarden.

In de praktijk is dit de vereiste die het vaakst onvoldoende wordt benut. Een beleid voor sleutelrotatie dat weliswaar op papier staat, maar niet daadwerkelijk wordt afgedwongen door de tools, of een cryptoperiode die nooit formeel is gedefinieerd, is een veelvoorkomende bevinding bij QSA-beoordelingen. Door het beheer van de sleutellevenscyclus te centraliseren via een speciaal platform voor certificaten en sleutellevenscycli zoals CertSecure Manager, krijgt een organisatie afgedwongen rotatieschema's, verantwoordingsplicht voor de beheerder en rapportagemogelijkheden die geschikt zijn voor audits, in plaats van handmatig de leeftijd van sleutels bij te houden in een spreadsheet.

HSM-implementatie voor sleutelopslag

Een hardwarebeveiligingsmodule (HSM) is de praktische manier waarop de meeste organisaties die aan de vereisten voldoen, voldoen aan de formulering "beveiligd cryptografisch apparaat" van vereiste 3.6: een fraudebestendig, speciaal apparaat dat cryptografische sleutels genereert, opslaat en gebruikt zonder deze ooit in platte tekst aan de hostapplicatie of het besturingssysteem bloot te stellen. FIPS 140-3 is de huidige validatiestandaard waaraan HSM's worden getoetst, en QSA's verwachten steeds vaker FIPS-gevalideerde sleutelopslag in plaats van softwarematige sleutelkluizen voor omgevingen met hoge waarde.

Organisaties kiezen over het algemeen tussen on-premises HSM's, die maximale controle bieden en vaak worden gebruikt waar wettelijke of contractuele vereisten dit vereisen, en cloudgebaseerde HSM-as-a-Service , die de investeringskosten en de overhead van fysieke sleutelceremonies wegneemt, terwijl toch FIPS-gevalideerde sleutelopslag wordt geboden. Een typisch implementatievoorbeeld: de tokenisatiekluis van een betalingsverwerker slaat de hoofdsleutel voor encryptie op in een HSM-cluster, en elke aanroep voor het genereren of ontsleutelen van tokens wordt binnen de HSM-omgeving ondertekend of ontsleuteld, zodat de sleutel zelf de gevalideerde hardware nooit verlaat.

Wat stelt PCI DSS aan de eisen voor multifactorauthenticatie?

PCI DSS v4.0.1 heeft de MFA-vereisten onder vereiste 8.4 aanzienlijk uitgebreid, en de meest ingrijpende wijziging, MFA voor elke gebruiker die toegang heeft tot de omgeving met kaartgegevens, is sinds 31 maart 2025 volledig van kracht . Drie gerelateerde subvereisten verdienen nadere toelichting, omdat ze in informele samenvattingen vaak door elkaar worden gehaald:

• Eis 8.4.1MFA is vereist voor alle administratieve toegang tot de CDE die geen consoletoegang vereist. Deze vereiste is overgenomen uit PCI DSS v3.2.1 en is al jaren van kracht.
• Eis 8.4.2MFA is vereist voor alle toegang tot de CDE, niet alleen voor beheerders. Dit is de belangrijkste nieuwe beveiligingsmaatregel in versie 4.0, waarmee MFA wordt uitgebreid naar elke gebruiker in plaats van alleen beheerders, en het is vanaf die datum verplicht. 31 maart 2025.
• Eis 8.4.3MFA is vereist voor alle externe netwerktoegang afkomstig van buiten het netwerk van de entiteit die toegang kan krijgen tot of invloed kan hebben op de CDE, zowel voor personeel als voor externe toegang door derden of leveranciers. Deze vereiste bestond al vóór versie 4.0 en is verduidelijkt in plaats van nieuw geïntroduceerd.

Vereiste 8.5.1 werkt samen met 8.4.2 en is eveneens verplicht sinds 31 maart 2025: deze vereist dat MFA-systemen zodanig worden geïmplementeerd dat ze niet kunnen worden omzeild, behalve via een gedocumenteerde, risicobeoordeelde uitzonderingsprocedure, dat er ten minste twee onafhankelijke authenticatiefactoren worden gebruikt, dat alle factoren moeten slagen voordat toegang wordt verleend, en dat de implementatie bestand is tegen replay-aanvallen. Een MFA-implementatie die technisch gezien om een ​​tweede factor vraagt, maar een omzeiling toestaat met de optie "onthoud dit apparaat gedurende 30 dagen" zonder compenserende controle, voldoet niet aan 8.5.1.

Voor de meeste organisaties komt het er in de praktijk op neer dat MFA wordt uitgebreid van de beheerdersgroep die al onder paragraaf 8.4.1 viel naar elke applicatiegebruiker, aannemer en integratie van derden die met de CDE te maken heeft, en dat vervolgens de anti-bypass-maatregelen worden gedocumenteerd waar een beoordelaar specifiek bewijs van zal willen zien.

Wat is de route naar PCI DSS-conformiteit en -certificering?

Het behalen van PCI DSS-conformiteit volgt een consistente volgorde, ongeacht het type handelaar, hoewel de diepte van de validatie in elke fase verschilt. Hier volgt het traject, stap voor stap:

1. Bevestig uw CDE-bereik. Breng elk systeem, proces en netwerksegment in kaart dat kaartgegevens opslaat, verwerkt of verzendt, of dat de beveiliging ervan kan beïnvloeden. Netwerksegmentatie is de meest effectieve manier om deze reikwijdte te verkleinen en de beoordelingskosten te verlagen.
2. Bepaal uw merchantniveau en identificeer het juiste validatiepad. Het transactievolume bepaalt of u een zelfbeoordelingsvragenlijst moet invullen of dat een door een QSA uitgevoerde beoordeling op locatie vereist is, en welk type zelfbeoordelingsvragenlijst van toepassing is. Zie de tabel met nalevingsniveaus hieronder.
3. Voer een gap-analyse uit ten opzichte van alle 12 vereisten. Test de huidige beveiligingsmaatregelen, met name encryptie, tokenisatie, TLS-configuratie, MFA-dekking en sleutelbeheer, aan de hand van de daadwerkelijke eisen van PCI DSS, en niet alleen aan de hand van wat "veilig aanvoelt".
4. De geconstateerde tekortkomingen verhelpen. Dicht eerst de cryptografische lacunes (niet-versleutelde opgeslagen PAN, verouderde TLS-versies, ontbrekende MFA bij CDE-toegang), aangezien dit de ernstigste bevindingen zijn in de meeste beoordelingen, en pak vervolgens de lacunes in logging, toegangscontrole en documentatie aan.
5. Volledige formele validatie: SAQ- of QSA-beoordeling. Winkels met een lager verkoopvolume vullen de toepasselijke SAQ in; Level 1-winkeliers en de meeste dienstverleners ondergaan een QSA-beoordeling op locatie, die resulteert in een nalevingsrapport (Report on Compliance, ROC).
6. Dien de Verklaring van Naleving (AOC) in. De ondertekende AOC, ondersteund door de SAQ of ROC, wordt naar uw acquirerende bank en, indien vereist, naar de kaartmerken gestuurd als officieel bewijs van uw nalevingsstatus.
7. Zorg voor continue naleving van de regels. Driemaandelijkse ASV-kwetsbaarheidsscans, jaarlijkse penetratietests, continue logboekcontrole en een jaarlijkse evaluatie van de reikwijdte (vereiste 12.5.2) zorgen ervoor dat de controles niet ongemerkt niet meer aan de voorschriften voldoen tussen formele beoordelingen door.

Die laatste stap is de stap waarin organisaties het vaakst te weinig investeren. Een ROC of AOC is een momentopname. PCI DSS-compliance is een discipline die het hele jaar door wordt toegepast, geen jaarlijkse gebeurtenis.

Welk nalevingsniveau en welk type SAQ zijn van toepassing op uw bedrijf?

PCI DSS categoriseert winkeliers in vier niveaus op basis van het jaarlijkse transactievolume met betaalkaarten. Het niveau bepaalt hoe u de naleving valideert, niet of de 12 vereisten van toepassing zijn. Elke winkelier die betaalkaartgegevens verwerkt, moet aan alle 12 vereisten voldoen, ongeacht het niveau.

Niveau	Jaarlijks transactievolume	Validatie vereist	typische voorbeelden
Niveau 1	Meer dan 6 miljoen	Jaarlijkse QSA/ISA-audit op locatie, ROC, driemaandelijkse ASV-scans, jaarlijkse penetratietest, AOC	Grote e-commerceplatforms, grote detailhandelaren, betalingsverwerkers
Niveau 2	1 tot 6 miljoen	Jaarlijkse SAQ (of QSA-audit indien vereist door de overnemende partij), driemaandelijkse ASV-scans, jaarlijkse penetratietest, AOC	Middelgrote winkelketens, regionale dienstverleners
Niveau 3	20,000 tot 1 miljoen (e-commerce)	Jaarlijkse SAQ, driemaandelijkse ASV-scans, AOC	Groeiende e-commercebedrijven, niche-abonnementsdiensten
Niveau 4	Minder dan 20,000 (e-commerce) of tot 1 miljoen (alle kanalen)	SAQ aanbevolen of vereist door de opdrachtgever, scans indien van toepassing, AOC	Lokale winkeliers, kleine cafés, kleine websites

Binnen de niveaus 2 tot en met 4 hangt het specifieke SAQ-type af van hoe de handelaar kaartgegevens accepteert en verwerkt, en niet alleen van het transactievolume:

• SAQ A: voor handelaars die de verwerking van kaartgegevens volledig uitbesteden aan een PCI DSS-gecertificeerde derde partij, zoals een e-commercewebsite die doorverwijst naar een externe betaalpagina.
• SAQ B: voor winkeliers die gebruikmaken van losstaande, uitgaande betaalterminals die geen kaartgegevens van de kaarthouder elektronisch opslaan.
• SAQ C: voor winkeliers die gebruikmaken van internetgekoppelde betaalapplicaties, zonder elektronische opslag van kaartgegevens.
• SAQ DVoor handelaars en dienstverleners die kaartgegevens van kaarthouders opslaan, verwerken of verzenden buiten de bovengenoemde, meer specifieke scenario's; dit is de meest uitgebreide SAQ en dekt alle 12 vereisten.

Hoe vertalen de 12 vereisten zich naar praktische beheersmaatregelen?

De onderstaande tabel koppelt elke vereiste aan het beheersgebied waarop deze betrekking heeft en een representatieve implementatie. Deze tabel is nuttig als checklist bij het opstellen van een herstelplan.

eis	Controle gebied	Representatieve implementatie
1	Netwerkbeveiligingscontroles	Firewalls, netwerksegmentatie die de CDE isoleert
2	Veilige configuratie	Versterkte basislijnen, geen standaard inloggegevens van de leverancier.
3	Bescherm opgeslagen accountgegevens	AES-256-encryptie of -tokenisatie, HSM-ondersteunde sleutels
4	Versleutel gegevens tijdens de overdracht	Minimaal TLS 1.2, bij voorkeur TLS 1.3, geen SSL/vroege TLS.
5	Anti-malware	Endpointbeveiliging met actieve monitoring
6	Veilige ontwikkeling en patching	Wijzigingsbeheer, gedefinieerde patch-SLA's, veilige SDLC
7	Toegangscontrole (noodzakelijke informatie)	Toegang op basis van rollen met minimale privileges
8	Identificatie en authenticatie	Unieke ID's, MFA voor alle CDE-toegang (8.4.2/8.5.1)
9	Fysieke bewaking	Gecontroleerde toegang tot de faciliteit en de media
10	Logboekregistratie en monitoring	Gecentraliseerde audit trails, regelmatige logboekcontrole
11	Beveiligingstests	Driemaandelijkse ASV-scans, jaarlijkse penetratietests
12	Veiligheidsbeleid en -bestuur	Gedocumenteerd beleid, incidentresponsplan, jaarlijkse evaluatie van de reikwijdte

Een korte geschiedenis van PCI DSS

PCI DSS is ontstaan ​​door de opkomst van e-commercefraude eind jaren negentig. CyberSource meldde dat de winst uit online fraude tegen het einde van dat decennium $1.5 miljard bedroeg, en Visa en Mastercard rapporteerden gezamenlijke verliezen van meer dan $750 miljoen als gevolg van online diefstal tussen 1988 en 1999. Visa reageerde als eerste met het Cardholder Information Security Program (CISP) begin jaren 2000, maar concurrerende, soms tegenstrijdige merkspecifieke programma's maakten de naleving verwarrend voor winkeliers. De grote betaalmerken bundelden hun krachten en lanceerden PCI DSS versie 1.0 op 15 december 2004.

• PCI DSS v2.0 (oktober 2010): verduidelijkte implementatierichtlijnen en verminderde onduidelijkheid over inconsistente implementaties bij verschillende verkopers.
• PCI DSS v3.0 (november 2013): verscherpt beveiligingsbeheer en strengere wachtwoordvereisten als reactie op geavanceerdere hacktechnieken.
• PCI DSS v4.0 (maart 2022): introduceerde uitgebreidere vereisten voor multifactorauthenticatie, aangepaste implementatieopties en sterkere bescherming tegen e-commerce en phishing.
• PCI DSS v4.0.1 (juni 2024)Een beperkte herziening die de opmaak corrigeert en de bedoeling van bestaande vereisten verduidelijkt, zonder nieuwe of verwijderde vereisten. Het werd de enige actieve versie nadat versie 4.0 op 31 december 2024 buiten gebruik werd gesteld en blijft de huidige standaard vanaf deze update.

De PCI SSC heeft bevestigd dat een toekomstige versie, PCI DSS v5.0 , zich in een vroeg planningsstadium bevindt (vanaf 2026), maar er is nog geen publicatiedatum vastgesteld. Rapporten uit de eigen assessorengemeenschap van de Raad geven aan dat dit minstens nog een jaar zal duren. Organisaties dienen v4.0.1 als de geldende standaard te beschouwen en te wachten op een officieel concept voordat ze architectuurwijzigingen doorvoeren in afwachting van v5.0.

Beperkingen

PCI DSS-conformiteit is noodzakelijk, maar niet voldoende voor de veiligheid van betalingen, en het is belangrijk om duidelijk te zijn over wat het níét garandeert:

• Conformiteit is niet hetzelfde als veiligheid. Een ROC of AOC weerspiegelt de controles op het moment van de beoordeling. Organisaties zijn kort na het behalen van een beoordeling overtreden doordat een configuratie afweek of een nieuw systeem aan de CDE werd toegevoegd zonder dat dit binnen de scope viel.
• De nauwkeurigheid van de scope hangt af van de validatie van de segmentatie, niet alleen van de bewering ervan. Een onbewezen aanname dat een netwerksegment geïsoleerd is van de CDE (Cardholder Data Environment) is een van de meest voorkomende oorzaken van datalekken met betaalkaartgegevens bij organisaties die verder aan alle regelgeving voldoen.
• Compensatiemaatregelen vereisen nauwkeurigheid, geen gemak. PCI DSS staat compenserende maatregelen toe wanneer niet exact aan een vereiste kan worden voldaan zoals deze is beschreven, maar voor elke maatregel is een gedocumenteerde risicoanalyse en goedkeuring door een QSA vereist; bij een onzorgvuldig gebruik worden ze een manier om het onderliggende probleem niet op te lossen.
• De standaard is versiespecifiek en wordt voortdurend ontwikkeld. De richtlijnen in dit artikel zijn gebaseerd op PCI DSS v4.0.1 zoals die gold in augustus 2026. Een toekomstige versie 5.0 kan specifieke vereisten, tijdlijnen of drempelwaarden wijzigen. Organisaties dienen de richtlijnen te vergelijken met de actuele gepubliceerde standaard voordat zij beslissingen nemen over naleving.
• De interpretatie van QSA kan variëren. Twee beoordelaars kunnen redelijkerwijs tot verschillende conclusies komen over grensgevallen in de scope of over compenserende beheersmaatregelen; door uw QSA vroegtijdig bij een architectuurbeslissing te betrekken, voorkomt u herwerk achteraf.

Wat zou Encryption Consulting aanbevelen?

Na het uitvoeren van PCI DSS-nalevingsbeoordelingen voor organisaties, van regionale winkeliers tot nationale banken, zijn wij van mening dat de meeste PCI DSS-programma's niet falen omdat er een controle ontbreekt, maar omdat de cryptografische en sleutelbeheerlaag er achteraf aan is toegevoegd in plaats van dat deze is ontworpen volgens een vast principe. Hieronder leggen we uit wat we in de praktijk zouden doen, in de aangegeven volgorde.

Begin met een echte cryptografische inventaris, niet met een aanname. Je kunt niet beschermen wat je niet kunt zien. Voordat je een keuze maakt tussen encryptie en tokenisatie, of voordat je TLS-configuraties controleert, stel je een nauwkeurige inventaris samen van elke cipher suite, elk protocol, elk certificaat en elke sleutel in je CDE. Dit overlapt direct met de cryptografische materiaallijst (CBOM) van vereiste 12.3.3 , die we in een aparte, diepgaande analyse behandelen als die specifieke vereiste je onmiddellijke prioriteit heeft.

Centraliseer het beheer van de levenscyclus van sleutels en certificaten. We implementeren CertSecure Manager om organisaties te voorzien van afgedwongen rotatieschema's, verantwoordingsplicht voor de beheerder en gecentraliseerd inzicht in elke sleutel en elk certificaat binnen het toepassingsgebied. Dit pakt direct de bevindingen van vereiste 3.6/3.7 aan die het vaakst naar voren komen bij mislukte beoordelingen. Voor de hoofdsleutels die tokenisatiekluizen of bulkversleuteling beschermen, adviseren we doorgaans FIPS 140-3 gevalideerde opslag via on-premises HSM's of HSM-as-a-Service , afhankelijk van de operationele volwassenheid en de bestaande infrastructuur van de organisatie.

Breid MFA doelbewust uit, niet alleen technisch. Voldoen aan de letter van vereiste 8.4.2 is eenvoudig; voldoen aan de anti-omzeilingsintentie van vereiste 8.5.1 vereist meer discipline. We werken samen met klanten om elke legitieme MFA-uitzondering te documenteren, deze te koppelen aan een compenserende maatregel en de informele omzeilingen die zich in de loop der tijd ophopen, te verwijderen.

Beschouw compliance als een continu proces, niet als een jaarlijks terugkerend proces. Onze compliance-adviesdiensten combineren PCI DSS-werk met het bredere regelgevingslandschap waarmee veel van onze klanten te maken hebben, waaronder DORA, NIS2 en NIST CSF. Hierdoor zijn cryptografische controles die voor PCI DSS zijn ontwikkeld, ontworpen om te voldoen aan overlappende vereisten in plaats van voor elk afzonderlijk te worden herbouwd.

Als u zich nog in een vroeg stadium van dit proces bevindt, is de meest effectieve eerste stap doorgaans een analyse van de tekortkomingen ten opzichte van vereisten 3, 4 en 8, aangezien de kosten van fouten op die punten het hoogst zijn en de kosten van latere correcties het grootst. Neem contact met ons op om een ​​eerste analyse te bespreken.

Conclusie

PCI DSS-naleving is een continu proces van engineering en governance, gebaseerd op 12 vereisten. De cryptografische controles in vereisten 3, 4 en 8 vormen de kern van het werkelijke risico en de meeste inspanningen. De juiste keuze maken tussen encryptie en tokenisatie, TLS 1.2 of hoger overal afdwingen waar kaartgegevens worden verwerkt, MFA uitbreiden naar elke CDE-gebruiker volgens vereiste 8.4.2 en een gedisciplineerde sleutelbeheercyclus hanteren volgens vereisten 3.6 en 3.7, helpt een organisatie bij het grootste deel van de tests die een QSA uitvoert.

Niets daarvan vervangt het doorlopende werk: driemaandelijkse scans, jaarlijkse penetratietests, jaarlijkse bevestiging van de reikwijdte en de gewoonte om compliance als een doorlopende houding te beschouwen in plaats van een jaarlijkse gebeurtenis. Als u een tweede paar ogen wilt laten kijken naar de daadwerkelijke positie van uw organisatie ten opzichte van PCI DSS v4.0.1, kunnen onze adviesdiensten op het gebied van encryptie u helpen de lacune in kaart te brengen, prioriteiten te stellen voor herstelmaatregelen en een programma op te bouwen dat bestand is tegen beoordelingen en aanvallen.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen een SAQ en een ROC? Een SAQ (Self-Assessment Questionnaire) is een zelfrapportage-instrument dat de meeste bedrijven onder niveau 1 gebruiken om hun naleving te bevestigen zonder een audit op locatie. Een ROC (Report on Compliance) is het gedetailleerde rapport dat een Qualified Security Assessor opstelt na een formele beoordeling op locatie. Dit rapport is vereist voor bedrijven op niveau 1 en de meeste dienstverleners. Beide documenten ondersteunen uiteindelijk hetzelfde document, de Attestation of Compliance (AOC), dat wordt ingediend bij de acquirerende bank.

Is PCI DSS een wettelijke verplichting of een contractuele verplichting? PCI DSS is geen overheidswetgeving; het is een contractuele verplichting die wordt afgedwongen via de overeenkomst tussen een bedrijf en de bank waarmee het betalingen verwerkt, en die wordt ondersteund door de kaartmerken. Niet-naleving kan nog steeds leiden tot boetes, hogere transactiekosten en, na een overtreding, aansprakelijkheid voor fraudeverliezen. De praktische gevolgen zijn dus vergelijkbaar met een wettelijke verplichting, ook al is de standaard zelf door de sector opgelegd.

Valt het versleutelen van kaartgegevens buiten het toepassingsgebied van PCI DSS? Niet op zichzelf. Een systeem dat versleutelde PAN-gegevens opslaat, valt over het algemeen nog steeds onder de PCI DSS-regelgeving, omdat het nog steeds rekeninggegevens opslaat, zij het in beveiligde vorm. Tokenisatie, waarbij het echte PAN-nummer volledig wordt vervangen en alleen in een aparte kluis wordt opgeslagen, zorgt er doorgaans voor dat een systeem buiten het toepassingsgebied valt, mits het token zelf niet kan worden teruggezet naar het PAN-nummer zonder de kluis.

Hoe vaak moeten penetratietests en kwetsbaarheidsscans worden uitgevoerd? PCI DSS vereist driemaandelijkse externe kwetsbaarheidsscans door een erkende scanleverancier (Approved Scanning Vendor, ASV) en, voor de meeste bedrijven boven de kleinste, een jaarlijkse penetratietest die zowel de netwerk- als de applicatielaag omvat. Aanvullende scans zijn vereist na elke significante wijziging aan de CDE, zoals een nieuw systeem, een netwerkwijziging of een grote applicatie-update.

Wat gebeurt er als mijn organisatie na een datalek niet aan de regels voldoet? De gevolgen zijn doorgaans boetes die door de kaartmaatschappijen via de acquirerende bank worden opgelegd, verplichte kosten voor forensisch onderzoek, aansprakelijkheid voor verliezen door frauduleuze transacties, hogere transactiekosten en, in ernstige of herhaalde gevallen, intrekking van de mogelijkheid om kaartbetalingen te verwerken. Het kunnen aantonen van naleving op het moment van het datalek, in plaats van achteraf, heeft een aanzienlijke invloed op de manier waarop deze gevolgen worden toegepast.

Referenties

• PCI DSS v4.0.1 standaarddocument, PCI Security Standards Council
• Zojuist gepubliceerd: PCI DSS v4.0.1, PCI SSC-blog
• Nu is het moment om de toekomstgerichte vereisten van PCI DSS v4.x te implementeren, aldus de PCI SSC-blog.
• Migreren van SSL en vroege TLS, PCI SSC-informatiesupplement
• Definieert PCI DSS welke versies van TLS moeten worden gebruikt? (Veelgestelde vragen over PCI DSS)
• PCI SSC-documentenbibliotheek