# ROS-analyse for AI-systemer

**Last updated:** 2026-06-19
**Status:** Gjeldende
**Category:** Norwegian Public Sector AI Governance

---

## Introduksjon

ROS-analyse (Risiko- og Sårbarhetsanalyse) er en systematisk tilnærming til å identifisere, vurdere og håndtere risikoer knyttet til IKT-systemer. For AI-systemer i norsk offentlig sektor innebærer dette en utvidet metodikk som tar høyde for AI-spesifikke risikoer som modellsikkerhet, dataintegritet, bias, og konsekvenser av automatiserte beslutninger.

**Hva er ROS-analyse?**
ROS-analyse dekker tre hovedsteg:
1. **Risikoidentifisering** – identifisere hva som kan gå galt
2. **Risikoanalyse** – vurdere sannsynlighet og konsekvens
3. **Risikoevaluering** – prioritere og beslutte tiltak

For AI-systemer må denne prosessen inkludere både tekniske sårbarheter (prompt injection, datalekkasje, modellmanipulasjon) og samfunnsmessige risikoer (diskriminering, feilbeslutninger, manglende forklarbarhet).

**Hvorfor er dette kritisk for offentlig sektor?**
- Offentlige tjenester påvirker borgeres rettigheter og velferd direkte
- AI-beslutninger kan ha alvorlige konsekvenser (ytelser, tillatelser, helsetjenester)
- Lovkrav om forsvarlig risikostyring og internkontroll
- Tillitskrav til offentlige digitale tjenester

---

## Lovgrunnlag og krav

### Sikkerhetsloven
Sikkerhetsloven regulerer sikkerhet i virksomheter av betydning for nasjonale sikkerhetsinteresser, herunder IKT-sikkerhet i kritiske samfunnsfunksjoner.

**Relevans for AI-systemer:**
- AI-systemer i kritisk infrastruktur (helse, samferdsel, energi) må tilfredsstille sikkerhetskrav
- Krav om risikovurdering av IKT-systemer som behandler gradert informasjon
- Leverandørvurdering for skytjenester med AI-kapabiliteter

### Sektorregelverk

**Helseregisterloven og Pasientjournalloven**
- Særlige krav til behandling av helseopplysninger med AI
- Dokumentasjonskrav for automatiserte beslutninger i helsesektoren

**Forvaltningsloven**
- § 11: Begrunnelsesplikt for enkeltvedtak – gjelder også AI-assisterte beslutninger
- Krav om forsvarlighet og sporbarhet i saksbehandling

**Personopplysningsloven (GDPR)**
- Art. 22: Rett til ikke å bli undergitt automatiserte individuelle avgjørelser
- Art. 35: DPIA (Data Protection Impact Assessment) for høyrisiko AI-behandling
- Art. 32: Sikkerhetstiltak tilpasset risiko

**Offentleglova (Offentlighetsloven)**
- Innsyn i offentlige AI-systemer (med visse unntak)
- Dokumentasjonsplikt for beslutningsgrunnlag

### Internkontrollforskriften
Pålegger virksomheter å:
- Kartlegge farer og problemer
- Analysere risiko
- Iverksette tiltak for å redusere risiko
- Systematisk oppfølging og revisjon

**For AI-systemer betyr dette:**
- Dokumentert risikovurdering før iverksetting
- Kontinuerlig overvåking av AI-ytelse og sikkerhet
- Beredskapsplaner for AI-feil eller misbruk

---

## ROS-metodikk for AI

### Verdivurdering (Asset Identification)

**Identifiser verdier som skal beskyttes:**
1. **Data**
   - Treningsdata (ofte personopplysninger)
   - Spørringer/prompts fra brukere
   - Loggdata fra AI-interaksjoner

2. **AI-modeller**
   - Proprietære modeller eller fine-tuned versjoner
   - Konfigurasjoner og prompt engineering
   - Vektinger og hyperparametre

3. **Tjenester**
   - Tilgjengelighet av AI-tjenesten
   - Integritet i beslutningsgrunnlag
   - Konfidensiell behandling av brukerdata

