Forretningskonsekvensanalyse for ISO 27001, NIS2 og DORA

Revisionsspørgsmålet, der afslører det reelle hul i forretningskontinuiteten

Det er mandag morgen, og Maria, CISO i en hurtigt voksende FinTech-virksomhed, forbereder sig til et møde i bestyrelsens risikoudvalg. Emnelinjen er kort: “DORA og NIS2-parathed: BIA-gennemgang.”

Hendes team har opbygget det, de fleste ledere forventer at se. Der findes et certificeret ISO/IEC 27001:2022 ISMS, playbooks for hændelseshåndtering, skærmbilleder fra backup, sårbarhedsrapporter, leverandørspørgeskemaer, diagrammer over cloudarkitektur og et opdateret risikoregister. Virksomhedskunder sender NIS2-spørgeskemaer. Kunder i finanssektoren indarbejder DORA-klausuler i kontrakterne. Overvågningsrevisionen for ISO/IEC 27001:2022 er kun en måned væk.

Så stiller den eksterne revisor spørgsmålet, der ændrer stemningen i lokalet:

“Hvis jeres platform til kundeonboarding er utilgængelig i 18 timer, hvilke regulerede tjenester påvirkes så, hvilke leverandører er involveret, hvad er den godkendte genopretningsprioritet, og hvor er bevismaterialet for, at forretningen har accepteret RTO og RPO?”

Lokalet bliver stille.

Backupplanen siger én ting. Planen for genopretning efter alvorlige hændelser siger noget andet. Leverandørkontrakten indeholder en SLA for tilgængelighed, men intet bevismateriale fra genopretningstest. Risikoregisteret nævner tilgængelighed, men forklarer ikke, hvorfor én tjeneste skal gendannes hurtigere end en anden. Ledelsen har godkendt sikkerhedspolitikken, men ikke den forretningsmæssige konsekvens af nedetid.

Det er BIA-problemet i 2026.

En forretningskonsekvensanalyse, eller BIA, er ikke længere et regneark vedlagt en kontinuitetsplan. Den er bevisbroen mellem forretningstjenester, IKT-aktiver, leverandører, genopretningsprioriteter, RTO/RPO, hændelsestærskler, robusthedstest og bestyrelsens ansvar. For organisationer, der tilpasser ISO/IEC 27001:2022 til NIS2-forretningskontinuitet og DORA IKT-robusthed, er BIA’en dér, hvor efterlevelse bliver operationel.

De stærkeste organisationer har allerede mange af de rigtige kontroller. Deres svaghed er sporbarhed. BIA’en omsætter spredt bevismateriale til en revisionsklar fortælling: hvad der er vigtigt, hvorfor det er vigtigt, hvor hurtigt det skal gendannes, hvilke afhængigheder der understøtter det, hvad der er testet, hvad der fejlede, hvad der blev forbedret, og hvem der godkendte restrisikoen.

Hvorfor gamle BIA-regneark nu er en belastning

NIS2 og DORA har ændret tonen i efterlevelse vedrørende forretningskontinuitet. De behandler ikke forretningskontinuitet, genopretning efter alvorlige hændelser, hændelseshåndtering, leverandørrobusthed og styring som adskilte dokumenter. De forventer, at de fungerer som ét samlet system.

For NIS2-enheder kræver Article 21 tekniske, operationelle og organisatoriske foranstaltninger til styring af risici for net- og informationssystemer samt til at forebygge eller minimere hændelsers påvirkning af modtagere af tjenester og andre tjenester. Minimumsforanstaltningerne omfatter risikoanalyse, håndtering af hændelser, forretningskontinuitet inklusive backupstyring, genopretning efter alvorlige hændelser og krisestyring, sikkerhed i forsyningskæden, håndtering af sårbarheder, vurdering af kontroleffektivitet, træning, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver, MFA og sikker kommunikation.

NIS2 Article 20 flytter spørgsmålet ind i bestyrelseslokalet. Ledelsesorganer skal godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og kan holdes ansvarlige for overtrædelser. Det betyder, at en udokumenteret RTO på fire timer ikke blot er en teknisk uoverensstemmelse. Det er en svaghed i governance.

