# Contingency Plan

# Beredskapsplan — Drop

**Dokument-ID:** BCP-DROP-001
**Versjon:** 1.0
**Dato:** 12. februar 2026
**Eier:** ALAI Holding AS, org.nr. 932 516 136
**Klassifisering:** Intern — Fortrolig
**Regulatorisk grunnlag:** DORA (EU) 2022/2554 art. 11, Finanstilsynets IKT-forskrift

---

## 1. Innledning

### 1.1 Formål
Denne beredskapsplanen sikrer at Drop-tjenesten kan opprettholde eller raskt gjenopprette kritiske funksjoner ved vesentlige forstyrrelser. Planen er utarbeidet i henhold til DORA artikkel 11 om forretningskontinuitet og krisekommunikasjon.

### 1.2 Virkeområde
Planen dekker:
- Alle IKT-systemer som understøtter Drop-tjenesten
- Alle forretningsprosesser knyttet til betalingsbehandling
- Tredjepartsleverandører som er kritiske for tjenesteleveransen
- Kommunikasjon med berørte parter under og etter hendelser

### 1.3 Definisjoner
| Begrep | Definisjon |
|--------|-----------|
| RTO (Recovery Time Objective) | Maksimal akseptabel nedetid |
| RPO (Recovery Point Objective) | Maksimalt akseptabelt datatap (tidsperiode) |
| MTPD (Maximum Tolerable Period of Disruption) | Maksimal periode tjenesten kan være nede |
| BIA (Business Impact Analysis) | Analyse av konsekvenser ved bortfall |

---

## 2. Business Impact Analysis (BIA)

### 2.1 Kritiske forretningsprosesser

| Prosess | Kritikalitet | RTO | RPO | MTPD | Konsekvens ved bortfall |
|---------|-------------|-----|-----|------|------------------------|
| Betalingsbehandling (PISP) | Kritisk | 1 time | 0 (null datatap) | 4 timer | Brukere kan ikke gjennomføre betalinger, omdømmetap, regulatorisk risiko |
| Kontoinformasjon (AISP) | Viktig | 4 timer | 1 time | 8 timer | Brukere kan ikke se saldo, begrenset funksjonalitet |
| Utenlandsoverføring (remittance) | Kritisk | 2 timer | 0 | 8 timer | Forsinkede overføringer, kundetap |
| QR-betalinger | Kritisk | 1 time | 0 | 4 timer | Forhandlere kan ikke motta betaling |
| Brukerautentisering (BankID) | Kritisk | 30 min | N/A | 2 timer | Ingen kan logge inn, total tjenestestans |
| Kundeservice | Viktig | 8 timer | 4 timer | 24 timer | Kunder kan ikke få hjelp, klagebehandling forsinkes |
| KYC/AML-kontroll | Viktig | 4 timer | 1 time | 12 timer | Nye kunder kan ikke registrere seg |
| Rapportering og compliance | Standard | 24 timer | 4 timer | 48 timer | Regulatorisk rapportering forsinkes |
| Push-varsler | Standard | 8 timer | N/A | 24 timer | Brukere mottar ikke transaksjonsvarsler |

### 2.2 Kritiske IKT-systemer

| System | Avhengigheter | Redundans | RTO |
|--------|-------------|-----------|-----|
| Betalingsmotor | Database, Open Banking API | Aktiv-aktiv | 1 time |
| Database (PostgreSQL) | Lagring, nettverk | Replikering, automatisk failover | 15 min |
| Open Banking-gateway | Ekstern leverandør | Sekundær leverandør (varm standby) | 2 timer |
| BankID-integrasjon | BankID Norge AS | BankID HA-oppsett | Avhengig av BankID |
| API-gateway | CDN, lastbalansering | Multiregion | 30 min |
| Appservere | Container-orkestrator | Autoskalering, multinode | 15 min |
| Meldingskø | Broker-klynge | Klynge med replikering | 15 min |
| Cache | Redis-klynge | Replikering | 5 min |
| Overvåkingssystem | SIEM, logger | Separat infrastruktur | 1 time |

### 2.3 Avhengigheter til tredjeparter

| Leverandør | Tjeneste | Kritikalitet | Alternativ |
|-----------|---------|-------------|-----------|
| Open Banking-leverandør | PSD2 PISP/AISP | Kritisk | Sekundær leverandør med varm standby |
| BankID Norge AS | Autentisering | Kritisk | Ingen alternativ (nasjonal eID) — degradert modus |
| Skyinfrastrukturleverandør | Hosting | Kritisk | Multiregion-oppsett, alternativ region |
| Korrespondentbanker | Remittance | Kritisk | Flere partnere per korridor |
| CDN-leverandør | Innholdslevering | Viktig | Sekundær CDN konfigurert |
| E-postleverandør | Transaksjonelle e-poster | Standard | Sekundær leverandør |

