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

Integrasjonsguide: ROS, DPIA og sikkerhetsvurdering

Sist oppdatert: 2026-02 Kategori: 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

---

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 Cosmo

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.