Bedrijfsimpactanalyse voor ISO 27001, NIS2 en DORA

De auditvraag die het echte continuïteitshiaat blootlegt

Het is maandagochtend en Maria, de CISO van een snelgroeiende FinTech, bereidt zich voor op een vergadering van de risicocommissie van het bestuur. De onderwerpregel is kort: “DORA- en NIS2-gereedheid: BIA-beoordeling.”

Haar team heeft opgebouwd wat de meeste bestuurders verwachten te zien. Er is een gecertificeerd ISO/IEC 27001:2022 ISMS, er zijn incidentresponsdraaiboeken, screenshots van back-ups, kwetsbaarheidsrapporten, leveranciersvragenlijsten, diagrammen van de cloudarchitectuur en een bijgewerkt risicoregister. Enterprise-klanten sturen NIS2-vragenlijsten. Klanten uit de financiële sector nemen DORA-clausules op in contracten. De ISO/IEC 27001:2022 surveillance-audit is nog maar een maand weg.

Dan stelt de externe auditor de vraag die de dynamiek in de ruimte verandert:

“Als uw onboardingplatform voor klanten 18 uur niet beschikbaar is, welke gereguleerde diensten worden dan geraakt, welke leveranciers zijn betrokken, wat is de goedgekeurde herstelprioriteit en waar is het bewijs dat de business de RTO en RPO heeft geaccepteerd?”

Het wordt stil in de ruimte.

Het back-upschema zegt het ene. Het disasterrecoveryplan zegt iets anders. Het leverancierscontract bevat een beschikbaarheids-SLA, maar geen bewijs van hersteltesten. Het risicoregister noemt beschikbaarheid, maar verklaart niet waarom de ene dienst sneller moet herstellen dan de andere. Het management heeft het beveiligingsbeleid goedgekeurd, maar niet de bedrijfsimpact van uitval.

Dat is het probleem van de bedrijfsimpactanalyse in 2026.

Een bedrijfsimpactanalyse, of BIA, is niet langer een spreadsheet als bijlage bij een continuïteitsplan. Het is de bewijsbrug tussen bedrijfsdiensten, ICT-activa, leveranciers, herstelprioriteiten, RTO/RPO, incidentdrempels, weerbaarheidstesten en verantwoordingsplicht van het bestuur. Voor organisaties die ISO/IEC 27001:2022 afstemmen op NIS2-continuïteit en DORA ICT-weerbaarheid, is de BIA het punt waarop naleving operationeel wordt.

De sterkste organisaties hebben al veel van de juiste beheersmaatregelen. Hun zwakte is traceerbaarheid. De BIA zet versnipperd bewijs om in een auditgereed verhaal: wat belangrijk is, waarom het belangrijk is, hoe snel het moet herstellen, welke afhankelijkheden het ondersteunen, wat is getest, wat is mislukt, wat is verbeterd en wie het restrisico heeft goedgekeurd.

Waarom oude BIA-spreadsheets nu een aansprakelijkheidsrisico zijn

NIS2 en DORA hebben de toon van continuïteitscompliance veranderd. Zij behandelen bedrijfscontinuïteit, disaster recovery, incidentrespons, leveranciersweerbaarheid en governance niet als afzonderlijke documenten. Zij verwachten dat deze als één systeem werken.

Voor NIS2-entiteiten vereist Article 21 technische, operationele en organisatorische maatregelen om risico’s voor netwerk- en informatiesystemen te beheren en de impact van incidenten op afnemers van diensten en andere diensten te voorkomen of te beperken. De minimumeisen omvatten risicoanalyse, incidentafhandeling, bedrijfscontinuïteit inclusief back-upbeheer, disaster recovery en crisismanagement, beveiliging van de toeleveringsketen, kwetsbaarhedenafhandeling, beoordeling van de doeltreffendheid van beheersmaatregelen, training, cryptografie, HR-beveiliging, toegangscontrole, assetmanagement, MFA en beveiligde communicatie.

NIS2 Article 20 brengt het onderwerp naar de bestuurskamer. Bestuursorganen moeten cybersecurityrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en kunnen aansprakelijk worden gehouden voor inbreuken. Dat betekent dat een niet-onderbouwde RTO van vier uur niet slechts een technische inconsistentie is. Het is een governancezwakte.

