Beredskapsplaner i regnskapsbransjen

Det er ikke helt intuitivt hvordan en slik plan skal utarbeides, selve innholdet og vedlikehold av den. Og hva må du tenke på ved et driftsavbrudd?

Del

Etter God regnskapsførerskikk (GRFS) skal alle regnskapsførervirksomheter ha en beredskapsplan.

En beredskapsplan er en plan som beskriver varslingsrutiner, ansvar og oppgaver hvis det oppstår en situasjon med vesentlige driftsavbrudd i IT-systemene. Beredskapsplanen må oppdateres og testes for å sikre at løsningene virker som forutsatt i en situasjon med vesentlige driftsavbrudd. 

Rettsgrunnlaget 

GRFS 2.3 om Bruk av IT-systemer i oppdragsutførelsen sier at regnskapsførervirksomheten skal ha en oppdatert og testet beredskapsplan for å kunne håndtere vesentlige driftsavbrudd knyttet til program- og maskinvare. 

GRFS sier ikke noe om ambisjonene til planen, kun krav til innhold på overordnet nivå. Er det naturlig at en liten regnskapsførervirksomhet har en tilsvarende plan som for en stor virksomhet? Er det naturlig at en virksomhet med kun bruk av skytjenester har en tilsvarende plan som en som har egen server eller har satt ut drift delvis til en ASP-leverandør?  

Svaret på disse spørsmålene er åpenbart nei. Planen skal tilpasses virksomheten og de teknologiske løsningene som benyttes. GRFS kan kun sette generelle krav til planen for å ikke bli irrelevant ved introduksjon av nye teknologiske løsninger i markedet.  

Hva er viktigst å tenke på ved et driftsbrudd? 

Noe av det viktigste å vurdere først ved et driftsavbrudd er effekten av driftsavbruddet.

  • Er kundene rammet på noen måte?
  • Har regnskapsfører avtaler om oppetid for tjenester kundene bruker til daglig?
  • Er det tidsfrister på pliktig rapportering som ikke vil bli overholdt med driftsavbruddet?
  • Er det fare for at ansatte hos kundene ikke får lønn til avtalt tid?

Å kunne svare på slike spørsmål krever god dokumentasjon av oppdragsavtaler, IT-avtaler, løsninger og rutiner. Det er ikke tid til å lese igjennom alt dette ved en krise, derfor kreves det en plan hvor prioriteringsrekkefølgen er avklart på forhånd basert på de avtaler som foreligger.

  • Hvilke systemer må opp først, hva kan vente til senere?
  • Er det vanskelig å gjenskape dokumentasjon i ettertid?
  • Vil transaksjoner gå tapt? 

Når skal planen iverksettes? 

En annen viktig faktor å raskt vurdere er hvorvidt feilen som har oppstått kan bli langvarig. Hvis driftsleverandøren varsler status løpende, må den ansvarlige i regnskapsførervirksomheten på ett eller annet tidspunkt ta en avgjørelse for når planen skal iverksettes, det vil si når det antas å få vesentlige konsekvenser for egen drift – og kundene og nødløsninger må settes i gang.  

Varsling ved iverksettelse 

For å foreta de rette prioriteringene, må de rette personene varsles med en gang hendelsen har skjedd. På denne måten vil et team kunne vurdere videre handlinger. Varslingslisten består normalt av ansatte i regnskapsførervirksomheten med særskilte roller, og eksterne parter som IT-leverandører mv.  Varslingslisten må derfor ligge på en tilgjengelig tjeneste, slik at ressurser blir lett å få tak i når det gjelder, også i helger. 

Hva kan gå galt? 

Noe av det viktigste å tenke ut på forhånd er hva som kan gå galt. Det er ikke noe poeng å ta høyde for alt mulig rart av hendelser, men det er viktig å fokusere på det som er mest sannsynlig, relevant og har størst betydning for virksomheten. Dette er typisk brann, innbrudd, hacking av PC-miljøet, driftsstans ASP-leverandører eller sky-leverandører. Relevante hendelser er avhengig av den teknologiske plattformen virksomheten har. 

Gjenoppretting til normal drift 

En oppgave som bør ligge som en del av en beredskapsplan, er å sikre gjenoppretting til normal drift. Dette innebærer oppgaver som håndtering av transaksjonskøer i systemene, avstemminger for å se at rett datasett har blir gjenopprettet og at manglende transaksjoner har blitt komplettert.  

Evaluering av hendelser 

En viktig del av det løpende vedlikeholdet av en beredskapsplan er å lære av reelle hendelser. Det er lurt å sette seg ned å vurdere hva som gikk bra og hva som kan forbedres ved siste hendelse. Hva sier kundene? Hva sier systemleverandørene? Ble det mye etterarbeid, og kan dette unngås i fremtiden? 

Testing av planen 

Reelle hendelser er den beste testingen av om en plan fungerer eller ikke. GRFS krever årlig testing for å påse at planen er relevant og hensiktsmessig. Når det ikke skjer hendelser er det vanskelig å teste den fullt ut. En anbefaling er derfor å løpende teste deler av planen om gangen og ta en årlig skrivebordsøvelse. Eksempelvis kan skrivebordsøvelsen inneholde elementer som:  

  • Er personene på varslingslisten fremdeles relevante? Interne og eksterne. Ring og hør med dem som svarer om de er klar over sin rolle. 
  • Sett sammen beredskapsteamet rundt et bord og gå igjennom krav til iverksettelse, prioriteringer og relevante handlinger.  
  • Er det nye systemer som har kommet til som skal inkluderes i planene? Er det systemer som har utgått og som skal ut av planen? Viktig at ikke irrelevante forhold forstyrrer i en krisesituasjon. 
  • Er det lagt tilbake sikkerhetskopier i det siste som underbygger at sikkerhetskopieringen virker? Om ikke, skal vi prøve på en testserver og sjekke? Kan systemleverandøren dokumentere at de legger tilbake sikkerhetskopier løpende for sine kunder uten feil? 
  • Er det inngått nye kundeavtaler som krever spesielle oppetider eller som har dagsbøter ved manglende kundetilgang til tjenester? 
  • Er det inngått nye lisensavtaler med nye krav til, og rutiner for, sikkerhetskopiering og tilbakelegging av sikkerhetskopier? 
  • Har vi sikkerhetskopiering av alt som er viktig? Herunder kontorstøtteløsninger? 
  • Har vi avtaler om rask tilgang til erstatningsutstyr hvis utstyr på kontoret har gått tapt i brann o.l.? 

Testing kan skje på flere måter avhengig av den teknologiske plattformen. Det er særdeles viktig å dokumentere at testing har skjedd, enten gjennom året, eller på et tidspunkt årlig. Mye kan avklares med en skrivebordstest, men sørg for at det tekniske også testes slik at dere ikke får noen overraskelser her. 

KS Komplett 

I KS komplett har vi utarbeidet en mal (7-3-6) for en beredskapsplan som dere kan benytte til egen virksomhet. Denne malen er veiledende, og bør tilpasses egen virksomhet avhengig av underliggende teknologi og risikobildet. I dette dokumentet har vi listet opp typiske hendelser som kan skje, og hvor det bør foreligge beredskapsplaner. 

(Artikkelen er oppdatert 9.2.2024 med henvisning til ny GRFS 2.3)