---

## 3. Scenarioer og responsstrategier

### 3.1 Scenario S1: Fullstendig datasentertap
**Beskrivelse:** Primær hosting-region er utilgjengelig (brann, naturkatastrofe, regionalt strømbrudd).

**Responsstrategi:**
1. Automatisk failover til sekundær region (konfigurasjon: aktiv-passiv)
2. DNS-oppdatering peker trafikk til sekundær region (TTL: 60 sekunder)
3. Database failover til standby-replikka i sekundær region
4. Verifiser tjenestekvalitet i sekundær region
5. Informer brukere via push-varsling og statusside
6. Initier gjenoppbygging av primær region etter at hendelsen er løst

**RTO:** 2 timer | **RPO:** 5 minutter (asynkron replikering)

### 3.2 Scenario S2: Databasekorrupsjon
**Beskrivelse:** Primær database korruptert (programvarefeil, menneskelig feil, ondsinnet aktivitet).

**Responsstrategi:**
1. Stopp skriving til korrupt database umiddelbart
2. Aktiver skrivebeskyttet modus (brukere kan se, men ikke utføre transaksjoner)
3. Identifiser tidspunkt for korrupsjon
4. Gjenopprett fra siste gyldige backup + WAL-replay til tidspunkt før korrupsjon
5. Verifiser dataintegritet
6. Gjenoppta normal drift
7. Gjennomfør rotårsaksanalyse

**RTO:** 1 time | **RPO:** 0 (med WAL-replay)

### 3.3 Scenario S3: Open Banking-leverandør nede
**Beskrivelse:** Primær Open Banking-leverandør er utilgjengelig.

**Responsstrategi:**
1. Automatisk failover til sekundær Open Banking-leverandør
2. Aktiver hurtigbuffer for kontoinformasjon (siste kjente saldo, maks 1 time gammel)
3. Informer brukere om mulig forsinkelse i betalingsbehandling
4. Kontakt primær leverandør for statusoppdatering
5. Logg alle transaksjoner som venter på behandling
6. Gjenoppta mot primær leverandør når tilgjengelig

**RTO:** 30 minutter (failover) | **RPO:** 0

### 3.4 Scenario S4: BankID utilgjengelig
**Beskrivelse:** BankID-infrastrukturen er nede nasjonalt.

**Responsstrategi:**
1. Aktiver degradert modus: eksisterende innloggede brukere kan fullføre pågående transaksjoner
2. Ny autentisering er ikke mulig — informer brukere via app og statusside
3. Kontakt BankID Norge AS for statusoppdatering
4. Forleng sesjonstimeout midlertidig (fra 15 min til 60 min) for aktive sesjoner
5. Logg alle forsøk på autentisering for senere analyse
6. Gjenoppta normal drift når BankID er tilbake

**RTO:** Avhengig av BankID | **Mitigering:** Forlengede sesjoner for aktive brukere

### 3.5 Scenario S5: Cyberangrep (ransomware/DDoS)
**Beskrivelse:** Målrettet cyberangrep mot Drop-infrastrukturen.

**Responsstrategi:**
1. Aktiver hendelsesresponsplan (se `hendelseshaandtering.md`)
2. Isoler berørte systemer
3. Aktiver DDoS-mitigering på CDN/WAF-nivå
4. Ved ransomware: gjenopprett fra sikkerhetskopier (ingen betaling)
5. Eskaler til Finanstilsynet innen 4 timer
6. Informer berørte brukere
7. Engasjer ekstern hendelsesresponsteam ved behov

**RTO:** 4 timer (DDoS), 8 timer (ransomware) | **RPO:** 0 (fra backup)

### 3.6 Scenario S6: Nøkkelpersonavhengighet
**Beskrivelse:** Kritisk personell er utilgjengelig (sykdom, fratredelse).

**Responsstrategi:**
1. Alle kritiske roller har stedfortreder dokumentert
2. Alle prosedyrer er dokumentert og tilgjengelig
3. Alle tilganger er rollebasert (ikke personbasert)
4. Tredjepartsavtaler har kontaktlister med flere kontaktpunkter
5. Eskaleringsmatrisen oppdateres ved personalendringer

---

## 4. Gjenopprettingsprosedyrer

