Governance voor browserextensies onder NIS2, DORA en GDPR

Maria, de CISO van een snelgroeiend fintechbedrijf, dacht dat de DORA-voorbeoordeling goed verliep. Haar team had het ICT-register voor derde partijen, de kritieke SaaS-contracten, de registraties van leveranciersdue diligence, de besluiten over risicoacceptatie en het rapportagepakket voor het bestuursorgaan voorbereid.

Toen stelde de auditor een vraag waarop niemand had gerekend.

“Kunt u ons uw governanceproces voor browserextensies laten zien?”

De vraag kwam voort uit een endpointbeoordeling met een financieel analist. Tijdens een schermdeling zag de auditor een productiviteitsextensie van een derde partij in de browser van de analist. Die leek onschuldig, maar een snelle zoekactie toonde aan dat de ontwikkelaar drie maanden eerder was getroffen door een compromittering van de toeleveringsketen. De gecompromitteerde extensie was gebruikt om sessietokens voor grote SaaS-platforms af te tappen.

Het fintechbedrijf had sterke beleidsregels tegen ongeautoriseerde software. Het had EDR, MFA, CASB, SaaS-logboeken en een op ISO/IEC 27001 afgestemd ISMS. Maar niemand had de browser behandeld als een beheerd softwareplatform. Niemand had extensies geïnventariseerd. Niemand had hun machtigingen goedgekeurd. Niemand had beoordeeld of extensieontwikkelaars leveranciers waren. Niemand had extensieactiviteit gekoppeld aan bewijs voor DORA, NIS2 of GDPR.

Eén enkele browser-add-on had een endpoint dat compliant leek, veranderd in een mogelijke achterdeur naar financiële systemen, klantgegevens en gereguleerde werkstromen.

Dat is het governanceprobleem rond browserextensies in 2026. De browser is niet langer alleen een venster naar het internet. Het is de plaats waar medewerkers authenticeren, betalingen goedkeuren, CRM-registraties raadplegen, persoonsgegevens verwerken, cloudinfrastructuur beheren en met kritieke SaaS-platforms werken. Extensies zijn niet langer cosmetische add-ons. Het is code van derden die draait in de meest gevoelige laag van modern werk.

Voor CISO’s, complianceverantwoordelijken, DPO’s en eigenaren van ICT-risico bevinden onbeheerde extensies zich op het snijvlak van endpointbeveiliging, schaduw-IT, leveranciersrisico, wijzigingsbeheer, kwetsbaarhedenbeheer en privacyverantwoordingsplicht. ISO/IEC 27001:2022 geeft organisaties de structuur om dit risico te beheersen. NIS2, DORA en GDPR leveren de regelgevende druk om dit aantoonbaar te maken.

Browserextensies zijn software, leveranciers en gegevensverwerkers

De meeste organisaties hebben inmiddels geleerd om laptops, mobiele apparaten, servers, SaaS-toepassingen, cloudinfrastructuur en geprivilegieerde accounts te beheren. Browserextensies vallen vaak tussen deze programma’s in.

Beveiligingsteams zien ze als een browserinstelling. Inkoop ziet ze niet, omdat er geen contract wordt ondertekend. Juridische zaken ziet ze niet, omdat er geen aanvraag voor leveranciersonboarding wordt geopend. Privacyteams zien ze niet, omdat de extensie door een gebruiker wordt geïnstalleerd en niet als officiële toepassing wordt uitgerold. Toch kan de extensie toestemming vragen om gegevens op alle websites te lezen en te wijzigen, klembordinhoud te benaderen, paginametadata vast te leggen, downloads te beheren, scripts te injecteren of te communiceren met een externe backend.

Dat betekent dat een browserextensie tegelijk al het volgende kan zijn:

De [ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap vat de kern van het probleem samen in de ISO/IEC 27002:2022-richtsnoeren voor maatregel 8.19. Daarin wordt gewaarschuwd dat “zelfs goedbedoelende medewerkers tools kunnen installeren om ‘het werk sneller gedaan te krijgen’ — een browserextensie, een codebibliotheek, een app voor bestandsoverdracht — zonder te beseffen dat zij zojuist een achterdeur, een ongepatchte afhankelijkheid of een vector voor data-exfiltratie hebben geïntroduceerd.”

Die zin moet worden behandeld als een risicostelling op bestuursniveau. Medewerkers die risicovolle extensies installeren, proberen doorgaans niet de beveiliging te omzeilen. Zij proberen productiever te werken. De governancefout ontstaat wanneer de organisatie geen veilig proces biedt voor aanvraag, goedkeuring, uitrol en monitoring.

Waarom NIS2, DORA en GDPR deze blinde vlek urgent maken

Risico’s van browserextensies bestaan al jaren, maar de regelgevende context is veranderd. In 2026 wordt van organisaties verwacht dat zij niet alleen aantonen dat beheersmaatregelen bestaan, maar ook dat die risicogebaseerd, geïntegreerd, gemonitord en onderbouwd zijn.

NIS2 verhoogt de verwachtingen voor cyberhygiëne en beveiliging van de toeleveringsketen. DORA verplicht financiële entiteiten om ICT-risico te beheren over interne afhankelijkheden en afhankelijkheden van derde partijen heen. GDPR verplicht verwerkingsverantwoordelijken en verwerkers om beveiliging van de verwerking, verantwoordingsplicht en privacy by design aan te tonen. Onbeheerde extensies kunnen alle drie ondermijnen.

De les is eenvoudig. Een browserextensie is niet te klein om ertoe te doen. Als zij gereguleerde gegevens, geauthenticeerde sessies, financiële werkstromen of kritieke SaaS-diensten kan raken, moet zij worden beheerst.

Gebruik ISO/IEC 27001:2022 als operationeel model

ISO/IEC 27001:2022 is effectief voor governance van browserextensies omdat hiervoor geen afzonderlijke compliance-silo nodig is. Organisaties kunnen bestaande ISMS-processen uitbreiden naar de browserlaag.

Het praktische beheersmodel is opgebouwd rond acht beheersmaatregelen uit ISO/IEC 27001:2022 Bijlage A:

De [ZC] Zenith Controls: The Cross-Compliance Guide is bijzonder nuttig omdat deze uitlegt hoe ISO/IEC 27001-beheersmaatregelen worden geaudit en hoe zij bewijs over meerdere kaders heen ondersteunen. Voor maatregel 8.19 legt Zenith Controls: The Cross-Compliance Guide uit dat auditors “de workflow volgen: van aanvraag naar test, naar goedkeuring, naar implementatie.” Precies zo moet governance voor extensies worden ontworpen.

Als een auditor een extensie aantreft die niet op de goedgekeurde lijst staat, niet in wijzigingsregistraties is gedocumenteerd en niet risicobeoordeeld is, gaat het niet langer alleen om een browserinstelling. Het wordt bewijs voor zwakke beheersing van software-installatie, zwakke endpointgovernance en mogelijk falen van leveranciersrisicobeheer.

Stap 1, breng het extensielandschap in kaart

De eerste tekortkoming in de beheersmaatregelen bij Maria’s fintechbedrijf was zichtbaarheid. Haar team wist niet welke extensies waren geïnstalleerd, wie ze had geïnstalleerd, welke machtigingen ze vroegen en of ze verbinding maakten met externe diensten.

Inventarisatie moet alle beheerde browsers, profielen, gebruikers, apparaten en besturingssystemen omvatten. Zij moet de extensienaam, unieke ID, versie, uitgever, installatiebron, machtigingenset, installatiedatum, updatestatus, aantal gebruikers, bedrijfseigenaar en de status als verplicht geïnstalleerd, door de gebruiker geïnstalleerd, via sideloading geïnstalleerd of geblokkeerd identificeren.

Maatregel 8.1, Gebruikersendpointapparaten, is het anker. De richtlijn van Zenith Blueprint: An Auditor’s 30-Step Roadmap voor maatregel 8.1 stelt dat gebruikersendpointapparaten “moeten worden versterkt, bewaakt en beheerst.” Die eis omvat vanzelfsprekend de browser, omdat de browser nu de primaire gebruikersinterface op het endpoint is voor SaaS- en cloudwerk.

Maatregel 5.23 is ook van toepassing wanneer extensies verbinding maken met cloudservices. Zenith Blueprint: An Auditor’s 30-Step Roadmap positioneert deze beheersmaatregel als reactie op schaduw-IT, waarbij gebruikers niet-goedgekeurde diensten zonder governance gebruiken. Een browserextensie die inhoud naar een onbekende gehoste backend verzendt, is een adoptiegebeurtenis voor een clouddienst, ook als niemand bij inkoop die heeft goedgekeurd.

Een volwassen inventarisatie-uitkomst moet elke extensie in een van vijf statussen classificeren:

Inventarisatie mag geen eenmalig project zijn. Extensies worden vaak bijgewerkt, uitgevers wisselen van eigenaar, machtigingen worden uitgebreid en stores verwijderen kwaadaardige pakketten nadat gebruikers ze al hebben geïnstalleerd. De inventaris moet continu worden bijgewerkt of ten minste vaak genoeg worden herhaald om kwetsbaarhedenbeheer en auditbewijs te ondersteunen.

Stap 2, maak aanvaardbaar gebruik expliciet

Zodra extensies zichtbaar zijn, moeten verwachtingen voor gebruikers duidelijk zijn. Veel organisaties hebben al beleidstaal die governance voor extensies kan ondersteunen, maar die moet expliciet op de browser worden toegepast.

[P-EPM] Endpointbeveiligingsbeleid - Malwarebescherming - mkb stelt dat gebruikers “geen ongeautoriseerde software of plug-ins mogen installeren die risico kunnen introduceren.” Die ene zin geeft beveiligingsteams een sterke beleidsbasis om browserextensies als beheerde software te behandelen.

[P03-AUP] P03 Beleid inzake aanvaardbaar gebruik, ook aangeduid als het ondernemingsbrede Beleid inzake aanvaardbaar gebruik, verbiedt “Niet-goedgekeurde tools: het installeren of gebruiken van ongeautoriseerde software, hardware, cloudservices of apparaten”. Dit is de gebruikersgerichte basis. Het maakt van governance voor browserextensies geen technische voorkeur, maar een afdwingbare gedrags- en compliance-eis.

Een sterk beleid voor browserextensies moet zes praktische vragen beantwoorden:

Dit gaat niet over het verbieden van elke nuttige extensie. Het gaat om de verschuiving van impliciet vertrouwen naar expliciete goedkeuring. Sommige extensies kunnen veilig, noodzakelijk en productiviteitsverhogend zijn. Andere kunnen onnodig, overmatig geprivilegieerd, verlaten of vijandig zijn. Het governanceprogramma moet daartussen onderscheid maken.

Stap 3, dwing default-deny af met toelatingslijsten per uitzondering

Maatregel 8.19, Installatie van software op operationele systemen, is de beheersmaatregel die beleid omzet in uitvoering. Browserextensies mogen niet anders worden behandeld dan andere software alleen omdat gebruikers ze via een browserstore installeren.

Zenith Blueprint: An Auditor’s 30-Step Roadmap is hierover duidelijk: “er wordt geen software geïnstalleerd tenzij die gerechtvaardigd, geautoriseerd en beveiligd is.” Voor browserextensies betekent dit dat enterprise browser management, endpointbeheer of tooling voor apparaatconfiguratie wordt gebruikt om installatieregels af te dwingen.

Het meest verdedigbare model is default-deny met toelatingslijsten per uitzondering:

1. Blokkeer standaard alle extensies voor beheerde browsers.
2. Installeer alleen essentiële, goedgekeurde bedrijfsextensies verplicht.
3. Beheer een toelatingslijst voor goedgekeurde extensies per gebruikersgroep, afdeling of rol.
4. Blokkeer sideloaded extensies en niet-vertrouwde installatiebronnen.
5. Voorkom dat gebruikers beleid omzeilen door van profiel te wisselen of onbeheerde browsers te gebruiken.
6. Verwijder reeds geïnstalleerde extensies die niet zijn goedgekeurd.
7. Beoordeel extensiemachtigingen en uitgeversrisico vóór goedkeuring.
8. Log toegestane, geblokkeerde, verwijderde en gewijzigde extensies.

Sommige organisaties starten met een minder strikt model vanwege operationele complexiteit. Zij inventariseren mogelijk eerst, blokkeren bekende kwaadaardige extensies en faseren vervolgens toelatingslijsten in voor hoog-risicogroepen zoals finance, engineering, geprivilegieerde beheerders, juridische zaken, HR en klantenservice. Dat is aanvaardbaar als er een gedocumenteerde roadmap is. Niet verdedigbaar is permanente tolerantie voor onbekend extensierisico.

Stap 4, beoordeel extensies op risico zoals leveranciers en software

Een risicobeoordeling van browserextensies moet licht genoeg zijn voor acceptatie door de business, maar sterk genoeg om een audit te doorstaan. De beoordeling moet softwarerisico, leveranciersrisico, cloudrisico, gegevensbescherming en kwetsbaarhedenbeheer combineren.

[P-TP] Beleid inzake beveiliging van derden en leveranciers schrijft voor dat “alle nieuwe leveranciers vóór contractondertekening een gedocumenteerde beveiligingsbeoordeling moeten ondergaan.” Niet elke ontwikkelaar van extensies vereist een volledig ondernemingsbreed proces voor leveranciersonboarding, maar het principe van leveranciersrisico blijft van toepassing. Als een ontwikkelaar code-updates naar browsers van medewerkers kan pushen of gegevens van de organisatie via een backenddienst kan verwerken, heeft de organisatie een afhankelijkheid van een derde partij.

[P-ASR] Beleid inzake vereisten voor applicatiebeveiliging - mkb versterkt dezelfde eis vanuit softwareperspectief: “elke tool, plug-in of externe codebibliotheek van derden die in een toepassing wordt gebruikt, moet worden geregistreerd en jaarlijks worden beoordeeld op beveiligingsimpact en patchstatus.”

Gebruik het volgende risicomodel om besluiten te standaardiseren:

Een hoog-risico-extensie mag niet worden goedgekeurd tenzij er een kritieke zakelijke behoefte, gedocumenteerde compenserende beheersmaatregelen en risicoacceptatie door senior management zijn. Voorbeelden van compenserende beheersmaatregelen zijn het beperken van gebruik tot een gehard browserprofiel, beperken tot specifieke URL’s, blokkeren van gegevensinvoer in gevoelige toepassingen terwijl de extensie actief is, gebruik van DLP-monitoring, of het vereisen van een leverancierscontract en privacyaddendum.

Stap 5, integreer privacy- en GDPR-beoordeling

Governance voor browserextensies faalt vaak omdat privacybeoordeling losstaat van endpointtooling. Toch kunnen veel extensies persoonsgegevens zien die worden weergegeven in SaaS-toepassingen, HR-systemen, supporttickets, CRM-registraties, e-mail, analyseplatforms en samenwerkingstools.

Onder GDPR artikel 5(2) moet de organisatie verantwoordingsplicht aantonen. Onder artikel 25 moet zij gegevensbescherming door ontwerp en standaardinstellingen implementeren. Onder artikel 32 moet zij passende technische en organisatorische maatregelen toepassen voor beveiliging van de verwerking. Als een extensie persoonsgegevens exfiltreert, kan de gebeurtenis een datalek worden onder artikel 4(12), met beoordeling en mogelijk meldingsverplichtingen onder artikel 33 tot gevolg.

Een privacybewuste extensiebeoordeling moet vragen:

Niet elke extensie vereist een volledige DPIA. Extensies met brede paginatoegang, AI-verwerking, schermopname, e-mailtoegang, CRM-toegang, toegang tot HR-gegevens, klantenservicegegevens of gereguleerde financiële gegevens moeten echter een gestructureerde privacybeoordeling activeren.

Stap 6, log en monitor voor audits en incidentrespons

Een governanceprogramma voor extensies zonder logboeken is niet auditeerbaar. Het verzwakt ook incidentrespons, omdat de organisatie niet kan vaststellen wanneer een extensie is geïnstalleerd, wie deze gebruikte, welke versie aanwezig was, wanneer machtigingen veranderden of of een geblokkeerde installatiepoging heeft plaatsgevonden.

[P-LM] Beleid voor logging en bewaking - mkb noemt logboeken voor “software-installaties” als belangrijke governancevereiste. Installatie van browserextensies is een software-installatiegebeurtenis en moet dienovereenkomstig worden vastgelegd.

Logboeken moeten minimaal het volgende bevatten:

Deze logboeken moeten worden opgenomen in monitoringprocessen onder maatregelen 8.15 en 8.16. Afhankelijk van het risico kunnen zij ook naar een SIEM, endpointplatform of repository voor compliancebewijs worden gestuurd. Waarschuwingen moeten worden geconfigureerd voor geblokkeerde hoog-risico-extensies, plotselinge pieken in extensieaanvragen, wijzigingen in machtigingen voor goedgekeurde extensies, pogingen tot installatie uit niet-officiële bronnen en installatiepogingen door geprivilegieerde gebruikers.

Monitoring is ook een voordeel voor NIS2 en DORA. Incidentmelding onder NIS2 artikel 23 hangt af van vroege detectie en impactbeoordeling. DORA vereist robuuste ICT-incidentafhandeling en bewijs van weerbaarheid. GDPR-beoordeling van datalekken hangt af van weten wat er is gebeurd, wanneer dat gebeurde en welke gegevens mogelijk zijn geraakt.

Wat de auditor wil zien

Een auditor neemt zelden genoegen met een uitspraak als “wij blokkeren risicovolle extensies.” Auditors willen bewijs van governance. Het bewijs moet beleid, risicobeoordeling, technische afdwinging, monitoring en verantwoordingsplicht van het management met elkaar verbinden.

Hier wordt Zenith Controls: The Cross-Compliance Guide waardevol. Het helpt organisaties aantonen hoe één beheersactiviteit meerdere complianceverwachtingen ondersteunt. Eén goedkeuringsworkflow voor browserextensies kan ISO/IEC 27001 maatregel 8.19, NIS2-cyberhygiëne, DORA ICT-risicobeheer en GDPR-verantwoordingsplicht ondersteunen als het bewijs wordt bewaard en duidelijk wordt gemapt.

Kruisverwijzing, ISO/IEC 27001:2022 naar NIS2, DORA en GDPR

Een praktische kruisverwijzing helpt CISO’s uit te leggen waarom governance voor browserextensies geen nichetechnische beheersmaatregel is. Het is een compliancebeheersmaatregel met brede regelgevende waarde.

De DORA-mapping verdient bijzondere aandacht. Sommige auditors en assessoren gebruiken COBIT-achtige taal bij de beoordeling van governance voor ICT-wijzigingen. COBIT BAI06 wordt algemeen begrepen als Managed IT Changes. Als browserextensies software zijn en hun installatie de gebruikerscomputeromgeving wijzigt, hoort extensie-installatie binnen dezelfde beheerste wijzigingslogica. Zenith Controls: The Cross-Compliance Guide ondersteunt deze auditlens door te laten zien hoe bewijs voor ISO/IEC 27001-beheersmaatregelen kan worden hergebruikt voor verschillende complianceverwachtingen.

Een implementatieplan van 90 dagen voor governance van browserextensies

Organisaties hoeven niet alles in één week op te lossen. Een praktisch programma kan gefaseerd worden opgebouwd, vooral als verstoring van de business zorgvuldig moet worden beheerst.

Voor hoog-risico-organisaties, vooral financiële entiteiten onder DORA of essentiële en belangrijke entiteiten onder NIS2, moet de eerste afdwingingsfase prioriteit geven aan gebruikers met toegang tot kritieke systemen, gereguleerde gegevens, geprivilegieerde beheerconsoles, financiële platforms, klantenservicetools en ontwikkelomgevingen.

De boodschap op bestuursniveau

Governance voor browserextensies moet niet aan bestuurders worden gepresenteerd als een project voor browserhardening. Het moet worden gepresenteerd als beheersing van niet-beoordeelde code van derden in gereguleerde werkstromen.

De raad van bestuur en het bestuursorgaan moeten vier punten begrijpen:

1. De browser is nu een kernplatform voor de bedrijfsvoering.
2. Extensies kunnen toegang krijgen tot gevoelige SaaS-gegevens en geauthenticeerde sessies.
3. Onbeheerde extensies creëren leveranciers-, privacy-, incident- en weerbaarheidsrisico.
4. ISO/IEC 27001:2022 biedt een verdedigbaar beheersmodel dat bewijs voor NIS2, DORA en GDPR ondersteunt.

Die positionering verplaatst de discussie van technische voorkeur naar operationele weerbaarheid. Zij ondersteunt ook financiering voor enterprise browser management, endpointintegratie, monitoring, privacybeoordeling, leverancierstriage en automatisering van auditbewijs.

Van blinde vlek naar strategische beheersmaatregel

Maria’s auditissue werd niet veroorzaakt doordat één analist één productiviteitstool installeerde. Het werd veroorzaakt door een onbeheerde risicocategorie. De organisatie had een sterk complianceprogramma gebouwd rond zichtbare bedrijfsmiddelen, zichtbare leveranciers, zichtbare SaaS-platforms en zichtbare endpoints, maar de laag met browserextensies bleef onzichtbaar.

Dat hiaat is inmiddels te belangrijk om te negeren.

De oplossing is niet ingewikkeld, maar moet doelbewust worden uitgevoerd. Behandel de browser als onderdeel van het endpoint. Behandel extensies als software. Behandel ontwikkelaars en backends van extensies als leveranciers waar relevant. Behandel machtigingen als gegevenstoegang. Behandel installatie als wijziging. Behandel logboeken als compliancebewijs.

Een verdedigbaar programma begint met vier acties:

1. Ontdek elke extensie in beheerde browsers en endpoints.
2. Definieer regels voor aanvaardbaar gebruik en default-deny met behulp van Endpointbeveiligingsbeleid - Malwarebescherming - mkb, P03 Beleid inzake aanvaardbaar gebruik en het ondernemingsbrede Beleid inzake aanvaardbaar gebruik.
3. Beoordeel extensieaanvragen aan de hand van leveranciers-, cloud-, kwetsbaarheids- en privacycriteria uit Beleid inzake beveiliging van derden en leveranciers en Beleid inzake vereisten voor applicatiebeveiliging - mkb.
4. Dwing installatieactiviteit af en monitor deze met browserbeheer, logging en bewijspraktijken die zijn afgestemd op Beleid voor logging en bewaking - mkb.

Voor CISO’s die zich voorbereiden op audits voor NIS2, DORA, GDPR of ISO/IEC 27001:2022 is governance voor browserextensies een waardevolle verbetering van beheersmaatregelen, omdat hiermee een werkelijk aanvalspad wordt gesloten en herbruikbaar bewijs over kaders heen wordt geproduceerd.

Download Zenith Blueprint: An Auditor’s 30-Step Roadmap om het werk te versnellen en map uw bewijs met Zenith Controls: The Cross-Compliance Guide. Wilt u chaos rond browserextensies omzetten in een auditgereed governanceprogramma, plan dan een Clarysec-assessment of demo en begin met een praktische inventaris, risicokaart en beheersplan van 90 dagen.