DORA finder anvendelse fra 17. januar 2025 og etablerer en ensartet EU-ramme for styring af IKT-risiko, rapportering af hændelser, test af digital operationel robusthed, styring af IKT-tredjepartsrisiko, kontraktlige krav og tilsyn med kritiske IKT-tredjepartsudbydere. For finansielle enheder, og for teknologileverandører, der understøtter dem gennem kontrakter, gør DORA operationel robusthed til et struktureret dokumentationskrav.

DORA Articles 5 og 6 kræver governance og en dokumenteret ramme for styring af IKT-risiko. Articles 7 til 14 dækker pålidelige og robuste IKT-systemer, identifikation af aktiver og afhængigheder, beskyttelse, detektion, IKT-forretningskontinuitet, backup, gendannelse, genopretning, læring efter hændelser, awareness, træning og krisekommunikation. Articles 24 til 26 kræver test af digital operationel robusthed for finansielle enheder, der ikke er mikrovirksomheder. Articles 28 til 30 formaliserer IKT-tredjepartsrisiko, registre over IKT-tjenestekontrakter, exitstrategier, serviceniveauer, revisionsrettigheder og beredskabskrav.

ISO/IEC 27001:2022 giver rygraden i ledelsessystemet. Klausulerne kræver, at organisationen definerer kontekst, interessenter, retlige og kontraktlige forpligtelser, omfang, lederskab, politik, roller, risikovurdering, risikobehandling, anvendelseserklæring, operationel planlægning, evaluering af performance og løbende forbedring.

Det manglende led er ofte BIA’en. Uden den er kontinuitetsplaner ikke tydeligt risikobaserede, backupmål er ikke forretningsgodkendte, leverandører er ikke kortlagt til kritiske tjenester, og ledelsen kan ikke pålideligt dokumentere, at robusthedsbeslutninger er baseret på forretningsmæssig påvirkning.

BIA som kontrolplan for robusthedsbevismateriale

En juridisk forsvarlig BIA besvarer syv spørgsmål, som revisorer, tilsynsmyndigheder, kunder og bestyrelser i stigende grad stiller:

1. Hvilke forretningstjenester er kritiske?
2. Hvilke IKT-aktiver, datalagre, personer, leverandører og forsyninger understøtter hver tjeneste?
3. Hvad er den operationelle, finansielle, juridiske, kontraktlige, kundemæssige, sikkerhedsmæssige og omdømmemæssige konsekvens af afbrydelser over tid?
4. Hvad er Maximum Tolerable Downtime, eller MTD?
5. Hvad er de godkendte Recovery Time Objective, eller RTO, og Recovery Point Objective, eller RPO?
6. Gør backup, redundans, cloud, leverandører, bemanding og kommunikationsordninger disse mål realistisk opnåelige?
7. Har organisationen testet genopretningsvejen og gennemgået resultaterne?

Clarysecs enterpriseudgave af Politik for forretningskontinuitet og genopretning efter alvorlige hændelser P32 Politik for forretningskontinuitet og genopretning efter alvorlige hændelser fastsætter kravet tydeligt:

Forretningskonsekvensanalyse (BIA) skal udføres mindst én gang årligt for alle kritiske forretningsenheder og gennemgås ved væsentlige ændringer i systemer, processer eller afhængigheder. BIA-output skal definere: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTO’er) 5.2.3. Recovery Point Objectives (RPO’er) 5.2.4. Kritiske afhængigheder (systemer, leverandører, personale)

Denne klausul giver revisorer et praktisk udgangspunkt. Den forebygger også den almindelige fejl, hvor planen for forretningskontinuitet, planen for genopretning efter alvorlige hændelser, backupplanen, leverandørregisteret og hændelseshåndteringsprocessen hver især bruger en forskellig definition af “kritisk”.

Den samme politik kræver en integreret ledelsestilgang:

Organisationen skal vedligeholde et integreret ledelsessystem for forretningskontinuitet (BCMS), der er tilpasset ISO 22301 og ISO/IEC 27001, og sikre integration af: 5.1.1. Forretningskonsekvensanalyse (BIA) 5.1.2. Sikkerhedsrisikovurdering for kontinuitetstrusler 5.1.3. Planer for forretningskontinuitet (BCP’er) 5.1.4. IKT-planer for genopretning efter alvorlige hændelser (DRP’er) 5.1.5. Test- og øvelsesprogrammer 5.1.6. Dokumentation og løbende forbedring

Det er forskellen mellem tjeklisteefterlevelse og revisionsklar robusthed. BIA’en er ikke et engangsdokument. Den bliver en del af ISMS- og BCMS-beviskæden.

Hvordan ISO/IEC 27001:2022 gør BIA til revisionsbart bevismateriale

ISO/IEC 27001:2022 kræver ikke, at alle organisationer bruger udtrykket “forretningskonsekvensanalyse” i hver klausul, men kravene gør BIA-bevismateriale meget værdifuldt.

Klausulerne 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessenter, retlige og regulatoriske forpligtelser, kontraktlige krav, grænseflader, afhængigheder og ISMS-omfang. En BIA er ofte det mest praktiske bevismateriale for disse grænseflader og afhængigheder. Den viser, hvilken cloudtjeneste, betalingsprocessor, identitetsudbyder, teleudbyder, administreret sikkerhedstjeneste, datacenter eller outsourcet supportteam der muliggør en kritisk tjeneste.

Klausulerne 5.1 til 5.3 kræver lederskab fra øverste ledelse, ressourcer, kommunikation, rolletildeling og rapportering. En BIA giver ledelsen et forretningsmæssigt grundlag for investeringer i forretningskontinuitet. Uden den er RTO- og RPO-mål tekniske ønsker, ikke godkendte forretningskrav.

Klausulerne 6.1.1 til 6.1.3 kræver gentagelig risikovurdering og risikobehandling for informationssikkerhed. Organisationen skal identificere risici for fortrolighed, integritet og tilgængelighed, analysere konsekvenser og sandsynlighed, fastsætte risikoniveauer, prioritere behandling, vælge kontroller, sammenligne valgte kontroller med Annex A, udarbejde en anvendelseserklæring, oprette en risikobehandlingsplan og indhente godkendelse fra risikoejeren. En BIA styrker “konsekvens”-siden af risikovurderingen. Den forklarer, hvorfor en to timers afbrydelse af ét system er acceptabel, mens en to timers afbrydelse af et andet medfører kundeskade, regulatorisk eksponering, kontraktbrud eller væsentlig omsætningspåvirkning.

Annex A indeholder kontrolkataloget. For BIA og forretningskontinuitet omfatter de mest relevante ISO/IEC 27001:2022 Annex A-kontroller:

I Zenith Controls: The Cross-Compliance Guide Zenith Controls profilerer Clarysec ISO/IEC 27002:2022-kontrol 5.30, IKT-beredskab for forretningskontinuitet, som en korrigerende kontrol med fokus på tilgængelighed, kortlagt til Respond-cybersikkerhedskonceptet, den operationelle kapacitet for forretningskontinuitet og robusthedsdomænet. Kontrol 5.29, informationssikkerhed under afbrydelse, profileres som forebyggende og korrigerende og beskytter fortrolighed, integritet og tilgængelighed. Kontrol 8.13, backup af information, profileres som korrigerende og understøtter integritet og tilgængelighed gennem genopretning.

Denne sondring er vigtig. En BIA må ikke kun spørge: “Kan vi gendanne?” Den skal også spørge: “Kan vi forblive sikre under en afbrydelse?” Under et ransomware-angreb, en cloudafbrydelse, et leverandørsvigt eller en datacenterhændelse har organisationen stadig behov for adgangsstyring, logning, overvågning, bevaring af bevismateriale, sikker kommunikation og databeskyttelsesforanstaltninger.

Den praktiske BIA-model for bevismateriale

En stærk BIA kobler forretningssprog til teknisk dokumentation. Clarysec strukturerer typisk bevismodellen i fem lag.

