Styrning av webbläsartillägg för NIS2, DORA och GDPR

Maria, informationssäkerhetschef på ett snabbt växande fintechbolag, tyckte att förhandsbedömningen inför DORA gick bra. Hennes team hade förberett registret över IKT-tredjeparter, kritiska SaaS-avtal, leverantörsgranskningsunderlag, beslut om riskacceptans och rapporteringspaketet till ledningsorganet.

Då ställde revisorn en fråga som ingen hade planerat för.

“Kan ni visa er styrningsprocess för webbläsartillägg?”

Frågan kom från en granskning av en slutpunkt hos en finansanalytiker. Under en skärmdelning upptäckte revisorn ett tredjepartstillägg för produktivitet i analytikerns webbläsare. Det såg harmlöst ut, men en snabb sökning visade att utvecklaren hade drabbats av en kompromettering i leveranskedjan tre månader tidigare. Det komprometterade tillägget hade använts för att stjäla sessionstokens för stora SaaS-plattformar.

Fintechbolaget hade starka policyer mot otillåten programvara. Det hade EDR, MFA, CASB, SaaS-loggar och ett ISMS anpassat till ISO/IEC 27001. Men ingen hade behandlat webbläsaren som en hanterad programvaruplattform. Ingen hade inventerat tillägg. Ingen hade godkänt deras behörigheter. Ingen hade kontrollerat om tilläggsutvecklare var leverantörer. Ingen hade mappat tilläggsaktivitet till underlag för DORA, NIS2 eller GDPR.

Ett enda webbläsartillägg hade förvandlat en slutpunkt som såg efterlevande ut till en möjlig bakdörr till finansiella system, kunddata och reglerade arbetsflöden.

Det är problemet med styrning av webbläsartillägg 2026. Webbläsaren är inte längre bara ett fönster mot internet. Det är där medarbetare autentiserar sig, godkänner betalningar, får åtkomst till CRM-poster, behandlar personuppgifter, hanterar molninfrastruktur och arbetar i kritiska SaaS-plattformar. Tillägg är inte längre kosmetiska extrafunktioner. De är tredjepartskod som körs i det mest känsliga lagret av modernt arbete.

För informationssäkerhetschefer, regelefterlevnadsansvariga, dataskyddsombud och IKT-riskägare ligger ohanterade tillägg i skärningspunkten mellan slutpunktssäkerhet, skugg-IT, leverantörsrisk, ändringshantering, sårbarhetshantering och ansvarsskyldighet inom dataskydd. ISO/IEC 27001:2022 ger organisationer strukturen för att styra denna risk. NIS2, DORA och GDPR skapar det regulatoriska trycket att kunna bevisa kontrollen.

Webbläsartillägg är programvara, leverantörer och personuppgiftsbiträden

De flesta organisationer har redan lärt sig att hantera bärbara datorer, mobila enheter, servrar, SaaS-applikationer, molninfrastruktur och privilegierade konton. Webbläsartillägg hamnar ofta mellan dessa styrningsprogram.

Säkerhetsteam ser dem som en webbläsarinställning. Upphandling ser dem inte eftersom inget avtal tecknas. Juridik ser dem inte eftersom ingen begäran om leverantörsonboarding öppnas. Dataskyddsteam ser dem inte eftersom tillägget installeras av en användare och inte distribueras som en officiell applikation. Ändå kan tillägget begära behörighet att läsa och ändra data på alla webbplatser, få åtkomst till urklippsinnehåll, samla in sidmetadata, hantera nedladdningar, injicera skript eller kommunicera med en extern backendtjänst.

Det innebär att ett webbläsartillägg kan vara allt följande samtidigt:

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap fångar kärnproblemet i sin vägledning för ISO/IEC 27002:2022 avseende Kontroll 8.19. Den varnar för att “även välmenande medarbetare kan installera verktyg för att ‘få jobbet gjort snabbare’, ett webbläsartillägg, ett kodbibliotek, en filöverföringsapp, utan att inse att de just har infört en bakdörr, ett opatchat beroende eller en vektor för dataexfiltration.”

Den meningen bör behandlas som ett riskuttalande på styrelsenivå. De medarbetare som installerar riskfyllda tillägg försöker vanligtvis inte kringgå säkerheten. De försöker förbättra produktiviteten. Styrningsbristen uppstår när organisationen inte tillhandahåller en säker process för begäran, godkännande, driftsättning och övervakning.

