ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md

ROS-rapportmaler for AI-systemer

Sist oppdatert: 2026-02 Kategori: Norwegian Public Sector AI Governance Status: Established Practice Formål: Standardiserte rapportmaler for ros-analysis-agent — Quick ROS og Full ROS Type: template

---

Innhold

• Oversikt
• Mal A: Quick ROS
• Mal B: Full ROS
• For Cosmo

Oversikt

To maler for ulike behov og målgrupper. Agenten velger mal basert på brukerens intensjon og tilgjengelig informasjon.

Mal	Omfang	Typisk lengde	Målgruppe	Trigger
Quick ROS	Top-10 risikoer, trafikklys-dashboard	~50–80 linjer	Ledelse, prosjektleder, produkteier	--quick flagg eller åpenbart behov
Full ROS	Komplett 8-fase NS 5814 prosess	~200–300 linjer	Arkitekturrevisjonsråd, DPO, CISO, anskaffelsesansvarlig	Standard (default)

Begge maler bruker identiske risiko-ID-serier (R-001, T-001) slik at Quick ROS enkelt kan utvides til Full ROS ved behov.

---

Mal A: Quick ROS

Bruk denne malen for raske orienteringsanalyser, statusoppdateringer til ledelsen, eller som inngang til en mer fullstendig analyse. Fyll inn alle placeholders markert med [...].

## ROS-analyse (Quick): [Systemnavn]

**Dato:** [YYYY-MM-DD]
**Versjon:** [1.0]
**Vurdert av:** ROS Analysis Agent (ms-ai-architect)
**Rekvirent:** [Navn / rolle]
**Metodikk:** NS 5814:2021 (forenklet), ISO 31000:2018
**Scope:** [Kort én-setnings beskrivelse av systemet og primær bruksflate]
**Klassifisering:** [Åpen / Begrenset / Fortrolig]

---

### Trafikklys per risikodimensjon

Scorene er vektede gjennomsnitt der 1 = svært lav risiko og 5 = svært høy risiko.
Trafikklys: 🟢 ≤ 2.0 (lav) | 🟡 2.1–3.5 (moderat) | 🔴 > 3.5 (høy/kritisk)

| Dimensjon | Vekt | Score | Status | Nøkkelfunn |
|-----------|------|-------|--------|------------|
| Modellsikkerhet og robusthet | 20 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Dataintegritet og personvern | 20 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Bias og diskriminering | 15 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Tilgjengelighet og robusthet | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Forklarbarhet og sporbarhet | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Juridisk og regulatorisk | 15 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Organisatorisk og menneskelig | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |

**Vektet totalscore:** X.XX / 5
**Risikokategori:** [Lav / Moderat / Høy / Kritisk]
**Overordnet trafikklys:** 🟢 / 🟡 / 🔴

---

### Top-10 risikoer

Rangert etter risikoscore (Sannsynlighet × Konsekvens, skala 1–5).

| # | Risiko-ID | Risikobeskrivelse | S | K | Score | Anbefalt tiltak |
|---|-----------|-------------------|---|---|-------|-----------------|
| 1 | R-001 | [Kort risikoformulering — hva kan gå galt, for hvem] | X | X | XX | [Konkret tiltaksforslag] |
| 2 | R-002 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 3 | R-003 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 4 | R-004 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 5 | R-005 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 6 | R-006 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 7 | R-007 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 8 | R-008 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 9 | R-009 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 10 | R-010 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |

S = Sannsynlighet (1–5), K = Konsekvens (1–5), Score = S × K (maks 25)

---

### Anbefaling

**[GO / GO med forbehold / NO-GO]**

[2–3 setninger som oppsummerer anbefalingen. Forklar begrunnelsen — hva veier tyngst, og hva er absolutte krav dersom anbefalingen er betinget.]

**Forutsetninger for GO (dersom relevant):**
- [Forutsetning 1]
- [Forutsetning 2]

---

### Neste steg

