Verksamhetskonsekvensanalys (BIA) för ISO 27001, NIS2 och DORA

Revisionsfrågan som blottlägger den verkliga kontinuitetsluckan

Det är måndag morgon och Maria, CISO på ett snabbväxande fintechbolag, förbereder sig inför ett möte med styrelsens riskkommitté. Ämnesraden är kort: ”Beredskap för DORA och NIS2: BIA-granskning.”

Hennes team har tagit fram det som de flesta ledningsgrupper förväntar sig att se. Det finns ett certifierat ISO/IEC 27001:2022 ISMS, åtgärdsplaner för incidenthantering, skärmbilder från säkerhetskopiering, sårbarhetsrapporter, leverantörsfrågeformulär, diagram över molnarkitektur och ett uppdaterat riskregister. Företagskunder skickar NIS2-frågeformulär. Kunder i finanssektorn för in DORA-klausuler i avtalen. Den uppföljande revisionen enligt ISO/IEC 27001:2022 är bara en månad bort.

Då ställer den externa revisorn frågan som förändrar stämningen i rummet:

”Om er plattform för kundintroduktion är otillgänglig i 18 timmar, vilka reglerade tjänster påverkas, vilka leverantörer är involverade, vilken återställningsprioritet är godkänd och var finns underlaget för att verksamheten har accepterat RTO och RPO?”

Rummet blir tyst.

Planen för säkerhetskopiering säger en sak. Planen för katastrofåterställning säger en annan. Leverantörsavtalet innehåller ett SLA för tillgänglighet, men inget underlag från återställningstester. Riskregistret nämner tillgänglighet, men förklarar inte varför en tjänst måste återställas snabbare än en annan. Ledningen har godkänt säkerhetspolicyn, men inte den verksamhetsmässiga påverkan av avbrottstid.

Det är BIA-problemet 2026.

En verksamhetskonsekvensanalys, eller Business Impact Analysis (BIA), är inte längre ett kalkylblad som bifogas en kontinuitetsplan. Den är bevisbryggan mellan verksamhetstjänster, IKT-tillgångar, leverantörer, återställningsprioriteringar, RTO/RPO, incidenttrösklar, resiliensövningar och styrelsens ansvar. För organisationer som anpassar ISO/IEC 27001:2022 till NIS2-kontinuitet och DORA:s krav på IKT-resiliens är BIA den punkt där efterlevnad blir operativ.

De starkaste organisationerna har redan många av rätt kontroller på plats. Deras svaghet är spårbarhet. BIA gör utspritt underlag till en revisionsklar berättelse: vad som är viktigt, varför det är viktigt, hur snabbt det måste återställas, vilka beroenden som stödjer det, vad som har testats, vad som fallerade, vad som förbättrades och vem som godkände kvarstående risk.

Varför gamla BIA-kalkylblad nu är en belastning

NIS2 och DORA har förändrat tonen i efterlevnaden för verksamhetskontinuitet. De behandlar inte verksamhetskontinuitet, katastrofåterställning, incidenthantering, leverantörsresiliens och styrning som separata dokument. De förväntar sig att de fungerar som ett sammanhängande system.

För NIS2-entiteter kräver Article 21 tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem och för att förebygga eller minimera incidentpåverkan på tjänstemottagare och andra tjänster. Minimiåtgärderna omfattar riskanalys, incidenthantering, verksamhetskontinuitet inklusive hantering av säkerhetskopiering, katastrofåterställning och krishantering, säkerhet i leveranskedjan, hantering av sårbarheter, bedömning av kontrolleffektivitet, utbildning, kryptografi, personalsäkerhet, åtkomstkontroll, policy för tillgångshantering, MFA och säker kommunikation.

NIS2 Article 20 flyttar frågan in i styrelserummet. Ledningsorgan ska godkänna åtgärder för cybersäkerhetsriskhantering, utöva tillsyn över genomförandet och kan hållas ansvariga för överträdelser. Det innebär att ett ogrundat RTO på fyra timmar inte bara är en teknisk inkonsekvens. Det är en styrningsbrist.