Varför NIS2, DORA och GDPR gör blindfläcken akut

Risker kopplade till webbläsartillägg har funnits i flera år, men det regulatoriska sammanhanget har förändrats. Under 2026 förväntas organisationer kunna visa inte bara att kontroller finns, utan att de är riskbaserade, integrerade, övervakade och styrkta med underlag.

NIS2 höjer förväntningarna på cyberhygien och säkerhet i leveranskedjan. DORA kräver att finansiella entiteter hanterar IKT-risk över interna beroenden och tredjepartsberoenden. GDPR kräver att personuppgiftsansvariga och personuppgiftsbiträden kan visa säkerhet i behandlingen, ansvarsskyldighet och inbyggt dataskydd. Ohanterade tillägg kan underminera alla tre.

Lärdomen är enkel. Ett webbläsartillägg är inte för litet för att spela roll. Om det kan beröra reglerade data, autentiserade sessioner, finansiella arbetsflöden eller kritiska SaaS-tjänster måste det styras.

Använd ISO/IEC 27001:2022 som operativ modell

ISO/IEC 27001:2022 är effektiv för styrning av webbläsartillägg eftersom den inte kräver en separat efterlevnadssilo. Den gör det möjligt för organisationer att utvidga befintliga ISMS-processer till webbläsarlagret.

Den praktiska kontrollmodellen bygger på åtta kontroller i Bilaga A till ISO/IEC 27001:2022:

[ZC] Zenith Controls: The Cross-Compliance Guide är särskilt användbar eftersom den förklarar hur ISO/IEC 27001-kontroller granskas och hur de stödjer underlag över flera ramverk. För Kontroll 8.19 förklarar Zenith Controls: The Cross-Compliance Guide att revisorer kommer att “spåra arbetsflödet: från begäran till test, godkännande och genomförande.” Det är precis så styrning av tillägg bör utformas.

Om en revisor hittar ett tillägg som inte finns på den godkända listan, inte är dokumenterat i ändringsposter och inte har riskbedömts är frågan inte längre bara en webbläsarinställning. Den blir bevis för svag kontroll över programvaruinstallation, svag styrning av slutpunkter och ett möjligt bristande arbetssätt för leverantörsrisk.

Steg 1, kartlägg tilläggsbeståndet

Det första kontrollmisslyckandet i Marias fintechbolag var bristande synlighet. Hennes team visste inte vilka tillägg som var installerade, vem som hade installerat dem, vilka behörigheter de begärde eller om de anslöt till externa tjänster.

Kartläggningen bör omfatta alla hanterade webbläsare, profiler, användare, enheter och operativsystem. Den bör identifiera tilläggets namn, unik identifierare, version, utgivare, installationskälla, behörighetsuppsättning, installationsdatum, uppdateringsstatus, antal användare, verksamhetsägare och om tillägget är tvångsinstallerat, användarinstallerat, sidoladdat eller blockerat.

Kontroll 8.1, användarnas slutpunkter, är ankaret. Vägledningen i Zenith Blueprint: An Auditor’s 30-Step Roadmap för Kontroll 8.1 anger att användarnas slutpunkter “måste förstärkas, övervakas och kontrolleras.” Det kravet omfattar naturligt webbläsaren, eftersom webbläsaren nu är det primära användargränssnittet för SaaS- och molnarbete.

Kontroll 5.23 gäller också när tillägg ansluter till molntjänster. Zenith Blueprint: An Auditor’s 30-Step Roadmap beskriver denna kontroll som ett svar på skugg-IT, där användare börjar använda otillåtna tjänster utan styrning. Ett webbläsartillägg som skickar innehåll till en okänd hostad backendtjänst är införande av en molntjänst, även om ingen inom upphandling har godkänt den.

Ett moget resultat från kartläggningen bör klassificera varje tillägg i ett av fem tillstånd:

Kartläggning bör inte vara ett engångsprojekt. Tillägg uppdateras ofta, utgivare byter ägare, behörigheter utökas och butiker tar bort skadliga paket efter att användare redan har installerat dem. Förteckningen måste bli kontinuerlig, eller åtminstone tillräckligt återkommande för att stödja sårbarhetshantering och revisionsunderlag.

Steg 2, gör acceptabel användning tydlig

När tillägg är synliga måste användarnas förväntningar vara tydliga. Många organisationer har redan policyformuleringar som kan stödja styrning av tillägg, men de måste tillämpas uttryckligen på webbläsaren.