DORA is van toepassing vanaf 17 januari 2025 en creëert een uniform EU-kader voor ICT-risicobeheer, incidentrapportage, testen van digitale operationele weerbaarheid, ICT-risicobeheer voor derde partijen, contractuele eisen en toezicht op kritieke ICT-dienstverleners van derde partijen. Voor financiële entiteiten, en voor technologieaanbieders die hen contractueel ondersteunen, maakt DORA van operationele weerbaarheid een gestructureerde bewijsvereiste.

DORA Articles 5 en 6 vereisen governance en een gedocumenteerd ICT-risicobeheerkader. Articles 7 tot en met 14 behandelen betrouwbare en weerbare ICT-systemen, identificatie van bedrijfsmiddelen en afhankelijkheden, bescherming, detectie, ICT-bedrijfscontinuïteit, back-up, herstel, leren na incidenten, bewustwording, training en crisiscommunicatie. Articles 24 tot en met 26 vereisen testen van digitale operationele weerbaarheid voor financiële entiteiten die geen micro-onderneming zijn. Articles 28 tot en met 30 formaliseren ICT-risico’s van derde partijen, registers van ICT-dienstverleningscontracten, exitstrategieën, serviceniveaus, auditrechten en noodvoorzieningen.

ISO/IEC 27001:2022 biedt de ruggengraat van het managementsysteem. De clausules vereisen dat de organisatie context, belanghebbenden, wettelijke en contractuele verplichtingen, toepassingsgebied, leiderschap, beleid, rollen, risicobeoordeling, risicobehandeling, de Verklaring van Toepasselijkheid, operationele planning, prestatie-evaluatie en continue verbetering definieert.

De ontbrekende schakel is vaak de BIA. Zonder BIA zijn continuïteitsplannen niet aantoonbaar risicogebaseerd, zijn back-updoelstellingen niet door de business goedgekeurd, zijn leveranciers niet gekoppeld aan kritieke diensten en kan het management niet betrouwbaar aantonen dat weerbaarheidsbesluiten zijn gebaseerd op bedrijfsimpact.

De BIA als regielaag voor weerbaarheidsbewijs

Een verdedigbare BIA beantwoordt zeven vragen die auditors, toezichthouders, klanten en besturen steeds vaker stellen:

1. Welke bedrijfsdiensten zijn kritisch?
2. Welke ICT-activa, gegevensopslagplaatsen, medewerkers, leveranciers en nutsvoorzieningen ondersteunen elke dienst?
3. Wat is de operationele, financiële, juridische, contractuele, klantgerelateerde, veiligheidsgerelateerde en reputatie-impact van verstoring in de tijd?
4. Wat is de maximaal toelaatbare uitvaltijd, of MTD?
5. Wat zijn de goedgekeurde hersteltijddoelstelling, of RTO, en herstelpuntdoelstelling, of RPO?
6. Maken back-up-, redundantie-, cloud-, leveranciers-, personeels- en communicatievoorzieningen die doelstellingen haalbaar?
7. Heeft de organisatie het herstelpad getest en de resultaten beoordeeld?

Clarysec’s enterprise Beleid voor bedrijfscontinuïteit en disaster recovery P32 Beleid voor bedrijfscontinuïteit en disaster recovery formuleert de eis duidelijk:

Voor alle kritieke bedrijfseenheden moet ten minste jaarlijks een bedrijfsimpactanalyse (BIA) worden uitgevoerd en worden beoordeeld bij significante wijzigingen in systemen, processen of afhankelijkheden. BIA-resultaten moeten het volgende definiëren: 5.2.1. Maximale toelaatbare uitvaltijd (MTD) 5.2.2. Hersteltijddoelstellingen (RTO’s) 5.2.3. Herstelpuntdoelstellingen (RPO’s) 5.2.4. Kritieke afhankelijkheden (systemen, leveranciers, personeel)

Die clausule geeft auditors een praktisch startpunt. Zij voorkomt ook de veelvoorkomende fout waarbij het bedrijfscontinuïteitsplan, het disasterrecoveryplan, het back-upschema, het leveranciersregister en het incidentresponsproces elk een andere definitie van “kritiek” gebruiken.

Hetzelfde beleid vereist een geïntegreerde managementaanpak:

De organisatie moet een geïntegreerd managementsysteem voor bedrijfscontinuïteit (BCMS) onderhouden dat is afgestemd op ISO 22301 en ISO/IEC 27001, waarbij integratie wordt geborgd van: 5.1.1. Bedrijfsimpactanalyse (BIA) 5.1.2. Beveiligingsrisicobeoordeling voor continuïteitsdreigingen 5.1.3. Bedrijfscontinuïteitsplannen (BCP’s) 5.1.4. ICT-disasterrecoveryplannen (DRP’s) 5.1.5. Test- en oefenprogramma’s 5.1.6. Documentatie en continue verbetering

Dit is het onderscheid tussen checklistcompliance en auditgereede weerbaarheid. De BIA is geen eenmalig document. Zij wordt onderdeel van de bewijsketen van het ISMS en BCMS.

Hoe ISO/IEC 27001:2022 BIA omzet in auditeerbaar bewijs

ISO/IEC 27001:2022 vereist niet dat elke organisatie in elke clausule de term “bedrijfsimpactanalyse” gebruikt, maar de eisen maken BIA-bewijs zeer waardevol.

Clauses 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe onderwerpen, belanghebbenden, wettelijke en regelgevende verplichtingen, contractuele eisen, interfaces, afhankelijkheden en het ISMS-toepassingsgebied begrijpt. Een BIA is vaak het meest praktische bewijs voor die interfaces en afhankelijkheden. Zij laat zien welke clouddienst, betalingsverwerker, identiteitsprovider, telecomprovider, managed security service, datacenter of uitbesteed supportteam een kritieke dienst mogelijk maakt.

Clauses 5.1 tot en met 5.3 vereisen leiderschap van het topmanagement, middelen, communicatie, toewijzing van rollen en rapportage. Een BIA geeft het leiderschap een zakelijke basis voor investeringen in continuïteit. Zonder BIA zijn RTO- en RPO-doelstellingen technische wensen, geen goedgekeurde bedrijfseisen.

Clauses 6.1.1 tot en met 6.1.3 vereisen herhaalbare risicobeoordeling en risicobehandeling voor informatiebeveiliging. De organisatie moet risico’s voor vertrouwelijkheid, integriteit en beschikbaarheid identificeren, gevolgen en waarschijnlijkheid analyseren, risiconiveaus bepalen, behandeling prioriteren, beheersmaatregelen selecteren, geselecteerde beheersmaatregelen vergelijken met Annex A, een Verklaring van Toepasselijkheid opstellen, een risicobehandelingsplan maken en goedkeuring van de risico-eigenaar verkrijgen. Een BIA versterkt de “gevolgen”-kant van de risicobeoordeling. Zij verklaart waarom een uitval van twee uur van het ene systeem aanvaardbaar is, terwijl een uitval van twee uur van een ander systeem leidt tot klantschade, blootstelling aan regelgeving, contractbreuk of ernstige omzetimpact.

Annex A biedt de catalogus van beheersmaatregelen. Voor BIA en continuïteit omvatten de meest relevante ISO/IEC 27001:2022 Annex A-beheersmaatregelen:

In Zenith Controls: de cross-compliancegids Zenith Controls profileert Clarysec ISO/IEC 27002:2022-beheersmaatregel 5.30, ICT-gereedheid voor bedrijfscontinuïteit, als een corrigerende beheersmaatregel gericht op beschikbaarheid, gekoppeld aan het cybersecurityconcept Respond, de operationele continuïteitscapaciteit en het beveiligingsdomein weerbaarheid. Beheersmaatregel 5.29, informatiebeveiliging tijdens verstoring, wordt geprofileerd als preventief en corrigerend en beschermt vertrouwelijkheid, integriteit en beschikbaarheid. Beheersmaatregel 8.13, informatieback-up, wordt geprofileerd als corrigerend en ondersteunt integriteit en beschikbaarheid door herstel.

Dat onderscheid is belangrijk. Een BIA moet niet alleen vragen: “Kunnen we herstellen?” Zij moet ook vragen: “Kunnen we veilig blijven terwijl we verstoord zijn?” Tijdens een ransomware-incident, cloudstoring, leveranciersuitval of datacenterincident heeft de organisatie nog steeds toegangscontrole, logging, monitoring, bewaring van bewijs, beveiligde communicatie en privacywaarborgen nodig.