4. **Omdømme og tillit**
   - Tilliten til offentlig sektor
   - Virksomhetens ansvarlighetsmål

### Trusselvurdering (Threat Assessment)

**Kartlegg relevante trusler:**

| Trusselelement | Beskrivelse | Eksempel (AI-kontekst) |
|----------------|-------------|------------------------|
| **Sabotasje** | Forsettlig skade på system | Data poisoning, adversarial attacks |
| **Spionasje** | Uautorisert tilgang til informasjon | Model extraction, training data inference |
| **Svikt** | Tekniske eller menneskelige feil | Modell-drift, hallusinasjoner, bias |
| **Ulykke** | Utilsiktede hendelser | Feilklassifisering med alvorlige konsekvenser |

**AI-spesifikke trusler:**
- **Prompt injection** – manipulering av AI-respons via ondsinnet input
- **Jailbreaking** – omgåelse av sikkerhetsbegrensninger
- **Model inversion** – rekonstruksjon av treningsdata fra modell
- **Bias amplification** – systematisk forskjellsbehandling

### Sårbarhetsanalyse (Vulnerability Analysis)

**Vurder sårbarhet langs ulike dimensjoner:**

1. **Teknisk sårbarhet**
   - Eksponering av API-endepunkter
   - Manglende input-validering
   - Svak autentisering/autorisasjon
   - Manglende kryptering av data i transit/rest

2. **Organisatorisk sårbarhet**
   - Manglende kompetanse på AI-sikkerhet
   - Uklar ansvarsfordeling for AI-drift
   - Manglende prosedyrer for hendelseshåndtering

3. **Juridisk sårbarhet**
   - Uklare retningslinjer for AI-bruk
   - Manglende dokumentasjon av beslutningslogikk
   - Ikke-compliance med GDPR eller AI-forordningen

### Konsekvensanalyse (Impact Assessment)

**Vurder konsekvens på skala 1-5:**

| Nivå | Beskrivelse | Eksempel (AI) |
|------|-------------|---------------|
| **1 - Ubetydelig** | Ingen merkbar påvirkning | Trivielle feil i ikke-kritiske tjenester |
| **2 - Liten** | Begrenset påvirkning | Forsinkelser i saksbehandling |
| **3 - Moderat** | Merkbar påvirkning | Feilaktig avslag på søknad (reversibel) |
| **4 - Alvorlig** | Betydelig skade | Diskriminering i tjenesteyting |
| **5 - Svært alvorlig** | Katastrofal skade | Feil i helsebeslutninger med livsfare |

**Konsekvensdimensjoner:**
- Personvern og individuelle rettigheter
- Tjenestekvalitet og tilgjengelighet
- Juridiske konsekvenser (erstatning, sanksjoner)
- Omdømme og tillit
- Økonomisk tap

### Sannsynlighetsvurdering (Likelihood Assessment)

**Vurder sannsynlighet på skala 1-5:**

| Nivå | Beskrivelse | Estimat |
|------|-------------|---------|
| **1 - Svært lite sannsynlig** | Ekstremt sjelden hendelse | < 1 gang per 10 år |
| **2 - Lite sannsynlig** | Kan skje, men sjelden | 1 gang per 5-10 år |
| **3 - Mulig** | Kan skje med jevne mellomrom | 1 gang per 1-5 år |
| **4 - Sannsynlig** | Vil sannsynligvis skje | 1-5 ganger per år |
| **5 - Svært sannsynlig** | Forventes å skje ofte | Ukentlig/månedlig |

**Faktorer som påvirker sannsynlighet:**
- Eksponering (intern vs. eksternt tilgjengelig AI)
- Kompleksitet av systemet
- Modenhetsgrad på sikkerhetstiltak
- Trussel-landskap (målrettet vs. opportunistisk)

### Risikoberegning

**Risiko = Sannsynlighet × Konsekvens**