### 4.1 Generell gjenopprettingsprosess
```
1. OPPDAGE  → Automatisert overvåking eller manuell varsling
2. VURDERE  → Kategoriser hendelsen (S1-S6), identifiser omfang
3. ESKALER  → Aktiver beredskapsorganisasjon iht. eskaleringstrinn
4. HÅNDTERE → Utfør scenariospesifikk respons
5. VERIFISER → Kontroller at gjenoppretting er vellykket
6. INFORMER → Oppdater berørte parter om status
7. NORMALISER → Gjenoppta normal drift
8. ANALYSER → Rotårsaksanalyse og forbedring
```

### 4.2 Database-gjenoppretting
**Forutsetninger:** PostgreSQL med streaming replikering og WAL-arkivering.

1. Identifiser siste gyldige tidspunkt
2. Stopp applikasjonsservere
3. Gjenopprett database fra siste fullsikkerhetskopi
4. Replay WAL-segmenter frem til identifisert tidspunkt (PITR)
5. Verifiser dataintegritet med sjekksumkontroll
6. Kjør integrasjonstester mot gjenopprettet database
7. Start applikasjonsservere i kontrollert rekkefølge
8. Overvåk tett de neste 24 timene

### 4.3 Infrastruktur-gjenoppretting
1. Verifiser at infrastruktur-som-kode (IaC) er tilgjengelig
2. Provisionér ny infrastruktur i sekundær region/sone
3. Deploy siste gyldige applikasjonsversjon
4. Gjenopprett databaser (se 4.2)
5. Konfigurer nettverksruter og lastbalansering
6. Verifiser tjenestekvalitet
7. Oppdater DNS

---

## 5. Kommunikasjonsplan

### 5.1 Intern kommunikasjon

| Eskaleringstrinn | Kriterium | Varsler | Metode | Innen |
|-----------------|----------|---------|--------|-------|
| Trinn 1 | Degradert tjeneste | Driftsteam | Automatisk varsling | Umiddelbart |
| Trinn 2 | Kritisk tjeneste nede | Driftsteam + CISO | Telefon + e-post | 15 min |
| Trinn 3 | Fullstendig tjenestestans > 1 time | + Daglig leder | Telefon | 30 min |
| Trinn 4 | Tjenestestans > 4 timer eller databrudd | + Styreleder | Telefon | 1 time |

### 5.2 Ekstern kommunikasjon

| Mottaker | Kriterium | Metode | Innen |
|----------|----------|--------|-------|
| Brukere | Tjenestestans > 15 min | Push-varsling, statusside | 30 min |
| Forhandlere | QR-betalinger nede > 15 min | E-post, telefon (store) | 30 min |
| Finanstilsynet | Alvorlig IKT-hendelse (DORA art. 19) | Varslingsskjema | 4 timer |
| Datatilsynet | Personvernbrudd | Avviksskjema | 72 timer |
| Open Banking-leverandør | Integrasjonsproblemer | Avtalt kanal | Umiddelbart |
| BankID Norge AS | Autentiseringsproblemer | Avtalt kanal | Umiddelbart |
| Media | Ved offentlig oppmerksomhet | Pressekontakt | Koordinert |

### 5.3 Statusside
- Ekstern statusside oppdateres ved alle hendelser som påvirker brukere
- Automatisert oppdatering fra overvåkingssystem
- Manuell oppdatering ved komplekse hendelser
- Historikk over alle hendelser tilgjengelig

### 5.4 Maler for kommunikasjon
Ferdigformulerte maler for:
- Planlagt vedlikehold
- Uplanlagt tjenesteavbrudd
- Gjenoppretting bekreftet
- Sikkerhetsbrudd (til brukere)
- Regulatorisk varsling (Finanstilsynet)

---

## 6. Beredskapsorganisasjon

### 6.1 Roller og ansvar

| Rolle | Ansvar | Stedfortreder |
|-------|--------|--------------|
| Beredskapsleder (daglig leder) | Overordnet beslutningsansvar, ekstern kommunikasjon | CTO |
| Teknisk leder (CTO) | Teknisk gjenoppretting, koordinering av driftsteam | Senior utvikler |
| Kommunikasjonsansvarlig | Intern/ekstern kommunikasjon, statusoppdateringer | Daglig leder |
| CISO | Sikkerhetsvurdering, koordinering med myndigheter | CTO |
| Compliance-ansvarlig | Regulatorisk vurdering, varsling til tilsyn | CISO |
| Driftsleder | Utfører gjenopprettingsprosedyrer | Backup driftsteam |

