ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/compliance-requirements-bcdr.md

# Compliance Requirements for BCDR in Norwegian Public Sector

**Last updated:** 2026-06-24
**Status:** GA
**Category:** Business Continuity & Disaster Recovery
**Type:** reference
**Source:** https://learn.microsoft.com/azure/compliance

---

## Innhold

- [Introduksjon](#introduksjon)
- [Forvaltningslovens krav til kontinuitet](#forvaltningslovens-krav-til-kontinuitet)
- [GDPR og data residency-krav](#gdpr-og-data-residency-krav)
- [NSMs sikkerhetsveiledninger for kritisk infrastruktur](#nsms-sikkerhetsveiledninger-for-kritisk-infrastruktur)
- [Sektorspesifikke reguleringer](#sektorspesifikke-reguleringer)
- [Audit og dokumentasjonskrav](#audit-og-dokumentasjonskrav)
- [Referanser](#referanser)
- [For Cosmo](#for-cosmo)

## 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:

```markdown
## 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

```markdown
## 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

```markdown
## 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

```markdown
## 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

```markdown
## 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

```markdown
## Å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](https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-overview-wwps) — Data residency og compliance
- [Support your GDPR program with Accountability Readiness Checklists](https://learn.microsoft.com/en-us/compliance/regulatory/gdpr-arc) — GDPR compliance
- [Geographic data residency in Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/geo-data-residency) — Data residency for Copilot
- [Recommendations for defining reliability targets](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics) — SLO/RTO/RPO-definisjoner
- [Azure compliance offerings](https://learn.microsoft.com/en-us/azure/compliance/) — Azure compliance-dokumentasjon
- [NSM — Grunnprinsipper for IKT-sikkerhet](https://nsm.no/grunnprinsipper-ikt) — 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.