PCI DSS 6.4.3 vraagt drie dingen op elke betaalpagina: een inventaris van elk script, een bevestiging dat elk ervan geautoriseerd is, en assurance dat de integriteit van elk script behouden blijft. De inventaris en het autorisatierecord zijn waar de meeste teams vastlopen. Dit bericht gaat alleen over die twee artefacten — hoe je ze bouwt, welke velden elk record bevat, en hoe je voorkomt dat ze een week na de audit alweer verouderd zijn.
De control werd verplicht op 2025-03-31. Een spreadsheet-snapshot die één keer is genomen en vergeten, voldoet niet, omdat wat gecontroleerd wordt — third-party-JavaScript — op zijn eigen schema wijzigt. Een schone inventaris is een levend record met een owner, een rechtvaardiging en een versiegeschiedenis per script. Krijg de record-structuur eerst goed; de tooling-beslissing volgt daaruit.
Voor de requirement-tekst zelf, het buy-vs-build-debat, en wat auditors end-to-end zoeken, lees de praktische PCI 6.4.3- en 11.6.1-gids en de QSA-assessment-gids. Deze pagina blijft eng gericht op de inventaris-mechaniek.
Welke scope moet de inventaris dekken?
Het PCI SSC scopt 6.4.3 tot de scripts die geladen en geëxecuteerd worden in de browser van de consument op de betaalpagina — zowel scripts uit de eigen omgeving van de entiteit als scripts die geladen worden van derden en vierden. Lees die scope letterlijk voordat je begint met opsommen. Je inventaris moet vastleggen:
- First-party / same-origin scripts — je eigen bundles, geserveerd vanaf je domein.
- Inline scripts — snippets in het HTML-template geplakt, inclusief tag-manager-bootstraps.
- Third-party scripts — analytics, A/B-testen, support-widgets, fraude-SDK's, betaal-helpers.
- Fourth-party scripts — alles wat een third-party-script laadt nadat het draait. Deze verschijnen nooit in een vendor-contract of een tag-manager.
De fourth-party-laag is degene die teams missen. Eén analytics-tag kan een keten van extra scripts op runtime meetrekken die niemand direct goedkeurde. Als je inventaris start bij een vendor-lijst of een tag-manager-export, is die keten onzichtbaar. Begin bij wat de browser daadwerkelijk ontvangt op de live betaalpagina.
Welke velden heeft elke inventarisrij nodig?
Een inventarisrij is bewijs. Hij moet "wat is dit, waar komt het vandaan, en is het hetzelfde als vorige week" beantwoorden zonder dat iemand mid-audit devtools opent. De minimaal bruikbare kolommen:
| Veld | Wat het registreert | Waarom een QSA het wil |
|---|---|---|
| Script-URL / source | Volledige URL, of inline voor ingebedde code | Identificeert de asset en het origin-domein |
| Party-tier | First-, third- of fourth-party | Bewijst dat fourth-party-keten verantwoord zijn |
| Content-hash | Hash van de daadwerkelijk geserveerde payload | Ankert integrity-checks aan echte content, niet een bestandsnaam |
| First seen / last seen | Wanneer het verscheen, wanneer voor het laatst geobserveerd | Flagt scripts die verdwenen of verschenen zonder change-record |
| Owner | Genoemde accountable persoon | Traceert wie het script kan rechtvaardigen |
| Business-justificatie | Waarom het nabij de betaalpagina draait | Voldoet aan de "written justification"-clausule |
| Data-access-notitie | Wat het script op de pagina kan lezen | Brengt alles wat formuliervelden aanraakt aan de oppervlakte |
| Autorisatiestatus | Authorized / pending / rejected | De 6.4.3-autorisatiebevestiging zelf |
| Versiegeschiedenis | Eerdere hashes met timestamps | Toont dat het record onderhouden wordt, geen snapshot |
De twee kolommen die echt bewijs van een vinkje scheiden zijn content-hash en versiegeschiedenis. Een rij die alleen een URL opsomt bewijst dat het script bestaat. Een rij die de hash van de aan de browser geserveerde payload vastpint, en de eerdere hashes bewaart, bewijst dat je kunt vertellen wanneer dat script wijzigde — wat de brug is tussen de inventaris van 6.4.3 en de change-detectie van 11.6.1.
Hoe ziet één autorisatierecord eruit?
Autorisatie is geen kolom die je aanvinkt. Het is een beslissing die iemand nam en kan verdedigen. Een volledig record koppelt het script aan een persoon, een reden en een moment. Hier is één rij ingevuld als worked example:
| Veld | Waarde |
|---|---|
| Script-source | https://cdn.example-analytics.com/v3/tag.js |
| Party-tier | Third-party |
| Content-hash | sha256:8f2a…c91d (payload geserveerd 2026-06-15) |
| Owner | Priya N., Web Platform Lead |
| Business-justificatie | Funnel-analytics voor checkout-conversie-rapportage |
| Data-access-notitie | Leest pagina-URL en klik-events; geen toegang tot kaart-input-velden |
| Autorisatiestatus | Authorized — goedgekeurd 2026-06-15 |
| Versiegeschiedenis | sha256:8f2a…c91d (2026-06-15), sha256:4b07…aa12 (2026-05-02) |
Let op de data-access-notitie. Hij zegt niet alleen dat het script is toegestaan — hij stelt wat het script mag aanraken. Wanneer de volgende versie van die tag plotseling het kaart-input-veld begint te lezen, is de kloof tussen de notitie en het geobserveerde gedrag de alert. Een rechtvaardiging zonder gestelde grens kan niet geschonden worden, dus kan nooit iets triggeren.
Hoe voorkom je dat de inventaris veroudert?
De faalmodus is voorspelbaar. Een team bouwt een grondige inventaris voor de audit, slaagt, en binnen weken levert marketing een nieuwe tag, een vendor pusht een v3 van zijn SDK, en een fourth-party-dependency wisselt van domein. Niets daarvan landt in de spreadsheet. De inventaris is nu fictie, en de volgende assessment legt dat bloot.
Een onderhoudbare inventaris volgt een loop, geen eenmalige build:
- Seed vanuit live captures. Inventariseer wat de browser ontvangt op de productie-betaalpagina, niet een vendor-lijst of een tag-manager-export.
- Verminder oppervlak. Verwijder scripts die niet op de betaalpagina hoeven te draaien. Minder geautoriseerde scripts betekent minder records eerlijk te houden.
- Autoriseer vóór blootstelling. Ken een owner toe, schrijf de rechtvaardiging en data-access-grens, en zet de status voordat het script naar het betaalpad shipt.
- Herautoriseer bij wijziging. Wanneer de geserveerde payload van een script van hash wijzigt, dekt de eerdere autorisatie de nieuwe content niet meer. Behandel elke wijziging als een nieuwe goedkeuringsbeslissing.
- Plan een standing review. Draai een terugkerende review zodat de rechtvaardigingstekst accuraat blijft naarmate scripts evolueren, en zodat niets voor onbepaalde tijd in
pendingzit.
Stap vier is waar handmatige processen instorten. Een moderne third-party-tag kan een andere payload serveren per gebruikerslocatie, browser of tijd van dag. Elke hashwijziging handmatig vangen over elk script op elke load is niet realistisch. Daarom moet de inventaris verbonden zijn met een detectiemechanisme in plaats van elke week door een mens te worden overgetypt.
Waar cside past in de inventaris-workflow
cside bouwt de inventaris vanuit de browserlaag — het registreert de scripts die de browsers van echte klanten daadwerkelijk ontvangen, inclusief inline- en fourth-party-loads die vendor-lijsten en tag-manager-exports nooit tonen. Elke entry bevat de source, de geserveerde payload, een content-hash en first-seen-/last-seen-timestamps, zodat de inventaris productie reflecteert in plaats van een verouderde snapshot.
Aan de autorisatie-kant slaat cside de owner, rechtvaardiging en data-access-context naast elk script op, en flagt wanneer de geserveerde content van een script wijzigt, zodat de eerdere autorisatie tegen de nieuwe payload kan worden herzien. Dat verandert 6.4.3 van een driemaandelijkse spreadsheet in een levend record met QSA-ready exports, en voedt het change-detection-bewijs dat 11.6.1 vereist. Zie cside PCI Shield voor de platformweergave.
Verder lezen op cside
- Hoe voldoe je aan PCI 6.4.3 en 11.6.1
- Waar QSAs op moeten letten in 6.4.3 en 11.6.1
- PCI DSS 4.0.1 client-side compliance-gids
- cside PCI Shield
Met ingang van 2026-06-18, behandel dit als operationele richtlijn, niet als juridisch advies. Bevestig de exacte control-tekst met je QSA, juridisch adviseur of risk-owner.