### 6.2 Kontaktliste
Oppdatert kontaktliste med:
- Mobilnummer (primær og sekundær)
- E-postadresse
- Alternativ kontaktmetode
- Oppdateres minimum kvartalsvis

### 6.3 Aktivering av beredskap
Beredskap aktiveres når:
- Automatisert overvåking utløser P1- eller P2-alarm
- Manuell vurdering tilsier aktivering
- Finanstilsynet krever det
- Tredjepartsleverandør rapporterer kritisk hendelse

---

## 7. Testing og øvelser

### 7.1 Testprogram

| Testtype | Frekvens | Omfang | Ansvarlig |
|---------|---------|--------|-----------|
| Tabletop-øvelse | Kvartalsvis | Gjennomgang av scenarioer med beredskapsorganisasjon | Beredskapsleder |
| Failover-test | Halvårlig | Teknisk failover til sekundær region | CTO |
| Database-gjenoppretting | Halvårlig | Full gjenoppretting fra backup | Driftsleder |
| Kommunikasjonstest | Kvartalsvis | Test av kontaktlister og eskaleringsprosedyrer | Kommunikasjonsansvarlig |
| Full beredskapsøvelse | Årlig | Ende-til-ende simulering inkl. tredjeparter | Beredskapsleder |

### 7.2 Testdokumentasjon
Alle tester dokumenteres med:
- Dato og deltakere
- Scenario som ble testet
- Faktisk RTO/RPO oppnådd
- Avvik fra planlagte prosedyrer
- Forbedringstiltak med frist og ansvarlig

### 7.3 Oppdatering etter test
- Beredskapsplanen oppdateres innen 30 dager etter test/øvelse
- Identifiserte svakheter utbedres innen 60 dager
- Neste test planlegges

---

## 8. Vedlikehold av planen

### 8.1 Gjennomgangsfrekvens
- **Årlig:** Full gjennomgang av beredskapsplanen
- **Kvartalsvis:** Oppdatering av kontaktlister
- **Ved vesentlige endringer:** Ny leverandør, ny teknologi, organisasjonsendring
- **Etter hendelser:** Revideres basert på lærdommer
- **Etter øvelser:** Oppdateres basert på testresultater

### 8.2 Ansvar for vedlikehold

| Aktivitet | Ansvarlig | Frekvens |
|-----------|-----------|---------|
| Oppdatering av kontaktlister | Alle rolleinnehavere | Kvartalsvis |
| Teknisk gjennomgang | CTO | Halvårlig |
| Full plangjennomgang | Beredskapsleder | Årlig |
| Godkjenning | Daglig leder | Ved endring |

### 8.3 Distribusjon
- Planen distribueres til alle i beredskapsorganisasjonen
- Tilgjengelig offline (utskrift) hos beredskapsleder og CTO
- Lagret i versjonskontroll med endringshistorikk
- Kopier hos tredjepartsleverandører ved behov

---

## 9. Samsvar med DORA artikkel 11

Denne beredskapsplanen er utarbeidet i henhold til kravene i DORA artikkel 11:

| DORA-krav | Dekning i planen |
|-----------|-----------------|
| Art. 11(1): IKT-kontinuitetspolicy | Hele dokumentet |
| Art. 11(2): BIA for kritiske funksjoner | Seksjon 2 |
| Art. 11(3): Responsstrategier | Seksjon 3 |
| Art. 11(4): Gjenopprettingsprosedyrer | Seksjon 4 |
| Art. 11(5): Kommunikasjonsplan | Seksjon 5 |
| Art. 11(6): Testing | Seksjon 7 |
| Art. 11(7): Gjennomgang og oppdatering | Seksjon 8 |
| Art. 11(8): Hendelsesrespons | Ref. hendelseshaandtering.md |
| Art. 11(9): Tredjepartsavhengigheter | Seksjon 2.3 |

---

## 10. Versjonshistorikk

| Versjon | Dato | Endring | Godkjent av |
|---------|------|---------|-------------|
| 1.0 | 12.02.2026 | Opprinnelig dokument | ____________ |

---

## Vedlegg

### Vedlegg A: Kontaktliste beredskapsorganisasjon
*Separat dokument — fortrolig.*

### Vedlegg B: Sjekklister per scenario
*Operasjonelle sjekklister — oppbevares hos driftsteam.*

### Vedlegg C: Oversikt over sikkerhetskopier og gjenopprettingspunkter
*Teknisk dokumentasjon — vedlikeholdes av driftsteam.*

---

*Beredskapsplanen er eid av beredskapsleder og godkjent av styret i ALAI Holding AS. Planen revideres minimum årlig og etter enhver vesentlig hendelse.*