Bij een verstoring of calamiteit wil je uiteraard dat kritieke processen blijven draaien. Niet voor niets hebben veel veiligheidsregio’s en OOV-organisaties al een raamwerk voor bedrijfscontinuïteit. Ook voeren ze Business Impact Analyses (BIA’s) uit op hun systemen. Logisch, het onder alle omstandigheden kunnen blijven functioneren is voor deze sector geen bijzaak, maar hoofdzaak. Maar hoe houd je de controle? In dit blog schetsen we een stappenplan zonder nieuw raamwerk, waarmee je in 90 dagen inzicht krijgt in je cloudafhankelijkheid. Een goede start is het halve werk!
Waar zit het probleem?
Niet in het ontbreken van een plan of een aanpak. Nee, het zit ‘m in twee vragen die een klassieke BIA meestal niet stelt:
- Vraag 1: Wie kan een dienst beïnvloeden of intrekken? En onder welke wetgeving valt die partij?
Een BIA kijkt naar beschikbaarheid en hersteltijd. Uitval wordt gezien als iets technisch of als pech. Maar een storing is iets anders dan een blokkade. Een storing overkomt je, terwijl een blokkade een besluit van een ander is. En daartegen helpt geen hersteltijd.
- Vraag 2: Hoe groot is het concentratierisico?
Een BIA bekijkt elk systeem apart. Daardoor blijft dit risico standaard buiten beeld. Ieder systeem lijkt op zichzelf prima geregeld. Maar draaien vijf systemen op hetzelfde platform van dezelfde leverancier, dan betekent één storing vijf uitvallen tegelijk.
Zo pak je het in drie fases aan
Hoe pak je dit nu aan? Om met het goede nieuws te beginnen: je begint je aanpak niet bij nul. Heb je al een actuele BIA en weet je welke systemen kritiek zijn? Dan heb je de eerste fase waarschijnlijk in weken rond in plaats van maanden.
Fase 1 (0–90 dagen): verkrijg inzicht en behaal quick wins
In de eerste negentig dagen breng je de situatie in kaart en pak je quick wins. Dat doe je zo:
- Vul je bestaande BIA aan. Stel per systeem twee extra vragen: waar draait dit systeem, en wie heeft er zeggenschap over?
- Deel je portefeuille in naar drie niveaus. Niveau 1: systemen die móéten blijven werken als externe platforms wegvallen, omdat uitval direct de hulpverlening raakt. Niveau 2: systemen die wel van het netwerk afhankelijk mogen zijn, maar waarvoor hoge eisen gelden aan continuïteit en jurisdictie. Niveau 3: systemen waarvan uitval vervelend is, maar wel te herstellen is.
- Check en zoek naar gedeelde afhankelijkheden. Welke systemen gebruiken hetzelfde platform, dezelfde leverancier of dezelfde inlogvoorziening? En draait de uitwijk van een systeem toevallig op hetzelfde platform als het systeem zelf? Dan is het geen echte uitwijk.
- Benut contractverlengingen. Loopt er in deze periode een contract af? Neem dan meteen afspraken op over een exit, het meenemen van je data en de inzet van onderaannemers.
Wie de kartrekker is in de eerste fase? Meestal is dat de CIO of het hoofd I&A. De CISO brengt de jurisdictie- en dreigingsrisico’s in beeld. De proceseigenaren van meldkamer en crisisbeheersing bepalen wat écht de operationele kern is.
Dat levert je in de eerste fase het volgende resultaat op: een overzicht van al je systemen, ingedeeld in drie niveaus, plus een lijst van systemen die nu op de verkeerde plek staan.
Fase 2 (3–12 maanden): zorg voor regie en inkoop
Nu je dankzij fase 1 weet waar je staat, ga je sturen. Ga in fase 2 alsvolgt aan de slag:
- Koppel elk niveau aan een vast eisenpakket en waar je systeem staat. Gebruik daarvoor bestaande instrumenten zoals VeRA, de ICO-Wizard en het toetsingsinstrument van DICTU.
- Toets de leveranciers van je meest kritieke systemen op ketenafhankelijkheid. Waar wordt gehost? Welke onderaannemers zijn betrokken? Wie heeft op afstand beheertoegang en hoe ziet een exit eruit?
- Vraag aan SaaS-leveranciers waar ze voor kiezen. Waar draaien hun diensten en je data feitelijk, en welke partijen zitten daarachter? We zien in de praktijk dat dit nog nauwelijks gebeurt.
- Voer de eerste uitwijkoefening uit voor een systeem uit de hoogste risicoklasse.
Fase 3 (12–24 maanden): verplaats wat verkeerd staat
In deze fase gaat het om ‘verhuizen’ en samenwerken:
- Verplaats systemen die op de verkeerde plek staan. Doe dit stap voor stap. Begin bij de meest kritieke, met per stap een teststrategie en een terugvalscenario.
- Richt lokale of soevereine AI in voor toepassingen waar externe AI-diensten niet passen.
- Werk samen met andere regio’s aan voorzieningen die te groot zijn voor één regio alleen. Regel uitwijk en governance vooraf, niet achteraf.
En daarna?
Daarna wordt het routine. Oefen regelmatig met uitval en uitwijk. Toets bij elke nieuwe aanschaf en elke contractverlenging opnieuw: welk niveau, welke plek, welke keten? En herijk dit jaarlijks binnen je bestaande BIA-cyclus, want het belang van systemen verandert in de loop van de tijd.
Zo wordt de vraag waar je systemen staan en wie er zeggenschap over heeft geen apart project meer, maar een vast onderdeel van je bestaande werk. En dat is precies waar je naartoe wilt.