ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/compliance-requirements-bcdr.md

Compliance Requirements for BCDR in Norwegian Public Sector

Last updated: 2026-02 Status: GA Category: Business Continuity & Disaster Recovery

---

Introduksjon

Norske offentlige organisasjoner som bruker AI-tjenester i Azure er underlagt et komplekst regulatorisk landskap for Business Continuity and Disaster Recovery. Kravene kommer fra nasjonale lover (Forvaltningsloven, Sikkerhetsloven), EU-forordninger (GDPR, AI Act), sektorkrav (NSM, Digdir) og internasjonale standarder (ISO 22301, ISO 27001).

BCDR for AI-systemer i offentlig sektor har særlige utfordringer: data residency-krav begrenser hvilke Azure-regioner som kan brukes for DR, taushetsplikt stiller krav til kryptering og tilgangskontroll også i DR-scenarier, og Utredningsinstruksens krav til konsekvensanalyse påvirker hvordan DR-strategier velges og dokumenteres.

Denne referansen sammenfatter de viktigste regulatoriske kravene og gir praktisk veiledning for hvordan de påvirker BCDR-design for AI-løsninger i Azure.

Forvaltningslovens krav til kontinuitet

Relevant lovgivning

Lov/forskrift	Krav	Påvirkning på BCDR
Forvaltningsloven §11a	Forsvarlig saksbehandlingstid	AI-systemer som støtter saksbehandling må ha definert RTO
Forvaltningsloven §13	Taushetsplikt	DR-data må krypteres, tilgang begrenses
eForvaltningsforskriften §15	Tilgang til elektroniske tjenester	Digitale tjenester skal være tilgjengelige
Arkivlova §6	Bevaring av arkivmateriale	AI-generert innhold kan være arkivverdig
Offentleglova §6	Innsynskrav	AI-systemer må kunne levere data for innsyn

Krav til konsekvensanalyse

Utredningsinstruksen (KMD 2016) krever at statlige tiltak utredes før beslutning. For BCDR betyr dette:

## Konsekvensutredning for BCDR-strategi

### 1. Problem og mål
- Hva er risikoen ved manglende DR for AI-systemet?
- Hva er målet med DR-strategien (RTO/RPO)?

### 2. Alternativer
| Alternativ | RTO | RPO | Årlig kostnad | Risiko |
|-----------|-----|-----|---------------|--------|
| 0: Ingen DR | N/A | N/A | 0 kr | Høy — fullstendig tjenestebortfall |
| 1: Backup & Restore | 24t | 24t | 50,000 kr | Middels — lang nedetid |
| 2: Warm Standby | 15 min | 5 min | 300,000 kr | Lav — kort nedetid |
| 3: Active-Active | ~0 | ~0 | 600,000 kr | Svært lav — nær null nedetid |

### 3. Konsekvenser
- Økonomiske: Kostnad ved nedetid vs. DR-kostnad
- Administrative: Krav til bemanning og prosedyrer
- Samfunnsmessige: Påvirkning på brukere av offentlige tjenester

### 4. Anbefaling
[Anbefalt alternativ med begrunnelse]

GDPR og data residency-krav

GDPR Artikkel 32 — Sikkerhet ved behandling

GDPR krever "evnen til å sikre vedvarende konfidensialitet, integritet, tilgjengelighet og robusthet" for behandlingssystemer. For BCDR betyr dette:

GDPR-krav	BCDR-implikasjon	Azure-tiltak
Art. 32(1)(b)	Tilgjengelighet og robusthet	Multi-region DR
Art. 32(1)(c)	Evne til å gjenopprette tilgang	Definerte RTO/RPO
Art. 32(1)(d)	Regelmessig testing av sikkerhetstiltak	DR-drills
Art. 32(2)	Risikobasert tilnærming	BIA som grunnlag for DR

Data Residency og geo-replikering

## Godkjente Azure-regioner for norsk offentlig sektor

### Primærregioner (anbefalt)
- Norway East (Oslo) — Norsk datasuverenitetsregion
- Norway West (Stavanger) — Sekundær norsk region

### Sekundærregioner (DR, godkjent EU/EØS)
- Sweden Central (Gävle) — Typisk DR-region for Norway East
- North Europe (Dublin) — Alternativ EU-region
- West Europe (Amsterdam) — Alternativ EU-region