Het praktische BIA-bewijsmodel

Een sterke BIA verbindt bedrijfstaal met technisch bewijs. Clarysec structureert het bewijsmodel doorgaans in vijf lagen.

Dit bewijsmodel werkt omdat het aansluit op de denkwijze van auditors. Eerst vragen zij wat kritiek is. Daarna vragen zij wat dit ondersteunt. Vervolgens vragen zij wie de hersteldoelstelling heeft goedgekeurd. Daarna vragen zij of technische en leveranciersvoorzieningen die doelstelling kunnen halen. Tot slot vragen zij of de organisatie de capaciteit heeft getest en verbeterd.

NIST CSF 2.0 is nuttig als communicatielaag. De CSF Profiles-methode stimuleert organisaties om het toepassingsgebied te definiëren, input te verzamelen zoals beleid, prioriteiten voor ondernemingsrisico’s, BIA-registers, cybersecurity-eisen, normen, procedures, waarborgen en werkrollen, huidige en doelprofielen te creëren, hiaten te analyseren, een geprioriteerd actieplan op te stellen, dat plan te implementeren en het profiel bij te werken. Dat is vrijwel precies hoe een BIA een cross-compliance-roadmap moet voeden.

Een BIA-oefening van één week die echt bewijs oplevert

Stel dat een SaaS-aanbieder klanten in de financiële dienstverlening ondersteunt. Het platform ondersteunt clientonboarding, documentverificatie en klantmeldingen. De aanbieder is zelf geen bank, maar klanten sturen contractuele verzoeken die door DORA worden gedreven en NIS2-leveranciersvragenlijsten.

Een gerichte oefening van één week kan snel bruikbaar bewijs opleveren.

Dag 1: Identificeer kritieke diensten en impactvensters

Begin met diensten, niet met servers. Betrek proceseigenaren, IT, security, juridische zaken, support, privacy en leveranciersmanagement.

Deze framing is belangrijk. Toezichthouders en klanten herkennen diensten en functies. Applicaties zijn relevant omdat zij die diensten ondersteunen.

Dag 2: Breng afhankelijkheden in kaart

Breng per dienst applicaties, databanken, infrastructuur, clouddiensten, identiteitsproviders, monitoring, back-uptools, medewerkers, leveranciers en ondersteunende nutsvoorzieningen in kaart.

Hier begint de BIA waarde te leveren. Zij legt het onzichtbare herstelpad bloot, inclusief afhankelijkheden die vaak in een technisch DR-plan worden gemist.

Dag 3: Keur MTD, RTO en RPO goed

De proceseigenaar stelt de MTD voor. IT en security valideren of de voorgestelde RTO en RPO technisch haalbaar zijn. Het management keurt de definitieve doelstellingen goed.

Voor kleinere organisaties biedt Clarysec’s Beleid voor bedrijfscontinuïteit en disaster recovery - mkb P32S Beleid voor bedrijfscontinuïteit en disaster recovery - mkb dezelfde discipline in eenvoudiger taal. Het vereist BCP/DR-plannen die de aanpak voor het herstellen van essentiële functies vastleggen:

De algemeen directeur (GM) moet bedrijfscontinuïteits- en herstelplannen (BCP/DRP) goedkeuren en onderhouden die de aanpak van de organisatie voor het herstellen van essentiële functies duidelijk vastleggen.

Het plan moet ook bevatten:

geprioriteerde diensten en systemen (kritieke bedrijfsfuncties)

En:

Recovery Time Objectives (RTO’s) en Recovery Point Objectives (RPO’s) voor elk systeem

De kern is niet overmatige documentatie. De kern is traceerbaarheid, goedkeuring en bewijs dat hersteldoelstellingen op echte bedrijfsimpact zijn gebaseerd.

Dag 4: Stem back-up af op bedrijfsimpact

Veel organisaties falen hier. De BIA kan een RPO van vier uur vaststellen, terwijl back-ups elke 24 uur worden uitgevoerd. Of de back-uptool beschermt productiedatabanken, maar niet configuratie, secrets, infrastructure-as-code-repositories, objectopslag, DNS-records, identiteitsinstellingen of API-gatewayconfiguratie.

Clarysec’s Beleid voor back-up en herstel P15 Beleid voor back-up en herstel vereist een centraal back-upschema dat is gekoppeld aan BIA-uitkomsten:

Een centraal back-upschema moet worden onderhouden en jaarlijks worden beoordeeld. Het moet specificeren: 5.1.1 Back-upfrequentie (bijvoorbeeld dagelijkse incrementele back-ups en wekelijkse volledige back-ups) 5.1.2 Bewaartermijnen per systeem of gegevenstype 5.1.3 Encryptievereisten en gegevens over de opslaglocatie 5.1.4 RTO/RPO-doelstellingen gekoppeld aan de uitkomsten van de beoordeling van bedrijfsimpact

Deze clausule is goud waard voor audits. Zij dwingt af dat het back-upontwerp bedrijfsimpact weerspiegelt, niet opslaggemak.

Dag 5: Test één herstelpad en open corrigerende maatregelen

Test niet alles tegelijk. Kies één kritieke dienst en voer een gerichte hersteltest uit. Herstel de databank. Bouw de applicatieconfiguratie opnieuw op. Valideer authenticatie. Bevestig dat logboeken beschikbaar zijn. Controleer de mogelijkheid om klanten te informeren. Registreer de benodigde tijd, gegevensverlies, defecten, besluiten en corrigerende maatregelen.

In Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint behandelt de fase Beheersmaatregelen in actie, stap 23, organisatorische beheersmaatregelen inclusief ICT-gereedheid voor bedrijfscontinuïteit. Deze stelt de vraag die elk auditteam moet stellen:

Kunnen uw systemen uw doelstellingen voor bedrijfscontinuïteit ondersteunen wanneer het licht flikkert, netwerken uitvallen of een ramp toeslaat?

Dezelfde stap geeft een praktische instructie:

Verifieer dat hersteltijddoelstellingen (RTO) en herstelpuntdoelstellingen (RPO) voor kritieke systemen aansluiten op de verwachtingen voor bedrijfscontinuïteit (5.30). Voer ten minste één technische hersteltest of failoversimulatie uit en documenteer de resultaten.

Dat is het verschil tussen een BIA hebben en verdedigbaar BIA-bewijs hebben. De doelstelling is niet alleen gedocumenteerd. Zij is getest.

BIA-bewijs koppelen aan NIS2, DORA, GDPR, NIST en COBIT 2019

Een goed opgebouwde BIA wordt een cross-compliance-asset. Eén set bewijs kan veel vragen beantwoorden.

GDPR wordt in BIA-discussies vaak over het hoofd gezien. Toch vereist GDPR Article 5 dat persoonsgegevens worden verwerkt met integriteit en vertrouwelijkheid, inclusief bescherming tegen onopzettelijk verlies, vernietiging of beschadiging door passende technische of organisatorische maatregelen. Verantwoordingsplicht vereist dat de verwerkingsverantwoordelijke naleving kan aantonen. Als een platform met persoonsgegevens niet binnen een goedgekeurd en getest tijdvenster kan worden hersteld, raakt het privacyrisico beschikbaarheid, integriteit, beoordeling van inbreuken en klantvertrouwen.

NIS2-incidentmelding voegt een extra dimensie toe. Article 23 vereist dat significante incidenten zonder onnodige vertraging worden gemeld, inclusief een vroegtijdige waarschuwing binnen 24 uur, incidentmelding binnen 72 uur en eindrapportage binnen één maand. Een BIA helpt de ernst te classificeren omdat zij getroffen diensten, afnemers van diensten, operationele verstoring en mogelijke grensoverschrijdende impact definieert.

DORA-incidentclassificatie kijkt ook naar getroffen klanten of transacties, duur, geografische spreiding, gegevensverliezen, criticaliteit van getroffen diensten en economische impact. Dit zijn BIA-velden. Als de BIA zwak is, wordt incidentclassificatie subjectief op het slechtst mogelijke moment.

Leverancierscontinuïteit is waar de BIA de contractuele realiteit raakt

Voor NIS2 en DORA is leverancierscontinuïteit niet langer optioneel. NIS2 Article 21 omvat beveiliging van de toeleveringsketen en vereist aandacht voor leverancierskwetsbaarheden, productkwaliteit en weerbaarheid, cybersecuritypraktijken van leveranciers en veilige ontwikkelprocedures. DORA vereist dat ICT-risico van derde partijen binnen het ICT-risicokader wordt beheerd, inclusief registers van ICT-dienstverleningscontracten, due diligence, concentratierisico, exitstrategieën, audit- en toegangsrechten, incidentassistentie, serviceniveaus en noodvoorzieningen.

