PCI DSS.
Betaalgegevens en afhankelijkheden afbakenen, operationele verantwoordelijkheid bepalen en het passende bewijs met de bevoegde instantie afspreken.
- PCI DSS v4.0.1 · PCI SSC
- Door Jonathan Bezdek
- Stand: 22-10-2026
- Leestijd: 7 min.
Kort antwoord.
PCI DSS is de sectorstandaard voor bescherming van betaalkaartgegevens. De standaard betreft handelaren, dienstverleners en systemen die zulke gegevens verwerken of de beveiliging ervan beïnvloeden. De actuele versie is PCI DSS v4.0.1. Betaalomgeving en rol bepalen de scope; het validatietraject wordt afgestemd met acquirer of betaalkaartmerk, bijvoorbeeld via SAQ of ROC.
PCI DSS 4.0 en de actuele versie.
PCI DSS verbindt technische en operationele beveiligingseisen voor betaalgegevens. De PCI Security Standards Council, kortweg PCI SSC, ontwikkelt de standaard en ondersteunende hulpmiddelen. Hoe naleving in een concreet betaalprogramma wordt aangetoond, bepalen daarentegen de bevoegde accepterende instanties, doorgaans acquirers en betaalkaartmerken; PCI SSC FAQ 1473 licht dit onderscheid in rollen toe.
PCI DSS v4.0.1 is de versie die in de officiële Document Library staat. Volgens de PCI SSC-publicatie over de herziening is v4.0 op 31 december 2024 ingetrokken. De reeds voor de nieuwe v4-eisen vastgestelde datum van 31 maart 2025 bleef ongewijzigd. Op de peildatum van deze pagina ligt deze datum in het verleden; het is geen nog komende invoeringstermijn.
Een succesvol afgeronde validatie vervangt doorlopende bescherming niet. Voor de praktische organisatie moeten wijzigingen in betaalroutes, applicaties en dienstverleners aanleiding zijn om de afgesproken scope opnieuw te bekijken. Een nieuwe checkoutintegratie kan andere afhankelijkheden creëren dan de eerder beoordeelde oplossing, hoewel dezelfde onderneming betalingen blijft accepteren.
Voor wie PCI DSS geldt.
Volgens het PCI SSC-overzicht richt PCI DSS zich op meer dan organisaties die kaartgegevens opslaan, verwerken of doorgeven. Ook mogelijke invloed op de beveiliging van de kaarthoudergegevensomgeving, de Cardholder Data Environment of CDE, hoort bij de beoordeling. Handelaren en dienstverleners moeten daarom eerst hun concrete rol en daadwerkelijk geleverde diensten beschrijven.
Uitbestede betalingsverwerking is geen automatische vrijstelling. PCI SSC FAQ 1092 onderscheidt een mogelijk kleinere directe eisenscope van de blijvende verantwoordelijkheid voor geschikte dienstverleners, afgesproken verantwoordelijkheden en het vereiste bewijs. Bepaal ook bij hosted checkout met uw bevoegde instantie aan welke voorwaarden de gekozen technische integratie moet voldoen.
De grens wordt onderbouwd door doeltreffende maatregelen, meer dan alleen door een naam in een architectuurdiagram. PCI SSC FAQ 1115 licht toe dat verbonden systemen en de feitelijke werking van segmentatie moeten worden getoetst. Wie beheertoegang, ondersteunende diensten of interfaces voortijdig uitsluit, kan een onvolledige onderzoeksscope beschrijven.
De PCI DSS-eisen ordenen in de bedrijfsvoering.
De implementatie verbindt bescherming van de betaalomgeving met navolgbare operationele procedures. De volgende zes werkgebieden bieden redactionele oriëntatie voor planning, geen weergave van de twaalf officiële eisen of afzonderlijke toetspunten; hun concrete toepasselijkheid wordt aan de bevestigde scope getoetst.
Betaalstromen en scope begrijpelijk maken.
Volg praktisch waar betaalinformatie ontstaat, welke componenten betrokken zijn en welke personen of aanbieders daarop invloed kunnen uitoefenen. Leg de bevestigde grens samen met de aannames vast. Een begrijpelijke beschrijving helpt ontwikkeling, beheer en de accepterende instantie over dezelfde betaalroute te spreken.
Systemen en wijzigingen veilig beheren.
Wijs duidelijke verantwoordelijken toe aan de betrokken applicaties en infrastructuurcomponenten. Verbind wijzigingen met de vraag of nieuwe verbindingen, functies of afhankelijkheden de bevestigde scope veranderen. Voor de dagelijkse praktijk is een navolgbaar wijzigingsverloop nuttiger dan een momentopname die uitsluitend voor het onderzoek is samengesteld.
Gegevensgebruik en overdracht beperken.
Toets als praktisch uitgangspunt welke betaalgegevens voor de gekozen procedure daadwerkelijk nodig zijn en waar kopieën kunnen ontstaan. Neem daarbij exports, logs en ondersteunende processen mee. De verdere beveiligingsplanning moet aansluiten op gegevenssoorten en gebruiksdoel; een algemene vertrouwelijkheidsmarkering verklaart die beslissingen nog niet.
Toegang navolgbaar organiseren.
Verbind inhoudelijke verantwoordelijkheden met de daadwerkelijk verleende technische mogelijkheden. Bekijk naast medewerkers ook serviceaccounts, beheertoegang en leveranciers. Voor de werkorganisatie is een duidelijk antwoord aan te raden op wie toegang goedkeurt, wie wijzigingen behandelt en waaraan tijdig ingetrokken toegang herkenbaar is.
Bedrijfsvoering toetsen en inzichten behandelen.
Plan passende registraties en onderzoeken samen met de verantwoordelijken van de betaalomgeving. Eén scan of penetratietest beschrijft alleen het betreffende onderzoeksobject. Leg bij bevindingen vast welke wijziging daaruit volgt en hoe het effect wordt getoetst, in plaats van een testresultaat gelijk te stellen aan de volledige PCI DSS-validatie.
Dienstverleners en incidenten betrekken.
Leg operationele contactpersonen en de procedure bij afwijkingen vast. Bij uitbestede diensten moeten de eigen taken naast de toezeggingen van de aanbieder begrijpelijk blijven. PCI SSC FAQ 1576 legt uit dat dienstverlenersbewijs de gebruikte diensten moet dekken; een willekeurig ondernemingsdocument volstaat daarvoor niet automatisch.
PCI DSS als doorlopende taak implementeren.
Rol en validatietraject afstemmen.
Bepaal als praktische eerste stap met acquirer of betaalkaartmerk uw rol, het verwachte bewijs en de bevoegde contactpersoon voordat u een formulier kiest.
Een betaalroute in kaart brengen.
Beschrijf de betrokken gegevens, applicaties, systemen en dienstverleners vanaf het begin van de betaling tot de resterende operationele registraties.
De scope bevestigen.
Toets de relevante verbindingen en componenten die de beveiliging beïnvloeden en laat de afbakening, inclusief mogelijke segmentatie, deskundig beoordelen.
Taken in de bedrijfsvoering verankeren.
Wijs beschermingsmaatregelen en gedeelde verantwoordelijkheden toe aan concrete personen en verbind hun uitvoering met passende registraties.
Bewijsmateriaal consistent voorbereiden.
Toets of de vereiste documenten dezelfde dienst, rol en scope beschrijven en of openstaande beslissingen navolgbaar zijn behandeld.
Wijzigingen en vervolgonderzoeken volgen.
Spreek de vereiste validatie-intervallen af en toets bij veranderingen of scope, dienstverlenersbewijs en operationele verantwoordelijkheden nog passen.
PCI-certificering en de werkelijke bewijsvorm.
Erkende PCI DSS-validatie gebruikt de daarvoor bestemde officiële documenten. Een SAQ documenteert een toegestane zelfbeoordeling, een ROC de resultaten van het bijbehorende onderzoekstraject en een AOC de bijbehorende bevestiging. Volgens PCI SSC FAQ 1220 zijn willekeurige documenten die compliancecertificaat worden genoemd geen vervanging voor de officiële sjablonen.
De accepterende instantie bepaalt het vereiste traject; bij een bijbehorend onderzoek kan een Qualified Security Assessor, kortweg QSA, betrokken zijn. Volgens PCI SSC FAQ 1473 moeten scope en toepasselijkheid correct worden beoordeeld. Het kiezen van een SAQ-naam bevestigt daarom nog niet dat aan de geschiktheidscriteria is voldaan of alle relevante eisen zijn geïmplementeerd.
Ook het passende sjabloon moet in de actuele versie worden gebruikt. PCI SSC heeft de SAQ A-regels per 31 maart 2025 gewijzigd en expliciet verduidelijkt dat vervallen afzonderlijke toetspunten in de vragenlijst de onderliggende PCI DSS-eisen niet opheffen. Spreek validatiemomenten en vervolgverplichtingen voor uw geval af, in plaats van uit te gaan van een algemene certificaatlooptijd.
Andere frameworks duiden.
ISO 27001 behandelt informatiebeveiligingsmanagement binnen de vastgestelde scope; PCI DSS-validatie is een afzonderlijke beslissing voor de betaalomgeving. CIS Controls ondersteunen algemene prioritering van beveiligingswerk, maar leggen geen PCI-validatietraject vast. De AVG betreft verwerking van persoonsgegevens en moet onafhankelijk van het betaalgegevensbewijs worden getoetst.
In Secani.
Secani biedt een eigen redactionele ondernemingscatalogus voor PCI DSS v4.0.1. Het profiel legt onder meer CDE-scope, handelaars- of dienstverlenersrol en het afgesproken SAQ-/ROC-traject vast. Deze werkgegevens ondersteunen gestructureerde behandeling; ze vervangen noch de officiële onderzoeksdocumenten, noch de bevestiging van geschiktheid of het oordeel van de bevoegde instantie.
Begin met een concrete betaalroute.
Kies een daadwerkelijk gebruikte betaalroute en benoem de inhoudelijke en technische verantwoordelijkheid. Leg vast welke diensten u zelf levert en welke een dienstverlener overneemt. Stem daarna het verwachte bewijs af met de bevoegde instantie voordat u de inspanning plant op basis van een ogenschijnlijk passende vragenlijst.
Bronnen.
- PCI SSC – PCI DSS-overzicht en doelgroep
- PCI SSC – officiële Document Library
- PCI SSC – publicatie van PCI DSS v4.0.1
- PCI SSC FAQ 1473 – bevoegde instanties en validatietraject
- PCI SSC FAQ 1092 – uitbestede betalingsverwerking
- PCI SSC FAQ 1576 – bewijs van dienstverleners
- PCI SSC FAQ 1220 – officiële documenten in plaats van compliancecertificaten
- PCI SSC FAQ 1115 – verbonden systemen en segmentatie
- PCI SSC – wijzigingen in SAQ A per 31 maart 2025
- PCI SSC – SAQ-bulletin van 15 oktober 2024
Veelgestelde vragen.
Nee, niet automatisch. Uitbesteding kan de directe scope veranderen; verantwoordelijkheid voor geschikte dienstverleners, duidelijke verantwoordelijkheden en het vereiste bewijs moet afzonderlijk worden bekeken.
Niet alleen op basis van de gewenste inspanning. Er moet aan de geschiktheidscriteria worden voldaan en het vereiste validatietraject moet worden afgestemd met de accepterende instantie.
Willekeurige compliancecertificaten zijn geen erkende vervanging voor de officiële documenten. Het afgesproken onderzoekstraject en de bijbehorende officiële rapporten of verklaringen zijn bepalend.
Nee. Een ISMS-certificaat betreft de vermelde managementsysteemscope; de eisen en het validatietraject voor de betaalomgeving moeten afzonderlijk worden bepaald.
De betaalroute afbakenen.
Bespreek hoe u scope, taken en bewijsmateriaal in Secani kunt behandelen.
Deze pagina duidt PCI DSS in eigen woorden en vervangt de officiële PCI SSC-documenten of een deskundig onderzoek niet. Eisen van het betreffende betaalprogramma en beslissingen van de bevoegde instantie blijven afzonderlijk van belang.