ISO 27090 förklarad för team som arbetar med AI-säkerhet

ISO/IEC 27090:2026 är en internationell standard som ger vägledning om säkerhetshot och intrång som påverkar system för artificiell intelligens. Den publicerades den 14 oktober 2026 och behandlar hur organisationer kan förstå, upptäcka och begränsa dessa hot under hela AI-livscykeln. Dess formella titel är Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. ISO:s publiceringspost

För ett säkerhetsteam är den praktiska frågan enkel: vad skulle en angripare kunna ändra i, stjäla från eller få ett AI-system att göra, och vad skulle begränsa den skada som uppstår?

Den här guiden förklarar tillämpningsområdet för standarden ISO 27090, de viktigaste AI-säkerhetshoten, dess förhållande till ISO 27001 och ISO 42001 samt ett praktiskt sätt att omsätta vägledningen i säkerhetsarbete med ägare, skyddsåtgärder och underlag. Researchen bakom guiden kontrollerades den 18 oktober 2026.

Vad standarden ISO 27090 omfattar

ISO 27090 fokuserar på att skydda AI-system. Ämnet sträcker sig bortom generativ AI, stora språkmodeller och chattbotar till AI-system i bredare mening. ISO:s förklaring av ISO 27090

Den publicerade standarden kopplar etablerade metoder för informationssäkerhet till AI-specifika hot. Innehållet behandlar styrning, säkerhet i leveranskedjan, hotmodellering och red teaming, följt av typer av intrång som förgiftning, undanmanöver (evasion), exponering av information och promptinjektion. Standarden tar också upp hur skyddsåtgärder samverkar och förblir effektiva över tid. Publicerat utdrag ur ISO/IEC 27090

Tillämpningsområdet omfattar organisationer av alla storlekar som utvecklar eller använder AI, däribland företag, myndigheter och ideella organisationer. Att köpa en AI-tjänst från en tredje part placerar alltså inte en organisation utanför den avsedda målgruppen. IEC:s publiceringspost

En bra utgångspunkt är en gemensam genomgång med säkerhet, utveckling, data, inköp och verksamhetsägaren. Var och en bör kunna förklara den del av systemet de kontrollerar och de beslut de är beroende av att andra fattar.

Varför AI-system kräver ytterligare säkerhetsanalys

En AI-applikation kopplar samman flera delar som förtjänar en egen granskning: programvara, data, modellfiler eller modelltjänster, instruktioner, användare och efterföljande åtgärder.

Tänk dig en dokumentassistent som är ansluten till en intern kunskapsbas. En konventionell granskning kan undersöka autentisering, kryptering och sårbarheter i programvaran. En AI-säkerhetsgranskning bör dessutom fråga vad som händer om ett hämtat dokument försöker ändra assistentens instruktioner, om användare kan hämta material utanför sina behörigheter och vilka åtgärder genererade utdata kan utlösa.

Frågorna får större betydelse när en assistent kan uppdatera poster eller anropa externa verktyg. Ett felaktigt svar och en obehörig åtgärd har olika konsekvenser och kräver olika skyddsåtgärder.

Kartlägg tre frågor vid din första granskning:

• Vad kan påverka systemet? Ta med träningsdata, hämtat innehåll, promptar, leverantörer och modelluppdateringar.
• Vad kan lämna systemet? Ta med svar, loggar, exporter och modelltillgångar.
• Vad kan systemet ändra? Ta med filer, ärenden, konton, transaktioner och andra anslutna tjänster.

Detta är en praktisk metod för att avgränsa exemplen nedan, inte en återgivning av standardens avsnitt.

AI-säkerhetshot att förstå

Förklaringarna nedan använder NIST:s terminologi för adversariell maskininlärning och OWASP:s vägledning för LLM-applikationer. Scenarierna är illustrativa. NIST:s taxonomi för adversariell maskininlärning OWASP:s vägledning om promptinjektion OWASP:s vägledning om hantering av utdata

