Kort samengevat: referentie van de 12 PCI DSS 4.0.1-vereisten
- Voorbij de 12: PCI DSS kent 12 hoofdvereisten. Iedereen citeert dat getal en stopt. Het interessante feit is dat 4.0.1 nu meer dan 400 subvereisten telt, en de twee die de meesten falen zijn de nieuwste, waar niemand voor 2025 bewijs voor had.
- De twee meest gefaald: PCI DSS 4.0.1 werd verplicht in maart 2025. Vereisten 6.4.3 (scriptinventaris, zakelijke rechtvaardiging, integriteitsverificatie, wijzigingsdetectie) en 11.6.1 (HTTP-headermonitoring op betaalpagina's) zijn de twee minst voorbereide in huidige assessments. cside levert beide artefacten continu.
- Waar te beginnen: Scop je een 4.0.1-assessment zonder scriptinventaris of headermonitoring, begin daar dan voordat je Vereisten 3 of 12 aanraakt. Stroomt jouw 6.4.3- en 11.6.1-bewijs al, focus dan op scope creep-review en de MFA-uitrol onder 8.4.2.
Weinig tijd? Bekijk cside PCI Shield. Dit dekt alles hieronder in één deployment.
De 12 PCI DSS-vereisten vormen de kern van de Payment Card Industry Data Security Standard. Elke entiteit die kaartgegevens opslaat, verwerkt of verzendt moet eraan voldoen. Dit is de praktische referentie voor wat elke vereiste omvat in PCI DSS 4.0.1, wat er veranderde ten opzichte van 3.2.1 en waar de meeste omgevingen tekortschieten.
De structuur: 6 doelen, 12 vereisten
PCI DSS ordent zijn controls onder zes beveiligingsdoelen. Elk doel bevat een of meer van de 12 hoofdvereisten. Elke vereiste bevat meerdere subvereisten, en het totale aantal subvereisten in 4.0.1 ligt boven de 400.
Doel 1: Bouw en onderhoud een beveiligd netwerk en beveiligde systemen
Vereiste 1: Installeer en onderhoud netwerkbeveiligingscontrols. Firewalls, routerconfiguraties en netwerksegmentatie moeten de cardholder data environment isoleren van niet-vertrouwde netwerken. Elke regel heeft een gedocumenteerde zakelijke rechtvaardiging nodig.
Vereiste 2: Pas beveiligde configuraties toe op alle systeemcomponenten. Geen standaardwachtwoorden, geen standaardaccounts, geen onnodige services. Hardening-baselines moeten worden gedocumenteerd en op elk systeem worden toegepast.
Doel 2: Bescherm accountgegevens
Vereiste 3: Bescherm opgeslagen accountgegevens. Cardholder data moet in rust versleuteld zijn met sterke cryptografie. Gevoelige authenticatiegegevens (CVV, PIN, volledige track) mogen na autorisatie niet worden opgeslagen. Als je cardholder data niet hoeft op te slaan, doe het dan niet. De snelste weg naar naleving van vereiste 3 is de gegevens niet hebben.
Vereiste 4: Bescherm cardholder data met sterke cryptografie tijdens verzending. TLS 1.2 of hoger over publieke netwerken. Verouderde protocollen en zwakke ciphers moeten worden geïnventariseerd en verwijderd.
Doel 3: Onderhoud een programma voor kwetsbaarhedenbeheer
Vereiste 5: Bescherm alle systemen en netwerken tegen schadelijke software. Anti-malware-controls op alle systemen in de CDE. Regelmatige scans en updates van definities.
Vereiste 6: Ontwikkel en onderhoud beveiligde systemen en software. Patchbeheer, veilige codeerpraktijken, wijzigingsbeheer. Hier hoort vereiste 6.4.3 thuis: de inventaris en integriteitscontrole van client-side scripts die nieuw was in 4.0. Zie onze praktische gids voor het naleven van PCI 6.4.3 en 11.6.1 voor de specifieke implementatie.
Doel 4: Implementeer sterke maatregelen voor toegangsbeheer
Vereiste 7: Beperk toegang tot systeemcomponenten en cardholder data op basis van business need to know. Rolgebaseerde toegangscontrols, least privilege, gedocumenteerde toegangsgoedkeuring.
Vereiste 8: Identificeer gebruikers en authenticeer toegang tot systeemcomponenten. Unieke ID's voor elke gebruiker, strenge wachtwoordvereisten, MFA op alle administratieve toegang tot de CDE (aangescherpt in 4.0.1 onder 8.4.2).
Vereiste 9: Beperk fysieke toegang tot cardholder data. Fysieke controls op faciliteiten die cardholder data opslaan of CDE-systemen huisvesten.
Doel 5: Monitor en test netwerken regelmatig
Vereiste 10: Log en monitor alle toegang tot systeemcomponenten en cardholder data. Uitgebreide logging, logintegriteit, logbeoordeling en tijdsynchronisatie over systemen heen.
Vereiste 11: Test de beveiliging van systemen en netwerken regelmatig. Kwetsbaarheidsscans (intern en extern, elk kwartaal), penetratietests (jaarlijks + na significante wijzigingen) en, cruciaal voor 4.0.1, vereiste 11.6.1 over de monitoring van HTTP-headers op betaalpagina's.
Doel 6: Onderhoud een informatiebeveiligingsbeleid
Vereiste 12: Ondersteun informatiebeveiliging met organisatorisch beleid en programma's. Beveiligingsbeleid, risicobeoordeling, security-awarenesstraining, incidentrespons, leveranciersbeheer. Vereiste 12 is de raamwerkvereiste die elke andere control terugkoppelt aan een organisatorische toewijding.
Wat is nieuw in 4.0.1 ten opzichte van 3.2.1
PCI DSS 4.0.1 werd verplicht in maart 2025. De grootste veranderingen sinds 3.2.1:
| Wijziging | Vereiste | Impact |
|---|---|---|
| Scriptinventaris + integriteit op betaalpagina's | 6.4.3 | De meeste omgevingen hadden vóór 2025 geen dekking |
| Monitoring van HTTP-headers op betaalpagina's | 11.6.1 | Idem, nieuw bewijsstuk vereist |
| Wachtwoordregels aangescherpt | 8.3.6 | Minimaal 12 tekens |
| MFA op administratieve toegang tot de CDE | 8.4.2 | Geldt voor niet-console-beheer, niet alleen op afstand |
| Cryptografische inventaris | 12.3.3 | Documentatie van ciphers en protocollen |
| Logbewaring en -beoordeling | 10.7.2/3 | Uitgebreide vereisten voor logbeoordeling |
| Aangepaste aanpak | Meerdere | Nieuw alternatief voor de gedefinieerde aanpak van controls |
Met de aangepaste aanpak kunnen organisaties aan de bedoeling van een vereiste voldoen met een andere control dan de standaard voorschrijft, zolang ze de risicoanalyse en controls formeel documenteren. Dit is krachtig voor volwassen beveiligingsprogramma's en gevaarlijk voor organisaties die het gebruiken om zwakkere controls te rechtvaardigen.
Waar audits vastlopen
In het werk met merchants die 4.0.1-beoordelingen doorlopen, komen drie patronen steeds terug:
- Vereisten 6.4.3 en 11.6.1: geen scriptinventaris, geen integriteitsmonitoring, geen monitoring van HTTP-headers. Zie de QSA-gids voor waar auditors specifiek naar kijken.
- Scope creep: de CDE omvat meer systemen dan het oorspronkelijke scopediagram liet zien, meestal omdat de segmentatie zwakker is dan aangenomen
- Handmatig bewijs: QSA's hebben doorlopend bewijs nodig, geen screenshots die tijdens de beoordelingsweek zijn gemaakt
De volledige lijst met PCI DSS-vereisten
PCI DSS 4.0.1 is opgebouwd uit 6 doelen en 12 vereisten. De volledige lijst met PCI DSS-vereisten is:
- Installeer en onderhoud netwerkbeveiligingscontrols.
- Pas beveiligde configuraties toe op alle systeemcomponenten.
- Bescherm opgeslagen accountgegevens.
- Bescherm cardholder data met sterke cryptografie tijdens verzending over open, publieke netwerken.
- Bescherm alle systemen en netwerken tegen schadelijke software.
- Ontwikkel en onderhoud beveiligde systemen en software.
- Beperk toegang tot systeemcomponenten en cardholder data op basis van business need to know.
- Identificeer gebruikers en authenticeer toegang tot systeemcomponenten.
- Beperk fysieke toegang tot cardholder data.
- Log en monitor alle toegang tot systeemcomponenten en cardholder data.
- Test de beveiliging van systemen en netwerken regelmatig.
- Ondersteun informatiebeveiliging met organisatorisch beleid en programma's.
Vereisten 6.4.3 en 11.6.1, beide onder vereiste 6 en vereiste 11 hierboven, zijn waar client-side scriptbeveiliging thuishoort: 6.4.3 regelt de inventaris en autorisatie van scripts op betaalpagina's, en 11.6.1 vereist wijzigings- en manipulatiedetectie op die scripts en op kritieke HTTP-headers.
Waar cside past
Vereisten 6.4.3 en 11.6.1 zijn het thuisterrein van cside. Doorlopende scriptinventaris, tagging met zakelijke rechtvaardiging, integriteitsmonitoring, detectie van wijzigingen in HTTP-headers en een auditklare geschiedenis van meldingen komen uit het platform. De nalevingsgids voor PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 loopt door wat het dashboard oplevert en hoe een QSA het leest.
Voor het bredere beeld van de voorbereiding op een volledige beoordeling, zie de gids over het Report on Compliance en de SAQ D-gids.
