Hoe weet je of je cloudprovider voldoende bijdraagt aan je disaster recovery?

Je cloudprovider dekt minder dan je denkt — ontdek wat jij zelf moet regelen voor echte disaster recovery.

Gespleten serverrack in datacenter: linkerkant donker met verwarde kabels, rechterkant verlicht met blauwe indicatielampjes en nette kabelmanagement.

Als IT-manager of operations directeur ken je het gevoel: een systeem valt uit op een ongelegen moment. Je belt je cloudprovider, maar die vertelt je dat hun infrastructuur gewoon draait. En dat klopt ook — maar jouw data, applicaties of bedrijfsprocessen zijn toch niet beschikbaar. Dit is precies waar veel organisaties tegenaan lopen: een cloudprovider zorgt voor de infrastructuur, maar niet automatisch voor het herstel van wat jij daarop hebt draaien. De vraag is dus niet óf je cloudprovider zijn werk doet, maar wat er gebeurt als jouw kant van de verantwoordelijkheid niet goed is ingericht.

Wat dekt een cloudprovider wel — en wat niet — bij een incident?

Een cloudprovider is verantwoordelijk voor de beschikbaarheid en beveiliging van de onderliggende infrastructuur, maar niet voor de bescherming of het herstel van jouw data en applicaties. Dit principe heet het gedeelde verantwoordelijkheidsmodel en is de basis van vrijwel elke cloudovereenkomst.

Wat providers zoals Microsoft Azure, AWS of Google Cloud doorgaans wél regelen:

Fysieke beveiliging van datacenters
Beschikbaarheid van de cloudinfrastructuur
Beveiliging van het platform zelf
Basisfunctionaliteit voor replicatie en redundantie

Wat je als organisatie zelf moet regelen:

Back-up en herstel van jouw eigen data
Beveiliging van accounts, identiteiten en toegangsrechten
Configuratie van applicaties en beveiligingsinstellingen
Herstelplannen voor bedrijfskritieke processen

Dit onderscheid is in de praktijk belangrijker dan het lijkt. De infrastructuur kan volledig beschikbaar zijn, terwijl je toch geen toegang hebt tot je eigen bestanden of applicaties — bijvoorbeeld wanneer data door een incident onbereikbaar of verwijderd is geraakt. Dat valt buiten de verantwoordelijkheid van de provider.

Wat is het verschil tussen uptime-garanties en echt herstellen na een grote verstoring?

Uptime-garanties zeggen iets over de beschikbaarheid van de cloudinfrastructuur, niet over het herstel van jouw organisatie na een incident. Een SLA van 99,9% betekent dat de cloudinfrastructuur nagenoeg altijd beschikbaar is, maar biedt geen garantie dat jij na een verstoring snel weer operationeel bent.

Zorgen dat je bedrijf door kan draaien na een grote verstoring — wat vakmatig disaster recovery heet — gaat over het vermogen van jouw organisatie om kritieke systemen, data en processen te herstellen. Dat vereist onder andere:

Een vastgesteld herstelplan met duidelijke rollen en verantwoordelijkheden
Betrouwbare, geïsoleerde back-ups die buiten bereik blijven van eventuele verstoringen in de productieomgeving
Gedefinieerde RTO (Recovery Time Objective: hoe snel moet je weer draaien?) en RPO (Recovery Point Objective: hoeveel dataverlies is acceptabel?)
Regelmatige tests van het herstelproces

De uptime van je cloudprovider is een randvoorwaarde, geen vervanging voor een eigen herstelstrategie.

Welke vragen moet je je cloudprovider stellen over herstel?

Om te beoordelen of je cloudprovider voldoende bijdraagt aan jouw cyberweerbaarheid, stel je gerichte vragen over herstelcapaciteiten, verantwoordelijkheden en beperkingen. Vraag niet alleen naar beschikbaarheid, maar vraag door op herstelscenario’s die voor jouw organisatie relevant zijn.

Stel in ieder geval de volgende vragen:

Wie is verantwoordelijk voor het herstel van mijn data bij een verstoring of incident? Zorg dat je het gedeelde verantwoordelijkheidsmodel goed begrijpt voor jouw specifieke dienst.
Hoe lang worden back-ups bewaard, en zijn ze geïsoleerd van mijn productieomgeving? Back-ups die in dezelfde omgeving staan, kunnen bij een incident ook onbereikbaar raken.
Wat is de maximale hersteltijd die jullie kunnen garanderen? Onderscheid hierbij infrastructuurherstel van applicatie- en dataherstel.
Hoe worden beveiligingsincidenten aan mij gerapporteerd? Vraag naar meldingstijden en communicatieprocessen.
Welke aanvullende hersteloplossingen bieden jullie, en wat valt buiten de standaardovereenkomst?