DORA gäller från den 17 januari 2025 och skapar ett enhetligt EU-ramverk för IKT-riskhantering, incidentrapportering, testning av digital operativ resiliens, IKT-tredjepartsriskhantering, avtalskrav och tillsyn över kritiska IKT-tredjepartsleverantörer. För finansiella entiteter, och för teknikleverantörer som stödjer dem genom avtal, gör DORA operativ resiliens till ett strukturerat krav på underlag.

DORA Articles 5 och 6 kräver styrning och ett dokumenterat ramverk för IKT-riskhantering. Articles 7–14 omfattar tillförlitliga och resilienta IKT-system, identifiering av tillgångar och beroenden, skydd, detektering, IKT-verksamhetskontinuitet, säkerhetskopiering, återställning, återhämtning, lärdomar efter incident, medvetenhet, utbildning och kriskommunikation. Articles 24–26 kräver testning av digital operativ resiliens för finansiella entiteter som inte är mikroföretag. Articles 28–30 formaliserar IKT-tredjepartsrisk, register över IKT-tjänsteavtal, exitstrategier, servicenivåer, revisionsrätt och beredskapskrav.

ISO/IEC 27001:2022 utgör ryggraden i ledningssystemet. Dess klausuler kräver att organisationen definierar kontext, intressenter, rättsliga skyldigheter och avtalsförpliktelser, omfattning, ledarskap, policy, roller, riskbedömning, riskbehandling, Statement of Applicability, operativ planering, utvärdering av prestation och ständig förbättring.

Den saknade länken är ofta BIA. Utan den är kontinuitetsplaner inte tydligt riskbaserade, mål för säkerhetskopiering är inte godkända av verksamheten, leverantörer är inte kartlagda mot kritiska tjänster och ledningen kan inte tillförlitligt visa att beslut om resiliens bygger på verksamhetspåverkan.

BIA som kontrollplan för resiliensunderlag

En revisionsbar BIA besvarar sju frågor som revisorer, tillsynsmyndigheter, kunder och styrelser i allt högre grad ställer:

1. Vilka verksamhetstjänster är kritiska?
2. Vilka IKT-tillgångar, datalager, personer, leverantörer och försörjningsfunktioner stödjer varje tjänst?
3. Vilken operativ, finansiell, rättslig, avtalsmässig, kundrelaterad, säkerhetsmässig och anseenderelaterad påverkan får en störning över tid?
4. Vad är maximal tolererbar avbrottstid, eller MTD?
5. Vilka är de godkända Recovery Time Objective, eller RTO, och Recovery Point Objective, eller RPO?
6. Gör upplägg för säkerhetskopiering, redundans, moln, leverantörer, bemanning och kommunikation att dessa mål kan uppnås?
7. Har organisationen testat återställningsvägen och granskat resultaten?

Clarysecs företagsanpassade Policy för verksamhetskontinuitet och katastrofåterställning P32 Policy för verksamhetskontinuitet och katastrofåterställning anger kravet tydligt:

Business Impact Analysis (BIA) ska genomföras minst årligen för alla kritiska verksamhetsenheter och granskas vid väsentliga förändringar i system, processer eller beroenden. BIA-resultat ska definiera: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Kritiska beroenden (system, leverantörer, personal)

Den klausulen ger revisorer en praktisk startpunkt. Den motverkar också det vanliga felet där planen för verksamhetskontinuitet, planen för katastrofåterställning, schemat för säkerhetskopiering, leverantörsregistret och processen för incidenthantering använder olika definitioner av ”kritisk”.

Samma policy kräver ett integrerat ledningssätt:

Organisationen ska upprätthålla ett integrerat ledningssystem för verksamhetskontinuitet (BCMS) som är anpassat till ISO 22301 och ISO/IEC 27001 och säkerställer integration av: 5.1.1. Business Impact Analysis (BIA) 5.1.2. Säkerhetsriskbedömning för kontinuitetshot 5.1.3. Planer för verksamhetskontinuitet (BCP) 5.1.4. IKT-planer för katastrofåterställning (DRP) 5.1.5. Program för testning och övning 5.1.6. Dokumentation och ständig förbättring

Detta är skillnaden mellan checklistebaserad efterlevnad och revisionsklar resiliens. BIA är inte ett engångsdokument. Den blir en del av beviskedjan i ISMS och BCMS.

Hur ISO/IEC 27001:2022 gör BIA till verifierbart revisionsunderlag

ISO/IEC 27001:2022 kräver inte att varje organisation använder frasen ”Business Impact Analysis” i varje klausul, men dess krav gör BIA-underlag mycket värdefullt.

Clauses 4.1–4.4 kräver att organisationen förstår interna och externa frågor, intressenter, rättsliga och regulatoriska krav, avtalskrav, gränssnitt, beroenden och ISMS-omfattning. En BIA är ofta det mest praktiska underlaget för dessa gränssnitt och beroenden. Den visar vilken molntjänst, betalningsförmedlare, identitetsleverantör, telekomleverantör, hanterad säkerhetstjänst, datacenterleverantör eller outsourcat supportteam som möjliggör en kritisk tjänst.

Clauses 5.1–5.3 kräver ledarskap från högsta ledningen, resurssättning, kommunikation, tilldelning av roller och rapportering. En BIA ger ledningen en verksamhetsmässig grund för investeringar i kontinuitet. Utan den är RTO- och RPO-mål tekniska önskemål, inte godkända verksamhetskrav.

Clauses 6.1.1–6.1.3 kräver upprepningsbar riskbedömning och riskbehandling för informationssäkerhet. Organisationen ska identifiera risker för konfidentialitet, riktighet och tillgänglighet, analysera konsekvenser och sannolikhet, fastställa risknivåer, prioritera behandling, välja kontroller, jämföra valda kontroller med Annex A, ta fram en Statement of Applicability, skapa en riskbehandlingsplan och inhämta riskägarens godkännande. En BIA stärker konsekvensdelen av riskbedömningen. Den förklarar varför ett tvåtimmarsavbrott i ett system är tolererbart medan ett tvåtimmarsavbrott i ett annat orsakar kundskada, regulatorisk exponering, avtalsöverträdelse eller betydande intäktsbortfall.

Annex A tillhandahåller kontrollkatalogen. För BIA och kontinuitet omfattar de mest relevanta ISO/IEC 27001:2022 Annex A-kontrollerna:

I Zenith Controls: The Cross-Compliance Guide Zenith Controls profilerar Clarysec ISO/IEC 27002:2022-kontroll 5.30, IKT-beredskap för verksamhetskontinuitet, som en korrigerande kontroll med fokus på tillgänglighet, mappad till cybersäkerhetskonceptet Respond, den operativa kontinuitetsförmågan och säkerhetsdomänen resiliens. Kontroll 5.29, informationssäkerhet vid störning, profileras som förebyggande och korrigerande och skyddar konfidentialitet, riktighet och tillgänglighet. Kontroll 8.13, säkerhetskopiering av information, profileras som korrigerande och stödjer riktighet och tillgänglighet genom återställning.

Den distinktionen är viktig. En BIA får inte bara fråga: ”Kan vi återställa?” Den måste också fråga: ”Kan vi fortsätta vara säkra under en störning?” Vid en ransomware-händelse, molnavbrott, leverantörsfel eller datacenterincident behöver organisationen fortfarande åtkomstkontroll, loggning, övervakning, bevarande av bevismaterial, säker kommunikation och dataskyddskontroller.

Den praktiska modellen för BIA-underlag

En stark BIA kopplar verksamhetsspråk till tekniskt underlag. Clarysec strukturerar normalt underlagsmodellen i fem lager.