- [ ] [Tiltak 1 — ansvarlig rolle, frist]
- [ ] [Tiltak 2 — ansvarlig rolle, frist]
- [ ] [Tiltak 3 — ansvarlig rolle, frist]
- [ ] Vurder full ROS dersom systemet skaleres eller scope endres
- [ ] Planlegg revisjon om [6/12] måneder

---

*Generert av ros-analysis-agent (ms-ai-architect). Basert på informasjon oppgitt av rekvirent — ikke ekstern revisjon.*

---

Mal B: Full ROS

Bruk denne malen for alle AI-systemer som skal i produksjon i offentlig sektor, ved høy risiko-score i Quick ROS, eller der lovkrav (AI Act, sikkerhetsloven, forvaltningsloven) krever dokumentert risikovurdering. Alle faser er obligatoriske.

## ROS-analyse (Full): [Systemnavn]

**Dato:** [YYYY-MM-DD]
**Versjon:** [1.0 / revisjon X.Y]
**Vurdert av:** ROS Analysis Agent (ms-ai-architect)
**Rekvirent:** [Navn, rolle, enhet]
**Godkjent av:** [Navn, rolle — fylles inn manuelt]
**Metodikk:** NS 5814:2021, ISO 31000:2018, ISO/IEC 23894:2023
**Klassifisering:** [Åpen / Begrenset / Fortrolig]
**Gyldig til:** [YYYY-MM-DD — anbefalt 12 måneder eller ved vesentlig endring]

---

### Versjonsoversikt

| Versjon | Dato | Endring | Forfatter |
|---------|------|---------|-----------|
| 1.0 | [YYYY-MM-DD] | Første versjon | ROS Analysis Agent |

---

### Ledelsessammendrag

[3-5 avsnitt for beslutningstakere. Inkluderer:]
- Hva ble vurdert og hvorfor
- Samlet risikonivå (med trafikklys)
- Kritiske funn (røde risikoer) — maks 3
- Overordnet anbefaling (GO / GO med forbehold / NO-GO)
- Neste steg (maks 3 punkter)

---

### Fase 1: Scope og kontekst

#### 1.1 Systemidentifikasjon

| Felt | Verdi |
|------|-------|
| Systemnavn | [Navn] |
| Versjon / iterasjon | [X.Y] |
| Primær bruksflate | [Intern saksbehandling / publikumstjeneste / beslutningsstøtte / etc.] |
| Eierenhet | [Avdeling / direktorat] |
| Systemeier (rolle) | [Tittel] |
| Driftsansvarlig | [Internt / ekstern leverandør: navn] |
| Planlagt produksjonsdato | [YYYY-MM-DD] |

#### 1.2 Organisasjonskontekst

[Beskriv virksomhetens mandat, relevante strategier (digitaliseringsstrategi, AI-strategi), og hvordan dette systemet understøtter dem. 3–5 setninger.]

#### 1.3 Juridisk kontekst

[Liste opp alle relevante lover og regelverk som systemet er underlagt.]

- Forvaltningsloven (vedtaksstøtte, klagerett)
- Personopplysningsloven / GDPR (Art. [XX])
- EU AI Act — risikoklasse: [Uakseptabel / Høy risiko / Begrenset / Minimal]
- Sikkerhetsloven § [XX] (dersom relevant)
- Likestillings- og diskrimineringsloven § [XX]
- Sektorspesifikt: [Lov/forskrift]

#### 1.3.1 EU AI Act-klassifisering

| Kriterie | Vurdering | Kommentar |
|----------|-----------|-----------|
| Annex III-område | [Ja/Nei] | [Hvilket område] |
| Risikoklasse | [Uakseptabel/Høy/Begrenset/Minimal] | [Begrunnelse] |
| Krav utløst | [Art. 9, 13, 14, etc.] | [Spesifikke krav] |

#### 1.4 Avgrensninger

[Hva er eksplisitt utenfor scope for denne analysen. Eksempel: tredjeparts API-sikkerhet dekkes av leverandørs egne ROS.]