Het enterprise Beleid voor bedrijfscontinuïteit en disaster recovery vereist:

Afhankelijkheden van derde partijen en de toeleveringsketen 6.5.1. Contracten met kritieke leveranciers moeten continuïteitsverplichtingen en hersteltijdtoezeggingen bevatten. 6.5.2. Belangrijke dienstverleners moeten op verzoek periodieke continuïteitstesten en deelname aan incidentoefeningen kunnen aantonen.

De mkb-versie vereist ook:

contactpunten voor continuïteit bij leveranciers

Dat kleine veld kan bij een echt incident doorslaggevend zijn. Als uw herstelplan zegt “neem contact op met cloudprovider-support”, maar niemand de escalatieroute, contractreferentie, ernstprocedure of contactpersoon buiten kantooruren kent, is de RTO fictie.

Deze tabel vervangt leveranciersrisicobeheer niet. Zij maakt leveranciersrisico operationeel.

Hoe auditors uw BIA zullen toetsen

Een ISO/IEC 27001:2022-auditor begint doorgaans met toepassingsgebied, context, risicobeoordeling, risicobehandeling, Verklaring van Toepasselijkheid, Annex A-beheersmaatregelen, gedocumenteerde informatie, operationele planning, prestatie-evaluatie en verbetering. De auditor vergelijkt de BIA met de risicobeoordeling en de SoA. Als A.5.30, A.5.29 of A.8.13 zijn opgenomen, vraagt de auditor om bewijs van implementatie en testen.

Een DORA-beoordelaar richt zich op kritieke of belangrijke functies, ICT-activa, ICT-afhankelijkheden van derde partijen, weerbaarheidstesten, incidentclassificatie, contractuele eisen, exitstrategieën en toezicht door het bestuursorgaan. De beoordelaar verwacht dat de BIA aansluit op het ICT-risicobeheerkader, de strategie voor digitale operationele weerbaarheid, ICT-bedrijfscontinuïteitsplannen, respons- en herstelplannen en het testprogramma.

Een NIS2-toezichthouder vraagt naar maatregelen voor bedrijfscontinuïteit, back-upbeheer, disaster recovery, crisismanagement, beveiliging van de toeleveringsketen, governancegoedkeuring en de capaciteit om significante incidenten te melden. De BIA moet aantonen dat deze maatregelen zijn gebaseerd op dienstimpact en goedgekeurde prioriteiten.

Een NIST CSF 2.0-beoordelaar vraagt hoe de BIA het Current Profile, Target Profile, de gap-analyse en het actieplan informeert. De beoordelaar kijkt naar Govern-uitkomsten voor juridische, regelgevende, contractuele, risico-, rol-, beleids-, toezicht- en leveranciersrisicobesluiten. Ook worden Identify-, Protect-, Detect-, Respond- en Recover-uitkomsten onderzocht.

Een COBIT 2019- of ISACA-achtige auditor richt zich doorgaans op governance. Wie is eigenaar van de dienst? Wie heeft het risico geaccepteerd? Zijn doelstellingen afgestemd op ondernemingsdoelen? Worden leveranciers gemonitord? Zijn baten, risico’s en middelen in balans? Worden corrigerende maatregelen tot afsluiting opgevolgd?

Clarysec’s Beleid voor audit en compliancemonitoring Beleid voor audit en compliancemonitoring maakt de BIA onderdeel van de auditplanningscyclus:

Jaarlijks moet een risicogebaseerd auditplan worden opgesteld en goedgekeurd, rekening houdend met: 5.2.1 De resultaten van de meest recente risicobeoordelingen en bedrijfsimpactanalyse (BIA) 5.2.2 Eerdere auditbevindingen en de status van corrigerende maatregelen 5.2.3 Wijzigingen in processen, IT-infrastructuur, systemen of leveranciers 5.2.4 Externe verplichtingen zoals DORA Article 25 of klantcontracten

Dit is een volwassenheidsstap die veel organisaties missen. De BIA mag niet buiten assurance staan. Zij moet het auditplan sturen.

Veelvoorkomende BIA-fouten in echte beoordelingen