### Ikke godkjent uten tilleggsanalyse
- UK-regioner — Etter Brexit, krever separat vurdering
- US-regioner — Schrems II-problematikk
- APAC-regioner — Ikke relevant for offentlig sektor

Overføringsmekanismer for DR-data

Scenario	Overføringsmekanisme	Krav
Norway East → Sweden Central	EU/EØS intern	Ingen tilleggstiltak
Norway East → UK	SCCs + TIA	Tilleggsanalyse
Azure GRS (automatisk)	Avhenger av region-par	Verifiser at sekundær er EU/EØS
Backup til annen region	GDPR Art. 46	Dokumentér overføringsgrunnlag

DPIA for BCDR

## DPIA — BCDR-spesifikke vurderinger

### Tilgjengelighetsvurdering
- Hva er konsekvensen for registrerte ved tap av tilgang til AI-systemet?
- Kan vedtak fattes manuelt som fallback?
- Finnes det risiko for diskriminering ved degradert AI-funksjonalitet?

### Data i transit
- Er all DR-replikering kryptert (TLS 1.2+)?
- Går data gjennom tredjeland under replikering?
- Finnes det logger over alle dataoverføringer?

### Tredjepartstilgang
- Har Microsoft tilgang til data i DR-regionen?
  → Ja, men begrenset av Customer Lockbox og JIT
- Er det andre behandlere involvert i DR-prosessen?
  → Dokumentér i databehandleravtale

### Tiltak
| Risiko | Tiltak | Ansvarlig |
|--------|--------|-----------|
| Data i feil region | Verifiser GRS-konfiguration | Platform team |
| Ukryptert replikering | Enforce TLS i transit | Security team |
| Tap av tilgangskontroll | RBAC i DR-region | IAM team |

NSMs sikkerhetsveiledninger for kritisk infrastruktur

NSMs grunnprinsipper relevante for BCDR

Prinsipp	Krav	BCDR-tiltak
2.1 Kartlegg leveranser, systemer og avhengigheter	Forstå AI-systemets avhengigheter	Avhengighetskartlegging for alle AI-komponenter
2.2 Klassifiser virksomhetens verdier	Vurder kritikalitet av AI-data	BIA med klassifisering
2.3 Risikovurder virksomhetens digitale verdier	ROS-analyse	Inkluder tilgjengelighetstrusler
3.1 Beskytt virksomhetens verdier	Sikkerhet i DR-miljø	Identisk sikkerhetskonfigurasjon
4.1 Logg og overvåk	Loggføring også under DR	Sentralisert logging cross-region
4.3 Planlegg for å håndtere hendelser	Hendelseshåndtering	Runbooks og kommunikasjonsplaner

NSMs krav til beredskapsplanlegging

## Beredskapskrav for AI-systemer (NSM)

1. **Risikovurdering (ROS)**
   - Identifiser trusler mot AI-systemets tilgjengelighet
   - Vurder sannsynlighet og konsekvens
   - Definer akseptabelt risikonivå

2. **Beredskapsplan**
   - Dokumenterte gjenopprettingsprosedyrer
   - Definerte roller og ansvar
   - Kommunikasjonsprosedyrer
   - Eskaleringsrutiner

3. **Øvelser**
   - Minimum årlig fullskala DR-øvelse
   - Kvartalsvis tabletop-øvelse
   - Dokumentasjon av resultater og forbedringstiltak

4. **Rapportering**
   - Avviksrapportering til leder
   - Sikkerhetshendelsesrapportering til NSM/NCSC
   - Årlig statusrapport til ledelsen

Sektorspesifikke reguleringer

Helse (Normen)

Krav	Beskrivelse	BCDR-implikasjon
Tilgjengelighet	Kritiske systemer: 99.5% uptime	Multi-AZ minimum
Gjenoppretting	RTO < 4 timer for kritiske	Warm standby
Personvern	Helseopplysninger er sensitive	Kryptering i alle regioner
Logging	All tilgang til pasientdata logges	Cross-region logging

Finans (Finanstilsynet)

Krav	Beskrivelse	BCDR-implikasjon
IKT-forskriften §4	Adekvat IKT-beredskap	Dokumentert DR-plan
IKT-forskriften §7	Drift og overvåking	24/7 monitoring
DORA (EU)	Digital Operational Resilience	Regelmessig DR-testing