---

### Fase 2: Systembeskrivelse

#### 2.1 Funksjonell beskrivelse

[2–4 avsnitt som forklarer hva systemet gjør, hvordan brukere interagerer med det, og hvilke beslutninger eller handlinger det støtter eller automatiserer.]

**AI-komponenttype:** [Generativ AI / klassifisering / anbefaling / prediktiv / NLP / computer vision / hybrid]
**Grad av autonomi:** [Fullt manuelt (HITL alltid) / beslutningsstøtte / semi-autonomt / fullt autonomt]
**Modell(er):** [GPT-4o / Phi-4 / Azure AI Services / etc.]
**Plattform:** [Microsoft Foundry / Copilot Studio / Power Platform / Azure OpenAI / custom]

#### 2.2 Dataflyt

[Tegn enkel ASCII-dataflyt eller beskriv i punkter:]

Bruker → [Grensesnitt] → [Orkestrering / agent] → [AI-modell] → [Output] ↕ [Datakilder: intern DB, SharePoint, eksternt API] ↕ [Logging / auditlog / SIEM]

#### 2.3 Integrasjoner og avhengigheter

| System / tjeneste | Type | Eier | Kritikalitet |
|-------------------|------|------|--------------|
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |

#### 2.4 Brukere og berørte parter

| Gruppe | Antall (estimat) | Rolle | Sårbarhet |
|--------|-----------------|-------|-----------|
| [Saksbehandlere] | [XX] | Primærbruker | [Lav] |
| [Publikum / innbyggere] | [XX] | Sluttmottaker av beslutning | [Varierer] |
| [IT-driftsansvarlig] | [X] | Vedlikehold | [Lav] |
| [Spesielt sårbare grupper] | [Ukjent/XX] | Berørt part | [Høy] |

---

### Fase 3: Verdivurdering

#### 3.1 Informasjonsverdier (assets)

| Asset | Type | Konfidensialitet | Integritet | Tilgjengelighet | Samlet kritikalitet |
|-------|------|-----------------|------------|-----------------|---------------------|
| [Persondata / saksdokumenter] | Data | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [AI-modell / prompts] | System | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [Integrasjonsnøkler / API-tokens] | Konfigurasjon | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [Auditlog / sporingsdata] | Data | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |

#### 3.2 Kritikalitetsmatrise

| Asset | Konsekvens ved tap (K) | Sannsynlighet for tap (S) | Samlet (K×S) |
|-------|------------------------|---------------------------|---------------|
| [Asset 1] | [1–5] | [1–5] | [1–25] |
| [Asset 2] | [1–5] | [1–5] | [1–25] |

---

### Fase 4: Trusselidentifisering

Trusler er identifisert på tvers av STRIDE-kategorier og AI-spesifikke angrepsvektorer.

| Trussel-ID | Kategori | Trusselaktør | Beskrivelse | STRIDE | Angrepsvei |
|------------|----------|--------------|-------------|--------|------------|
| T-001 | Modellmisbruk | Ekstern aktør | Prompt injection via brukerinnput for å omgå sikkerhetspolicy | Tampering | Brukergrensesnitt |
| T-002 | Dataeksponering | Intern aktør | Utilsiktet eksponering av persondata i AI-generert svar | Information disclosure | Modelloutput |
| T-003 | Tilgjengelighetsangrep | Ekstern aktør | DDoS mot API-endepunkt | Denial of service | Nettverk |
| T-004 | Forsyningskjedeangrep | Trusselaktør | Kompromittering av tredjeparts AI-modell eller SDK | Tampering | Leverandørkjede |
| T-005 | Bias-utnyttelse | Systeminherent | Skjevheter i treningsdata gir diskriminerende output | [N/A — systemisk] | Modellarkitektur |
| T-006 | [Trussel] | [Aktør] | [Beskrivelse] | [STRIDE] | [Vei] |

*Legg til rader etter behov. STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.*

---

### Fase 5: Sårbarhetsanalyse