[P-EPM] Endpointskyddspolicy – skadlig kod - SME anger att användare “inte får installera otillåten programvara eller insticksprogram som kan medföra risk.” Den enda meningen ger säkerhetsteam en stark policygrund för att behandla webbläsartillägg som kontrollerad programvara.

[P03-AUP] P03 policy för acceptabel användning, även kallad organisationens policy för acceptabel användning, förbjuder “icke-godkända verktyg: installation eller användning av otillåten programvara, hårdvara, molntjänster eller enheter”. Detta är den användarnära grunden. Den gör styrning av webbläsartillägg till ett bindande beteende- och efterlevnadskrav, inte bara en teknisk preferens.

En stark policy för webbläsartillägg bör besvara sex praktiska frågor:

Det här handlar inte om att förbjuda varje användbart tillägg. Det handlar om att gå från underförstådd tillit till uttryckligt godkännande. Vissa tillägg kan vara säkra, nödvändiga och produktivitetshöjande. Andra kan vara onödiga, ha för omfattande behörigheter, vara övergivna eller vara fientliga. Styrningsprogrammet måste skilja mellan dem.

Steg 3, tillämpa neka som standard med tillåtelselista genom undantag

Kontroll 8.19, installation av programvara i driftmiljöer, är den kontroll som omsätter policy i drift. Webbläsartillägg bör inte behandlas annorlunda än annan programvara bara för att användare installerar dem via en webbläsarbutik.

Zenith Blueprint: An Auditor’s 30-Step Roadmap är tydlig på denna punkt: “ingen programvara installeras om den inte är motiverad, behörig och säkrad.” För webbläsartillägg innebär detta att organisationen använder hantering av företagswebbläsare, slutpunktshantering eller verktyg för enhetskonfiguration för att tillämpa installationsregler.

Den mest försvarbara modellen är att neka som standard och tillåta genom kontrollerade undantag:

1. Blockera alla tillägg som standard för hanterade webbläsare.
2. Tvångsinstallera endast nödvändiga, godkända organisationstillägg.
3. Upprätthåll en tillåtelselista för godkända tillägg per användargrupp, avdelning eller roll.
4. Blockera sidoladdade tillägg och icke betrodda installationskällor.
5. Förhindra att användare kringgår policyer genom att byta profiler eller använda ohanterade webbläsare.
6. Ta bort redan installerade tillägg som inte är godkända.
7. Granska tilläggsbehörigheter och utgivarrisk före godkännande.
8. Logga tillåtna, blockerade, borttagna och ändrade tillägg.

Vissa organisationer börjar med en mjukare modell på grund av operativ komplexitet. De kan först inventera, blockera känt skadliga tillägg och därefter fasa in tillåtelselistor för högriskgrupper som ekonomi, utveckling, privilegierade administratörer, juridik, HR och kundsupport. Det är acceptabelt om det finns en dokumenterad färdplan. Det som inte är försvarbart är permanent tolerans för okänd tilläggsrisk.

Steg 4, riskbedöm tillägg som leverantörer och programvara

En riskgranskning av webbläsartillägg bör vara tillräckligt lättviktig för att verksamheten ska använda den, men tillräckligt robust för att klara revision. Granskningen bör kombinera programvarurisk, leverantörsrisk, molnrisk, dataskydd och sårbarhetshantering.

[P-TP] Policy för leverantörssäkerhet och tredjepartssäkerhet kräver att “alla nya leverantörer måste genomgå en dokumenterad säkerhetsbedömning innan avtal ingås.” Inte varje tilläggsutvecklare kräver en fullständig process för leverantörsonboarding på företagsnivå, men principen om leverantörsrisk gäller ändå. Om en utvecklare kan skicka koduppdateringar till anställdas webbläsare eller behandla organisationens data via en backendtjänst har organisationen ett tredjepartsberoende.

[P-ASR] Policy för applikationssäkerhetskrav - SME förstärker samma krav ur ett programvaruperspektiv: “alla tredjepartsverktyg, insticksprogram eller externa kodbibliotek som används i en applikation måste registreras och granskas årligen avseende säkerhetspåverkan och patchstatus.”

Använd följande riskmodell för att standardisera beslut:

Ett högrisktillägg bör inte godkännas om det inte finns ett kritiskt verksamhetsbehov, dokumenterade kompenserande kontroller och riskacceptans från en senior riskägare. Exempel på kompenserande kontroller är att begränsa användningen till en härdad webbläsarprofil, begränsa till specifika URL:er, blockera datainmatning i känsliga applikationer medan tillägget är aktivt, använda DLP-övervakning eller kräva leverantörsavtal och personuppgiftsbiträdesavtal.

Steg 5, integrera dataskydds- och GDPR-granskning

Styrning av webbläsartillägg misslyckas ofta eftersom dataskyddsgranskning är frikopplad från slutpunktsverktyg. Ändå kan många tillägg se personuppgifter som visas i SaaS-applikationer, HR-system, supportärenden, CRM-poster, e-post, analyssystem och samarbetsverktyg.

Enligt GDPR Article 5(2) måste organisationen kunna visa ansvarsskyldighet. Enligt Article 25 måste den genomföra inbyggt dataskydd och dataskydd som standard. Enligt Article 32 måste den tillämpa lämpliga tekniska och organisatoriska åtgärder för säkerhet i behandlingen. Om ett tillägg exfiltrerar personuppgifter kan händelsen bli en personuppgiftsincident enligt Article 4(12), vilket utlöser bedömning och eventuella underrättelseskyldigheter enligt Article 33.

En dataskyddsmedveten granskning av tillägg bör ställa följande frågor:

Inte varje tillägg kräver en fullständig DPIA. Tillägg med bred sidåtkomst, AI-behandling, skärminspelning, e-poståtkomst, CRM-åtkomst, åtkomst till HR-data, kundsupportdata eller reglerade finansiella data bör dock utlösa en strukturerad dataskyddsbedömning.

Steg 6, logga och övervaka för revision och incidenthantering

Ett styrningsprogram för tillägg utan loggar är inte verifierbart vid revision. Det försvagar också incidenthantering, eftersom organisationen inte kan avgöra när ett tillägg installerades, vem som använde det, vilken version som fanns på plats, när behörigheter ändrades eller om ett blockerat installationsförsök inträffade.

[P-LM] Loggnings- och övervakningspolicy - SME identifierar loggar för “programvaruinstallationer” som ett centralt styrningskrav. Installation av webbläsartillägg är en programvaruinstallationshändelse och bör samlas in därefter.

Som minimum bör loggar omfatta:

Dessa loggar bör matas in i övervakningsprocesser enligt Kontrollerna 8.15 och 8.16. Beroende på risk kan de också skickas till ett SIEM, en plattform för slutpunktssäkerhet eller ett arkiv för efterlevnadsunderlag. Larm bör konfigureras för blockerade högrisktillägg, plötsliga ökningar av tilläggsbegäranden, ändrade behörigheter för godkända tillägg, försök att installera från icke-officiella källor och installationsförsök av privilegierade användare.

Övervakning är också en fördel för NIS2 och DORA. Incidentrapportering enligt NIS2 Article 23 beror på tidig detektering och konsekvensbedömning. DORA kräver robust incidenthantering inom IKT och resiliensunderlag. Bedömning av personuppgiftsincidenter enligt GDPR beror på att organisationen vet vad som hände, när det hände och vilka data som kan ha påverkats.

Vad revisorn vill se

En revisor nöjer sig sällan med ett påstående som “vi blockerar riskfyllda tillägg.” Revisorn vill se styrningsunderlag. Underlaget måste koppla samman policy, riskbedömning, teknisk tillämpning, övervakning och ledningens ansvarsskyldighet.

Det är här Zenith Controls: The Cross-Compliance Guide blir värdefull. Den hjälper organisationer att visa hur en kontrollaktivitet stödjer flera efterlevnadsförväntningar. Ett enda godkännandearbetsflöde för webbläsartillägg kan stödja ISO/IEC 27001 Kontroll 8.19, NIS2:s cyberhygien, DORA:s IKT-riskhantering och GDPR:s ansvarsskyldighet om underlaget bevaras och mappas tydligt.

Korsreferens, ISO/IEC 27001:2022 till NIS2, DORA och GDPR

En praktisk korsreferens hjälper informationssäkerhetschefer att förklara varför styrning av webbläsartillägg inte är en smal teknisk kontroll. Det är en efterlevnadskontroll med brett regulatoriskt värde.