Kommunal sektor

Krav	Beskrivelse	BCDR-implikasjon
Kommuneloven §25-1	Internkontroll	BCDR som del av IK
Digitaliseringsrundskrivet	Digital tilgjengelighet	Definerte SLA
KS anbefalinger	IKT-sikkerhet i kommuner	Praktisk veiledning

Audit og dokumentasjonskrav

Påkrevd dokumentasjon

## BCDR Dokumentasjonspakke for Audit

### 1. Strategidokument
- [ ] BCDR-policy godkjent av ledelsen
- [ ] Kritikalitetsklassifisering av AI-systemer
- [ ] RTO/RPO-mål per system/komponent
- [ ] Valgt DR-strategi med begrunnelse

### 2. Teknisk dokumentasjon
- [ ] Arkitekturtegning med DR-konfigurasjon
- [ ] Nettverksdiagram inkl. failover-ruter
- [ ] Data flow diagram med replikering
- [ ] Konfigurasjonsdetaljer per Azure-tjeneste

### 3. Operasjonell dokumentasjon
- [ ] DR-runbooks (failover og failback)
- [ ] Eskaleringsmatrise
- [ ] Kommunikasjonsplan
- [ ] Kontaktliste (primær og backup)

### 4. Test og verifisering
- [ ] DR-testplan med frekvens og omfang
- [ ] Testrapporter fra gjennomførte DR-drills
- [ ] Avvikslogg med korrigerende tiltak
- [ ] Måloppnåelse (faktisk vs. planlagt RTO/RPO)

### 5. Compliance-dokumentasjon
- [ ] DPIA med BCDR-vurderinger
- [ ] Databehandleravtale som dekker DR
- [ ] Overføringsgrunnlag for cross-region data
- [ ] Årlig compliance-rapport

Revisjons-sjekkliste

## Årlig BCDR Revisjons-sjekkliste

### Governance
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 1 | BCDR-policy er oppdatert og godkjent | ☐ | |
| 2 | Roller og ansvar er dokumentert | ☐ | |
| 3 | Ledelsen er informert om DR-status | ☐ | |

### Teknisk
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 4 | DR-konfigurasjon matcher dokumentasjon | ☐ | |
| 5 | Replikering fungerer korrekt | ☐ | |
| 6 | Backup er verifisert | ☐ | |
| 7 | IaC-maler er oppdatert | ☐ | |

### Testing
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 8 | Fullskala DR-test gjennomført siste 12 mnd | ☐ | |
| 9 | RTO-mål oppnådd i test | ☐ | |
| 10 | RPO-mål oppnådd i test | ☐ | |
| 11 | Forbedringstiltak implementert | ☐ | |

### Compliance
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 12 | GDPR-krav ivaretatt i DR | ☐ | |
| 13 | Data residency verifisert | ☐ | |
| 14 | NSM-krav etterlevd | ☐ | |
| 15 | Sektorspesifikke krav dekket | ☐ | |

Referanser

• Azure for secure worldwide public sector cloud adoption — Data residency og compliance
• Support your GDPR program with Accountability Readiness Checklists — GDPR compliance
• Geographic data residency in Copilot Studio — Data residency for Copilot
• Recommendations for defining reliability targets — SLO/RTO/RPO-definisjoner
• Azure compliance offerings — Azure compliance-dokumentasjon
• NSM — Grunnprinsipper for IKT-sikkerhet — Norske sikkerhetskrav

For Cosmo

• Bruk denne referansen når kunden er en norsk offentlig organisasjon og trenger veiledning om regulatoriske krav til BCDR for AI-systemer.
• Start alltid med å identifisere hvilke sektorkrav som gjelder (helse, finans, kommunal, statlig) — dette påvirker RTO/RPO-krav direkte.
• Data residency er en showstopper: ALDRI foreslå DR-regioner utenfor EU/EØS for norsk offentlig sektor uten eksplisitt juridisk vurdering.
• Påminn om at GDPR Art. 32 eksplisitt nevner tilgjengelighet — mangelfull BCDR kan være et GDPR-brudd.
• Utredningsinstruksens krav til alternativanalyse betyr at kunden bør evaluere minst 3 BCDR-alternativer med kost/nytte-vurdering.