Denna underlagsmodell fungerar eftersom den följer hur revisorer tänker. Först frågar de vad som är kritiskt. Därefter frågar de vad som stödjer det. Sedan frågar de vem som har godkänt återställningsmålet. Därefter frågar de om tekniska arrangemang och leverantörsupplägg kan uppfylla målet. Slutligen frågar de om organisationen har testat och förbättrat förmågan.

NIST CSF 2.0 är användbart som kommunikationslager. Metoden CSF Profiles uppmuntrar organisationer att definiera omfattning, samla in underlag såsom policyer, organisationens riskprioriteringar, BIA-register, cybersäkerhetskrav, standarder, förfaranden, skyddsåtgärder och arbetsroller, skapa nuläges- och målprofiler, analysera luckor, ta fram en prioriterad åtgärdsplan, genomföra planen och uppdatera profilen. Det är nästan exakt så en BIA bör mata in i en färdplan för tvärgående efterlevnad.

En BIA-övning på en vecka som skapar verkligt underlag

Anta att en SaaS-leverantör stödjer kunder inom finansiella tjänster. Plattformen stödjer kundintroduktion, dokumentverifiering och kundaviseringar. Leverantören är inte själv en bank, men kunderna skickar DORA-drivna avtalsförfrågningar och NIS2-frågeformulär för leverantörer.

En fokuserad övning på en vecka kan snabbt skapa användbart underlag.

Dag 1: Identifiera kritiska tjänster och konsekvensfönster

Börja med tjänster, inte servrar. Involvera verksamhetsägare, IT, säkerhet, juridik, support, dataskydd och leverantörshantering.

Denna inramning är viktig. Tillsynsmyndigheter och kunder känner igen tjänster och funktioner. Applikationer är viktiga eftersom de stödjer dessa tjänster.

Dag 2: Kartlägg beroenden

Kartlägg för varje tjänst applikationer, databaser, infrastruktur, molntjänster, identitetsleverantörer, övervakning, verktyg för säkerhetskopiering, personer, leverantörer och stödjande försörjningsfunktioner.

Här börjar BIA skapa värde. Den synliggör den dolda återställningsvägen, inklusive beroenden som ofta missas i en teknisk DR-plan.

Dag 3: Godkänn MTD, RTO och RPO

Verksamhetsägaren föreslår MTD. IT och säkerhet validerar om föreslagna RTO och RPO är tekniskt uppnåeliga. Ledningen godkänner de slutliga målen.

För mindre organisationer ger Clarysecs Policy för verksamhetskontinuitet och katastrofåterställning – SME P32S Policy för verksamhetskontinuitet och katastrofåterställning – SME samma disciplin med enklare språk. Den kräver BCP/DR-planer som anger hur väsentliga funktioner ska återställas:

General Manager (GM) ska godkänna och upprätthålla planer för verksamhetskontinuitet och katastrofåterställning (BCP/DRP) som tydligt anger organisationens tillvägagångssätt för att återställa väsentliga funktioner.

Den kräver också att planen innehåller:

prioriterade tjänster och system (kritiska verksamhetsfunktioner)

Och:

Recovery Time Objectives (RTOs) och Recovery Point Objectives (RPOs) för varje system

Nyckeln är inte överdriven dokumentation. Nyckeln är spårbarhet, godkännande och underlag som visar att återställningsmålen bygger på verklig verksamhetspåverkan.

Dag 4: Stäm av säkerhetskopiering mot verksamhetspåverkan

Många organisationer brister här. BIA kan ange ett RPO på fyra timmar, medan säkerhetskopior tas var 24:e timme. Eller så skyddar verktyget för säkerhetskopiering produktionsdatabaser, men inte konfiguration, hemligheter, lagringsplatser för infrastructure-as-code, objektlagring, DNS-poster, identitetsinställningar eller API-gateway-konfiguration.

Clarysecs Policy för säkerhetskopiering och återställning P15 Policy för säkerhetskopiering och återställning kräver ett huvudschema för säkerhetskopiering kopplat till BIA-resultat:

Ett huvudschema för säkerhetskopiering ska upprätthållas och granskas årligen. Det ska ange: 5.1.1 Frekvens för säkerhetskopiering (till exempel dagliga inkrementella säkerhetskopieringar och veckovisa fullständiga säkerhetskopieringar) 5.1.2 Bevarandetider per system eller datatyp 5.1.3 Krypteringskrav och uppgifter om lagringsplats 5.1.4 RTO/RPO-mål kopplade till resultat från bedömning av verksamhetspåverkan

Denna klausul är revisionsmässigt mycket värdefull. Den tvingar utformningen av säkerhetskopiering att spegla verksamhetspåverkan, inte lagringsbekvämlighet.

Dag 5: Testa en återställningsväg och öppna korrigerande åtgärder

Testa inte allt på en gång. Välj en kritisk tjänst och genomför ett fokuserat återställningstest. Återställ databasen. Återskapa applikationskonfigurationen. Validera autentisering. Bekräfta att loggar är tillgängliga. Kontrollera möjligheten till kundavisering. Registrera tidsåtgång, dataförlust, brister, beslut och korrigerande åtgärder.

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandlar fasen Controls in Action, Step 23, organisatoriska kontroller inklusive IKT-beredskap för verksamhetskontinuitet. Den ställer frågan som varje revisionsteam bör ställa:

Kan era system stödja era mål för verksamhetskontinuitet när ljuset blinkar, nätverk går ner och katastrofen inträffar?

Samma steg ger en praktisk instruktion:

Verifiera att recovery time objectives (RTO) och recovery point objectives (RPO) för kritiska system är anpassade till förväntningarna på verksamhetskontinuitet (5.30). Genomför minst ett tekniskt återställningstest eller en failover-simulering och dokumentera resultaten.

Det är skillnaden mellan att ha en BIA och att ha revisionsbart BIA-underlag. Målet är inte bara dokumenterat. Det är testat.

Mappning av BIA-underlag till NIS2, DORA, GDPR, NIST och COBIT 2019

En väl utformad BIA blir en tillgång för tvärgående efterlevnad. En uppsättning underlag kan besvara många frågor.

GDPR förbises ofta i BIA-diskussioner. Ändå kräver GDPR Article 5 att personuppgifter behandlas med riktighet och konfidentialitet, inklusive skydd mot oavsiktlig förlust, förstöring eller skada genom lämpliga tekniska eller organisatoriska åtgärder. Ansvarsskyldighet kräver att den personuppgiftsansvarige kan visa efterlevnad. Om en plattform för personuppgifter inte kan återställas inom en godkänd och testad tidsram påverkar dataskyddsrisken tillgänglighet, riktighet, incidentbedömning och kundförtroende.

NIS2-incidentrapportering tillför ytterligare en dimension. Article 23 kräver att betydande incidenter anmäls utan onödigt dröjsmål, inklusive en tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapportering inom en månad. En BIA hjälper till att klassificera allvarlighetsgrad eftersom den definierar berörda tjänster, tjänstemottagare, operativ störning och potentiell gränsöverskridande påverkan.

DORA:s incidentklassificering beaktar också berörda kunder eller transaktioner, varaktighet, geografisk spridning, dataförluster, kritikaliteten hos påverkade tjänster och ekonomisk påverkan. Detta är BIA-fält. Om BIA är svag blir incidentklassificeringen subjektiv vid sämsta tänkbara tidpunkt.

Leverantörskontinuitet är där BIA möter avtalens verklighet

För NIS2 och DORA är leverantörskontinuitet inte längre valfri. NIS2 Article 21 omfattar säkerhet i leveranskedjan och kräver uppmärksamhet på leverantörssårbarheter, produktkvalitet och resiliens, leverantörers cybersäkerhetspraxis och rutiner för säker utveckling. DORA kräver att IKT-tredjepartsrisk hanteras inom ramverket för IKT-riskhantering, inklusive register över IKT-tjänsteavtal, leverantörsgranskning, koncentrationsrisk, exitstrategier, revisionsrätt och åtkomsträttigheter, incidentstöd, servicenivåer och beredskapskrav.