De antwoorden op deze vragen geven je een realistisch beeld van wat je kunt verwachten en waar de hiaten in je herstelstrategie zitten.

Hoe test je of je cloudomgeving herstelbaar is na een grote verstoring?

De enige manier om te weten of je cloudomgeving herstelbaar is, is door het herstelproces daadwerkelijk te testen. Veel organisaties hebben een herstelplan op papier, maar hebben nooit gecontroleerd of het in de praktijk ook werkt. Regelmatige hersteltests zijn een essentieel onderdeel van cyber resilience en zorgen dat je bedrijf door kan draaien.

Een goede hersteltest voor je cloudomgeving bestaat minimaal uit de volgende stappen:

Definieer een realistisch scenario, zoals onbeschikbare data door een configuratiefout of een gecompromitteerd beheerdersaccount.
Test het herstel van back-ups in een geïsoleerde omgeving, los van je productiesystemen.
Meet de werkelijke hersteltijd en vergelijk die met je RTO. Is het verschil groot, dan pas je je herstelplan aan.
Controleer de integriteit van herstelde data en of applicaties daadwerkelijk functioneren na herstel.
Evalueer de communicatie en coördinatie tijdens de test: wie deed wat, wat ging goed en waar lagen de knelpunten?

Voer dit soort testen minimaal één keer per jaar uit, en bij voorkeur vaker als je omgeving regelmatig verandert. Een herstelplan dat nooit getest is, geeft je onvoldoende houvast op het moment dat het er echt toe doet.

Wanneer is een aanvullende disaster recovery-oplossing zinvol?

Een aanvullende oplossing is zinvol zodra de standaard herstelcapaciteiten van je cloudprovider niet aansluiten op de herstelbehoeften van jouw organisatie. Voor de meeste middelgrote tot grote organisaties is dat vrijwel altijd het geval, zeker wanneer bedrijfskritieke applicaties, klantdata of operationele processen afhankelijk zijn van de cloud.

Signalen dat aanvullende maatregelen de moeite waard zijn:

Je hebt geen inzicht in waar je back-ups staan en of ze geïsoleerd zijn
Je cloudprovider biedt geen garanties voor dataherstel na een incident
Je RTO en RPO zijn niet gedefinieerd of niet getest
Je hebt geen herstelplan voor scenario’s zoals onbeschikbare data of problemen met toegangsbeheer
Compliance-eisen zoals NIS2 of ISO 27001 verplichten je tot aantoonbare herstelcapaciteit

Een aanvullende oplossing kan bestaan uit een dedicated Minimum Viable Company-aanpak, waarbij je de minimale set aan systemen en processen definieert die nodig is om operationeel te blijven na een incident. Daarbovenop kun je denken aan aanvullende back-upoplossingen, immutable storage, of een volledig uitgewerkt cyber recovery-platform.

Hoe OpenSight helpt met disaster recovery in de cloud

Wij helpen organisaties om helder in beeld te krijgen wat hun cloudprovider daadwerkelijk dekt en waar de herstelgaten zitten. Dat doen we niet met een standaard rapport, maar met een aanpak die aansluit op jouw risicoprofiel, bedrijfsdoelstellingen en de systemen die er voor jou echt toe doen.

Concreet betekent dat:

We brengen samen met jou de kritieke applicaties, data en processen in kaart die na een incident als eerste hersteld moeten worden
We beoordelen de herstelcapaciteiten van je huidige cloudprovider en brengen in beeld waar aanvullende maatregelen zinvol zijn
We helpen bij het opzetten van een herstelstrategie met duidelijke RTO en RPO, inclusief back-up, isolatie en testprocedures
We ondersteunen bij de implementatie van aanvullende cyber resilience-oplossingen die passen bij jouw omgeving
We zorgen dat je herstelplan niet alleen op papier klopt, maar ook in de praktijk werkt

Wil je weten hoe herstelbaar jouw cloudomgeving werkelijk is? Neem contact op en we kijken samen waar de verbeterpunten liggen en wat er nodig is om te zorgen dat jouw bedrijf door kan draaien.