| Risiko | Farge | Tiltak |
|--------|-------|--------|
| **1-4** | 🟢 Grønn | Akseptabel – dokumenter og overvåk |
| **5-9** | 🟡 Gul | Moderat – vurder tiltak |
| **10-14** | 🟠 Oransje | Betydelig – implementer tiltak |
| **15-25** | 🔴 Rød | Uakseptabel – umiddelbare tiltak eller avslutt aktivitet |

**Eksempel:**
- **Trussel:** Prompt injection som gir tilgang til sensitiv data
- **Sannsynlighet:** 4 (sannsynlig – offentlig eksponert chatbot)
- **Konsekvens:** 4 (alvorlig – brudd på personvern)
- **Risiko:** 16 (rød – krever umiddelbare tiltak)

### Tiltaksplan (Risk Treatment)

**Fire hovedstrategier:**

1. **Redusere risiko** – implementere tekniske/organisatoriske tiltak
2. **Akseptere risiko** – dokumentert beslutning om å leve med restrisiko
3. **Overføre risiko** – forsikring, leverandøransvar
4. **Unngå risiko** – ikke implementere AI-løsningen

**Prioritering:**
- Røde risikoer først
- Fokuser på tiltak med høyest effekt vs. kostnad
- Kombiner flere tiltak for forsvar i dybden (defense-in-depth)

---

## AI-spesifikke risikoer

### Modellsikkerhet

**Trusler:**
- **Adversarial attacks** – subtile endringer i input som får modellen til å feile
- **Model poisoning** – manipulering av treningsdata for å påvirke modell
- **Backdoor attacks** – skjulte triggere som aktiverer ondsinnet oppførsel

**Tiltak:**
- Robust training med adversarial examples
- Validering av treningsdata (data provenance)
- Red teaming og penetrasjonstesting av AI-modeller
- Versjonshåndtering og auditlogg for modellendringer

### Dataintegritet og konfidensialitet

**Trusler:**
- **Training data leakage** – gjenoppbygging av treningsdata via model queries
- **Membership inference** – avdekke om spesifikke data var i treningssett
- **Data poisoning** – injisere korrupte data i treningspipeline

**Tiltak:**
- Differential privacy i treningsprosess
- Anonymisering og pseudonymisering
- Streng tilgangskontroll til treningsdata
- Kryptering av data i hvile og under overføring
- Secure multi-party computation (SMPC) for sensitive datasett

### Bias og diskriminering

**Trusler:**
- **Historisk bias** – gjenspeiling av diskriminering i treningsdata
- **Representasjonsbias** – underrepresenterte grupper i treningsdata
- **Aggregasjonsbias** – feil aggregering av data fra heterogene populasjoner

**Tiltak:**
- Fairness-testing på beskyttede grupper
- Balanserte datasett (resampling, synthetic data)
- Fairness constraints i treningsalgoritmer
- Kontinuerlig overvåking av ytelse per demografisk gruppe
- Menneskelig oversyn ved beslutninger som påvirker rettigheter

### Tilgjengelighet (Availability)

**Trusler:**
- **DDoS mot AI-endepunkter** – overbelaste modellen med forespørsler
- **Resource exhaustion** – langvarige eller komplekse queries som blokkerer tjenesten
- **Dependency failures** – feil i underliggende infrastruktur (Azure OpenAI throttling)

**Tiltak:**
- Rate limiting og throttling
- Caching av vanlige svar
- Redundans og failover-mekanismer
- Azure Front Door med DDoS-beskyttelse
- Kapasitetsplanlegging med PTU (Provisioned Throughput Units)

### Forklarbarhet og sporbarhet

**Trusser:**
- **Black-box problem** – umulig å forklare hvorfor AI tok en beslutning
- **Manglende audit trail** – ingen sporbarhet i beslutningsprosess
- **Repudiation** – bruker eller system nekter for handling

**Tiltak:**
- Explainable AI (XAI) metoder – SHAP, LIME
- Omfattende logging av alle AI-interaksjoner
- Menneske-i-løkken (HITL) for kritiske beslutninger
- Versjonering av modeller og beslutningslogikk
- Digital signering av AI-genererte beslutninger

