Driftskontinuitet under DORA
Driftskontinuitet er et sentralt krav innenfor DORAs pilar 1 om IKT-risikostyring. Artikkel 11 krever at alle finansielle enheter etablerer, vedlikeholder og jevnlig gjennomgar en IKT-driftskontinuitetspolicy. Artikkel 12 bygger videre pa dette ved a kreve dedikerte IKT-respons- og gjenopprettingsplaner som spesifiserer hvordan enheten skal gjenopprette driften etter en IKT-relatert forstyrrelse.
Sammen skaper disse to artiklene et omfattende kontinuitetsrammeverk: policyen (art. 11) fastsetter de strategiske malene og styringsstrukturen, mens respons- og gjenopprettingsplanene (art. 12) gir de operasjonelle detaljene som trengs for a handle under en krise. Begge ma godkjennes av ledelsesorganet og utsettes for regelmessig testing.
For finansielle enheter som allerede er kjent med tradisjonell driftskontinuitetsstyring, tilforer DORA en spesifikk IKT-dimensjon. Forordningen anerkjenner at moderne finansielle tjenester er sterkt avhengige av teknologisk infrastruktur, og at kontinuitetsplanlegging ma adressere IKT-spesifikke risikoer som cyberangrep, systemfeil, datakorrupsjon og avbrudd hos tredjepartsleverandorer. Dette skiller seg fra bredere driftskontinuitetsplanlegging, som ogsa dekker fysiske forstyrrelser, pandemier og andre ikke-IKT-scenarier.
IKT-driftskontinuitetspolicy (art. 11)
Artikkel 11 krever at finansielle enheter etablerer en omfattende IKT-driftskontinuitetspolicy som en integrert del av det overordnede IKT-risikorammeverket. Denne policyen danner det strategiske grunnlaget for all kontinuitets- og gjenopprettingsvirksomhet.
Konsekvensanalyse (BIA)
Policyen skal vaere basert pa en konsekvensanalyse (BIA) som identifiserer kritiske og viktige funksjoner, vurderer den potensielle konsekvensen av alvorlige forstyrrelser, og kvantifiserer den maksimalt tolerable nedetiden for hver funksjon. BIA danner grunnlaget for alle gjenopprettingsmal og beslutninger om ressursallokering.
Gjenopprettingsmal (RPO og RTO)
Finansielle enheter skal definere gjenopprettingspunktmal (RPO) og gjenopprettingstidsmal (RTO) for hver kritisk funksjon. RPO angir det maksimalt akseptable datatapet malt i tid, mens RTO fastsetter den maksimalt akseptable varigheten for en funksjon er gjenopprettet. Disse malene skal vaere realistiske og stottet av enhetens tekniske infrastruktur.
Identifisering av kritiske funksjoner
Enheten skal opprettholde en oppdatert oversikt over alle IKT-systemer, eiendeler og prosesser som stotter kritiske eller viktige funksjoner. Denne kartleggingen gjor enheten i stand til a forsta avhengigheter, prioritere gjenopprettingsarbeid og allokere ressurser effektivt under en forstyrrelse.
Kommunikasjonsplaner
IKT-driftskontinuitetspolicyen skal inkludere kommunikasjonsordninger for krisesituasjoner. Dette dekker interne eskaleringsruter, varsling av tilsynsmyndigheter, kommunikasjon med kunder og motparter, og koordinering med kritiske IKT-tredjepartsleverandorer. Tydelige kommunikasjonsprotokoller reduserer responstid og forhindrer forvirring under en hendelse.
Regelmessig gjennomgang og oppdatering
Policyen skal gjennomgas og oppdateres minst arlig, eller oftere etter vesentlige endringer i IKT-miljoet, organisasjonsstrukturen eller trusselbildet. Laerdommer fra hendelser, tester og nestenulykker skal innarbeides i policyrevisjoner. Alle endringer krever godkjenning fra ledelsesorganet.
Respons- og gjenopprettingsplaner (art. 12)
Der artikkel 11 fastsetter det strategiske rammeverket, krever artikkel 12 de operasjonelle detaljene. Finansielle enheter skal utvikle, dokumentere og vedlikeholde IKT-respons- og gjenopprettingsplaner som oversetter kontinuitetspolicyen til handlingsrettede prosedyrer.
IKT-responsplaner skal definere de umiddelbare tiltakene som skal iverksettes nar en IKT-forstyrrelse oppdages. Dette inkluderer klassifiseringskriterier for hendelser, initielle inneslutningsstiltak, roller og ansvar for responsteamet, beslutningsmyndighet for aktivering av gjenopprettingsprosedyrer, og utlosere for eskalering til seniorledelsen eller ledelsesorganet.
IKT-gjenopprettingsplaner skal beskrive steg-for-steg-prosedyrer for gjenoppretting av forstyrrede funksjoner innenfor definerte RTO- og RPO-mal. Dette omfatter bytte til backup- eller redundante systemer, gjenoppretting av data fra sikkerhetskopier, validering av integriteten til gjenopprettede systemer og data, og kriteriene for a erklare at normal drift er gjenopptatt.
Eskaleringsprosedyrer skal vaere tydelig definert, med spesifikasjon av nar og hvordan hendelser eskaleres internt, nar tilsynsmyndigheter skal varsles, og hvordan kommunikasjon med eksterne interessenter (kunder, markedsaktorer, betalingssystemer) haandteres. Eskaleringsrammeverket skal vaere i trad med enhetens rapporteringsforpliktelser under DORA artikkel 17-23.
Laerdommer. Etter hver aktivering av respons- eller gjenopprettingsplaner skal enheten gjennomfore en etterevaluering for a identifisere hva som fungerte, hva som sviktet, og hva som ma forbedres. Disse laerdommene skal dokumenteres og mates tilbake i kontinuitetspolicyen og gjenopprettingsplanene. Der forstyrrelsene var forsaket av eller involverte en IKT-tredjepartsleverandor, skal evalueringen ogsa vurdere om kontraktsordningene og exit-strategiene fortsatt er tilstrekkelige.
Testkrav for BCP
En driftskontinuitetsplan som aldri er testet gir falsk trygghet. DORA krever at finansielle enheter tester sine IKT-driftskontinuitetsplaner regelmessig for a verifisere at de fungerer i praksis og at ansatte er forberedt pa a utfore dem under press.
Arlig testing. IKT-driftskontinuitetsplaner skal testes minst en gang per ar. For enheter med komplekse IKT-miljoer eller som stotter kritiske finansmarkedsfunksjoner, kan hyppigere testing vaere passende og forventet av tilsynsmyndigheter.
Scenariobaserte ovelser. Testing skal ga lenger enn enkle skrivebordsovelser. DORA forventer scenariobaserte ovelser som simulerer realistiske forstyrrelseshendelser, inkludert cyberangrep, losepengevirusangrep, datasenterssvikt, skytjenesteavbrudd og samtidige feil i flere systemer. Scenarier bor varieres pa tvers av testsykluser for a dekke ulike typer forstyrrelser og ulike kritiske funksjoner.
Dokumentasjon og rapportering. Alle testresultater skal dokumenteres grundig, inkludert scenario brukt, deltakere, tidslinje for hendelser, systemer og funksjoner testet, identifiserte problemer og utbedringstiltak. Testresultater skal rapporteres til ledelsesorganet, og vesentlige svakheter skal adresseres gjennom utbedringsplaner med klare tidsfrister og ansvarlige eiere.
Bredere testing av motstandsdyktighet. BCP-testing er del av det bredere programmet for testing av digital operasjonell motstandsdyktighet etablert under DORA artikkel 24-27. Dette rammeverket inkluderer sarbarhetsvurderinger, gjennomganger av nettverkssikkerhet, gap-analyser og — for utpekte enheter — trusselbasert penetrasjonstesting (TLPT) pa en trearssyklus. BCP-testing og motstandsdyktighetstesting bor koordineres for a unnga huller og duplisering, og for a gi et helhetlig bilde av enhetens operasjonelle motstandsdyktighet.
Tredjepartskontinuitet
Finansielle enheter er i okende grad avhengige av IKT-tredjepartsleverandorer for kritiske funksjoner, fra skyinfrastruktur og betalingsbehandling til kjernebanksystemer og cybersikkerhetstjenester. DORA anerkjenner at en kontinuitetsplan som kun dekker enhetens egne systemer er ufullstendig.
Dekning av kritiske leverandorer. IKT-driftskontinuitetspolicyen skal eksplisitt adressere scenarier der en kritisk IKT-tredjepartsleverandor opplever en forstyrrelse eller blir utilgjengelig. Dette betyr at kontinuitetsplaner ma inkludere alternative ordninger, manuelle reservelosninger eller sekundaere leverandorer som kan opprettholde tjenesteleveransen mens den primaere leverandoren gjenoppretter seg.
Exit-strategier. DORA krever at finansielle enheter opprettholder troverdige exit-strategier for alle kritiske tredjepartsordninger for IKT. En exit-strategi skal gjore enheten i stand til a trekke seg ut av ordningen uten a forstyrre forretningsaktivitetene, uten a begrense etterlevelse av regulatoriske krav, og uten a ga pa kompromiss med kontinuitet og kvalitet pa tjenester levert til kunder. Exit-strategier skal testes og oppdateres som del av den regelmessige kontinuitetsplanleggingssyklusen.
Konsentrasjonsrisiko. Der flere kritiske funksjoner avhenger av en enkelt IKT-tredjepartsleverandor, eller der flere leverandorer er avhengige av samme underliggende underleverandor, star enheten overfor konsentrasjonsrisiko. DORA krever at finansielle enheter vurderer og styrer denne konsentrasjonsrisikoen som del av sin kontinuitetsplanlegging, slik at et enkelt feilpunkt ikke kan ta ned flere kritiske funksjoner samtidig. Informasjonsregisteret som kreves under DORA art. 28 gir datagrunnlaget for denne vurderingen.
DORA og ISO 22301
ISO 22301 er den internasjonale standarden for styringssystemer for driftskontinuitet (BCMS). Den gir en strukturert tilnaerming til driftskontinuitet som inkluderer policyutvikling, konsekvensanalyse, strategiformulering, planutvikling, ovelser og testing, og kontinuerlig forbedring. Mange finansielle enheter har allerede tatt i bruk ISO 22301 som del av sine bredere motstandsdyktighetsprogrammer.
Den gode nyheten for enheter med eksisterende ISO 22301-sertifisering er at standarden i stor grad samsvarer med DORAs krav til driftskontinuitet. Begge rammeverk krever en ledelsesorgansgodkjent kontinuitetspolicy, regelmessig konsekvensanalyse, definerte gjenopprettingsmal, dokumenterte respons- og gjenopprettingsplaner, periodisk testing og en syklus med kontinuerlig forbedring basert pa laerdommer.
Hvor ISO 22301 moter DORA
Dersom enheten din allerede har ISO 22301-sertifisering, har du et sterkt grunnlag for DORA-samsvar pa driftskontinuitet. BIA-prosessen, plandokumentasjonen, testregimet og ledelsesgjennomgangssyklusen fra ISO 22301 samsvarer alle med DORA artikkel 11 og 12. Du vil imidlertid trolig matte utvide det eksisterende rammeverket med DORA-spesifikke elementer: IKT-fokuserte gjenopprettingsmal (RPO/RTO for spesifikke IKT-systemer heller enn bare forretningsprosesser), eksplisitt dekning av tredjepartskontinuitet for IKT, vurdering av konsentrasjonsrisiko, integrasjon med hendelsesrapportering og de spesifikke styringsrapporteringskravene DORA palegger.
Enheter uten ISO 22301 kan fortsatt oppfylle DORAs krav ved a bygge et IKT-driftskontinuitetsprogram direkte fra artikkel 11 og 12. A ta i bruk ISO 22301-strukturen gir imidlertid et velutprovd styringssystemrammeverk som forenkler bade forste implementering og lopende vedlikehold. For organisasjoner som ogsa er underlagt andre regulatoriske rammeverk, gir ISO 22301 et felles sprak og en struktur som stotter samsvar pa tvers av rammeverk. Se ogsa hvordan ISO 27001 samsvarer med DORAs bredere krav til IKT-risikostyring.
Hvordan DORA GRC hjelper
DORA GRC inkluderer en dedikert BCP-modul som stotter finansielle enheter i a bygge og vedlikeholde IKT-driftskontinuitetsordninger i trad med artikkel 11 og 12.
Strukturert BCP-arbeidsflate. Definer dine kritiske funksjoner, kartlegg IKT-avhengigheter, sett RPO- og RTO-mal, og dokumenter respons- og gjenopprettingsplanene dine i et strukturert format som samsvarer direkte med DORA-kravene. Modulen veileder deg gjennom hvert element i artikkel 11 og 12 for a sikre at ingenting overses.
Test- og ovelsessporing. Planlegg, dokumenter og spor resultatene av BCP-testene dine. Registrer scenarier, deltakere, funn og utbedringstiltak. Generer rapporter til ledelsesorganet som oppsummerer testresultater og apne utbedringsoppgaver.
Integrasjon med tredjepartskontinuitet. BCP-planer kobles direkte til tredjepartsrisikostyringsmodulen, slik at exit-strategier, vurderinger av konsentrasjonsrisiko og kontinuitetsordninger for leverandorer vedlikeholdes pa ett sted og holdes synkronisert.
Gap-analyse. Det gratis DORA-vurderingsverktoy evaluerer din navarende BCP-modenhet opp mot DORA-kravene og identifiserer spesifikke gap som ma adresseres. For en komplett oversikt over alle DORA-pilarer og plattformfunksjonalitet, utforsk funksjonssiden eller DORA compliance-guiden.
Ofte stilte sporsmal
DORA artikkel 11 krever at finansielle enheter etablerer en omfattende IKT-driftskontinuitetspolicy som inkluderer konsekvensanalyse, definerte RPO- og RTO-mal for kritiske funksjoner, kommunikasjonsplaner for krisesituasjoner og regelmessige gjennomgangssykluser. Artikkel 12 legger til kravet om detaljerte IKT-respons- og gjenopprettingsplaner som spesifiserer hvordan man gjenoppretter driften etter en forstyrrelse, inkludert bytte til backup-systemer, eskaleringsprosedyrer og laerdommer etter hendelser. Bade policyen og planene skal godkjennes av ledelsesorganet og testes minst arlig.
DORA krever testing minst en gang per ar. Tester skal bruke scenariobaserte ovelser som simulerer realistiske forstyrrelser som cyberangrep, infrastruktursvikt og tredjepartsavbrudd. Alle testresultater skal dokumenteres og rapporteres til ledelsesorganet, og svakheter som identifiseres skal adresseres gjennom utbedringsplaner med klare tidsfrister. For enheter med komplekse miljoer eller systemviktige roller kan tilsynsmyndigheter forvente hyppigere testing.
Ja. DORA krever at IKT-driftskontinuitetsordninger eksplisitt dekker kritiske IKT-tredjepartsleverandorer. Dette betyr at kontinuitetsplaner ma ta hensyn til leverandorforstyrrelser, inkludere exit-strategier for kritiske ordninger, og vurdere konsentrasjonsrisiko der flere funksjoner avhenger av en enkelt leverandor. Finansielle enheter ma sikre at kontraktsvilkar med kritiske leverandorer inkluderer adekvate bestemmelser for kontinuitet og katastrofegjenoppretting.
ISO 22301 er den internasjonale standarden for styringssystemer for driftskontinuitet, og den samsvarer godt med DORA artikkel 11 og 12. Begge rammeverk krever ledelsesorgansgodkjente policyer, konsekvensanalyser, definerte gjenopprettingsmal, dokumenterte planer, periodisk testing og kontinuerlig forbedring. Enheter med ISO 22301-sertifisering har et sterkt grunnlag for DORA BCP-samsvar, men ma kanskje tilfoye DORA-spesifikke elementer som IKT-fokuserte RPO/RTO-definisjoner, tredjepartskontinuitetsbestemmelser, vurderinger av konsentrasjonsrisiko og integrasjon med regulatorisk rapportering.