DORA-mappningen förtjänar särskild uppmärksamhet. Vissa revisorer och bedömare använder COBIT-liknande språk när de granskar styrning av IKT-ändringar. COBIT BAI06 förstås ofta som Managed IT Changes. Om webbläsartillägg är programvara och deras installation ändrar användarnas datormiljö hör installation av tillägg hemma i samma styrda ändringslogik. Zenith Controls: The Cross-Compliance Guide stödjer detta revisionsperspektiv genom att visa hur kontrollunderlag från ISO/IEC 27001 kan återanvändas över flera efterlevnadsförväntningar.

En 90-dagars införandeplan för styrning av webbläsartillägg

Organisationer behöver inte lösa allt på en enda vecka. Ett praktiskt program kan byggas i faser, särskilt om verksamhetsstörningar måste hanteras varsamt.

För högriskorganisationer, särskilt finansiella entiteter under DORA eller väsentliga och viktiga entiteter under NIS2, bör den första tillämpningsfasen prioritera användare med åtkomst till kritiska system, reglerade data, privilegierade administrativa konsoler, finansplattformar, kundsupportverktyg och utvecklingsmiljöer.

Budskapet till styrelsen

Styrning av webbläsartillägg bör inte presenteras för ledande befattningshavare som ett projekt för webbläsarhärdning. Det bör presenteras som en kontroll över ogranskad tredjepartskod i reglerade arbetsflöden.

Styrelsen och ledningsorganet behöver förstå fyra punkter:

1. Webbläsaren är nu en central verksamhetsplattform.
2. Tillägg kan få åtkomst till känsliga SaaS-data och autentiserade sessioner.
3. Ohanterade tillägg skapar leverantörs-, dataskydds-, incident- och resiliensrisk.
4. ISO/IEC 27001:2022 ger en försvarbar kontrollmodell som stödjer underlag för NIS2, DORA och GDPR.

Den inramningen flyttar diskussionen bort från teknisk preferens och mot operativ resiliens. Den stödjer också finansiering för hantering av företagswebbläsare, slutpunktsintegration, övervakning, dataskyddsgranskning, leverantörstriage och automatisering av revisionsunderlag.

Från blindfläck till strategisk kontroll

Marias revisionsfråga orsakades inte av att en analytiker installerade ett produktivitetsverktyg. Den orsakades av en ohanterad riskklass. Organisationen hade byggt ett starkt efterlevnadsprogram kring synliga tillgångar, synliga leverantörer, synliga SaaS-plattformar och synliga slutpunkter, men webbläsartilläggslagret förblev osynligt.

Den luckan är nu för viktig för att ignoreras.

Åtgärden är inte komplicerad, men den måste vara avsiktlig. Behandla webbläsaren som en del av slutpunkten. Behandla tillägg som programvara. Behandla tilläggsutvecklare och backendtjänster som leverantörer där det är relevant. Behandla behörigheter som dataåtkomst. Behandla installation som ändring. Behandla loggar som efterlevnadsunderlag.

Ett försvarbart program börjar med fyra åtgärder:

1. Kartlägg varje tillägg i hanterade webbläsare och slutpunkter.
2. Definiera acceptabel användning och regler för att neka som standard med hjälp av Endpointskyddspolicy – skadlig kod - SME, P03 policy för acceptabel användning och organisationens policy för acceptabel användning.
3. Bedöm tilläggsbegäranden med leverantörs-, moln-, sårbarhets- och dataskyddskriterier från Policy för leverantörssäkerhet och tredjepartssäkerhet och Policy för applikationssäkerhetskrav - SME.
4. Tillämpa och övervaka installationsaktivitet med webbläsarhantering, loggning och underlagspraxis anpassade till Loggnings- och övervakningspolicy - SME.

För informationssäkerhetschefer som förbereder sig för revisioner enligt NIS2, DORA, GDPR eller ISO/IEC 27001:2022 är styrning av webbläsartillägg en kontrollförbättring med högt värde eftersom den stänger en verklig angreppsväg samtidigt som den skapar återanvändbara underlag över flera ramverk.

För att påskynda arbetet, ladda ner Zenith Blueprint: An Auditor’s 30-Step Roadmap och mappa era underlag med Zenith Controls: The Cross-Compliance Guide. Om ni vill omvandla kaos kring webbläsartillägg till ett revisionsklart styrningsprogram, boka en Clarysec-bedömning eller demo och börja med en praktisk förteckning, riskkarta och 90-dagars kontrollplan.