---

## Microsoft-verktøy for risikostyring

### Azure Security Benchmark og Secure Score

**Funksjon:**
Azure Secure Score gir kontinuerlig vurdering av sikkerhetsstatus for Azure-ressurser.

**For AI-systemer:**
- Evaluer sikkerhet for Azure OpenAI, Azure AI Search, Azure ML
- Identifiser misconfigurations (f.eks. offentlig tilgjengelige endepunkter)
- Prioriterte anbefalinger for sikkerhetstiltak

**Praktisk bruk:**
```bash
# Azure CLI kommando for å hente Secure Score
az security secure-score list
```

### Microsoft Defender for Cloud

**Funksjon:**
CSPM (Cloud Security Posture Management) og trusseldeteksjon for Azure-ressurser.

**For AI-systemer:**
- **Defender for AI Workloads** (preview) – detekterer onormale AI-interaksjoner
- **Just-in-Time (JIT) access** – reduser eksponering av AI-administrasjonsportaler
- **Threat intelligence** – advarsler om kjente angrep mot AI-systemer

**Sikkerhetspolicies for AI:**
- Påkrev private endpoints for Azure OpenAI
- Krev managed identity istedenfor API keys
- Aktiver diagnostikklogging for alle AI-tjenester

### Microsoft Purview Compliance Manager

**Funksjon:**
Overvåk compliance med regelverk (GDPR, AI Act, ISO 27001).

**For AI-systemer:**
- **Compliance Score** – sporbare tiltak for AI-compliance
- **Improvement Actions** – spesifikke anbefalinger (f.eks. DPIA-mal)
- **Assessments** – forhåndsdefinerte maler for AI-relaterte regelverk

**Praktisk eksempel:**
1. Velg "Data Protection Baseline" assessment
2. Filtrer på AI-relevante kontroler (automated decision-making)
3. Dokumenter hvordan Azure OpenAI oppfyller GDPR Art. 22

### Microsoft Threat Modeling Tool

**Funksjon:**
Strukturert trusselmodellering basert på STRIDE-rammeverket.

**For AI-systemer:**
- Importer Azure-arkitektur (Azure AI Foundry, Copilot Studio)
- Identifiser trust boundaries (f.eks. bruker → AI → backend-database)
- Automatisk generering av trusler basert på dataflyt
- Eksport til Azure DevOps for sporing av tiltak

**STRIDE for AI:**
- **Spoofing** – forfalsket brukeridentitet i prompt
- **Tampering** – manipulering av treningsdata
- **Repudiation** – benekt AI-generert handling
- **Information Disclosure** – lekkasje av treningsdata
- **Denial of Service** – overbelasting av AI-endepunkt
- **Elevation of Privilege** – prompt injection som gir admin-tilgang

### Azure Policy og Blueprints

**Funksjon:**
Automatiser compliance-krav gjennom policy-as-code.

**Eksempler på AI-policies:**
```json
{
  "policyRule": {
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.CognitiveServices/accounts"},
        {"field": "Microsoft.CognitiveServices/accounts/publicNetworkAccess", "equals": "Enabled"}
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}
```
*Denne policyen blokkerer opprettelse av Azure OpenAI-ressurser med offentlig nettverkstilgang.*

**Azure Blueprints for AI:**
- Standard-oppsett med private endpoints, logging, og RBAC
- Compliance-preset for GDPR eller ISO 27001

### Microsoft Sentinel (SIEM)

**Funksjon:**
Security Information and Event Management for AI-tjenester.

**Bruksområder:**
- **Anomalideteksjon** – uvanlige mønstre i AI-bruk (f.eks. massiv datautvinning)
- **Threat hunting** – aktiv søking etter prompt injection-forsøk
- **Incident response** – automatiske playbooks ved AI-sikkerhetshendelser