Håll isär begreppen under en riskbedömning. Ett skadligt dokument som hämtas av en applikation för hämtningsförstärkt generering (RAG) är inte automatiskt förgiftning av träningsdata: hämtningen uppdaterar inte i sig modellens vikter. Den kan i stället utsätta applikationen för indirekt promptinjektion.

För LLM-säkerhet är starkare promptar på egen hand en ofullständig kontrollstrategi. OWASP rekommenderar skyddsåtgärder som begränsade behörigheter och godkännande av känsliga åtgärder, medan NCSC betonar att promptinjektion ska hanteras som en fortlöpande risk genom systemets utformning och drift. OWASP:s vägledning om promptinjektion NCSC:s vägledning om risken för promptinjektion

ISO 27090 jämfört med ISO 27001 och ISO 42001

Standarderna stöder olika delar av en organisations arbete med säkerhet och AI-styrning.

Distinktionerna följer utgivarnas beskrivningar av ISO 27001, ISO 27002 och ISO 42001.

För ett team som redan driver ett ISMS är ett praktiskt tillvägagångssätt att bygga ut befintliga poster. Lägg till relevanta AI-system i tillgångsförteckningen, bedöm deras attackvägar, utse ägare för riskbehandlingen och koppla stödjande underlag. Bakgrund om hur arbetet kan organiseras finns i checklistan för införande av ISO 27001.

En praktisk checklista för att införa ISO 27090

Stegen nedan är ett tillvägagångssätt för införande som bygger på standardens innehåll och offentlig vägledning om säker AI. De är inte en officiell ISO-checklista eller en redogörelse för obligatoriska avsnitt.

1. Definiera systemet och dess ägare

Välj ett AI-användningsfall med ett tydligt verksamhetssyfte. Dokumentera ansvarig ägare, användare, modellleverantör, driftmiljö och anslutna tjänster.

Dra sedan gränsen för granskningen. Ta med applikationen och dess beroenden, inte bara modellens endpoint. En kundnära assistent med åtkomst till verktyg kräver en annan bedömning än en intern textsammanfattare som saknar behörighet att agera.

Användbart resultat: en systempost som anger syfte, gränser, beroenden, tillåtna åtgärder och ansvarig ägare.

2. Spåra data- och modellursprung

Dokumentera var datamängder och modellartefakter kommer ifrån, vem som kan ändra dem och vilka versioner som är driftsatta. Ta med indata för finjustering, hämtningssamlingar, promptar och återkopplingskanaler som är relevanta för systemet.

NCSC:s vägledning för utveckling rekommenderar att AI-tillgångar och deras ursprung spåras, att de skyddas och att den information som behövs för att återställa pålitliga versioner bevaras. NCSC:s vägledning för säker AI-utveckling

För en köpt modell bör du fråga leverantören vilka ansvarsområden den hanterar och vilken information den tillhandahåller när modeller eller tjänster ändras.

Användbart resultat: en versionshanterad förteckning med källor, åtkomstregler, ändringshistorik och leverantörens ansvarsområden.

3. Hotmodellera det faktiska arbetsflödet

Granska systemet ur en angripares perspektiv. Identifiera ingångspunkter, känsliga tillgångar, behörigheter och konsekvenserna av ett lyckat intrång. NCSC:s vägledning för säker design rekommenderar hotmodellering och uppmärksamhet på tredjepartskomponenter och minsta möjliga behörighet. NCSC:s vägledning för säker AI-design

Skriv konkreta scenarier. ”AI-risk” är för brett för att leda till en användbar åtgärd. ”Ett dokument som laddats upp av en extern part övertalar assistenten att begära en underlagsfil med begränsad åtkomst” ger teamet något specifikt att analysera.

Prioritera utifrån exponering och potentiell skada. Dokumentera vem som accepterar eventuell kvarvarande risk och när beslutet ska omprövas.

