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:
- Automatisk failover til sekundær region (konfigurasjon: aktiv-passiv)
- DNS-oppdatering peker trafikk til sekundær region (TTL: 60 sekunder)
- Database failover til standby-replikka i sekundær region
- Verifiser tjenestekvalitet i sekundær region
- Informer brukere via push-varsling og statusside
- 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:
- Stopp skriving til korrupt database umiddelbart
- Aktiver skrivebeskyttet modus (brukere kan se, men ikke utføre transaksjoner)
- Identifiser tidspunkt for korrupsjon
- Gjenopprett fra siste gyldige backup + WAL-replay til tidspunkt før korrupsjon
- Verifiser dataintegritet
- Gjenoppta normal drift
- 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:
- Automatisk failover til sekundær Open Banking-leverandør
- Aktiver hurtigbuffer for kontoinformasjon (siste kjente saldo, maks 1 time gammel)
- Informer brukere om mulig forsinkelse i betalingsbehandling
- Kontakt primær leverandør for statusoppdatering
- Logg alle transaksjoner som venter på behandling
- 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:
- Aktiver degradert modus: eksisterende innloggede brukere kan fullføre pågående transaksjoner
- Ny autentisering er ikke mulig — informer brukere via app og statusside
- Kontakt BankID Norge AS for statusoppdatering
- Forleng sesjonstimeout midlertidig (fra 15 min til 60 min) for aktive sesjoner
- Logg alle forsøk på autentisering for senere analyse
- 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:
- Aktiver hendelsesresponsplan (se
hendelseshaandtering.md) - Isoler berørte systemer
- Aktiver DDoS-mitigering på CDN/WAF-nivå
- Ved ransomware: gjenopprett fra sikkerhetskopier (ingen betaling)
- Eskaler til Finanstilsynet innen 4 timer
- Informer berørte brukere
- 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:
- Alle kritiske roller har stedfortreder dokumentert
- Alle prosedyrer er dokumentert og tilgjengelig
- Alle tilganger er rollebasert (ikke personbasert)
- Tredjepartsavtaler har kontaktlister med flere kontaktpunkter
- 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.
- Identifiser siste gyldige tidspunkt
- Stopp applikasjonsservere
- Gjenopprett database fra siste fullsikkerhetskopi
- Replay WAL-segmenter frem til identifisert tidspunkt (PITR)
- Verifiser dataintegritet med sjekksumkontroll
- Kjør integrasjonstester mot gjenopprettet database
- Start applikasjonsservere i kontrollert rekkefølge
- Overvåk tett de neste 24 timene
4.3 Infrastruktur-gjenoppretting
- Verifiser at infrastruktur-som-kode (IaC) er tilgjengelig
- Provisionér ny infrastruktur i sekundær region/sone
- Deploy siste gyldige applikasjonsversjon
- Gjenopprett databaser (se 4.2)
- Konfigurer nettverksruter og lastbalansering
- Verifiser tjenestekvalitet
- 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.