**Eksempel-query (KQL):**
```kql
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| where ResultType == "Failure"
| where Properties contains "prompt injection"
| summarize count() by CallerIPAddress, bin(TimeGenerated, 1h)
```

---

## ROS-mal for AI-prosjekter

### Mal for ROS-analyse (Excel/tabellformat)

| ID | Trussel | Sårbarhet | Sannsynlighet (1-5) | Konsekvens (1-5) | Risiko | Eksisterende tiltak | Restrisiko | Nye tiltak | Ansvarlig | Frist |
|----|---------|-----------|---------------------|------------------|--------|---------------------|------------|------------|-----------|-------|
| AI-001 | Prompt injection | Ingen input-sanitering | 4 | 4 | 16 (🔴) | Ingen | 16 | Implementer Azure AI Content Safety | IT-sikkerhet | 2026-03-01 |
| AI-002 | Training data leakage | Ingen differential privacy | 2 | 5 | 10 (🟠) | Pseudonymisering | 10 | Differential privacy i ML pipeline | Data Science | 2026-04-01 |
| AI-003 | Bias i modell | Ubalansert treningsdata | 3 | 4 | 12 (🟠) | Ingen | 12 | Fairness-testing + diverse datasett | AI-lead | 2026-03-15 |
| AI-004 | DDoS mot API | Ingen rate limiting | 3 | 3 | 9 (🟡) | Azure Front Door | 6 | Rate limiting per bruker | DevOps | 2026-02-20 |

### Rapportmal

**1. Sammendrag**
- Kort beskrivelse av AI-systemet
- Overordnet risikonivå (rød/oransje/gul/grønn)
- Kritiske funn (røde risikoer)

**2. Systembeskrivelse**
- Formål og bruksområde
- Arkitektur (dataflyt-diagram)
- Brukergrupper og tilgangsnivåer

**3. Verdivurdering**
- Hvilke verdier skal beskyttes?
- Klassifisering av data (åpen, sensitiv, gradert)

**4. Trusselvurdering**
- Identifiserte trusler (intern/ekstern, forsettlig/utilsiktet)
- Trusselbilde (referanse til NSM, ENISA, OWASP)

**5. Risikoanalyse**
- Tabell med alle identifiserte risikoer (se mal over)
- Risikomatrise (heat map)

**6. Tiltaksplan**
- Prioriterte tiltak for røde/oransje risikoer
- Tidsplan og ansvarlig
- Ressursbehov

**7. Restrisiko og akseptanse**
- Dokumentert aksept av restrisiko av ledelsen
- Forbehold og forutsetninger

**8. Vedlegg**
- Referanser (lover, regelverk, standarder)
- Deltakerliste (hvem var involvert i analysen)
- Revisjonsplan (neste gjennomgang)

### Prosess-sjekkliste

**Før ROS-analyse:**
- [ ] Etabler tverrfaglig team (AI, jus, sikkerhet, domeneekspert)
- [ ] Skaff dokumentasjon (arkitektur, dataflyt, personvernkonsekvensvurdering)
- [ ] Definer scope (hvilke deler av AI-systemet dekkes?)

**Under ROS-analyse:**
- [ ] Identifiser verdier (hva skal beskyttes?)
- [ ] Kartlegg trusler (brainstorming, threat libraries)
- [ ] Vurder sårbarheter (gap-analyse mot beste praksis)
- [ ] Beregn risiko (sannsynlighet × konsekvens)
- [ ] Foreslå tiltak (teknisk, organisatorisk, juridisk)

**Etter ROS-analyse:**
- [ ] Dokumenter i rapport
- [ ] Få godkjenning fra ledelsen
- [ ] Implementer tiltak (følg opp i backlog)
- [ ] Planlegg neste revisjon (årlig eller ved vesentlige endringer)

---

## For arkitekten (Cosmo)

Når du møter en virksomhet som skal utføre ROS-analyse for et AI-system, bruk disse spørsmålene:

1. **Hva er formålet med AI-systemet?**
   - Hvilke beslutninger tar systemet? (automatiske eller assisterte)
   - Hvem er brukerne? (interne saksbehandlere, eksterne borgere)
   - Hvilke data behandles? (personopplysninger, sensitive opplysninger, gradert info)

2. **Hvilke juridiske krav gjelder?**
   - Er dette et høyrisiko AI-system ihht. AI Act?
   - Kreves DPIA etter GDPR Art. 35?
   - Gjelder særlovgivning (helseregisterloven, sikkerhetsloven)?

3. **Hvordan er AI-systemet arkitektonisk bygget?**
   - On-premises, cloud (Azure), hybrid?
   - Proprietær modell eller LLM-as-a-service (Azure OpenAI)?
   - Hvilke integrasjoner finnes? (databaser, fagsystemer, tredjepartstjenester)

4. **Hvilke trusler bekymrer virksomheten mest?**
   - Datalekkasje, bias, tjenestefeil, manipulering, omdømmetap?
   - Har det vært sikkerhetshendelser tidligere (for AI eller andre systemer)?

5. **Hvilke sikkerhetstiltak er allerede implementert?**
   - Input-validering, autentisering, kryptering, logging?
   - Content filtering (Azure AI Content Safety)?
   - Overvåking og alerting (Azure Monitor, Sentinel)?

6. **Hvem er ansvarlig for AI-sikkerheten?**
   - Finnes dedikert AI-sikkerhetsrolle?
   - Hvordan er ansvaret fordelt mellom IT, jus, og fagavdeling?

7. **Hvordan håndteres AI-hendelser?**
   - Finnes beredskapsplan for AI-feil eller angrep?
   - Hvem kontaktes ved mistanke om prompt injection eller datalekkasje?
   - Hvordan kommuniseres hendelser til brukere/berørte?

8. **Når skal ROS-analysen oppdateres?**
   - Årlig revisjon?
   - Ved vesentlige endringer (nye funksjoner, nye datasett, ny lovgivning)?
   - Etter sikkerhetshendelser?

**Anbefalinger basert på scope:**

| Scenario | Primær risiko | Anbefalt Microsoft-verktøy |
|----------|---------------|----------------------------|
| Intern chatbot for saksbehandling | Datalekkasje, bias | Azure OpenAI + Private Endpoint, Fairness-testing |
| Automatisk vedtak i forvaltning | Diskriminering, feilbeslutninger | Menneske-i-løkken, Explainable AI, omfattende logging |
| Prediktiv analyse på helsedata | Personvern, databrudd | Differential privacy, Defender for Cloud, Purview |
| Kunnskapsbase med RAG | Informasjonslekkasje | Azure AI Search med RBAC, Document-level security |

---

## Kilder og verifisering

### Norske myndigheter og organisasjoner