Dezelfde zwaktes komen herhaaldelijk terug.

Ten eerste vermeldt de BIA applicaties, geen diensten. Klanten en toezichthouders geven om verstoring van diensten. Applicaties zijn belangrijk omdat zij die diensten ondersteunen.

Ten tweede worden RTO- en RPO-doelstellingen uit sjablonen gekopieerd. Een RTO van vier uur kan redelijk klinken totdat een hersteltest laat zien dat het negen uur duurt om identiteitsintegratie opnieuw op te bouwen, configuratie te herstellen, gegevens terug te zetten, integriteit te valideren en monitoring opnieuw in te schakelen.

Ten derde zijn back-ups niet gekoppeld aan bedrijfsimpact. Frequentie, bewaartermijn, encryptie, opslaglocatie, herstelprioriteit en testen moeten de goedgekeurde hersteldoelstellingen weerspiegelen.

Ten vierde worden leveranciers behandeld als vragenlijstitems, niet als herstelafhankelijkheden. Continuïteitstoezeggingen van leveranciers, escalatiecontacten, herstelbewijs en deelname aan incidentoefeningen moeten worden gekoppeld aan kritieke diensten.

Ten vijfde ontbreekt goedkeuring door het management. Onder NIS2 en DORA is managementverantwoordelijkheid expliciet. Onder ISO/IEC 27001:2022 zijn leiderschap, rollen, goedkeuring door de risico-eigenaar en prestatierapportage kerneisen.

Ten zesde is testen te smal. Het herstellen van één bestand is nuttig, maar bewijst geen dienstherstel. Het herstelpad van een kritieke dienst kan DNS, identiteit, secrets, infrastructure-as-code, API-gateways, monitoring, logging, leverancierescalatie, klantcommunicatie en privacybeoordeling omvatten.

De Zenith Blueprint vat in de fase Beheersmaatregelen in actie, stap 19, de auditverwachting voor back-ups samen:

Test u uw back-ups?

Het antwoord moet “ja, met bewijs” zijn, en dat bewijs moet terug te voeren zijn op de BIA.

Het auditklare BIA-bewijspakket

Een praktisch BIA-programma moet een beknopt bewijspakket opleveren dat kan worden gebruikt voor audits, klant-due diligence, bestuursrapportage en verbetering van weerbaarheid.

Dit pakket vertelt een samenhangend verhaal. Het maakt weerbaarheid ook meetbaar.

Volgende stap: zet uw BIA om in compliancebewijs

Maria heeft geen grotere spreadsheet nodig. Zij heeft een levende bewijsketen nodig.

Begin met één kritieke dienst. Breng de ICT-activa, gegevens, medewerkers, leveranciers en nutsvoorzieningen ervan in kaart. Keur MTD, RTO en RPO goed. Stem het back-upschema af. Controleer hersteltoezeggingen van leveranciers. Voer één hersteltest uit. Registreer hiaten. Werk het risicobehandelingsplan bij. Presenteer het resultaat aan het management.

Herhaal dit vervolgens.

Clarysec kan helpen dit proces te versnellen met het Beleid voor bedrijfscontinuïteit en disaster recovery, Beleid voor bedrijfscontinuïteit en disaster recovery - mkb, Beleid voor back-up en herstel, Beleid voor audit en compliancemonitoring, Zenith Blueprint en Zenith Controls.

Uw BIA mag geen ongebruikt plankdocument zijn dat voor een audit is gemaakt. Zij moet het operationele bewijs zijn dat uw belangrijkste diensten verstoringen kunnen overleven, aan klant- en regelgevende verwachtingen kunnen voldoen en kunnen herstellen binnen grenzen die uw leiderschap daadwerkelijk heeft goedgekeurd.

Als uw organisatie zich voorbereidt op een ISO/IEC 27001:2022 surveillance-audit, NIS2-klantassurance, DORA ICT-beoordelingen door derde partijen of rapportage over weerbaarheid op bestuursniveau, begin dan met het verdedigbaar maken van de BIA. Download de continuïteits- en auditbeleidsdocumenten van Clarysec, beoordeel de Zenith-implementatieroadmap of vraag een beoordeling van weerbaarheidsbewijs aan om versnipperde beheersmaatregelen om te zetten in één auditgereed verhaal.