Denne bevismodel fungerer, fordi den følger revisorers tankegang. Først spørger de, hvad der er kritisk. Derefter spørger de, hvad der understøtter det. Så spørger de, hvem der godkendte genopretningsmålet. Derefter spørger de, om tekniske ordninger og leverandørordninger kan opfylde målet. Til sidst spørger de, om organisationen har testet og forbedret kapaciteten.

NIST CSF 2.0 er nyttig som kommunikationslag. Metoden med CSF-profiler tilskynder organisationer til at definere omfang, indsamle input som politikker, prioriteringer for enterprise-risiko, BIA-registre, cybersikkerhedskrav, standarder, procedurer, sikkerhedsforanstaltninger og arbejdsroller, oprette aktuelle profiler og målprofiler, analysere huller, udarbejde en prioriteret handlingsplan, implementere planen og opdatere profilen. Det er næsten præcis den måde, en BIA bør indgå i en køreplan for tværgående efterlevelse.

En BIA-øvelse på én uge, der skaber reelt bevismateriale

Antag, at en SaaS-udbyder understøtter kunder i finanssektoren. Platformen understøtter kundeonboarding, dokumentverifikation og kundeunderretninger. Udbyderen er ikke selv en bank, men kunderne sender kontraktlige anmodninger drevet af DORA og NIS2-leverandørspørgeskemaer.

En fokuseret øvelse på én uge kan hurtigt skabe brugbart bevismateriale.

Dag 1: Identificér kritiske tjenester og konsekvensvinduer

Start med tjenester, ikke servere. Involvér forretningsansvarlige, IT, sikkerhed, juridisk funktion, support, databeskyttelse og leverandørstyring.

Denne rammesætning er vigtig. Tilsynsmyndigheder og kunder forstår tjenester og funktioner. Applikationer er vigtige, fordi de understøtter disse tjenester.

Dag 2: Kortlæg afhængigheder

For hver tjeneste kortlægges applikationer, databaser, infrastruktur, cloudtjenester, identitetsudbydere, overvågning, backupværktøjer, personer, leverandører og understøttende forsyninger.

Her begynder BIA’en at skabe værdi. Den synliggør den ellers usynlige genopretningsvej, herunder de afhængigheder, der ofte overses i en teknisk DR-plan.

Dag 3: Godkend MTD, RTO og RPO

Den forretningsansvarlige foreslår MTD. IT og sikkerhed validerer, om den foreslåede RTO og RPO er teknisk opnåelige. Ledelsen godkender de endelige mål.

For mindre organisationer giver Clarysecs Politik for forretningskontinuitet og genopretning efter alvorlige hændelser - SME P32S Politik for forretningskontinuitet og genopretning efter alvorlige hændelser - SME den samme disciplin i et enklere sprog. Den kræver BCP/DR-planer, der beskriver tilgangen til gendannelse af væsentlige funktioner:

Den administrerende direktør (GM) skal godkende og vedligeholde planer for forretningskontinuitet og genopretning efter alvorlige hændelser (BCP/DRP), som klart beskriver organisationens tilgang til gendannelse af væsentlige funktioner.

Den kræver også, at planen omfatter:

prioriterede tjenester og systemer (kritiske forretningsfunktioner)

Og:

Recovery Time Objectives (RTO’er) og Recovery Point Objectives (RPO’er) for hvert system

Nøglen er ikke overdreven dokumentation. Nøglen er sporbarhed, godkendelse og bevismateriale for, at genopretningsmålene er baseret på reel forretningsmæssig påvirkning.

Dag 4: Afstem backup med forretningsmæssig påvirkning

Mange organisationer fejler her. BIA’en kan fastsætte en RPO på fire timer, mens backups kører hver 24. time. Eller backupværktøjet beskytter produktionsdatabaser, men ikke konfiguration, secrets, repositories med infrastructure-as-code, objektlagring, DNS-registreringer, identitetsindstillinger eller API-gateway-konfiguration.

Clarysecs Politik for backup og gendannelse P15 Politik for backup og gendannelse kræver en Master Backup Schedule, der er koblet til BIA-resultater:

En Master Backup Schedule skal vedligeholdes og gennemgås årligt. Den skal angive: 5.1.1 Backupfrekvens (f.eks. daglige inkrementelle backups og ugentlige fulde backups) 5.1.2 Opbevaringsperioder pr. system eller datatype 5.1.3 Krypteringskrav og oplysninger om lagringsplacering 5.1.4 RTO/RPO-mål koblet til resultaterne af vurderingen af forretningsmæssig påvirkning

Denne klausul er revisionsguld. Den tvinger backupdesignet til at afspejle forretningsmæssig påvirkning, ikke lagringsmæssig bekvemmelighed.

Dag 5: Test én genopretningsvej, og opret korrigerende handlinger

Test ikke alt på én gang. Vælg én kritisk tjeneste, og gennemfør en fokuseret genopretningstest. Gendan databasen. Genopbyg applikationskonfigurationen. Valider autentifikation. Bekræft, at logfiler er tilgængelige. Kontrollér kapaciteten til kundeunderretning. Registrér tidsforbrug, datatab, fejl, beslutninger og korrigerende handlinger.

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandler fasen Controls in Action, trin 23, organisatoriske kontroller, herunder IKT-beredskab for forretningskontinuitet. Den stiller det spørgsmål, ethvert revisionsteam bør stille:

Kan jeres systemer understøtte jeres mål for forretningskontinuitet, når lyset blinker, netværk går ned, eller katastrofen rammer?

Det samme trin giver en praktisk instruks:

Verificér, at Recovery Time Objectives (RTO) og Recovery Point Objectives (RPO) for kritiske systemer stemmer overens med forventningerne til forretningskontinuitet (5.30). Gennemfør mindst én teknisk genopretningstest eller failover-simulering, og dokumentér resultaterne.

Det er forskellen mellem at have en BIA og at have juridisk forsvarligt BIA-bevismateriale. Målet er ikke kun dokumenteret. Det er testet.

Kortlægning af BIA-bevismateriale til NIS2, DORA, GDPR, NIST og COBIT 2019

En velopbygget BIA bliver et aktiv for tværgående efterlevelse. Ét samlet bevisgrundlag kan besvare mange spørgsmål.

GDPR overses ofte i BIA-drøftelser. Alligevel kræver GDPR Article 5, at personoplysninger behandles med integritet og fortrolighed, herunder beskyttelse mod hændeligt tab, tilintetgørelse eller beskadigelse ved brug af passende tekniske eller organisatoriske foranstaltninger. Ansvarlighed kræver, at den dataansvarlige kan dokumentere efterlevelse. Hvis en platform med personoplysninger ikke kan gendannes inden for en godkendt og testet tidsramme, påvirker databeskyttelsesrisikoen tilgængelighed, integritet, vurdering af brud og kundetillid.

NIS2-hændelsesrapportering tilføjer en yderligere dimension. Article 23 kræver, at væsentlige hændelser anmeldes uden unødig forsinkelse, herunder en tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer og endelig rapportering inden for én måned. En BIA hjælper med at klassificere alvorlighed, fordi den definerer berørte tjenester, modtagere af tjenester, driftsmæssig afbrydelse og mulig grænseoverskridende påvirkning.

DORA-hændelsesklassificering tager også højde for berørte kunder eller transaktioner, varighed, geografisk udbredelse, datatab, kritikaliteten af de berørte tjenester og økonomisk påvirkning. Dette er BIA-felter. Hvis BIA’en er svag, bliver hændelsesklassificering subjektiv på det værst tænkelige tidspunkt.

Leverandørkontinuitet er dér, hvor BIA møder kontraktvirkeligheden

For NIS2 og DORA er leverandørkontinuitet ikke længere valgfrit. NIS2 Article 21 omfatter sikkerhed i forsyningskæden og kræver opmærksomhed på leverandørsårbarheder, produktkvalitet og robusthed, leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling. DORA kræver, at IKT-tredjepartsrisiko styres inden for IKT-risikostyringsrammen, herunder registre over IKT-tjenestekontrakter, due diligence, koncentrationsrisiko, exitstrategier, revisions- og adgangsrettigheder, bistand ved hændelser, serviceniveauer og beredskabskrav.