| Sårbarhet-ID | Knyttet til trussel | Beskrivelse | Eksisterende kontroll | Kontrolleffekt |
|--------------|---------------------|-------------|----------------------|----------------|
| V-001 | T-001 | Manglende input-validering og prompt-sanitering | Content Safety filters (Azure) | Moderat — omgås av avanserte angrep |
| V-002 | T-002 | Ingen systematisk PII-scrubbing av modellsvar | Manuell gjennomgang (delvis) | Lav |
| V-003 | T-003 | Rate limiting ikke implementert i dev-miljø | Azure APIM-kvote (prod) | Høy i prod, lav i test |
| V-004 | T-005 | Ingen formell bias-testing gjennomført | [Ingen] | Ingen |
| V-005 | [Trussel-ID] | [Beskrivelse] | [Kontroll] | [Effekt] |

#### 5.1 Vedlegg O-sjekk: Forsyningskjede og agentrisiko

| Sjekk | Relevant? | Status | Kommentar |
|-------|-----------|--------|-----------|
| MCP-servere / tredjeparts skills | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| RAG-pipeline med eksterne kilder | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Autonome agenter med tool-tilgang | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Multi-agent orkestrering | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Personlige AI-agenter (Copilot) | Ja/Nei | [OK/Gap/N/A] | [Detalj] |

---

### Fase 6: Risikoanalyse

#### 6.1 Risikoregister

| Risiko-ID | Beskrivelse | Årsak (V-ID) | Konsekvens | S | K | Brutto score | Eksisterende kontroll | Netto score | Eier |
|-----------|-------------|--------------|------------|---|---|--------------|-----------------------|-------------|------|
| R-001 | [Risikoformulering] | V-001 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-002 | [Risikoformulering] | V-002 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-003 | [Risikoformulering] | V-003 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-004 | [Risikoformulering] | V-004 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-005 | [Risikoformulering] | V-005 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |

S = Sannsynlighet (1–5), K = Konsekvens (1–5), Score = S × K (maks 25)

#### 6.2 Risikomatrise (5×5)

     Konsekvens →
          1       2       3       4       5
        Ubetyd  Liten   Moder   Alvor   Katas
     ┌───────┬───────┬───────┬───────┬───────┐

S 5 │ 5 │ 10 │ 15 │ 20 │ 25 │ ← Rød (> 15) a 4 │ 4 │ 8 │ 12 │ 16 │ 20 │ n 3 │ 3 │ 6 │ 9 │ 12 │ 15 │ ← Gul (8–15) n 2 │ 2 │ 4 │ 6 │ 8 │ 10 │ l 1 │ 1 │ 2 │ 3 │ 4 │ 5 │ ← Grønn (< 8) └───────┴───────┴───────┴───────┴───────┘

Plasser risikoer: R-001[S,K], R-002[S,K] ...

---

### Fase 7: Tiltaksplan

| Tiltak-ID | Adresserer | Tiltaksbeskrivelse | Strategi | Ansvarlig | Frist | Kostnad (est.) | Ny netto score |
|-----------|------------|--------------------|----------|-----------|-------|----------------|----------------|
| M-001 | R-001 | [Konkret tiltaksbeskrivelse] | Redusere | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-002 | R-002 | [Konkret tiltaksbeskrivelse] | Redusere | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-003 | R-003 | [Konkret tiltaksbeskrivelse] | Overføre | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-004 | R-004 | [Konkret tiltaksbeskrivelse] | Akseptere | [Rolle] | [YYYY-MM-DD] | — | [XX] |
| M-005 | R-005 | [Konkret tiltaksbeskrivelse] | Unngå | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |

Strategier: Unngå | Redusere | Overføre | Akseptere

#### 7.1 Implementeringstidslinje

[Nå]──────[30 dager]──────[60 dager]──────[90 dager]──────[6 mnd] │ │ │ │ │ M-001 M-002 M-003 M-004 Revisjon (kritisk) (høy prio) (moderat) (planlagt)

---

