NIS2 beredskapsplan: Slik bygger du driftskontinuitet i praksis
Av de ti sikkerhetskravene i NIS2 Artikkel 21 er driftskontinuitet og krisehåndtering det kravet som flest norske virksomheter undervurderer. Ikke fordi det er ukjent – de fleste forstår at de trenger backup – men fordi avstanden mellom «vi har backup» og «vi kan faktisk gjenopprette driften» er mye større enn folk tror.
Art. 21(2)(c) krever tiltak for driftskontinuitet og krisehåndtering, herunder backup-håndtering og gjenoppretting etter katastrofer. EU-gjennomføringsforordningen 2024/2690, som utdyper kravene for digitale infrastrukturleverandører, konkretiserer dette ytterligere: virksomheter skal ha dokumenterte planer for driftskontinuitet og gjenoppretting, gjennomføre konsekvensanalyser, og teste planene regelmessig. Selv om forordningen formelt gjelder et avgrenset sett virksomheter, gir den en tydelig indikasjon på hva myndighetene forventer av alle NIS2-virksomheter.
Kategorisiden for driftskontinuitet forklarer hva kravet innebærer og lister vurderingsspørsmålene. Denne artikkelen handler om hvordan – steg for steg, tilpasset norske virksomheter med 50–80 ansatte og uten et dedikert sikkerhetsteam.
Beredskapsplan, gjenopprettingsplan og krisehåndtering – hva er forskjellen?
Mange blander sammen begrepene, og det fører til at hele arbeidet blir uoversiktlig. Tre dokumenter, tre formål:
En beredskapsplan (ofte kalt BCP, fra business continuity plan) beskriver hvordan virksomheten opprettholder kritiske funksjoner under og etter en hendelse. Den handler ikke bare om IT – den dekker også kommunikasjon, roller, manuelle rutiner og prioriteringer. For en SMB trenger dette ikke være et 80-siders dokument. Et godt utgangspunkt er 10–15 sider som dekker det vesentlige.
En gjenopprettingsplan (DRP, fra disaster recovery plan) er den tekniske delen: hvordan du faktisk får systemer, data og infrastruktur tilbake i drift. Den er et underdokument av beredskapsplanen.
En krisehåndteringsplan beskriver hvem som tar beslutninger, hvordan informasjon flyter internt og eksternt, og hvilke fullmakter som gjelder når normalsituasjonen bryter sammen. Denne overlapper med kravene til hendelsesrapportering, som har egne tidsfrister.
Alle tre henger sammen, men de har ulik målgruppe. Beredskapsplanen er for hele virksomheten. Gjenopprettingsplanen er for de som faktisk skal gjøre den tekniske jobben. Krisehåndteringsplanen er for ledelsen som skal koordinere og kommunisere.
Steg 1: Kartlegg hva som faktisk er kritisk
Før du kan planlegge gjenoppretting, må du vite hva som skal gjenopprettes først. En forretningskonsekvensanalyse (business impact analysis, BIA) hjelper deg med å skille mellom det som er kritisk og det som bare føles viktig.
Start med å liste alle systemer, applikasjoner og prosesser virksomheten bruker. For hvert system, still to spørsmål:
Hvor lenge kan vi klare oss uten dette systemet? Svaret gir deg recovery time objective (RTO) – den maksimale akseptable nedetiden. For et ordrehåndteringssystem i en matprodusent kan RTO være 4 timer. For et internt wikisystem kan det være en uke.
Hvor mye data har vi råd til å tape? Svaret gir deg recovery point objective (RPO) – hvor langt tilbake du aksepterer å gå. Hvis du tar backup hver natt, er RPO 24 timer. Mister du hele gårsdagens ordrer, er det akseptabelt? Hvis ikke, trenger du hyppigere backup eller sanntidsreplikering.
De fleste SMBer oppdager at de har 3–5 virkelig kritiske systemer og kanskje 15–20 som kan vente. Denne sorteringen er verdifull fordi den styrer alt det videre arbeidet – fra backup-frekvens til gjenopprettingsrekkefølge.
Noen vanlige systemer som ofte havner i «kritisk»-kategorien for norske virksomheter i NIS2-sektorer: ERP/økonomisystem, e-post, produksjonsstyring, lagerstyring, og nettverksinfrastruktur. Systemer som intranett, HR-verktøy og prosjektstyring er sjelden like tidskritiske.
Dokumenter resultatet i en enkel tabell med kolonner for system, eier, RTO, RPO og avhengigheter. Dette er grunnlaget for alt som følger.
Steg 2: Sett opp backup som faktisk fungerer
De fleste virksomheter har en eller annen form for backup. Problemet er sjelden at backup mangler – det er at backupen ikke dekker det den skal, aldri er testet, eller ikke kan gjenopprettes raskt nok.
3-2-1-regelen er fortsatt det beste utgangspunktet: tre kopier av dataene, på minst to ulike medier, der minst én kopi er lagret utenfor virksomhetens lokaler. For virksomheter som bruker skybaserte løsninger, betyr «utenfor lokalet» et annet datasenter eller en annen skyleverandør, ikke bare en annen mappe i samme tjeneste.
Automatiserte backup-rutiner er sterkt å foretrekke fremfor manuelle. Manuelle rutiner glipper – det er et spørsmål om når, ikke om. De fleste moderne systemer støtter automatisert backup med konfigurerbar frekvens. Sett frekvensen ut fra RPO-verdiene du definerte i forrige steg.
Skybasert vs. lokal backup er ikke et enten-eller. Skybasert backup gir geografisk spredning og enkel skalering. Lokal backup gir raskere gjenopprettingstid for store datamengder. For kritiske systemer med kort RTO kan en kombinasjon gi best resultat.
En backup du ikke har testet, er en backup du ikke har. Gjennomfør gjenopprettingstest minst halvårlig for de mest kritiske systemene. Test ikke bare at filen eksisterer – test at du faktisk kan gjenopprette et helt system til en fungerende tilstand, og mål hvor lang tid det tar. Sammenlign med RTO. Hvis gjenopprettingen tar åtte timer og RTO er fire, har du et gap som må løses.
Hold også minst én offline-kopi som ikke er tilgjengelig via nettverket. Ransomware krypterer gjerne alt den kan nå, inkludert nettverkstilknyttede backup-disker og synkroniserte skymapper. En isolert kopi er siste forsvarslinje.
Steg 3: Skriv gjenopprettingsplanen
Gjenopprettingsplanen skal svare på tre spørsmål: hva gjør vi, i hvilken rekkefølge, og hvem gjør det.
Gjenopprettingsrekkefølge. Bruk BIA-tabellen fra steg 1. Systemer med kortest RTO gjenopprettes først. Vær oppmerksom på avhengigheter – det hjelper ikke å gjenopprette ERP-systemet hvis nettverket det kjører på fortsatt er nede. Kartlegg avhengighetskjeden og dokumenter den.
Roller og ansvar. For hver fase av gjenopprettingen, angi hvem som er ansvarlig. Bruk roller, ikke bare navn – folk kan være utilgjengelige under en krise. Definer stedfortredere. For en virksomhet med 50–80 ansatte er det typisk 3–5 nøkkelpersoner som trenger definerte ansvarsområder: en koordinator (gjerne daglig leder eller IT-ansvarlig), teknisk leder for gjenopprettingen, kommunikasjonsansvarlig, og kontaktpersoner mot leverandører.
Kommunikasjon under krisen. Bestem på forhånd hvordan dere kommuniserer internt hvis e-post og intranett er nede. SMS-liste? Telefonkjede? En ekstern meldingstjeneste som ikke avhenger av egen infrastruktur? Bestem også hvem som kommuniserer eksternt – med kunder, leverandører, myndigheter og eventuelt media. Husk at hendelsesrapporteringsplikten har konkrete tidsfrister som løper parallelt med gjenopprettingsarbeidet.
Leverandøravhengigheter. Mange SMBer er avhengige av eksterne leverandører for drift av kritiske systemer. Dokumenter kontaktinformasjon, SLA-er og eskaleringsrutiner for hver leverandør. Sjekk at leverandørkontraktene faktisk dekker det dere trenger under en krise – leverandørkravene i NIS2 gir føringer for hva som bør avtales.
Planen bør være konkret nok til at noen som ikke var involvert i utarbeidelsen kan følge den. Hvis planen krever implisitt kunnskap som bare finnes i hodet på én person, har du et alvorlig sårbarhetspunkt.
Steg 4: Test, øv, og gjør det igjen
En beredskapsplan som aldri er testet, gir falsk trygghet. NIS2 forventer at planer er testet, ikke bare skrevet – gjennomføringsforordningen 2024/2690 krever eksplisitt periodisk testing av driftskontinuitets- og gjenopprettingsplaner.
Tabletop-øvelser er det enkleste startpunktet. Samle nøkkelpersonene rundt et bord, presenter et scenario – «det er mandag morgen, og ransomware har kryptert alle produksjonssystemer» – og gå gjennom planen steg for steg. Hvem ringer hvem? Hvor finner vi backup-mediene? Hva gjør vi med kundeordrer som allerede er i systemet? Slike øvelser avslører hull i planen som ingen tenkte på da den ble skrevet.
Teknisk gjenopprettingstest innebærer å faktisk gjenopprette systemer fra backup, helst i et isolert testmiljø. Mål tiden. Verifiser at dataene er intakte. Sammenlign med RTO og RPO. Denne testen bør gjennomføres minst halvårlig for kritiske systemer.
Dokumenter resultatene. Etter hver øvelse og test, skriv ned hva som fungerte, hva som ikke fungerte, og hvilke endringer som skal gjøres i planen. Dette er ikke bare god praksis – det er dokumentasjon du vil trenge for å vise at virksomheten tar kravene på alvor. Oppdater planen basert på funnene og sett dato for neste test.
Hvor ofte bør du teste? For de fleste SMBer er en tabletop-øvelse årlig og en teknisk backup-test halvårlig et fornuftig minimum. Juster frekvensen opp hvis dere gjør vesentlige endringer i infrastruktur, bytter leverandører, eller har opplevd en reell hendelse.
Kobling til resten av NIS2-kravene
Driftskontinuitet eksisterer ikke i et vakuum. Den henger tett sammen med flere andre krav i Artikkel 21:
Risikoanalysen (Art. 21(2)(a)) identifiserer truslene som beredskapsplanen skal beskytte mot. Uten en god risikoanalyse vet du ikke hvilke scenarier du skal planlegge for.
Hendelseshåndtering (Art. 21(2)(b)) overlapper direkte – en sikkerhetshendelse utløser både hendelseshåndteringsprosessen og aktivering av beredskapsplanen. Rollene og kommunikasjonskanalene bør være koordinert. Se også hendelsesrapportering for de konkrete tidsfristene som gjelder ved varsling til myndigheter.
Leverandørkjedekrav (Art. 21(2)(d)) påvirker gjenopprettingsplanen fordi mange kritiske systemer driftes av eksterne leverandører. Leverandørenes responstid under en krise er en del av din egen gjenopprettingsevne.
For en samlet oversikt over hvordan disse kravene henger sammen, og hvilke tiltak som gir mest effekt for en SMB, se steg-for-steg-guiden til NIS2-forberedelser.
Kom i gang med det du har
Beredskapsplanlegging kan virke overveldende, spesielt for virksomheter uten dedikerte sikkerhetsressurser. Men en enkel plan som er testet, slår en omfattende plan som aldri forlot skrivebordsskuffen. Start med BIA-tabellen, definer RTO og RPO for de viktigste systemene, og bygg derfra.
Digitalsikkerhetsloven stiller allerede krav til virksomheter som leverer samfunnsviktige tjenester i dag. NIS2 vil utvide kretsen av virksomheter som må dokumentere driftskontinuitet. Å starte nå betyr at du bygger kompetanse og rutiner over tid, i stedet for å måtte gjøre alt på en gang under tidspress.
Kartlegg beredskapen din med en gratis NIS2-egenvurdering. Vurderingen dekker alle ti kravområdene i Artikkel 21 og gir deg en oversikt over hvor virksomheten din står – inkludert driftskontinuitet.