Enterpriseudgaven af Politik for forretningskontinuitet og genopretning efter alvorlige hændelser kræver:

Tredjeparts- og forsyningskædeafhængigheder 6.5.1. Kontrakter med kritiske leverandører skal indeholde kontinuitetsforpligtelser og forpligtelser til genopretningstid. 6.5.2. Væsentlige tjenesteudbydere skal efter anmodning dokumentere periodisk kontinuitetstest og deltagelse i hændelsesøvelser.

SME-versionen kræver også:

kontaktpunkter for leverandørkontinuitet

Det lille felt kan være afgørende i en reel hændelse. Hvis jeres genopretningsplan siger “kontakt cloududbyderens support”, men ingen kender eskalationsvejen, kontraktreferencen, alvorlighedsprocessen eller kontakt uden for åbningstid, er RTO’en fiktion.

Tabellen erstatter ikke styring af leverandørrisiko. Den gør leverandørrisiko operationel.

Hvordan revisorer vil teste jeres BIA

En ISO/IEC 27001:2022-revisor vil normalt starte med omfang, kontekst, risikovurdering, risikobehandling, anvendelseserklæring, Annex A-kontroller, dokumenteret information, operationel planlægning, evaluering af performance og forbedring. Revisoren vil sammenligne BIA’en med risikovurderingen og SoA. Hvis A.5.30, A.5.29 eller A.8.13 er inkluderet, vil revisoren bede om bevismateriale for implementering og test.

En DORA-gennemgang vil fokusere på kritiske eller vigtige funktioner, IKT-aktiver, IKT-tredjepartsafhængigheder, robusthedstest, hændelsesklassificering, kontraktlige krav, exitstrategier og ledelsesorganets tilsyn. Den vil forvente, at BIA’en stemmer overens med IKT-risikostyringsrammen, strategien for digital operationel robusthed, IKT-planer for forretningskontinuitet, respons- og genopretningsplaner samt testprogrammet.

En NIS2-tilsynsmyndighed vil bede om foranstaltninger for forretningskontinuitet, backupstyring, genopretning efter alvorlige hændelser, krisestyring, sikkerhed i forsyningskæden, governance-godkendelse og kapacitet til rapportering af væsentlige hændelser. BIA’en bør dokumentere, at disse foranstaltninger er baseret på tjenestepåvirkning og godkendte prioriteter.

En NIST CSF 2.0-vurderingspart vil spørge, hvordan BIA’en informerer Current Profile, Target Profile, gapanalyse og handlingsplan. Vurderingsparten vil se på Govern-resultater for retlige, regulatoriske, kontraktlige, risiko-, rolle-, politik-, tilsyns- og leverandørrisikobeslutninger. Vedkommende vil også undersøge Identify-, Protect-, Detect-, Respond- og Recover-resultater.

En COBIT 2019- eller ISACA-orienteret revisor vil typisk fokusere på styring. Hvem ejer tjenesten? Hvem accepterede risikoen? Er målene tilpasset organisationens mål? Overvåges leverandører? Er gevinster, risiko og ressourcer balanceret? Følges korrigerende handlinger til lukning?

Clarysecs Politik for revision og overvågning af efterlevelse Politik for revision og overvågning af efterlevelse gør BIA’en til en del af revisionsplanlægningscyklussen:

En risikobaseret revisionsplan skal udarbejdes og godkendes årligt under hensyntagen til: 5.2.1 Resultaterne af de seneste risikovurderinger og forretningskonsekvensanalyser (BIA) 5.2.2 Tidligere revisionskonstateringer og status for korrigerende handlinger 5.2.3 Ændringer i processer, IT-infrastruktur, systemer eller leverandører 5.2.4 Eksterne forpligtelser såsom DORA Article 25 eller kundekontrakter

Det er et modenhedstrin, som mange organisationer overser. BIA’en bør ikke ligge uden for assurance. Den bør drive revisionsplanen.