1. **Direktoratet for samfunnssikkerhet og beredskap (DSB)**
   - [Samfunnssikkerhet i arealplanlegging](https://www.dsb.no/veiledere-handboker-og-informasjonsmateriell/samfunnssikkerhet-i-kommunenes-arealplanlegging/) – Veileder til ROS-analyse som metode
   - [Helhetlig ROS i kommunen](https://www.dsb.no/lover/risiko-sarbarhet-og-beredskap/artikler/helhetlig-ros-i-kommunen/) – Metodikk for kommunal ROS

2. **Nasjonal sikkerhetsmyndighet (NSM)**
   - [Risikovurdering av IKT-systemer (PDF)](https://nsm.no/getfile.php/136603-1718717207/NSM/Filer/Bildegalleri/Bilder%20til%20grunnprinsipper/Risikovurdering%20av%20IKT-systemer.pdf) – Praktisk verktøy for risikovurdering
   - [NSMs Grunnprinsipper for IKT-sikkerhet v2.1 (PDF)](https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf) – 21 prinsipper og 118 sikkerhetstiltak
   - [Gode risikovurderinger ved tjenesteutsetting](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/sikkerhetsfaglige-anbefalinger-ved-tjenesteutsetting/gode-risikovurderinger-for-a-kunne-ta-riktig-beslutning/)

3. **Universitetet i Oslo (UiO)**
   - [Kapittel 7: Risiko- og sårbarhetsanalyser](https://www.uio.no/tjenester/it/sikkerhet/lsis/7.html) – Krav og metodikk for ROS i universitetssektor

4. **Finanstilsynet**
   - [Risiko- og sårbarhetsanalyse (ROS) 2024](https://www.finanstilsynet.no/publikasjoner-og-analyser/risiko--og-sarbarhetsanalyse/2024/ros-2024/risiko--og-sarbarhetsanalyse-ros-2024/) – Sektorspesifikk ROS for finansnæringen (inkl. IKT-risiko)

5. **KS (Kommunesektorens organisasjon)**
   - [Styrking av digital robusthet i kommunal sektor (PDF)](https://www.ks.no/contentassets/c1f4618f50e448069935735d9451765d/Digital-robusthet-i-kommunal-sektor-samlet.pdf) – Veiledning for kommuner om cybersikkerhet

6. **Datatilsynet**
   - [Risikovurdering](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/informasjonssikkerhet-internkontroll/risikovurdering/) – Personvernperspektivet på risikovurdering

### Microsoft Azure dokumentasjon

7. **Microsoft Learn – Threat Modeling**
   - [Security considerations for mission-critical workloads on Azure](https://learn.microsoft.com/en-us/azure/well-architected/mission-critical/mission-critical-security#threat-modeling) – STRIDE-rammeverk for Azure
   - [Architecture strategies for threat analysis](https://learn.microsoft.com/en-us/azure/well-architected/security/threat-model) – Microsoft Threat Modeling Tool
   - [Design secure applications on Azure](https://learn.microsoft.com/en-us/azure/security/develop/secure-design#design) – SDL og threat modeling i design-fasen

8. **Microsoft Training – Threat Modeling**
   - [Secure your infrastructure with threat modeling](https://learn.microsoft.com/en-us/training/modules/threat-modeling-enterprise-infrastructure/) – Praktisk trening i trusselmodellering
   - [Choose a client application with threat modeling](https://learn.microsoft.com/en-us/training/modules/threat-modeling-secured-environment/) – Sikkerhetsvurdering av applikasjoner
   - [Use a framework to identify threats](https://learn.microsoft.com/en-us/training/modules/tm-use-a-framework-to-identify-threats-and-find-ways-to-reduce-or-eliminate-risk/) – STRIDE-basert trusselidentifikasjon

9. **Microsoft Security Benchmark**
   - [DevOps Security – DS-1: Conduct threat modeling](https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-devop-security#ds-1-conduct-threat-modeling) – Integrere threat modeling i DevOps

10. **Microsoft Security Development Lifecycle**
    - [SDL Threat Modeling Tool](https://www.microsoft.com/securityengineering/sdl/threatmodeling) – Gratis verktøy for trusselmodellering

### Internasjonale standarder og rammeverk

11. **ISO/IEC 27005** – Information security risk management
12. **NIST SP 800-30** – Guide for Conducting Risk Assessments
13. **OWASP Threat Modeling** – [Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process)
14. **ENISA** – [AI Cybersecurity Challenges](https://www.enisa.europa.eu/topics/artificial-intelligence-cybersecurity) (EU-perspektiv på AI-risiko)

### Verifikasjon og aktualitet

Denne kunnskapsreferansen er basert på:
- **10 unike kilder** (DSB, NSM, Microsoft Learn, Datatilsynet, KS, Finanstilsynet, UiO)
- Dokumenter publisert i perioden **2021-2026**
- **NSMs Grunnprinsipper v2.1** (oppdatert 2024)
- **Microsoft Well-Architected Framework** (kontinuerlig oppdatert)
- Norsk regelverk gjeldende per **juni 2026**

**Sist verifisert:** 2026-06-19
**Neste revisjon:** 2026-09-19 (eller ved vesentlige endringer i AI-forordningen/NSM-veiledere)