ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-dpia-security-integration.md

# Integrasjonsguide: ROS, DPIA og sikkerhetsvurdering

**Last updated:** 2026-02
**Category:** Norwegian Public Sector AI Governance
**Status:** Established Practice
**Formål:** Veiledning for koordinering mellom ROS-analyse, DPIA og sikkerhetsvurdering — unngå duplisering, sikre dekning, og produser et sammenhengende risikovurderingsgrunnlag
**Type:** methodology

---

## Innhold

- [Oversikt](#oversikt)
- [Beslutningstre: Hvilke vurderinger er påkrevd?](#beslutningstre-hvilke-vurderinger-er-påkrevd)
- [Overlap-matrise: Hva dekkes av hva?](#overlap-matrise-hva-dekkes-av-hva)
- [Sekvensieringsanbefaling](#sekvensieringsanbefaling)
- [Cross-referencing mellom agenter: Konkrete eksempler](#cross-referencing-mellom-agenter-konkrete-eksempler)
- [Compliance-dekningsmatrise](#compliance-dekningsmatrise)
- [Praktisk arbeidsflyt med `/architect`-kommandoer](#praktisk-arbeidsflyt-med-architect-kommandoer)
- [Ansvarsfordeling mellom roller](#ansvarsfordeling-mellom-roller)
- [Dokumentasjonskrav og oppbevaring](#dokumentasjonskrav-og-oppbevaring)
- [For arkitekten](#for-arkitekten)

## Oversikt

Tre vurderingstyper dekker ulike aspekter av AI-risiko i norsk offentlig sektor. Alle tre kan bestilles via separate `/architect`-kommandoer, men gir størst verdi når de gjennomføres koordinert og cross-referanser hverandre eksplisitt.

| Vurdering | Primærfokus | Metodisk grunnlag | Agent |
|-----------|-------------|-------------------|-------|
| **ROS-analyse** | Alle risikodimensjoner (7 stk.) — teknisk, organisatorisk, regulatorisk, personvern, etikk, operasjonell, strategisk | NS 5814, ISO 31000, internkontrollforskriften | `ros-analysis-agent` |
| **DPIA** | Personvernrisiko for registrerte — sannsynlighet og alvorlighet ved behandling av personopplysninger | GDPR art. 35, Datatilsynets DPIA-veileder | `dpia-agent` |
| **Sikkerhetsvurdering** | Teknisk sikkerhet i 6 dimensjoner — identitet, nettverk, data, applikasjon, trusseldeteksjon, overholdelse | MCSB v2, OWASP LLM Top 10, NSM Grunnprinsipper | `security-assessment-agent` |

Vurderingene overlapper delvis, men har ulike formål, metodikk og juridisk forankring. Overlapp er en styrke — det gir uavhengig verifisering av de mest kritiske risikoene.

---

## Beslutningstre: Hvilke vurderinger er påkrevd?

```
Er systemet et AI-system i norsk offentlig sektor?
│
├── Ja
│   │
│   ├── ROS-analyse: ALLTID PÅKREVD
│   │   Hjemmel: internkontrollforskriften § 4, NS 5814, sektorlovgivning
│   │
│   ├── Behandler systemet personopplysninger?
│   │   ├── Ja
│   │   │   └── DPIA: PÅKREVD (GDPR art. 35)
│   │   │       Særlig dersom: systematisk og omfattende profilering,
│   │   │       behandling av særlige kategorier i stor skala,
│   │   │       systematisk overvåkning av offentlig tilgjengelig område,
│   │   │       AI Act høyrisikoklassifisering (Annex III)
│   │   └── Nei
│   │       └── DPIA: Ikke juridisk påkrevd
│   │           Anbefalt dersom systemet kan behandle personopplysninger
│   │           indirekte (aggregert data, avledet identifikasjon)
│   │
│   └── Skal systemet i produksjon med Azure/M365/skybasert infrastruktur?
│       ├── Ja
│       │   └── Sikkerhetsvurdering: STERKT ANBEFALT
│       │       Krav: NSM Grunnprinsipper, virksomhetens sikkerhetsinstruks,
│       │       evt. sektorkrav (Normen, DORA, POD-instruks)
│       └── Nei (Copilot Studio SaaS, Microsoft-administrert)
│           └── Sikkerhetsvurdering: ANBEFALT for delte ansvarsforhold
│               Fokus: konfigurasjon, tilgangsstyring, dataeksponering
│
└── Nei (privat sektor eller intern forskning uten offentlig forvaltningsfunksjon)
    └── Vurder behov individuelt basert på sektorkrav og risikonivå
```

**Tommelfingerregel for norsk offentlig sektor:** Gjennomfør alle tre for ethvert AI-system som håndterer personopplysninger og settes i produksjon. Totalvurderingen er sterkere enn enkeltdelene.

---

## Overlap-matrise: Hva dekkes av hva?

Matrisen viser hvilken vurdering som har primæransvar (P), hvilken som gir sekundærdekning (S), og hvilke risikoer som ikke dekkes (-) av den enkelte vurderingstype.

| Risikoområde | ROS | DPIA | Sikkerhet | Merknad |
|--------------|:---:|:----:|:---------:|---------|
| Teknisk infrastrukturrisiko | S | - | **P** | Sikkerhetsvurdering gir teknisk dybde |
| Nettverkssikkerhet og eksponering | S | - | **P** | Inkl. zero trust, perimetersikkerhet |
| Identitets- og tilgangsstyring | S | S | **P** | RBAC, MFA, Privileged Identity Management |
| Modellangrep (prompt injection, jailbreak) | S | - | **P** | OWASP LLM Top 10 — primært teknisk |
| Konfidensialitet av personopplysninger | S | **P** | S | DPIA gir juridisk dybde |
| Rettighetene til de registrerte (innsyn, sletting) | S | **P** | - | GDPR art. 12-23 — DPIA primær |
| Databehandleravtaler (DPA) | - | **P** | S | DPIA inkl. DPA-vurdering |
| Internasjonale dataoverføringer (Schrems II) | S | **P** | S | DPIA primær, sikkerhet gir teknisk dokumentasjon |
| Bias og diskriminering | **P** | S | - | ROS bredt, DPIA for personvern-vinkelen |
| Formålsbegrensning og dataminimering | S | **P** | - | Personvernprinsipp — DPIA primær |
| Ansvar og beslutningskjede (human-in-the-loop) | **P** | S | S | ROS som governance-vurdering |
| Regulatorisk etterlevelse (sektorlov) | **P** | S | S | ROS ivaretar helhetlig regulatorisk sjekk |
| AI Act-klassifisering og krav | **P** | S | S | ROS som overordnet ramme |
| GDPR art. 35 DPIA-plikt vurdering | S | **P** | - | DPIA vurderer selv sin egen nødvendighet |
| Systemtilgjengelighet og BCDR | **P** | - | S | ROS identifiserer, sikkerhet gir tekniske tiltak |
| Organisatorisk beredskap | **P** | - | - | ROS som eneste som dekker dette |
| Etikk og samfunnskonsekvenser | **P** | S | - | ROS bredt — DPIA for personvern-etikk |
| Modell-transparens og forklaring | **P** | S | - | ROS dekker XAI-krav |
| Opplærings- og kompetanserisiko | **P** | - | - | ROS dekker organisatorisk risiko |

**Legende:** P = Primæransvar, S = Sekundærdekning, - = Ikke dekket

---

## Sekvensieringsanbefaling

Optimal rekkefølge gir effektiv risikoidentifisering og minimerer duplisert arbeid:

### Fase 1: ROS-analyse (bredt, bredt)

**Tidspunkt:** Tidlig i designfase — før teknisk arkitektur er låst
**Formål:** Bred identifisering av alle risikodimensjoner. ROS-analysen fungerer som en overordnet risikolandskapsanalyse som setter agenda for de påfølgende dypvurderingene.
**Output brukt i:** DPIA (personvernrisikoer fra ROS prioriteres), Sikkerhetsvurdering (tekniske risikoer fra ROS gir fokusområder)

**Nøkkelaktiviteter:**
1. Identifiser alle risikodimensjoner (teknisk, regulatorisk, bias, personvern, etikk, operasjonell, strategisk)
2. Klassifiser systemet mot AI Act-risikoklasser og norsk sektorregelverk
3. Flagg hvilke risikoer som krever dypere DPIA-vurdering
4. Flagg hvilke tekniske risikoer som krever sikkerhetsvurdering

### Fase 2: DPIA og Sikkerhetsvurdering (parallelt)

**Tidspunkt:** Etter ROS, før produksjonssetting
**Formål:** Dypvurderinger av spesifikke risikodimensjoner identifisert i ROS
**Parallelitet:** DPIA og sikkerhetsvurdering kan gjennomføres parallelt — de deler lite overlapp i metode og ansvarlig personell

**DPIA:**
- Bygger på personvernrisikoer identifisert i ROS
- Gir juridisk forankret vurdering av konsekvenser for registrerte
- Output: DPA-krav, mitigeringstiltak, restkrisiko-godkjenning

**Sikkerhetsvurdering:**
- Bygger på tekniske risikoer identifisert i ROS
- Gir teknisk dybdeanalyse av sikkerhetsarkitektur
- Output: Sikkerhetsscore (1-5 per dimensjon), tekniske tiltak, sikkerhetsbriefing

### Fase 3: Konsolidering og samlerapport

**Tidspunkt:** Etter fase 1 og 2, før produksjonsgodkjenning
**Formål:** Cross-referansering og produksjon av samlet beslutningsgrunnlag
**Agent:** `summary-agent` via `/architect:summary`

**Nøkkelaktiviteter:**
1. Identifiser motstridende funn mellom vurderingene og løs dem
2. Bekreft at alle ROS-flaggede risikoer er adressert i DPIA eller sikkerhetsvurdering
3. Konsolider tiltak til én samlet tiltaksplan med prioritering
4. Produser beslutningsnotat for tjenesteeier og DPO

---

## Cross-referencing mellom agenter: Konkrete eksempler

### Eksempel 1: Personvernrisiko → Teknisk tiltak

**ROS finner:** Høy risiko for uautorisert tilgang til sensitive personopplysninger via RAG-grunnlag
**DPIA utdyper:** Behandlingen er i strid med dataminimeringsprinsippet — modellen har tilgang til mer data enn nødvendig for hvert spørsmål
**Sikkerhetsvurdering svarer:** Anbefaler row-level security i Azure AI Search + Entra ID-gruppebasert tilgangskontroll per dokumentsamling
**Konsolidert tiltak:** Implementer document-level ACL i AI Search koblet til Entra-grupper, med DPIA-godkjent dataflytdiagram som vedlegg

### Eksempel 2: Teknisk sårbarhet → Juridisk implikasjon

**Sikkerhetsvurdering finner:** Prompt injection-sårbarhet lar brukere hente ut innhold fra andres dokumenter via RAG
**DPIA utdyper:** Dette utgjør et potensielt brudd på GDPR art. 32 (sikkerhet ved behandling) og art. 5 nr. 1 litra f (integritet og konfidensialitet)
**ROS kontekstualiserer:** Sannsynlighet klassifiseres som høy (kjent angrepsvektor), konsekvens kritisk (brudd på taushetsplikt for helsedata)
**Konsolidert tiltak:** Blokkerende — system kan ikke settes i produksjon uten implementering av Prompt Shield og doc-level ACL

### Eksempel 3: Regulatorisk risiko → Delt ansvar

**ROS finner:** Systemet bruker Azure OpenAI i US East — Schrems II-risikovurdering mangler
**DPIA utdyper:** Overføring av personopplysninger til tredjeland krever SCCs + TIA (Transfer Impact Assessment) etter Datatilsynets veileder
**Sikkerhetsvurdering svarer:** Bekrefter at Azure tilbyr EU Data Boundary med norsk dataresidensopsjoner — anbefaler migrasjon til Sweden Central
**Konsolidert tiltak:** Migrer til Azure Sweden Central, dokumenter EU Data Boundary i DPA, gjennomfør forenklet TIA

### Eksempel 4: Bias-risiko → Tverrfaglig tilnærming

**ROS finner:** Høy risiko for demografisk bias i AI-basert saksbehandling — modellen er trent på historiske data med skjevhet
**DPIA utdyper:** Automatisert beslutning med rettsvirkninger utløser GDPR art. 22 — borger har rett til menneskelig overprøving
**Sikkerhetsvurdering:** Begrenset relevans for selve bias-risikoen, men anbefaler logging av alle AI-anbefalinger for etterhåndskontroll
**Konsolidert tiltak:** Implementer obligatorisk menneskelig kontroll (human-in-the-loop) for alle negative vedtak, etabler fairness-dashboard, dokumenter art. 22-begrunnelse i behandlingsprotokollen

---

## Compliance-dekningsmatrise

Matrisen viser hvilke regulatoriske krav som er dekket av hvilken vurdering, og om kombinasjonen av alle tre gir fullstendig dekning.

| Krav / Regelverk | ROS | DPIA | Sikkerhet | Alle tre | Merknad |
|-----------------|:---:|:----:|:---------:|:--------:|---------|
| NS 5814 (ROS-metodikk) | Primær | - | - | Ja | ROS alene dekker |
| ISO 31000 (risikostyring) | Primær | - | - | Ja | ROS alene dekker |
| GDPR art. 35 (DPIA-plikt) | Delvis | Primær | - | Ja | DPIA bekrefter og gjennomfører |
| GDPR art. 5 (prinsipper) | Delvis | Primær | Delvis | Ja | Kombinert dekning |
| GDPR art. 22 (automatiserte beslutninger) | Primær | Primær | - | Ja | Begge nødvendig |
| GDPR art. 32 (sikkerhet ved behandling) | Delvis | Primær | Primær | Ja | Sikkerhet gir teknisk innhold til DPIA |
| AI Act art. 9 (Risk Management System) | Primær | Delvis | Delvis | Ja | ROS er kjernen, supplert |
| AI Act art. 10 (datakvalitet) | Primær | Delvis | - | Ja | ROS + DPIA kombinert |
| AI Act art. 13 (transparens) | Primær | Delvis | - | Ja | ROS primær |
| AI Act art. 14 (human oversight) | Primær | Delvis | - | Ja | ROS primær |
| AI Act Annex III (høyrisikovurdering) | Primær | Delvis | Delvis | Ja | ROS klassifiserer, alle bidrar |
| NSM Grunnprinsipper (IKT-sikkerhet) | Delvis | - | Primær | Ja | Sikkerhetsvurdering gir primærdekning |
| Internkontrollforskriften | Primær | - | - | Ja | ROS alene dekker |
| Normen v7.0 (helse-IT) | Delvis | Primær | Primær | Ja | Tre-veis kombinasjon nødvendig |
| DORA (finansforetak) | Delvis | - | Primær | Ja | Sikkerhet primær, ROS supplerer |
| Schrems II / SCCs | Delvis | Primær | Delvis | Ja | DPIA primær, sikkerhet gir teknisk vedlegg |
| Datatilsynets DPIA-veileder | - | Primær | - | Ja | DPIA alene dekker |

---

## Praktisk arbeidsflyt med `/architect`-kommandoer

### Full triptykvurdering (anbefalt for høyrisikosystemer)

```
Steg 1: Bestill ROS-analyse
/architect → velg "Risiko- og sårbarhetsanalyse (ROS)"

Steg 2: Gjennomfør ROS med ros-analysis-agent
→ Identifiser flaggede personvernrisikoer
→ Identifiser flaggede tekniske risikoer
→ Lagre rapport som ros-rapport-[system]-[dato].md

Steg 3: Bestill DPIA parallelt med sikkerhetsvurdering
/architect:dpia → dpia-agent gjennomfører strukturert intervju
/architect:security → security-assessment-agent scorer 6 dimensjoner

Steg 4: Konsolider med summary-agent
/architect:summary → Les ros-rapport + dpia-rapport + sikkerhets-rapport
→ Produser samlet beslutningsnotat med prioriterte tiltak

Steg 5: Eksporter til PDF
/architect:export → Generer PDF-pakke for tjenesteeier og DPO
```

### Hurtigvurdering (lavrisikosystemer)

For systemer i AI Act lavrisiko-kategori uten behandling av særlige kategorier:

```
Steg 1: ROS-analyse (forenklet)
/architect → ROS → velg "forenklet vurdering"

Steg 2: Integrer personvern og sikkerhet i ROS
→ Be ros-analysis-agent inkludere personvern- og sikkerhetsaspekter
→ Dokumenter at fullstendig DPIA ikke er nødvendig og begrunn dette

Steg 3: Sikkerhetssjekk (begrenset)
/architect:security → Focus på kritiske dimensjoner (identitet, data)
```

### Revidering og re-vurdering

Gjennomfør ny vurderingssyklus ved:
- Vesentlige endringer i AI-modell, treningsdata eller systemarkitektur
- Ny sektorlovgivning eller tilsynspraksis med materielle konsekvenser
- Hendelser (datainnbrudd, modellsvikt, klage fra bruker)
- Planlagt intervall: Minimum hvert annet år for høyrisikosystemer

```
Steg 1: Identifiser endringsomfang (change impact)
/architect → beskriv endringen → be om "delta-vurdering"

Steg 2: Oppdater kun berørte vurderinger
→ Vesentlig modellendring: ROS + Sikkerhet
→ Ny behandlingsaktivitet: DPIA
→ Ny plattform: Alle tre
```

---

## Ansvarsfordeling mellom roller

| Aktivitet | Primæransvarlig | Bidragsytere |
|-----------|----------------|--------------|
| Bestille og eie ROS | Tjenesteeier / IT-leder | Arkitekt, DPO |
| Gjennomføre ROS | Arkitekt / Sikkerhetsansvarlig | Fageksperter, DPO |
| Bestille DPIA | DPO | Tjenesteeier |
| Gjennomføre DPIA | DPO | Systemutvikler, juridisk |
| Bestille sikkerhetsvurdering | IT-sikkerhetsleder | Arkitekt |
| Gjennomføre sikkerhetsvurdering | Sikkerhetsarkitekt | Infrastruktur, DevOps |
| Konsolidere og beslutte | Tjenesteeier | DPO, Sikkerhetssjef |
| Godkjenne produksjonssetting | Leder med fullmakt | Tjenesteeier, DPO |

---

## Dokumentasjonskrav og oppbevaring

Alle tre vurderinger skal dokumenteres og oppbevares i henhold til følgende minimumskrav:

| Dokument | Oppbevaringstid | Format | Tilgjengelighet |
|---------|----------------|--------|----------------|
| ROS-rapport | Systemets levetid + 5 år | PDF / Markdown | Tjenesteeier, Tilsyn ved forespørsel |
| DPIA-rapport | Behandlingsaktivitetens varighet + 3 år | PDF | DPO, Datatilsynet ved forespørsel |
| Sikkerhetsvurdering | Systemets levetid + 3 år | PDF (delvis gradert) | Sikkerhetssjef, NSM ved forespørsel |
| Samlet beslutningsnotat | Systemets levetid | PDF | Tjenesteeier, intern revisjon |
| Tiltaksplan (åpen) | Til tiltak er lukket + 1 år | Markdown / Jira | Prosjektteam |

---

## For arkitekten

Bruk denne guiden for å hjelpe virksomheter med å planlegge og koordinere triptykvurderingen. Vurder alltid hvilke av de tre vurderingene som er påkrevd (beslutningstre), anbefal parallell gjennomføring av DPIA og sikkerhet etter ROS, og avslutt alltid med konsolidering via summary-agent. Pek på konkrete eksempler fra overlap-matrisen når du forklarer hvorfor alle tre er nødvendig — den vanligste feilen er å gjennomføre kun én og tro at det er tilstrekkelig.