DigiReq/Dokumentsenter/Beredskap og kontinuitet
← Tilbake til digireq.no

Beredskap og kontinuitet

Versjon 1.0 · 29. mai 2026 · Backup, RTO/RPO, hendelseshåndtering og fallback-prosedyrer

Kort fortalt: Daglig kryptert backup med 7 dagers oppbevaring. Recovery time objective (RTO): 4 timer. Recovery point objective (RPO): 24 timer. Mobil-app fungerer offline for å vise allerede-godkjente rekvisisjoner i butikk.

1. Formål og virkeområde

Beskriver hvordan DigiReq håndterer tap av tilgjengelighet, datatap, og krise-scenarier. Komplementerer sikkerhetsside (tekniske tiltak) og SLA-en (kontraktsmessige mål).

2. Mål for gjenoppretting

MålVerdiBeskrivelse
RTO (Recovery Time Objective)4 timerMaks tid fra hendelses-start til tjenesten er operasjonell igjen
RPO (Recovery Point Objective)24 timerMaks datatap målt i tid — tilsvarer 1 dags rekvisisjoner i verste fall
MTTR (Mean Time To Repair)2 timer (mål)Gjennomsnittlig tid for å rette en feil
MTBF (Mean Time Between Failures)30 dager (mål)Forventet tid mellom uventede feil

3. Backup-strategi

3.1 Database (PostgreSQL)

3.2 Applikasjons-kode

3.3 Konfigurasjon og secrets

3.4 Audit-logg

3.5 Hva som IKKE backes opp

4. Gjenopprettingsprosedyrer

4.1 Database-korrupsjon eller -tap

  1. Hent siste gode Hetzner-snapshot (≤ 24 t gammel)
  2. Opprett ny PostgreSQL-instans fra snapshot
  3. Pek DATABASE_URL i .env mot ny instans
  4. Restart digireq-api.service
  5. Valider med /health-endepunkt (skal returnere db: true)
  6. Manuell sanity-sjekk: telle requisitions for 3-5 kunder mot deres egen statistikk

Estimat: 1-2 timer til funksjonell tjeneste; opp til 4 timer ved store data-volum.

4.2 VPS-utfall (Hetzner Helsinki nede)

  1. Vurder om utfallet er forventet kort (< 1 t) — vent ut
  2. Ved lengre utfall: provisjoner ny Hetzner-VPS i annet datasenter (typisk Nürnberg)
  3. Kjør deploy/install.sh med Postgres-passord
  4. Restore fra siste tilgjengelige database-snapshot
  5. Oppdater DNS (Cloudflare) for api.digireq.no til ny IP
  6. Vente på DNS-propagering (TTL 5 min)

Estimat: 3-4 timer; lengre hvis Hetzner-API selv er nede.

4.3 Domain/DNS-utfall (Cloudflare)

4.4 SMS-leverandør-utfall (46elks)

4.5 Push-utfall (Apple APNs / Google FCM / Expo)

5. Hendelseshåndtering

5.1 Klassifisering

Hendelser klassifiseres etter samme skala som SLA §4:

5.2 Respons-prosedyre (Alvorlighet 1)

  1. 0-15 min: deteksjon (UptimeRobot-varsel eller kundetilbakemelding)
  2. 15-30 min: verifikasjon — sjekk /health, logger, gjennomgå nylige deploys
  3. 30-60 min: aktiv arbeids-start, kommunikasjon til pågående kunder via e-post
  4. 60-240 min: løsning eller workaround
  5. +24 t: sikkerhetsbrudd-varsel sendes hvis personopplysninger er eksponert (per DPA §10)
  6. +7 d: post-mortem-rapport leveres berørte kunder

5.3 Sikkerhetsbrudd

Ved mistanke om sikkerhetsbrudd følges sikkerhetsbrudd-prosedyren beskrevet i /sikkerhet § 10. Datatilsynet varsles innen 72 timer hvis personopplysninger er eksponert.

6. Kommunikasjon under hendelser

6.1 Kanaler

6.2 Stakeholder-matriks

StakeholderNår varslesKanal
Kundens kontaktpersonAlvorlighet 1-2 ved start + ved løsningE-post
Kundens sikkerhets-teamSikkerhets-insidentE-post + telefon hvis tilgjengelig
DatatilsynetPersonopplysnings-bruddOnline-skjema, innen 72 t
Sub-prosessorerBare hvis deres tjeneste er årsakenE-post/portal
OffentlighetenSjelden — bare ved store, langvarige hendelserdigireq.no/status

7. Forretningskontinuitet (BCP)

7.1 Plattform-konsentrasjon (bus-faktor)

I dag har én person (Markus Eriksson) operativ tilgang til produksjon. Dette er en kjent risiko (ROS §3.15). Beredskap:

7.2 Konkurs-scenario (Påvakt AS)

Ved Påvakt AS' konkurs eller rekonstruksjon har kunden rett til:

Source-escrow er ikke etablert i dag, men kan diskuteres ved store kommersielle avtaler.

8. Testing

9. Endringer og oppdateringer

Beredskapsplanen revideres minst årlig og ved vesentlige endringer i infrastruktur eller arkitektur. Endringer logges nedenfor.

Endringslogg

Dokument-versjon 1.0 · Sist oppdatert 29. mai 2026 · sikkerhet@digireq.no