Incident Management
Hendelseshåndteringsplan — Drop
Dokument-ID: IRP-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. 17-23, GDPR art. 33-34, Finanstilsynets IKT-forskrift
1. Innledning
1.1 Formål
Denne hendelseshåndteringsplanen definerer prosesser for å oppdage, klassifisere, håndtere og rapportere IKT-relaterte hendelser i Drop-tjenesten. Planen sikrer effektiv respons i samsvar med DORA og øvrig regulering.
1.2 Virkeområde
Planen dekker:
- Alle IKT-sikkerhetshendelser som påvirker Drop-tjenesten
- Personvernbrudd (GDPR art. 4 nr. 12)
- Driftshendelser som påvirker tjenestetilgjengelighet
- Hendelser hos tredjepartsleverandører som påvirker Drop
- Cyberangrep og forsøk på uautorisert tilgang
1.3 Regulatorisk bakgrunn
| Regulering | Artikler | Krav |
|---|---|---|
| DORA art. 17 | IKT-hendelseshåndteringsprosess | Denne planen |
| DORA art. 18 | Klassifisering av hendelser | Seksjon 3 |
| DORA art. 19 | Rapportering til myndigheter | Seksjon 7 |
| DORA art. 20 | Harmonisert rapportering | Seksjon 7 |
| DORA art. 23 | Deling av trusseletterretning | Seksjon 9 |
| GDPR art. 33 | Varsling til tilsynsmyndighet | Seksjon 7.3 |
| GDPR art. 34 | Varsling til registrerte | Seksjon 7.4 |
2. Deteksjon og varsling
2.1 Deteksjonsmekanismer
| Kilde | Type | Beskrivelse |
|---|---|---|
| SIEM | Automatisert | Korrelasjon av sikkerhetshendelser, regelbaserte og ML-baserte varsler |
| Overvåking | Automatisert | Ytelse, tilgjengelighet, feilrater |
| WAF/IDS/IPS | Automatisert | Angrepsdeteksjon, trafikanalyse |
| Logganalyse | Automatisert/manuell | Anomalideteksjon i applikasjons- og systemlogger |
| Sårbarhetsskanner | Automatisert | Daglig skanning av kjente sårbarheter |
| Brukerrapportering | Manuell | Klager eller meldinger fra brukere |
| Leverandørvarsling | Manuell | Hendelsesrapporter fra tredjeparter |
| Trusseletterretning | Automatisert/manuell | Feed fra CERT, bransjekilder |
2.2 Initialvarsling
Ved deteksjon av potensiell hendelse:
- Automatisert varsling til vaktteam via definerte kanaler
- Vaktteamet foretar innledende vurdering innen 15 minutter
- Hendelsen registreres i hendelseshåndteringssystemet
- Innledende klassifisering gjennomføres (se seksjon 3)
- Eskalering iht. klassifisering
3. Klassifisering — DORA art. 18
3.1 Alvorlighetsgrader
Hendelser klassifiseres etter alvorlighetsgrad basert på kriteriene i DORA artikkel 18(1):
P1 — Kritisk
Kriterier (ett eller flere):
- Fullstendig tjenestestans for betalingsfunksjoner
- Bekreftet databrudd med personopplysninger eller finansielle data
- Aktivt pågående cyberangrep med vesentlig konsekvens
- Tap eller kompromittering av krypteringsnøkler
- Vesentlig økonomisk tap for brukere
- Hendelse som påvirker mer enn 10% av brukerbasisen
Responstid: Umiddelbart Rapportering: Finanstilsynet innen 4 timer (initialrapport)
P2 — Høy
Kriterier (ett eller flere):
- Delvis tjenestestans som påvirker betalinger for en gruppe brukere
- Sikkerhetsbrudd med begrenset omfang
- Kompromittert administratorkonto
- Uautorisert tilgang til produksjonssystemer
- Hendelse hos kritisk leverandør som påvirker tjenesten
Responstid: Innen 30 minutter Rapportering: Finanstilsynet innen 4 timer dersom hendelsen anses som vesentlig
P3 — Middels
Kriterier (ett eller flere):
- Degradert tjenestekvalitet (forsinkelser, feil i ikke-kritiske funksjoner)
- Mislykket inntrengningsforsøk med indikasjoner på målrettet angrep
- Sårbarhet med høy CVSS-score oppdaget i produksjon
- Hendelse hos leverandør som kan påvirke tjenesten
Responstid: Innen 2 timer Rapportering: Intern rapportering, Finanstilsynet ved behov
P4 — Lav
Kriterier (ett eller flere):
- Mindre tekniske problemer uten brukerpåvirkning
- Automatisk blokkerte angrepsforsøk (WAF, brannmur)
- Sårbarhet med lav/middels CVSS-score
- Informasjonshendelser som krever oppfølging
Responstid: Innen 8 timer Rapportering: Intern loggføring
3.2 Klassifiseringskriterier (DORA art. 18(1))
| Kriterium | Beskrivelse | Vurdering |
|---|---|---|
| Berørte brukere | Antall og andel berørte kunder/transaksjoner | Kvantitativt |
| Varighet | Faktisk eller forventet varighet | Tidsbasert |
| Geografisk omfang | Påvirkning i ulike markeder | Geografisk |
| Datatap | Omfang og sensitivitet av kompromittert data | Kvantitativt |
| Økonomisk konsekvens | Direkte og indirekte økonomisk påvirkning | Kvantitativt |
| Tjenestekritikalitet | Påvirkning på kritiske funksjoner | Kvalitativt |
| Omdømmerisiko | Potensiell påvirkning på tillit | Kvalitativt |
3.3 Reklassifisering
Hendelser kan reklassifiseres under håndteringen dersom:
- Omfanget endrer seg (øker eller reduseres)
- Ny informasjon fremkommer
- Konsekvensen viser seg annerledes enn først antatt
- Reklassifisering dokumenteres med begrunnelse
4. Respons per alvorlighetsgrad
4.1 P1 — Kritisk hendelsesrespons
MINUTT 0-15: Deteksjon → Innledende vurdering → Klassifisering P1
MINUTT 15-30: Aktiver hendelsesresponsteam → Isoler berørte systemer
MINUTT 30-60: Analyse pågår → Kommunikasjon til ledelse og CISO
TIME 1: Initialrapport til Finanstilsynet (innen 4t)
Aktivér beredskapsorganisasjon
Ekstern kommunikasjon (statusside, push-varsel)
TIME 1-4: Containment → Eradication → Gjenoppretting pågår
TIME 4: Statusrapport til Finanstilsynet
Oppdatering til berørte brukere
TIME 4-24: Fortsatt gjenoppretting → Overvåking
DAG 1-3: Intermediær rapport til Finanstilsynet (innen 72t)
GDPR-varsling til Datatilsynet (innen 72t) ved personvernbrudd
Kommunikasjon til berørte registrerte ved høy risiko
DAG 3-30: Endelig rapport til Finanstilsynet (innen 1 måned)
Post-incident review
4.2 P2 — Høy hendelsesrespons
MINUTT 0-30: Deteksjon → Vurdering → Klassifisering P2
MINUTT 30-60: Hendelsesansvarlig utpekt → Analyse startet
TIME 1-2: Containment-tiltak implementert
CISO informert
TIME 2-4: Eradication og gjenoppretting
Vurdering av rapporteringsplikt (Finanstilsynet)
TIME 4-8: Normal drift gjenopprettet
Intern statusrapport
DAG 1-5: Rotårsaksanalyse
Forbedringstiltak identifisert
4.3 P3 — Middels hendelsesrespons
TIME 0-2: Deteksjon → Vurdering → Klassifisering P3
TIME 2-4: Analyse og vurdering av tiltak
TIME 4-8: Tiltak implementert
DAG 1-3: Verifisering → Dokumentasjon
DAG 3-5: Hendelsesrapport ferdigstilt
4.4 P4 — Lav hendelsesrespons
TIME 0-8: Deteksjon → Vurdering → Klassifisering P4
DAG 1-5: Analyse og tiltak ved behov
DAG 5-10: Dokumentasjon i hendelsesloggen
5. Hendelseshåndteringsfaser
5.1 Fase 1: Identifisering
- Bekreft at hendelsen er reell (ikke falsk positiv)
- Kartlegg omfang og berørte systemer
- Identifiser hendelsestypen (angrep, feil, menneskelig feil, leverandør)
- Klassifiser alvorlighetsgrad (P1-P4)
- Dokumenter tidslinje fra deteksjon
5.2 Fase 2: Containment (Inneslutning)
Kortsiktig containment:
- Isoler berørte systemer for å hindre spredning
- Aktiver alternative systemer/failover der mulig
- Bevare bevis (ikke slett logger eller data)
- Blokkér identifiserte angrepsvektor
Langsiktig containment:
- Implementer midlertidige sikkerhetstiltak
- Patch eller oppdater sårbare systemer i isolert miljø
- Verifiser at containment er effektiv
5.3 Fase 3: Eradication (Fjerning)
- Identifiser og fjern rotårsaken
- Fjern skadelig programvare, uautoriserte kontoer, bakdører
- Oppdater/patch alle berørte systemer
- Verifiser at trusselen er eliminert
- Oppdater sikkerhetsregler og blokkérlister
5.4 Fase 4: Recovery (Gjenoppretting)
- Gjenopprett systemer fra kjent god tilstand (backup/clean install)
- Gjenopprett data fra verifiserte sikkerhetskopier
- Implementer forbedrede sikkerhetstiltak før gjenåpning
- Gradvis gjenåpning med forstørket overvåking
- Verifiser tjenestekvalitet
- Overvåk tett de neste 24-72 timene for tilbakefall
5.5 Fase 5: Lessons Learned (Lærdommer)
- Gjennomfør post-incident review innen 5 virkedager (P1/P2) eller 15 virkedager (P3/P4)
- Dokumenter hendelsesforløp, respons og utfall
- Identifiser forbedringstiltak
- Oppdater prosedyrer, deteksjonsregler og sikkerhetstiltak
- Del relevante lærdommer med teamet
6. Hendelsesresponsteam
6.1 Sammensetning
| Rolle | Ansvar | Aktiveres ved |
|---|---|---|
| Hendelsesleder (Incident Commander) | Overordnet koordinering, beslutninger, kommunikasjon | P1, P2 |
| CISO | Sikkerhetsvurdering, myndighetskontakt, strategiske beslutninger | P1, P2 |
| Teknisk leder | Teknisk analyse, containment, gjenoppretting | P1, P2, P3 |
| Driftsingeniør | Systemadministrasjon, failover, gjenoppretting | Alle |
| Compliance-ansvarlig | Regulatorisk vurdering, rapporteringsplikt | P1, P2 |
| Kommunikasjonsansvarlig | Ekstern/intern kommunikasjon | P1, P2 |
| Daglig leder | Strategiske beslutninger, styrekontakt | P1 |
| Personvernombud (DPO) | Personvernvurdering, Datatilsynet-rapportering | Alle med personvernimplikasjon |
6.2 Eskalering
| Fra | Til | Kriterium |
|---|---|---|
| Vaktteam | Teknisk leder | Alle bekreftede hendelser |
| Teknisk leder | CISO | P1, P2, sikkerhetshendelser |
| CISO | Daglig leder | P1, alle hendelser med regulatorisk rapporteringsplikt |
| Daglig leder | Styreleder | P1 med vesentlig konsekvens |
6.3 Kontaktinformasjon
Oppdatert kontaktliste for hendelsesresponsteamet, inkludert:
- Mobilnummer (primær og sekundær)
- E-post
- Alternativ kontaktmetode
- Stedfortreder per rolle
- Oppdateres minimum kvartalsvis
7. Rapportering til myndigheter
7.1 Finanstilsynet — DORA art. 19
Rapporteringsplikt
Vesentlige IKT-relaterte hendelser rapporteres til Finanstilsynet, jf. DORA art. 19(1).
Rapporteringsfrister
| Rapport | Frist | Innhold |
|---|---|---|
| Initialrapport | Innen 4 timer etter klassifisering som vesentlig | Hendelsestype, berørte tjenester, innledende konsekvens, iverksatte tiltak |
| Intermediær rapport | Innen 72 timer | Oppdatert omfang, rotårsak (foreløpig), status for containment/gjenoppretting |
| Endelig rapport | Innen 1 måned | Fullstendig beskrivelse, rotårsak, konsekvenser, lærdommer, forbedringstiltak |
Kriterier for «vesentlig hendelse» (DORA art. 18(1))
En hendelse er vesentlig dersom den:
- Berører kritiske betalingstjenester
- Påvirker et betydelig antall brukere
- Medfører eller kan medføre vesentlig økonomisk tap
- Medfører tap av data eller kompromittering av konfidensialitet
- Har eller kan ha betydelig omdømmekonsekvens
- Har varighet som overstiger terskelverdier satt av Finanstilsynet
7.2 DORA art. 20 — Harmonisert rapportering
Vi følger rapporteringsformatet definert av de europeiske tilsynsmyndighetene (ESAs) i henhold til DORA art. 20, når dette er implementert av Finanstilsynet.
7.3 Datatilsynet — GDPR art. 33
Ved brudd på personopplysningssikkerheten:
| Handling | Frist | Kriterium |
|---|---|---|
| Vurdering av rapporteringsplikt | Umiddelbart etter deteksjon | Alle personvernbrudd |
| Melding til Datatilsynet | Innen 72 timer | Med mindre bruddet sannsynligvis ikke medfører risiko for registrertes rettigheter |
| Informasjon til berørte registrerte | Uten ugrunnet opphold | Dersom bruddet sannsynligvis medfører høy risiko (GDPR art. 34) |
Innhold i melding til Datatilsynet (GDPR art. 33(3)):
- Bruddets art, inkludert kategorier og antall berørte registrerte
- Navn og kontaktinformasjon til personvernombudet
- Sannsynlige konsekvenser
- Tiltak som er iverksatt eller planlagt
7.4 Varsling til berørte registrerte — GDPR art. 34
Berørte registrerte varsles uten ugrunnet opphold dersom personvernbruddet sannsynligvis medfører høy risiko for deres rettigheter og friheter.
Unntak (GDPR art. 34(3)):
- Data var kryptert og nøkler ikke kompromittert
- Tiltak er truffet som gjør at høy risiko ikke lenger er sannsynlig
- Individuell varsling krever uforholdsmessig innsats (offentlig kommunikasjon brukes)
Varsling inneholder:
- Klar og tydelig beskrivelse av bruddet
- Kontaktinformasjon til personvernombudet
- Sannsynlige konsekvenser
- Tiltak iverksatt og anbefalt egenhandling
Varsling skjer via:
- Push-varsling i appen
- E-post til registrert e-postadresse
- Ved behov: SMS og statusside
8. Dokumentasjon
8.1 Hendelseslogg
Alle hendelser dokumenteres med:
- Unikt hendelses-ID
- Dato og tidspunkt for deteksjon
- Kilde for deteksjon
- Klassifisering (P1-P4)
- Hendelsestype (sikkerhet, drift, personvern, leverandør)
- Beskrivelse
- Berørte systemer og brukere
- Tidslinje for håndtering
- Iverksatte tiltak
- Rotårsak
- Rapportering til myndigheter (ja/nei, dato)
- Forbedringstiltak
- Status (åpen, under håndtering, lukket)
8.2 Bevissikring
Ved sikkerhetshendelser (P1/P2):
- Sikre logger og bevis før containment
- Forensisk kopi av berørte systemer der relevant
- Kjede av bevis (chain of custody) dokumenteres
- Bevis oppbevares sikkert og skrivebeskyttet
- Bevisene kan overleveres til politi/påtalemyndighet ved behov
8.3 Oppbevaring
| Dokumenttype | Oppbevaringstid |
|---|---|
| P1-hendelser | 5 år |
| P2-hendelser | 3 år |
| P3/P4-hendelser | 2 år |
| Rapporter til myndigheter | 5 år |
| Personvernbrudd (alle) | 5 år |
| Forensisk bevis | Til saken er avsluttet + 3 år |
9. Trusseletterretning — DORA art. 23
9.1 Kilder
Vi mottar og vurderer trusseletterretning fra:
- Norsk nasjonalt cybersikkerhetssenter (NCSC/NorCERT)
- FinansCERT (Nordic Financial CERT)
- Kommersielle trusseletterretningsfeeder
- Open-source trusseletterretning (OSINT)
- Bransjesamarbeid og informasjonsdeling
9.2 Deling
I henhold til DORA art. 23 deltar vi i informasjonsdeling om cybertrusler:
- Anonymiserte indikatorer deles med relevante bransjefellesskap
- Vi bidrar til FinansCERT med hendelsesdata
- Vi mottar og implementerer varsler fra myndigheter
9.3 Bruk
Trusseletterretning brukes til å:
- Oppdatere deteksjonsregler i SIEM
- Blokkere kjente ondsinnede IP-adresser og domener
- Prioritere sårbarhetshåndtering
- Informere risikost vurderinger
- Forbedre hendelsesresponsprosedyrer
10. Post-Incident Review
10.1 Gjennomføring
Post-incident review gjennomføres etter alle P1- og P2-hendelser, samt utvalgte P3-hendelser:
| Alvorlighetsgrad | Frist for review | Deltakere |
|---|---|---|
| P1 | Innen 5 virkedager | Hele hendelsesresponsteamet + ledelse |
| P2 | Innen 10 virkedager | Hendelsesresponsteam |
| P3 | Innen 15 virkedager | Teknisk leder + relevante ressurser |
10.2 Innhold i post-incident review
- Hendelsesforløp: Kronologisk gjennomgang av hendelsen
- Deteksjon: Ble hendelsen oppdaget raskt nok? Hva kan forbedres?
- Respons: Var responsen effektiv? Ble prosedyrer fulgt?
- Kommunikasjon: Fungerte intern og ekstern kommunikasjon?
- Rotårsak: Hva var den underliggende årsaken?
- Konsekvens: Faktisk konsekvens for brukere, tjeneste, økonomi og omdømme
- Forbedringstiltak: Konkrete tiltak med ansvarlig og frist
10.3 Oppfølging av forbedringstiltak
- Alle forbedringstiltak registreres med ansvarlig, frist og status
- Statusgjennomgang i månedlig sikkerhetsmøte
- Tiltak verifiseres før lukking
11. Øvelser og testing
11.1 Øvelsesprogram
| Øvelsestype | Frekvens | Beskrivelse |
|---|---|---|
| Tabletop | Kvartalsvis | Scenariobasert gjennomgang med hendelsesresponsteam |
| Simulering | Halvårlig | Teknisk simulering av hendelse (kontrollert) |
| Full øvelse | Årlig | Ende-til-ende simulering inkl. kommunikasjon og rapportering |
| Red team | Hvert 3. år | Realistisk angrepssimulering (jf. DORA TLPT) |
11.2 Scenarioer for øvelser
- Ransomware-angrep mot produksjonsserver
- Databasekompromittering med datatap
- DDoS-angrep mot betalingsmotor
- Insider-trussel (kompromittert ansattekonto)
- Leverandørhendelse (Open Banking-leverandør nede)
- Kombinert hendelse (cybersikkerhet + bortfall av leverandør)
11.3 Evaluering
Alle øvelser evalueres med:
- Hva fungerte godt
- Hva kan forbedres
- Konkrete forbedringstiltak
- Dato for neste øvelse
12. Revisjon og oppdatering
12.1 Gjennomgang
- Årlig: Full gjennomgang av planen
- Etter P1/P2-hendelser: Revisjon basert på lærdommer
- Etter øvelser: Oppdatering basert på funn
- Ved regulatoriske endringer: Tilpasning til nye krav
- Ved vesentlige endringer: Ny teknologi, nye leverandører, organisasjonsendring
12.2 Godkjenning
| Endring | Godkjenner |
|---|---|
| Redaksjonell | CISO |
| Vesentlig | Daglig leder |
| Prinsipiell | Styret |
12.3 Versjonshistorikk
| Versjon | Dato | Endring | Godkjent av |
|---|---|---|---|
| 1.0 | 12.02.2026 | Opprinnelig dokument | ____________ |
Vedlegg
Vedlegg A: Kontaktliste hendelsesresponsteam
Separat dokument — fortrolig.
Vedlegg B: Maler for rapportering
- Mal for initialrapport til Finanstilsynet
- Mal for intermediær rapport
- Mal for endelig rapport
- Mal for GDPR-bruddmelding til Datatilsynet
- Mal for varsling til berørte registrerte
Vedlegg C: Sjekklister per hendelsestype
- Sjekkliste: Ransomware
- Sjekkliste: DDoS
- Sjekkliste: Databrudd
- Sjekkliste: Leverandørhendelse
- Sjekkliste: Insider-trussel
Vedlegg D: Eskaleringstrinn visuelt
P4 (Lav) → Driftsingeniør
P3 (Middels) → Driftsingeniør → Teknisk leder
P2 (Høy) → Driftsingeniør → Teknisk leder → CISO → Daglig leder
P1 (Kritisk) → Hele hendelsesresponsteamet → Styreleder
Denne hendelseshåndteringsplanen er eid av CISO og godkjent av styret i ALAI Holding AS. Planen testes og revideres minimum årlig.