De meeste organisaties vertrouwen nog op het ingebouwde recyclemechanisme van Microsoft 365. Dat beschermt prima tegen per ongeluk verwijderen of hardwarestoringen, maar niet tegen een gerichte aanval waarbij een Global Admin versies verwijdert, recycle bins leegmaakt of een volledige tenant wist. Zonder aanvullende back-uplagen ontstaat schijnveiligheid: de infrastructuur draait nog, maar de data is onherstelbaar.
Het shared-responsibilitymodel is daarbij onverbiddelijk: Microsoft levert platformbeschikbaarheid, u blijft eigenaar van de informatie en dus van alle back-ups, herstelprocedures en governance rond RPO/RTO. Wie pas tijdens een crisis ontdekt dat standaardretentie onvoldoende is, verliest kostbare tijd en mogelijk zelfs bewijsmateriaal voor onderzoeken onder BIO, AVG, NIS2 en de Nederlandse Baseline voor Veilige Cloud.
Cloudransomware is bovendien volwassen geworden. Aanvallers richten zich op Exchange, SharePoint, OneDrive en Teams, schakelen retentie uit en wissen versies. Alleen een back-uparchitectuur met immutabele opslag, gescheiden beheer en geoefende herstelketens maakt het mogelijk om kritieke overheidsprocessen binnen de afgesproken tijd te herstellen en aantoonbaar te voldoen aan compliance-eisen. In deze gids werken we de architectuur, herstelprocessen en business continuity-aspecten van cloudback-ups uit, zodat bestuurders, CISO's en IT-teams dezelfde taal spreken wanneer zij beslissingen nemen over investering, risico en herstelvermogen.
Na het lezen van dit artikel begrijp je waarom de standaardretentie in Microsoft 365 niet voldoende is als laatste verdedigingslinie tegen ransomware en grootschalige incidenten, en hoe je een echte back-uparchitectuur ontwerpt met immutabele opslag, logische air-gaps en gescheiden beheer. Je krijgt een helder beeld van hoe je RPO- en RTO-eisen vanuit de business vertaalt naar concrete technische keuzes en hoe je herstelprocedures structureel test en verbetert. Tot slot laat de gids zien hoe back-up en disaster recovery worden ingebed in governance, compliance en rapportage binnen de Nederlandse Baseline voor Veilige Cloud.
Plan ieder kwartaal een end-to-end hersteltest met realistische tijdsdruk. Laat een onafhankelijk team de runbooks volgen, controleer of credentials beschikbaar zijn en meet de doorlooptijd tot de dienst weer bruikbaar is. Documentatie bewijst dat back-ups bestaan; alleen een geslaagde oefening bewijst dat u daadwerkelijk kunt herstellen.
Back-uparchitectuur: immutabel, air-gapped en gescheiden beheer
Een robuuste back-uparchitectuur voor Microsoft 365 begint met de erkenning dat data het eigenlijke kroonjuweel is van de organisatie. De onderliggende cloudplatforms zijn schaalbaar en redundant, maar juist de inhoud van mailboxen, SharePoint-sites, Teams-chats en OneDrive-documenten bepaalt of een overheidsdienst zijn wettelijke taken kan blijven uitvoeren. Vanuit de Nederlandse Baseline voor Veilige Cloud is het daarom noodzakelijk om de bescherming van die data te organiseren via meerdere lagen, waarbij immutabele opslag, logische air-gaps en gescheiden beheer elkaar versterken. Het doel is dat een aanvaller die beheerrechten weet te bemachtigen, de back-ups nog steeds niet kan manipuleren of verwijderen.
Immutabele opslag vormt in die architectuur de laatste verdedigingslinie. Met Write Once Read Many-beleid in bijvoorbeeld Azure Blob Storage of Azure Backup wordt vastgelegd dat back-upblokken na het schrijven niet meer kunnen worden gewijzigd of verwijderd binnen de ingestelde retentieperiode. Voor ransomware-scenario's is die retentie niet alleen een administratieve keuze, maar een directe afspiegeling van de dwell time: de periode waarin aanvallers onopgemerkt in het netwerk aanwezig kunnen zijn. In de praktijk betekent dit dat retentie van negentig dagen of langer nodig is om ook sluimerende aanvallen af te dekken, waarbij versies langzaam worden gecorrumpeerd voordat de aanval zichtbaar wordt. Voor informatie die onder de Archiefwet of AVG valt, wordt immutabiliteit gecombineerd met juridische bewaartermijnen en legal holds, zodat er altijd een onaantastbare kopie beschikbaar is voor onderzoek, bezwaar- en beroepsprocedures.
Daarnaast is een logische air-gap essentieel. In plaats van te vertrouwen op een enkel abonnement waarin zowel productie als back-ups worden beheerd, wordt opslag gescheiden in een dedicated back-upsubscriptie of zelfs een aparte tenant met eigen identity- en toegangsstructuren. Opslagaccounts krijgen strikte firewallregels, private endpoints en netwerkbeveiligingsgroepen, zodat zij uitsluitend toegankelijk zijn vanaf de back-upinfrastructuur en niet rechtstreeks vanuit productie. Resource locks voorkomen dat accounts per ongeluk of kwaadwillig worden verwijderd. Productiebeheerders hebben hooguit leesrechten op monitoring, maar geen verwijderrechten op de daadwerkelijk opgeslagen back-updata, waardoor hun compromittering niet automatisch tot verlies van back-ups leidt.
Die scheiding wordt versterkt door zorgvuldig credentialbeheer. In plaats van gedeelde serviceaccounts worden managed identities of dedicated serviceprincipals ingezet, die alleen gemachtigd zijn om back-ups te schrijven en te lezen. Privileged Identity Management zorgt ervoor dat beheerdersrechten tijdelijk en gecontroleerd worden toegekend en dat alle escalaties worden gelogd voor auditdoeleinden. Geheime sleutels en certificaten worden ondergebracht in een centraal Key Vault, waarbij Just-In-Time-toegang en automatische rotatie standaard zijn. Wie erin slaagt een productieserver of -account over te nemen, beschikt daarmee nog niet automatisch over de sleutels om de back-ups te vernietigen.
Tot slot speelt de inrichting van bewaartermijnen en kostenbeheersing een belangrijke rol in de architectuur. Een volwassen ontwerp maakt onderscheid tussen kortetermijnkopieën die frequente herstelacties ondersteunen en langetermijnkopieën die worden aangehouden voor compliance, forensisch onderzoek en geschillen. Dagelijkse of uurfrequente back-ups voorzien in herstel op detailniveau, terwijl wekelijkse of maandelijkse snapshots jarenlang kunnen worden bewaard in goedkopere opslagtiers. Lifecycle policies verplaatsen data automatisch naar cool- of archive-opslag zonder dat de retentie wordt doorbroken; de organisatie hoeft dus niet te kiezen tussen kostenbeheersing en naleving. Waar processen zeer kritisch zijn, wordt bovendien gerepliceerd naar een tweede Azure-regio zodat ook regionale verstoringen of grootschalige storingen kunnen worden opgevangen. In samenhang vormen deze keuzes een architectuur die aansluit op de eisen uit de BIO en NIS2 en die aantoonbaar maakt dat de organisatie haar back-ups niet als bijzaak, maar als integraal onderdeel van de beveiligingsstrategie behandelt.
Herstelprocedures: van RPO/RTO naar geoefende runbooks
Waar de back-uparchitectuur zich vooral richt op de opslag en bescherming van data, draait het bij herstelprocedures om de vraag hoe snel en betrouwbaar een organisatie de dienstverlening weer op gang kan brengen. Het uitgangspunt is dat RPO en RTO niet door techniek worden bepaald, maar door de bedrijfsimpact van uitval. Proceseigenaren, CISO, CIO en business continuity managers bepalen gezamenlijk hoeveel gegevens maximaal verloren mogen gaan en hoelang een dienst onbeschikbaar mag zijn, waarna technische teams deze eisen vertalen naar concrete ontwerpen en runbooks. In de context van de Nederlandse Baseline voor Veilige Cloud en de BIO is die dialoog cruciaal: hersteldoelen moeten aansluiten op wettelijke verplichtingen, bestuurlijke verwachtingen en de risicoacceptatie van de organisatie.
Een gestructureerde inventarisatie begint met het in kaart brengen van kritieke processen. Voor crisiscommunicatie, meldkamers, burgerportalen of kernregistratiesystemen blijkt in de praktijk dat een RPO van hooguit één uur en een RTO van enkele uren noodzakelijk is om maatschappelijke en bestuurlijke schade te beperken. Minder kritieke ondersteunende processen, zoals bepaalde interne rapportages of administratieve taken, mogen een ruimere bandbreedte hebben. Deze afspraken worden vastgelegd in service level targets en risicodossiers, zodat tijdens een incident geen discussie meer hoeft te worden gevoerd over prioritering: iedereen weet welke diensten als eerste moeten worden hersteld en welke acceptabele degradaties tijdelijk zijn.
Op basis van deze doelen worden runbooks ontwikkeld die de volledige herstelketen beschrijven. Een runbook gaat verder dan een technisch stappenplan; het legt ook vast welke teams betrokken zijn, welke bevoegdheden nodig zijn en hoe besluitvorming en escalatie verlopen. De volgorde van herstellen volgt de afhankelijkheden: eerst identiteits- en toegangslaag, vervolgens data en applicaties, en pas daarna interfaces en koppelingen met andere systemen. Zo wordt voorkomen dat gebruikers wel kunnen inloggen, maar nog geen toegang hebben tot de juiste gegevens, of dat koppelingen met ketenpartners falen omdat onderliggende componenten nog niet beschikbaar zijn. Heldere contactpunten, rolbeschrijvingen en escalatielijnen richting bestuur en communicatie worden expliciet opgenomen in het runbook, zodat niemand tijdens een crisis hoeft te improviseren.
Testen vormt het hart van volwassen herstelprocedures. In plaats van alleen op papier te vertrouwen dat back-ups werken, worden regelmatig oefeningen ingepland waarbij een representatieve workload wordt hersteld in een geïsoleerde omgeving. Tijdens zo'n oefening wordt niet alleen gekeken of data technisch beschikbaar komt, maar ook of de integriteit van documenten, metadata en machtigingen behouden blijft. De doorlooptijd van het herstel, van het moment van incidentmelding tot het moment waarop gebruikers weer normaal kunnen werken, wordt nauwkeurig gemeten en afgezet tegen de afgesproken RPO- en RTO-doelen. Waar de praktijk achterblijft bij het papier, worden scripts, automatisering, capaciteit of procedures aangepast.
Een herstel is pas écht geslaagd wanneer de business dat erkent. Proceseigenaren en functioneel beheerders spelen daarom een actieve rol in de validatiefase van elke hersteltest en van daadwerkelijke incidenten. Zij controleren of gebruikers kunnen aanmelden, documenten kunnen openen, transacties kunnen uitvoeren en rapportages kunnen draaien zoals vóór het incident. Pas wanneer zij formeel bevestigen dat de dienstverlening op een acceptabel niveau is hersteld, wordt de operatie als afgerond beschouwd. De bijbehorende rapportage, inclusief logbestanden, meetgegevens en lessons learned, wordt opgeslagen als auditbewijs voor toezicht op basis van BIO en NIS2 en dient als input voor verbetertrajecten. Zo ontstaat een cyclisch proces waarin runbooks geen statische documenten zijn, maar levende instrumenten die met elke oefening beter worden.
Business continuity: mensen, processen en leveranciers
Zelfs de beste back-up en de meest geoefende herstelprocedures lossen niet alles op als mensen en processen niet zijn voorbereid op tijdelijke verstoringen. Business continuity management vormt daarom de derde pijler van een volwassen cloud back-up- en disaster recoverystrategie. Waar technische teams vooral kijken naar data en infrastructuur, richt business continuity zich op de vraag hoe de organisatie als geheel blijft functioneren wanneer Microsoft 365-diensten of gerelateerde applicaties tijdelijk beperkt of niet beschikbaar zijn. In de Nederlandse publieke sector gaat het dan niet alleen om bedrijfscontinuïteit, maar vooral om de continuïteit van publieke dienstverlening en de bescherming van het vertrouwen van burgers en politiek.
Een belangrijke eerste stap is het ontwerpen van tijdelijke werkprocessen voor kritieke activiteiten. Proceseigenaren analyseren welke stappen absoluut digitaal moeten plaatsvinden en waar noodscenario's mogelijk zijn, bijvoorbeeld door tijdelijk met lokale kopieën te werken of alternatieve communicatiekanalen in te zetten. Voor sommige processen kan dat betekenen dat medewerkers vooraf instructies krijgen hoe zij in een crisissituatie overschakelen op vooraf voorbereide mapstructuren, offline sjablonen of een noodmailvoorziening. Voor andere processen is fysieke toegang tot papieren dossiers of noodlocaties nodig. Deze afspraken worden niet abstract beschreven, maar concreet uitgewerkt in werkinstructies die regelmatig worden getest.
Communicatie speelt een sleutelrol tijdens verstoringen. Een goed doordachte communicatie- en escalatiestructuur voorkomt dat verschillende afdelingen tegenstrijdige boodschappen verspreiden of dat bestuurders pas laat worden geïnformeerd. Daarom wordt in het business continuityplan vastgelegd wie welke doelgroepen informeert, via welke kanalen en met welk mandaat. Interne communicatie naar medewerkers, informatie aan bestuur en directie, berichtgeving richting burgers en externe stakeholders en afstemming met leveranciers krijgen elk een eigen aanpak. Vooraf opgestelde tekstvoorstellen, belschema's en afspraken over gebruik van sms, telefoon, intranet of publiekswebsites zorgen ervoor dat de organisatie snel kan schakelen zonder in de hectiek van het moment alles opnieuw te moeten bedenken.
Ook de afhankelijkheid van leveranciers en ketenpartners vraagt expliciete aandacht. Veel overheidsorganisaties steunen op een ecosysteem van softwareleveranciers, cloudproviders en dienstverleners, waarbij de continuïteit van de eigen dienstverlening nauw verweven is met de continuïteit van die partners. Contracten en service level agreements horen daarom niet alleen beschikbaarheids- en responstijden te bevatten, maar ook concrete eisen rond business continuity en disaster recovery. Het is belangrijk dat leveranciers aantoonbare plannen, testresultaten en hersteldoelstellingen kunnen laten zien en dat duidelijk is hoe zij communiceren tijdens incidenten. Daarnaast wordt in kaart gebracht welke alternatieve leveranciers, regioservices of tijdelijke oplossingen mogelijk zijn als een leverancier niet kan leveren.
Business continuity blijft theorie zolang er niet samen wordt geoefend. Daarom is het verstandig om technische hersteltests regelmatig te combineren met proces- en communicatieoefeningen waarbij niet alleen IT, maar ook proceseigenaren, communicatieadviseurs, HR, juridische functies en leveranciers betrokken zijn. Tijdens zo'n oefening wordt een realistisch scenario uitgewerkt, bijvoorbeeld een grootschalige ransomware-aanval die meerdere systemen raakt of een langdurige verstoring in een cloudregio. De organisatie doorloopt het volledige draaiboek: detectie, besluitvorming, interne en externe communicatie, inzet van noodwerkprocessen en uiteindelijk terugkeer naar de normale situatie. Na afloop worden de lessen vastgelegd, maatregelen geprioriteerd en plannen bijgewerkt. Door dit cyclische karakter groeit de organisatie langzaam naar een niveau waarop mensen instinctief weten wat hun rol is wanneer er echt iets misgaat.
Cloudback-ups vragen een andere mindset dan klassieke tapes. Ingebouwde retentie van Microsoft 365 is onvoldoende tegen aanvallen op beheeraccounts of configuratiefouten. Alleen immutabele opslag, gescheiden beheer, geoefende herstelprocedures en volwassen business-continuityplannen zorgen voor aantoonbare veerkracht.
Voor Nederlandse overheden is dit essentieel: RPO/RTO-afspraken uit de BIO moeten worden gehaald, NIS2 vereist bewijslast over herstelvermogen en bestuurders verwachten transparante rapportages over risico’s en oefeningen. Dat betekent continu investeren: architectuur evalueren, technische componenten actualiseren, runbooks bijwerken, testen plannen en lessons learned verwerken.
Organisaties die dit ritme vasthouden, kunnen een ransomware-aanval of regionale storing opvangen zonder langdurig verlies van publieke dienstverlening.