Verantwoordelijkheden bij Managed Backup Rollout: Provider versus Klant
Bij het implementeren van een managed backup oplossing is het cruciaal om duidelijke verantwoordelijkheden tussen provider en klant vast te leggen. Onduidelijkheden kunnen leiden tot dataverlies en juridische risico's, vooral binnen Microsoft 365 omgevingen.
- Nieuwe SharePoint-sites kunnen buiten de back-up vallen door onduidelijke scope-afbakening, wat pas bij een incident zichtbaar wordt.
- De complexiteit van de Shared Responsibility in Microsoft 365 kan leiden tot verantwoordelijkheidsontwijking tussen klant en provider.
- Een 'set and forget'-mentaliteit kan monitoring en afstemming verwaarlozen, waardoor back-upafspraken niet meer aansluiten op de werkelijkheid.
- De klant blijft onder de AVG verantwoordelijk voor gegevensverwerking, zelfs als de back-up door een provider wordt beheerd.
- Granulariteit versus kosten: Meer detail in back-ups verhoogt herstelmogelijkheden maar ook opslagkosten.
- Snelheid van herstel versus beveiliging: Cloud-only back-ups bieden bescherming maar kunnen trager zijn bij grote volumes dan lokale oplossingen.
Waarom verantwoordelijkheid cruciaal is bij een managed backup rollout
Nieuwe SharePoint-sites vallen soms buiten de back-up omdat de scope niet scherp is vastgelegd, terwijl de aanname aan klantzijde al is dat ‘alles’ wordt meegenomen. Dat gat ontstaat niet door één technische fout, maar door onduidelijkheid over wie de scope bepaalt, wie wijzigingen bijhoudt en wie controleert of nieuwe onderdelen van Microsoft 365 ook echt onder de back-up vallen. Bij een incident wordt dat verschil tussen aanname en werkelijkheid pas zichtbaar, en dan is het te laat om ontbrekende dekking nog te herstellen.
Die onduidelijkheid wordt groter door de complexiteit van de Shared Responsibility-verdeling rond Microsoft 365. In de praktijk kan daardoor verantwoordelijkheidsontwijking ontstaan: zowel klant als provider gaat ervan uit dat de ander bepaalde instellingen of onderdelen beheert. Het voorbeeld van retentie-instellingen voor Teams-chats laat zien hoe dat misloopt. Als beide partijen denken dat dit al ergens anders is geregeld, blijft een deel van de omgeving ongedekt zonder dat dat direct opvalt. Voor een middelgroot bedrijf met beperkte interne tijd betekent dat niet alleen extra afstemming, maar ook een rollout die op papier compleet lijkt en in werkelijkheid hiaten bevat.
Een tweede risico zit in de gedachte dat een managed backup na de eerste inrichting vanzelf goed blijft werken. Die ‘set and forget’-misvatting verschuift de aandacht weg van monitoring en periodieke afstemming, terwijl juist daar zichtbaar wordt of de afgesproken verantwoordelijkheid nog aansluit op de werkelijkheid. Zodra nieuwe data, nieuwe onderdelen of gewijzigde verwachtingen niet meer worden gespiegeld in de back-upafspraken, ontstaat een stille afwijking tussen wat is ingericht en wat het bedrijf denkt te hebben afgedekt.
Bij een managed backup rollout gaat het daardoor niet alleen om techniek, maar om eigenaarschap onder druk van complexiteit. Zodra de verdeling van taken vaag blijft, verschuift werk tussen klant en provider zonder duidelijke grens. Dan ontstaat dezelfde uitkomst op meerdere plekken: onderdelen van Microsoft 365 blijven buiten beeld, nieuwe SharePoint-sites worden niet toegevoegd en pas bij herstel blijkt dat de veronderstelde dekking nooit volledig was.
Risico's van onduidelijke verantwoordelijkheidsverdeling
Nieuwe SharePoint-sites die niet expliciet in de back-upscope zijn opgenomen, vallen buiten de dekking en komen pas in beeld zodra er iets misgaat. Dat maakt onduidelijke verantwoordelijkheidsverdeling direct riskant: de klant gaat ervan uit dat “alles” is meegenomen, terwijl de provider alleen back-upt wat binnen de afgesproken scope valt. In de praktijk ontstaat dan een gat tussen verwachting en uitvoering. Zolang er geen incident is, blijft dat vaak onzichtbaar. Pas bij verlies van data blijkt dat een deel van de omgeving nooit is toegevoegd en dus ook niet kan worden teruggezet.
Die fout begint niet bij de techniek, maar bij de afbakening. Als niet vastligt wie de scope definieert, wie nieuwe onderdelen aanmeldt en wie controleert of de back-up meegroeit, ontstaat een keten van stilzwijgende aannames. Een nieuwe SharePoint-site wordt aangemaakt, maar niet toegevoegd aan de back-up. De omgeving blijft draaien alsof alles geregeld is. Daarna volgt een incident en blijkt de dekking smaller dan gedacht. Het gevolg is dataverlies, terwijl beide partijen kunnen wijzen naar dezelfde onduidelijke afspraak. Juist bij managed backup geeft dat extra wrijving, omdat beheer uitbesteed lijkt, maar de grens van die verantwoordelijkheid niet vanzelf duidelijk is.
De juridische kant stopt daar niet. Bij online backup blijft een organisatie onder de AVG verantwoordelijk voor de verwerking van gegevens. Dat betekent dat onduidelijkheid over verantwoordelijkheden niet alleen een operationeel probleem is, maar ook een compliance-risico. Als back-ups ontbreken of niet bruikbaar zijn op het moment dat gegevens moeten worden opgevraagd, kan een organisatie niet voldoen aan data-opvraagverzoeken. Dan verschuift het probleem van een gemiste back-up naar een aantoonbaar tekort in de uitvoering van die verantwoordelijkheid.
Dat maakt de verdeling tussen klant en provider meer dan een praktische projectafspraak. Zodra niet helder is wie verantwoordelijk is voor de aanwezigheid en bruikbaarheid van back-ups, ontstaat er ruimte voor misverstanden op precies het moment dat bewijs, beschikbaarheid en herstel samenkomen. In dat scenario blijft de organisatie zelf aanspreekbaar onder de AVG, ook als een externe partij het back-upproces beheert, met juridische sancties en boetes als concrete consequentie wanneer data-opvraagverzoeken niet kunnen worden afgehandeld door ontbrekende back-ups.
Factoren bij het verdelen van verantwoordelijkheden
Een back-upopzet loopt vast in de verdeling van verantwoordelijkheden zodra de gewenste herstelmogelijkheden veel detail vragen, terwijl de opslagkosten tegelijk strak bewaakt moeten blijven.
| Factor | Wat de provider doorgaans draagt | Wat bij de klant blijft | Gevolg voor de verdeling van verantwoordelijkheden |
|---|---|---|---|
| Granulariteit versus kosten bij backup | De provider beheert de back-updienst en de onderliggende opslagstructuur waarin meer of minder detail kan worden vastgelegd. Daarmee ligt de technische uitvoering van de gekozen granulariteit meestal aan de kant van de provider. | De klant bepaalt in de praktijk hoeveel detail nodig is voor herstel. Zodra elke versie van een bestand moet worden meegenomen, nemen de herstelmogelijkheden toe, maar ook de opslagkosten aanzienlijk. | Hier ontstaat een duidelijke grens tussen uitvoering en keuze. De provider kan de inrichting dragen, maar de klant blijft eigenaar van de afweging tussen meer herstelopties en hogere kosten. Als die keuze niet vooraf scherp is, verschuift de discussie later naar budget in plaats van dekking. |
| Snelheid van herstel versus beveiliging | Bij cloud-only back-ups draagt de provider de online back-upomgeving die bescherming biedt tegen een lokale brand. Die opzet hoort bij de technische en beveiligde beschikbaarheid van de back-updienst. | De klant blijft partij in de afweging welk hersteltempo nodig is voor grote volumes. Een cloud-only keuze kan goed aansluiten op beveiliging, maar herstel duurt bij grote hoeveelheden data trager dan vanaf een lokale appliance. | De verantwoordelijkheidsverdeling hangt hier af van de bedrijfsimpact van langere hersteltijden. De provider kan een veilige cloudopzet leveren, maar de klant moet bepalen of een trager herstel voor grote volumes werkbaar is binnen de eigen operatie. |
| Combinatie van beide afwegingen | De provider kan de dienst technisch beheren binnen de gekozen opzet: meer versies bewaren, of juist een compactere back-upstructuur hanteren, en een cloud-only model leveren dat gericht is op bescherming buiten de eigen locatie. | De klant houdt de verantwoordelijkheid voor de zakelijke prioriteiten achter die keuzes: hoeveel detail nodig is bij herstel en hoeveel vertraging aanvaardbaar is als grote volumes teruggezet moeten worden. | In de praktijk bepaalt deze combinatie hoeveel regie de klant zelf wil houden. Hoe scherper de eisen rond detail en hersteltijd, hoe minder ruimte er is voor een algemene managed dienst zonder expliciete keuzes over kosten en herstelsnelheid. |
Praktische toepassing van verantwoordelijkheidsverdeling
De rollout stokt zodra de Microsoft 365-koppeling wel gepland staat, maar de tenant-rechten nog niet door de klant zijn verleend. Bij API-gebaseerde data-extractie ligt de technische koppeling bij de provider, maar die koppeling werkt alleen binnen de rechten die de klant beschikbaar maakt. In de praktijk betekent dat een duidelijke scheidslijn: de provider richt de extractie in en beheert de verbinding, terwijl de klant eigenaar blijft van de toegang die daarvoor nodig is. Die verdeling voorkomt dat een managed backup traject wordt behandeld alsof de provider zelfstandig alles kan activeren. Zonder die interne handeling aan klantzijde blijft de implementatie niet hangen op techniek, maar op eigenaarschap van rechten.
Die verdeling wordt meestal pas echt zichtbaar tijdens de inrichting. De provider bouwt de koppeling voor Microsoft 365 op, start de data-extractie via de API en verwacht dat de juiste tenant-rechten aanwezig zijn. Ontbreken die rechten of zijn ze onvolledig, dan komt er geen volledige extractie tot stand. Het gevolg is niet alleen vertraging in de onboarding, maar ook onduidelijkheid over wat al wel en nog niet onder backup valt. Voor een middelgroot bedrijf met beperkte interne capaciteit is dat precies het punt waarop taken blijven liggen: de provider wacht op toegang, de klant denkt dat de technische inrichting al loopt, en de feitelijke dekking blijft achter bij de planning.
Bij immutable storage ligt de verantwoordelijkheid juist veel duidelijker aan providerzijde. Dit mechanisme maakt back-ups onveranderbaar, zodat ze niet kunnen worden gewijzigd of verwijderd door ransomware. De klant beheert dat opslagmechanisme niet zelf binnen een managed model; de provider doet dat als onderdeel van de technische infrastructuur. Daarmee verschuift de klantrol van uitvoerend naar afbakenend: niet het beheren van de onveranderbare opslag zelf, maar het begrijpen dat dit onderdeel van de dienst door de provider wordt gedragen. In een rolloutgesprek voorkomt dat verwarring over wie de integriteit van opgeslagen back-ups bewaakt en wie alleen de bronsystemen en toegangsrechten beschikbaar moet maken.
Praktisch ontstaat zo een werkbare scheiding tussen brontoegang en opslagbescherming. Aan de voorkant levert de klant de rechten waarmee Microsoft 365-data via de API kan worden opgehaald; aan de achterkant beheert de provider de immutable storage waarin die back-ups niet meer aangepast of verwijderd kunnen worden door ransomware. Zodra één van die twee delen ontbreekt, ontstaat een scheef beeld van gereedheid: er kan wel opslagbescherming zijn ingericht zonder bruikbare data-extractie, of er kan wel toegang zijn verleend zonder dat de beschermde opslag als providerverantwoordelijkheid helder is belegd. Dan lijkt de rollout administratief gestart, terwijl de feitelijke backupketen nog niet compleet is.
Overblijvende uitdagingen en risico's bij managed backup
Herstelprocedures die niet zijn getest, vallen pas op het moment dat data echt teruggezet moet worden, en dan blijkt pas of de hersteltijd aansluit op de dagelijkse operatie. In een managed backup traject kan de verdeling van verantwoordelijkheden op papier helder zijn, terwijl de praktijk iets anders laat zien: back-ups draaien, rapportages bestaan, maar de vraag hoe snel systemen of gegevens bruikbaar terugkomen blijft onbeantwoord. Zodra die stap niet periodiek is doorlopen, kan een incident uitmonden in dagenlang productiviteitsverlies in plaats van een gecontroleerd herstel.
Daar zit ook een hardnekkige aanname achter. Een managed dienst wekt al snel de indruk dat beheer gelijkstaat aan aantoonbaar herstel, terwijl die twee niet hetzelfde zijn. De operationele wrijving ontstaat niet tijdens de inrichting, maar later, wanneer rapportages wel worden gezien en hersteltests uit beeld raken. Dan verschuift de onzekerheid van techniek naar bedrijfsvoering: afdelingen rekenen op beschikbaarheid, terwijl niemand scherp heeft of de hersteltijd in de praktijk haalbaar is. Die kloof wordt meestal pas zichtbaar onder druk, precies op het moment dat stilstand direct geld en capaciteit kost.
Opslagkosten blijven intussen een apart risico, ook als de uitrol technisch netjes verloopt. Een backupopzet kan namelijk doorschieten in bewaarbeleid of overlap, waardoor dezelfde data dubbel wordt opgeslagen en de rekening oploopt zonder extra operationele waarde. Het omgekeerde risico bestaat ook: te weinig historische data beschikbaar hebben op het moment dat die later toch nodig blijkt. Dan verschuift het probleem van kostenbeheersing naar ontbrekende onderbouwing of ontbrekende terugvalmogelijkheden, met financieel verlies als direct gevolg.
Juist die combinatie maakt managed backup in de laatste fase van een rollout minder eenvoudig dan het vaak lijkt: een dienst kan actief zijn, opslag kan gevuld raken en verantwoordelijkheden kunnen verdeeld zijn, terwijl herstel in de praktijk niet is beproefd en historische dekking niet goed aansluit op wat later nodig blijkt. Dan ontstaat geen theoretisch risico meer, maar een dubbele beperking: dagenlange operationele stilstand aan de ene kant en doorlopende of onnodige opslagkosten aan de andere kant.