Den företagsanpassade Policy för verksamhetskontinuitet och katastrofåterställning kräver:

Tredjeparts- och leveranskedjeberoenden 6.5.1. Avtal med kritiska leverantörer ska innehålla kontinuitetsförpliktelser och åtaganden om återställningstid. 6.5.2. Viktiga tjänsteleverantörer ska, på begäran, kunna visa periodisk kontinuitetstestning och deltagande i incidentövningar.

SME-versionen kräver också:

kontaktpunkter för leverantörskontinuitet

Det lilla fältet kan vara avgörande vid en verklig incident. Om återställningsplanen säger ”kontakta molnleverantörens support”, men ingen känner till eskaleringsvägen, avtalsreferensen, processen för allvarlighetsgrad eller kontaktvägen utanför kontorstid, är RTO en fiktion.

Den här tabellen ersätter inte leverantörsriskhantering. Den gör leverantörsrisker operativa.

Hur revisorer kommer att testa er BIA

En ISO/IEC 27001:2022-revisor börjar vanligtvis med omfattning, kontext, riskbedömning, riskbehandling, Statement of Applicability, Annex A-kontroller, dokumenterad information, operativ planering, utvärdering av prestation och förbättring. Revisorn jämför BIA med riskbedömningen och SoA. Om A.5.30, A.5.29 eller A.8.13 ingår kommer revisorn att begära underlag för genomförande och testning.

En DORA-granskare fokuserar på kritiska eller viktiga funktioner, IKT-tillgångar, IKT-tredjepartsberoenden, resiliensövningar, incidentklassificering, avtalskrav, exitstrategier och ledningsorganets tillsyn. Granskaren förväntar sig att BIA är anpassad till ramverket för IKT-riskhantering, strategin för digital operativ resiliens, IKT-planer för verksamhetskontinuitet, respons- och återställningsplaner samt testprogrammet.

En NIS2-tillsynsmyndighet kommer att efterfråga åtgärder för verksamhetskontinuitet, hantering av säkerhetskopiering, katastrofåterställning, krishantering, säkerhet i leveranskedjan, styrningsgodkännande och förmåga att rapportera betydande incidenter. BIA ska visa att dessa åtgärder bygger på tjänstepåverkan och godkända prioriteringar.

En NIST CSF 2.0-bedömare kommer att fråga hur BIA informerar Current Profile, Target Profile, gap-analys och åtgärdsplan. Bedömaren granskar Govern-resultat för rättsliga, regulatoriska, avtalsmässiga, riskrelaterade, rollrelaterade, policyrelaterade, tillsynsrelaterade och leverantörsriskrelaterade beslut. Bedömaren granskar också resultat inom Identify, Protect, Detect, Respond och Recover.

En COBIT 2019- eller ISACA-liknande revisor fokuserar vanligtvis på styrning. Vem äger tjänsten? Vem accepterade risken? Är målen anpassade till organisationens mål? Övervakas leverantörer? Är nyttor, risker och resurser balanserade? Följs korrigerande åtgärder till stängning?

Clarysecs Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning gör BIA till en del av revisionsplaneringscykeln:

En riskbaserad revisionsplan ska tas fram och godkännas årligen, med beaktande av: 5.2.1 Resultaten från de senaste riskbedömningarna och Business Impact Analysis (BIA) 5.2.2 Tidigare revisionsiakttagelser och status för korrigerande åtgärder 5.2.3 Förändringar i processer, IT-infrastruktur, system eller leverantörer 5.2.4 Externa krav såsom DORA Article 25 eller kundavtal

Detta är ett mognadssteg som många organisationer missar. BIA ska inte ligga utanför säkerhetsförsäkran. Den ska styra revisionsplanen.