Användbart resultat: ett kort riskregister som kopplar attackscenarier till tillgångar, konsekvenser, skyddsåtgärder och ägare.

4. Placera skyddsåtgärder vid de relevanta gränserna

Välj kontroller för det scenario du hanterar. För modelltillgångar kan det handla om skyddad lagring, åtkomstbegränsningar och integritetskontroller. För driftsatta tjänster bör du överväga autentisering, separation mellan miljöer och kontroller som minskar obehörig åtkomst eller dataexfiltrering. Detta är teman i NCSC:s vägledning för driftsättning. NCSC:s vägledning för säker driftsättning av AI

För genererade utdata ska innehållet valideras och kodas för sin destination innan ett annat system agerar på det. OWASP:s vägledning om hantering av utdata förklarar varför modellens utdata inte bör få auktoritet bara för att de kommer från modellen. OWASP:s vägledning om hantering av utdata

Användbart resultat: en kontrollpost som anger vilken gräns den skyddar, dess ägare och det underlag som används för att kontrollera den.

5. Testa hela applikationen

Utforma tester kring de konsekvenser som identifierats i hotmodellen. För en RAG-assistent kan du använda adversariella dokument och användare med olika behörigheter. För en agent testar du vad som händer när hämtat innehåll ber den att gå utöver sina tillåtna åtgärder.

Definiera det förväntade resultatet innan testet körs. Ett exempel: applikationen måste neka en begäran om en fil med begränsad åtkomst även om modellen försöker göra begäran.

Dokumentera applikationens konfiguration, modellversion, testindata, resultat och eventuella åtgärder. Välj testdata som inte i onödan exponerar verklig konfidentiell information.

Användbart resultat: repeterbara säkerhetstester som är kopplade till specifika risker och releasebeslut.

6. Övervaka ändringar och förbered en respons

Granska effekten av uppdateringar av modeller, data och promptar. Övervaka relevanta indata och utdata och skydda samtidigt känslig information i loggar. NCSC:s vägledning för drift lyfter fram beteendeövervakning och säkerhetskonsekvenserna av ändringar under hela driften. NCSC:s vägledning för säker drift av AI

Bestäm i förväg vem som får inaktivera ett verktyg, återkalla en inloggningsuppgift, isolera en integration eller återställa en release. Fastställ utlösare för granskning, till exempel en ny leverantör, utökade behörigheter, en väsentlig modelluppdatering eller en säkerhetsincident.

Användbart resultat: ansvar för övervakning, kriterier för granskning av ändringar, en rutin för incidenthantering och en testad återställningsväg.

Omsätt AI-säkerhetsrisker i underlag

Tabellen nedan är en föreslagen arbetsmall. Exemplen på underlag är praktiska rekommendationer, inte en förteckning över dokument som ISO 27090 kräver.

Tänk dig till exempel ett säkerhetsteam som använder en assistent för att sammanfatta kunders underlag. Ett dokument från en leverantör innehåller instruktioner om att ladda upp underlaget till en extern adress.

Teamets test bör följa den försökta åtgärden genom applikationen. Har assistenten ett verktyg som kan ladda upp filer? Upprätthåller verktyget användarens behörigheter? Är destinationerna begränsade? Måste en ansvarig person godkänna överföringen?

En användbar granskningspost skulle identifiera scenariot, gränsen som förhindrar överföringen, testresultatet och personen som godkände den kvarvarande risken. Om systemet ändras visar posten nästa granskare vad som behöver kontrolleras igen.

Det här tillvägagångssättet ger en bedömning mer substans än ett påstående om att systemet använder ”ansvarsfull AI”. Det kopplar säkerhetsbeslutet till något som en annan person kan granska. Mer om hur stödjande material kan organiseras finns i så strukturerar du revisionsberedskapen.

Certifiering och krav enligt ISO 27090

