De Microsoft 365-regel die niemand leest: jouw data is jouw probleem
Microsoft houdt de dienst draaiende; jouw data herstelbaar houden is contractueel, expliciet, jouw taak.
Een HR-manager verwijdert het account van een vertrokken medewerker, zonder te weten dat de gekoppelde OneDrive de enige exemplaren van getekende contracten bevatte. Negentig dagen later sluit het bewaarvenster en zijn de bestanden weg — definitief. Als het bedrijf Microsoft belt, is het antwoord beleefd en definitief: accountbeheer is de verantwoordelijkheid van de klant.
Dit is het shared responsibility-model dat precies werkt zoals ontworpen. Microsoft beheert het Microsoft 365-platform — datacenters, uptime, patching, infrastructuurbeveiliging — terwijl de klant eigenaar is van alles wat er met de data binnen gebeurt: retentie, toegang, bescherming en herstel. EU-organisaties met AVG-verantwoordingsplicht en NIS2-hersteleisen kunnen dat eigenaarschap niet per aanname uitbesteden.
De misvatting die dit artikel ontmantelt is de duurste in cloudcomputing: "het staat in Microsofts cloud, dus Microsoft maakt er back-ups van." Dat doet Microsoft niet, en dat zegt Microsoft ook.
Wat Is Het Shared Responsibility-model?
Het shared responsibility-model is de contractuele taakverdeling tussen een cloudprovider en zijn klant. Voor SaaS-platforms zoals Microsoft 365 beveiligt en beheert de provider de dienst; de klant beheert en beschermt de data, identiteiten en configuraties erbinnen. Microsoft documenteert deze verdeling openlijk in zijn shared responsibility-richtlijnen: de verantwoordelijkheid voor "informatie en data" blijft altijd bij de klant, ongeacht het servicemodel.
De Verdeling in Eén Oogopslag
| Verantwoordelijkheid | Microsoft | Jij |
|---|---|---|
| Datacenters, hardware, netwerk | ✔ | |
| Beschikbaarheid & platformbeveiliging | ✔ | |
| Identiteits- & toegangsconfiguratie | ✔ | |
| Dataretentie & levenscyclus | ✔ | |
| Back-up & herstel van jouw content | ✔ | |
| Regelgevingscompliance voor jouw data | ✔ |
Beschermt Microsofts Replicatie Mijn Data Dan Niet?
Nee — replicatie en back-up lossen verschillende problemen op. Microsoft repliceert je data over datacenters om hardwarefalen te overleven en de dienst beschikbaar te houden. Maar replicatie is trouw van aard: verwijder een bestand, en de verwijdering repliceert mee; word je getroffen door ransomware die via een gecompromitteerd account SharePoint-bibliotheken versleutelt, dan repliceren de versleutelde versies ook. Elke replica is binnen minuten even kapot.
Back-up daarentegen betekent een onafhankelijke point-in-time-kopie waaruit je kunt herstellen van vóór de schade. Native Microsoft 365-tools helpen gedeeltelijk — prullenbakken, versiegeschiedenis, retentiebeleid — maar met harde grenzen: bewaartermijnen van weken, geen echte point-in-time restore over een tenant, en geen kopie die buiten de tenant bestaat die een aanvaller zojuist heeft overgenomen. Beschikbaarheid is geen herstelbaarheid, en Microsoft belooft alleen het eerste.
Wat Er Misgaat Als Het Model Verkeerd Wordt Gelezen
De faalscenario's zijn alledaags en constant. Offboarding-opruimacties die bedrijfsdossiers geruisloos vernietigen zodra de retentie verloopt. Per ongeluk bulkverwijderingen die over apparaten synchroniseren voordat iemand het merkt. Kwaadwillende insiders die mailboxen leegtrekken bij vertrek. En ransomware-operators die juist clouddata targeten omdat ze weten dat de meeste slachtoffers geen kopie buiten de tenant hebben.
De regelgevingsdruk stapelt daar bovenop. Het verantwoordingsbeginsel van de AVG vereist dat organisaties passende bescherming van persoonsgegevens waarborgen — en kunnen aantonen. De NIS2-richtlijn gaat verder voor entiteiten binnen de reikwijdte en verplicht back-upbeheer en disaster recovery als expliciete risicomaatregelen. En volgens het Cost of a Data Breach Report van IBM bereikten de gemiddelde kosten van een datalek in 2024 wereldwijd 4,88 miljoen dollar — met onherstelbare data als een van de sterkste kostendrijvers. Cyberverzekeraars hebben hun conclusie getrokken: bewijs van onafhankelijke, geteste back-ups is in toenemende mate een dekkingsvoorwaarde.
Zo Vul Je Jouw Kant Van Het Model In: Een Stappenplan in Vijf Stappen
Breng je datalandschap in kaart. Bepaal wat er in Exchange, SharePoint, OneDrive en Teams leeft, en welk deel bedrijfskritisch is of onder bewaarverplichtingen valt.
Zet een onafhankelijke back-up in. Implementeer een gerichte Microsoft 365-back-up die immutable point-in-time-kopieën buiten je tenant opslaat — in EU-datacenters als datasoevereiniteit deel is van je compliance-opzet.
Stel retentie in op verplichting, niet op standaardwaarde. Stem back-upretentie af op je wettelijke en contractuele plichten (vaak jaren), niet op Microsofts prullenbakvensters (vaak weken).
Repareer het offboarding-lek. Maak "back-up geverifieerd" een verplichte stap vóór elke accountverwijdering — data van vertrokken medewerkers is in de praktijk hét scenario voor definitief verlies.
Test en documenteer restores. Draai elk kwartaal hersteltests tegen RTO/RPO-doelen en archiveer de resultaten; onder NIS2 is die documentatie het verschil tussen weerbaarheid claimen en bewijzen, en een geteste disaster recovery-procedure maakt de bewijsketen compleet.
Waarom EU-jurisdictie in Het Besluit Thuishoort
Waar je back-upkopieën staan, bepaalt welk recht erbij kan. Kopieën bij Amerikaanse hyperscalers blijven onderworpen aan de Amerikaanse CLOUD Act, ongeacht de datacenterlocatie — een reëel aandachtspunt voor Europese organisaties met strikte soevereiniteitseisen. Onafhankelijke back-ups in Europees eigendom onder Nederlandse of Duitse jurisdictie sluiten dat gat, passen naadloos bij AVG-verwachtingen en vereenvoudigen het gesprek met auditors. Er is ook een structureel beveiligingsvoordeel: een back-up buiten het Microsoft-ecosysteem, met eigen credentials en gerichte data security-maatregelen, ligt buiten bereik van wie je tenant ook compromitteert.
Conclusie
Het shared responsibility-model is geen kleine lettertjes — het is de exploitatieovereenkomst van cloudcomputing, en het legt de herstelbaarheid van jouw data ondubbelzinnig bij jou. Microsoft houdt de dienst door vrijwel alles heen draaiende; het repliceert ook trouw elke verwijdering, versleuteling en vergissing die je tenant produceert. Onafhankelijke, immutable, EU-gehoste back-ups met geteste restores zijn hoe een organisatie haar kant werkelijk invult. Wil je weten waar jouw huidige opzet gaten laat ten opzichte van het model? We brengen het graag met je in kaart.
Veelgestelde Vragen
Is Microsoft verantwoordelijk voor back-ups van mijn Microsoft 365-data?
Nee. Onder het shared responsibility-model is Microsoft verantwoordelijk voor de beschikbaarheid en beveiliging van de Microsoft 365-dienst, terwijl klanten volledig verantwoordelijk blijven voor hun data — inclusief back-up en herstel. Microsofts eigen documentatie stelt dat de verantwoordelijkheid voor informatie en data altijd bij de klant blijft. Native tools zoals prullenbakken en versiegeschiedenis bieden slechts beperkte, kortlopende herstelopties.
Wat is het verschil tussen replicatie en back-up in Microsoft 365?
Replicatie kopieert je live data naar meerdere datacenters om de dienst beschikbaar te houden bij infrastructuurstoringen — maar kopieert wijzigingen zonder onderscheid, inclusief verwijderingen, corruptie en ransomware-versleuteling. Een back-up is een onafhankelijke point-in-time-kopie buiten het live systeem, waaruit data hersteld kan worden naar een staat van vóór de schade. Replicatie beschermt de dienst; back-up beschermt jouw data.
Hoe lang bewaart Microsoft 365 verwijderde bestanden en e-mails?
De native bewaarvensters zijn beperkt: verwijderde items overleven doorgaans 30 tot 93 dagen, afhankelijk van dienst en configuratie, en worden daarna definitief gewist. Versiegeschiedenis en retentiebeleid kunnen de bescherming voor specifieke scenario's verlengen, maar vormen geen point-in-time-herstel van een mailbox, site of tenant. Organisaties met langere wettelijke bewaarplichten hebben een onafhankelijke back-up nodig met retentie die op die plichten is afgestemd.