Vanliga BIA-brister från verkliga granskningar

Samma svagheter återkommer ofta.

För det första listar BIA applikationer, inte tjänster. Kunder och tillsynsmyndigheter bryr sig om tjänstestörningar. Applikationer är viktiga eftersom de stödjer dessa tjänster.

För det andra kopieras RTO- och RPO-mål från mallar. Ett RTO på fyra timmar kan låta rimligt tills ett återställningstest visar att det tar nio timmar att återskapa identitetsintegrationen, återställa konfiguration, återställa data, validera riktighet och återaktivera övervakning.

För det tredje är säkerhetskopior inte kopplade till verksamhetspåverkan. Frekvens, bevarandetid, kryptering, lagringsplats, återställningsprioritet och testning måste spegla godkända återställningsmål.

För det fjärde behandlas leverantörer som poster i frågeformulär, inte som återställningsberoenden. Leverantörernas kontinuitetsåtaganden, eskaleringskontakter, återställningsunderlag och deltagande i incidentövningar bör kopplas till kritiska tjänster.

För det femte saknas ledningens godkännande. Enligt NIS2 och DORA är ledningens ansvar uttryckligt. Enligt ISO/IEC 27001:2022 är ledarskap, roller, riskägarens godkännande och prestationsrapportering kärnkrav.

För det sjätte är testningen för snäv. Att återställa en fil är användbart, men det bevisar inte återställning av en tjänst. Återställningsvägen för en kritisk tjänst kan omfatta DNS, identitet, hemligheter, infrastructure-as-code, API-gateways, övervakning, loggning, leverantörseskalering, kundkommunikation och dataskyddsgranskning.

Zenith Blueprint, i fasen Controls in Action, Step 19, fångar revisionsförväntan för säkerhetskopior:

Testar ni era säkerhetskopior?

Svaret måste vara ”ja, med underlag”, och det underlaget måste kopplas tillbaka till BIA.

Det revisionsklara BIA-underlagspaketet

Ett praktiskt BIA-program bör skapa ett koncist underlagspaket som kan användas för revisioner, kunders leverantörsgranskning, styrelserapportering och förbättring av resiliens.

Paketet berättar en sammanhängande historia. Det gör också resiliens mätbar.

Nästa steg: gör er BIA till efterlevnadsunderlag

Maria behöver inte ett större kalkylblad. Hon behöver en levande beviskedja.

Börja med en kritisk tjänst. Kartlägg dess IKT-tillgångar, data, personer, leverantörer och försörjningsfunktioner. Godkänn MTD, RTO och RPO. Stäm av schemat för säkerhetskopiering. Kontrollera leverantörernas återställningsåtaganden. Genomför ett återställningstest. Registrera luckor. Uppdatera riskbehandlingsplanen. Presentera resultatet för ledningen.

Upprepa därefter.

Clarysec kan hjälpa till att accelerera processen med Policy för verksamhetskontinuitet och katastrofåterställning, Policy för verksamhetskontinuitet och katastrofåterställning – SME, Policy för säkerhetskopiering och återställning, Policy för revision och regelefterlevnadsövervakning, Zenith Blueprint och Zenith Controls.

Er BIA ska inte vara en hyllvärmare framtagen för en revision. Den ska vara det operativa beviset på att era viktigaste tjänster kan överleva störningar, uppfylla kunders och tillsynsmyndigheters förväntningar och återställas inom gränser som er ledning faktiskt har godkänt.

Om er organisation förbereder sig för uppföljande revision enligt ISO/IEC 27001:2022, NIS2-relaterad kundförsäkran, DORA-granskningar av IKT-tredjepartsleverantörer eller rapportering om resiliens på styrelsenivå, börja med att göra BIA revisionsbar. Ladda ner Clarysecs kontinuitets- och revisionspolicyer, granska Zeniths införandefärdplan eller begär en bedömning av resiliensunderlag för att göra utspridda kontroller till en revisionsklar berättelse.