### Fase 8: Restrisiko og akseptanse

#### 8.1 Restrisikovurdering

| Risiko-ID | Beskrivelse | Restrisiko-score | Akseptabelt? | Begrunnelse |
|-----------|-------------|-----------------|--------------|-------------|
| R-001 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |
| R-002 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |
| R-003 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |

**Total restrisiko:** [Lav / Moderat / Høy / Kritisk]

#### 8.2 Akseptanseerklæring

[Dersom restrisiko er akseptabel:]
Systemeier bekrefter at restrisikonivået er akseptabelt og at beskrevne tiltak vil implementeres ihht. tiltaksplan. Systemet kan tas i bruk under forutsetning av at M-[XX] er implementert før produksjonsstart.

**Systemeier (signatur):** _________________________ Dato: __________
**CISO / informasjonssikkerhetsansvarlig:** _________________________ Dato: __________
**DPO (der GDPR-relevant):** _________________________ Dato: __________

---

### Dimensjonsvurdering (sammendrag)

| Dimensjon | Vekt | Brutto score | Netto score (etter tiltak) | Status |
|-----------|------|-------------|---------------------------|--------|
| Modellsikkerhet og robusthet | 20 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Dataintegritet og personvern | 20 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Bias og diskriminering | 15 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Tilgjengelighet og robusthet | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Forklarbarhet og sporbarhet | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Juridisk og regulatorisk | 15 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Organisatorisk og menneskelig | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| **Vektet total** | **100 %** | **X.XX / 5** | **X.XX / 5** | 🟢/🟡/🔴 |

**Risikokategori (brutto):** [Lav / Moderat / Høy / Kritisk]
**Risikokategori (netto):** [Lav / Moderat / Høy / Kritisk]

---

### Kryssreferanser

| Dokument | Status | Lenke / referanse |
|----------|--------|-------------------|
| DPIA / PVK | [Gjennomført / Pågår / Ikke påkrevd] | [Dokumentreferanse] |
| Sikkerhetsrevisjon | [Gjennomført / Planlagt / Ikke påkrevd] | [Dokumentreferanse] |
| ADR (Architecture Decision Record) | [Foreligger / Mangler] | [Dokumentreferanse] |
| AI Act conformity assessment | [Gjennomført / Pågår / Ikke påkrevd] | [Dokumentreferanse] |
| Leverandørs egne ROS / pen-test | [Foreligger / Mangler] | [Dokumentreferanse] |

---

### Referanser

- NS 5814:2021 — Krav til risikovurderinger
- ISO 31000:2018 — Risk management — Guidelines
- ISO/IEC 23894:2023 — Information technology — AI — Guidance on risk management
- EU AI Act (2024/1689) — særlig Art. 9 (risk management system) og Art. 13 (transparency)
- Datatilsynets veileder om kunstig intelligens og personvern (2023)
- Digdir Rammeverk for digital samhandling
- NSM Grunnprinsipper for IKT-sikkerhet 2.0
- NIST AI Risk Management Framework 1.0 (2023)

---

*Generert av ros-analysis-agent (ms-ai-architect plugin). Kilde: informasjon oppgitt av rekvirent og offentlig tilgjengelig dokumentasjon. Erstatter ikke ekstern revisjon eller juridisk rådgivning.*

---

For Cosmo

Bruk Mal A (Quick ROS) når bruker:

• Eksplisitt ber om rask oversikt eller "quick ROS"
• Er i tidlig utredningsfase og trenger orienteringsanalyse
• Allerede har fullstendig ROS og vil ha statusoppdatering

Bruk Mal B (Full ROS) i alle andre tilfeller — spesielt når:

• Systemet involverer persondata, sensitive kategorier eller automatiserte vedtak
• AI Act høyrisikoklassifisering er sannsynlig
• Rekvirent er i anskaffelses- eller godkjenningsfase
• Systemet driftes i offentlig sektor og berører innbyggere

Begge maler kan leveres på norsk eller engelsk — standard er norsk.