ISO 27090 ger säkerhetsvägledning snarare än krav för certifiering av ledningssystem. ISO:s förklaring skiljer standardens syfte från AIMS-kraven i ISO 42001. ISO:s förklaring av ISO 27090

Definiera först vilken försäkran du behöver: en säkerhetsgranskning, ett svar på en kunds förfrågan om försäkran, en intern gapanalys eller certifiering mot en tillämplig standard för ledningssystem.

Be alla som erbjuder en bedömning att ange dess omfattning, kriterier och system för försäkran. Det gör resultatet lättare att tolka och undviker att en granskning av AI-säkerhetsrutiner förväxlas med certifiering av ett ledningssystem.

För ett införandeprojekt bör du skaffa den publicerade standarden, granska vägledningen mot dina egna system och dokumentera varför vissa skyddsåtgärder är lämpliga. Exemplen i den här artikeln ger en första struktur för det arbetet.

ISO 27090 och EU:s AI-förordning

Att tillämpa en internationell standard innebär inte automatiskt överensstämmelse med EU:s AI-förordning. Artikel 40 kopplar en presumtion om överensstämmelse till harmoniserade standarder vars referenser har offentliggjorts i Europeiska unionens officiella tidning, och endast i den mån de omfattar de relevanta kraven eller skyldigheterna. Artikel 40 i EU:s AI-förordning

Använd en säkerhetsgranskning enligt ISO 27090 som ett av flera underlag till en separat avgränsad bedömning av regelefterlevnad. Dokumentera vilken rättslig skyldighet som utvärderas, vilket underlag som stöder den och eventuella kvarvarande luckor.

Vanliga frågor om ISO 27090

När publicerades ISO 27090?

Den första utgåvan, ISO/IEC 27090:2026, publicerades den 14 oktober 2026. Kontrollera utgivarens aktuella post när äldre material hänvisar till ett utkast eller ett tidigare år. IEC:s publiceringspost

Omfattar ISO 27090 generativ AI och LLM-säkerhet?

Det publicerade innehållet omfattar promptinjektion och känsliga modellutdata, vilket gör standarden relevant för säkerhet i generativ AI. Tillämpningsområdet omfattar även andra AI-system. Publicerat utdrag ur ISO/IEC 27090 ISO:s förklaring av ISO 27090

Kan ett företag som använder AI från tredje part tillämpa standarden?

Ja. Den angivna målgruppen omfattar organisationer som använder AI liksom organisationer som utvecklar den. Börja med riskerna och ansvarsområdena inom din kontroll, och identifiera vad du behöver förstå om dina leverantörer. IEC:s publiceringspost

Innebär en ISO 27001-certifiering att ett AI-system är säkert?

En certifiering av ett ledningssystem är ingen garanti för att en enskild applikation står emot alla attacker. Använd ledningssystemet för att organisera riskbeslut och bedöm AI-systemets faktiska design, konfiguration och beteende. ISO 27090 kan ge underlag för det säkerhetsarbetet.

Var kan jag få tag på ISO 27090 som PDF?

Använd ISO:s officiella katalog eller IEC Webstore för den publicerade standarden och licensalternativen. Kontrollera att beteckningen är ISO/IEC 27090:2026. En artikel eller ett utdrag ger bara en del av materialet.

Gör AI-säkerhetsarbetet granskningsbart

Börja med ett AI-användningsfall som har stor betydelse. Identifiera hur det skulle kunna komprometteras, välj skyddsåtgärder för de relevanta gränserna och definiera det underlag som ska visa att skyddsåtgärderna fungerar. Ge varje åtgärd en ägare och en utlösare för granskning.

Secani kopplar samman krav, risker, kontroller, underlag, ägare och granskningsbeslut i en gemensam arbetsyta för säkerhet och regelefterlevnad. Prata med Secani om hur ni kan organisera ert AI-säkerhetsarbete så att teamen ser vad som har bedömts, vad som behöver åtgärdas och vem som är ansvarig.