Almindelige BIA-fejl fundet i reelle vurderinger

De samme svagheder går igen.

For det første oplister BIA’en applikationer, ikke tjenester. Kunder og tilsynsmyndigheder bekymrer sig om serviceafbrydelser. Applikationer er vigtige, fordi de understøtter disse tjenester.

For det andet kopieres RTO- og RPO-mål fra skabeloner. En RTO på fire timer kan lyde rimelig, indtil en gendannelsestest viser, at det tager ni timer at genopbygge identitetsintegration, gendanne konfiguration, gendanne data, validere integritet og genaktivere overvågning.

For det tredje er backups ikke koblet til forretningsmæssig påvirkning. Frekvens, opbevaring, kryptering, lagringsplacering, gendannelsesprioritet og test skal afspejle godkendte genopretningsmål.

For det fjerde behandles leverandører som spørgeskemapunkter, ikke som genopretningsafhængigheder. Leverandørers kontinuitetsforpligtelser, eskalationskontakter, genopretningsbevismateriale og deltagelse i hændelsesøvelser bør være knyttet til kritiske tjenester.

For det femte mangler ledelsesgodkendelse. Under NIS2 og DORA er ledelsesansvar eksplicit. Under ISO/IEC 27001:2022 er lederskab, roller, godkendelse fra risikoejere og performancerapportering centrale krav.

For det sjette er test for snæver. Gendannelse af én fil er nyttigt, men det dokumenterer ikke genopretning af en tjeneste. En genopretningsvej for en kritisk tjeneste kan omfatte DNS, identitet, secrets, infrastructure-as-code, API-gateways, overvågning, logning, leverandøreskalering, kundekommunikation og databeskyttelsesgennemgang.

Zenith Blueprint indfanger i fasen Controls in Action, trin 19, revisionsforventningen til backups:

Tester I jeres backups?

Svaret skal være “ja, med bevismateriale”, og dette bevismateriale skal kobles tilbage til BIA’en.

Den revisionsklare BIA-bevispakke

Et praktisk BIA-program bør producere en kortfattet bevispakke, der kan bruges til revisioner, kunders due diligence, bestyrelsesrapportering og forbedring af robusthed.

Denne pakke fortæller en sammenhængende historie. Den gør også robusthed målbar.

Næste skridt: gør jeres BIA til efterlevelsesbevismateriale

Maria har ikke brug for et større regneark. Hun har brug for en levende beviskæde.

Start med én kritisk tjeneste. Kortlæg dens IKT-aktiver, data, personer, leverandører og forsyninger. Godkend MTD, RTO og RPO. Afstem backupplanen. Kontrollér leverandørernes genopretningsforpligtelser. Gennemfør én genopretningstest. Registrér huller. Opdater risikobehandlingsplanen. Præsentér resultatet for ledelsen.

Gentag derefter processen.

Clarysec kan hjælpe med at accelerere processen ved hjælp af Politik for forretningskontinuitet og genopretning efter alvorlige hændelser, Politik for forretningskontinuitet og genopretning efter alvorlige hændelser - SME, Politik for backup og gendannelse, Politik for revision og overvågning af efterlevelse, Zenith Blueprint og Zenith Controls.

Jeres BIA bør ikke være hyldevare udarbejdet til en revision. Den bør være det operationelle bevis for, at jeres vigtigste tjenester kan overleve afbrydelser, opfylde kunders og tilsynsmyndigheders forventninger og gendannes inden for de grænser, som jeres ledelse faktisk har godkendt.

Hvis jeres organisation forbereder sig på ISO/IEC 27001:2022-overvågningsrevision, NIS2-kundedokumentation, DORA IKT-tredjepartsgennemgange eller rapportering om robusthed på bestyrelsesniveau, så begynd med at gøre BIA’en juridisk forsvarlig. Download Clarysecs kontinuitets- og revisionspolitikker, gennemgå Zenith-implementeringskøreplanen, eller anmod om en vurdering af robusthedsbevismateriale for at omsætte spredte kontroller til én revisionsklar fortælling.