Is de gewoonte van uw MSP om alles te behouden, stilletjes een strategisch risico geworden?
Het behandelen van elk logbestand, ticket en elke back-up als een permanente verzekering leek ooit goedkoop, maar voor een MSP creëert het nu onnodige risico's, kosten en auditproblemen. Wanneer er nooit iets wordt verwijderd, komen inbreuken harder aan, wordt juridische onderzoek dieper en worden ISO 27001 en privacycontrole toegepast op gegevens die u of uw klanten niet langer van dienst zijn. Een weloverwogen, ISO-conforme aanpak stelt u in staat die impact te verkleinen, uw keuzes uit te leggen en klanten te bewijzen dat hun informatie wordt beheerd en niet gehamsterd.
De meeste managed service providers hebben nooit bewust een model voor gegevensbewaring ontworpen. Het is ontstaan uit standaardinstellingen in back-uptools, voorzichtige engineers die logvensters verlengen "voor het geval dat", en klanten die erop staan dat je nooit iets verwijdert dat ooit van pas zou kunnen komen bij een geschil. Dat was acceptabel toen klanten alleen beveiligingsvragen op hoog niveau stelden; het is veel minder verdedigbaar nu toezichthouders, inkoopteams en auditors onderzoeken hoe lang je verschillende datasets bewaart en wat er gebeurt aan het einde van een contract.
Een meerderheid van de organisaties in het rapport 'State of Information Security 2025' geeft aan dat ze in het afgelopen jaar te maken hebben gehad met minimaal één beveiligingsincident gerelateerd aan een derde partij of leverancier.
Deze informatie is algemene richtlijn en geen juridisch advies. Voor specifieke juridische verplichtingen dient u een gekwalificeerde advocaat in de relevante rechtsgebieden te raadplegen.
Echte controle over uw gegevens begint wanneer u kiest wat u niet wilt bewaren.
Uw echte datavoetafdruk zien
U ziet uw werkelijke datavoetafdruk door in kaart te brengen waar klantgegevens zich bevinden, hoe lang deze daar blijven en of dit overeenkomt met wat u hebt beloofd. Zodra u die realiteit vergelijkt met uw contracten en polissen, kunt u overmatige retentie beschouwen als een duidelijk risico in plaats van als een ongemakkelijk gevoel dat "we te veel bewaren".
Voor veel MSP's brengt een snelle inventarisatie van support, monitoring, toegang op afstand, samenwerking, back-ups en engineer-apparatuur opvallende verschillen aan het licht tussen beleid, contract en realiteit. Commentaar op dataretentie en -minimalisatie laat vaak hetzelfde patroon zien: organisaties documenteren levenscyclusregels, maar passen deze niet consistent toe in live systemen. Zodra deze verschillen zichtbaar zijn, kunt u ze behandelen als specifieke levenscyclusrisico's in plaats van een vage zorg over "te veel data".
Een praktisch startpunt is een eenvoudige mappingoefening:
- Maak een lijst van uw belangrijkste systemen: servicedesk, externe bewaking en beheer, monitoring, externe toegang, bestands- en e-mailplatforms, back-ups, documentatie, kluizen en engineer-apparaten.
- Registreer voor elk systeem welke klantgegevens er worden opgeslagen, van wie de gegevens zijn, hoe lang ze bewaard worden en hoe dat zich verhoudt tot contracten, privacyverklaringen en interne beleidsregels.
- Koppel die inventaris aan uw risicoregister, zodat risico's in de levenscyclus van gegevens naast bekende kwesties als patching, toegangscontrole en wanbetalingen van leveranciers komen te staan.
Binnen een paar uur vind je meestal oude mailboxen met jaren aan tickets, logsystemen met een vrijwel oneindige geschiedenis, back-upketens die nooit zijn opgeschoond en engineers met oude klantgegevens in de cache op laptops. Die realiteit, en niet wat het beleid voorschrijft, is waar een aanvaller, toezichthouder of advocaat van de eiser mee zou werken als er iets misgaat.
Zodra u de werkelijke voetafdruk kunt zien, wordt het gemakkelijker om drie soorten retentie te onderscheiden:
- Gegevens die u moet bewaren om te voldoen aan wetten, regels of contracten.
- Informatie die u besluit te bewaren omdat het nuttig is voor de bedrijfsvoering, ondersteuning of forensisch onderzoek.
- Informatie die u per ongeluk bewaart, omdat niemand ooit een systeem heeft opgedragen hiermee te stoppen.
Alleen de eerste twee kunnen gerechtvaardigd worden. De derde is pure exposure.
Een platform als ISMS.online kan u in deze fase helpen door u een gestructureerde plek te bieden waar u uw gegevensinventarisatie kunt vastleggen, elke opslag kunt koppelen aan risico's en controles, en het management een duidelijk overzicht te geven van waar het bewaren en verwijderen van gegevens op dit moment niet onder controle is.
Alles omzetten in een gekwantificeerd risicoverhaal
Je kunt alles in een gekwantificeerd risicoverhaal vastleggen door eenvoudige cijfers en scenario's aan je huidige gewoonten te koppelen, zodat het management ze kan afwegen tegen andere prioriteiten. In plaats van te discussiëren over principes in het abstracte, laat je zien wat je huidige geschiedenis betekent bij een inbreuk, geschil of audit en hoeveel extra inspanning incidenten kosten omdat er nooit iets wordt verwijderd.
U kunt klantbehoud herdefiniëren als een strategisch risico door vragen te stellen zoals:
- Als een bepaalde klant slachtoffer wordt van een inbreuk, voor hoeveel jaar staan de gegevens dan in uw systemen en back-ups?
- Hoeveel extra tijd kost het bij een ernstig incident om enorme hoeveelheden logboeken en ticketgeschiedenissen door te spitten in vergelijking met een nauwkeurig begrensd tijdsbestek?
- Stel dat u te maken krijgt met een juridische claim. Hoe ver terug in de tijd kunt u de informatie verzamelen, gezien uw huidige bewaartermijnen?
Je hebt geen perfecte statistieken nodig om een overtuigend verhaal te vertellen. Simpele vergelijkingen, zoals dat we momenteel zeven jaar volledige mailboxback-ups voor deze klant bewaren, hoewel geen enkel contract of regelgeving dit vereist, zijn voldoende om aan te tonen dat de huidige gewoonten nooit een bewuste risicobeslissing waren. Je kunt vervolgens bijzonder gevoelige datasets markeren, zoals identiteitsgegevens, logs met bevoorrechte toegang, betalingsgegevens, gezondheids- of kindergegevens, of tickets met screenshots en database-extracten. Wanneer deze in meerdere systemen en lange back-upketens voorkomen, worden de nadelen van ongecontroleerde retentie duidelijk.
Samengevat geeft deze baseline u een krachtig verhaal: uw organisatie loopt onzichtbare risico's en kosten door data die ze eigenlijk niet nodig heeft. Dit creëert een duidelijke opening om een ISO 27001-aanpak voor te stellen die de organisatie beschermt, klanten geruststelt en uw MSP positioneert als een volwassen, vertrouwde partner in plaats van een hoopvolle dataverzamelaar.
Demo boekenWat verwacht ISO 27001 nu werkelijk van MSP's op het gebied van dataretentie en -verwijdering?
ISO 27001 verwacht dat uw MSP een risicogebaseerd model voor de levenscyclus van informatie ontwerpt en hanteert in plaats van vaste aantallen te gokken voor elk log of ticket. Deze risicogebaseerde aanpak is hoe ISO 27001 en gerelateerde richtlijnen doorgaans het beheer van de levenscyclus van informatie vormgeven, met de nadruk op het begrijpen van de context en het behandelen van risico's in plaats van het voorschrijven van universele tijdslimieten; commentaar uit de sector, bijvoorbeeld van de Cloud Security Alliance, versterkt deze interpretatie. U moet de juridische en klantverwachtingen begrijpen, duidelijke regels voor het bewaren en verwijderen definiëren, deze koppelen aan controles in Bijlage A en vervolgens aan auditors laten zien dat u deze consistent toepast op tools, klanten en contracten. De norm hecht veel meer waarde aan de coherentie en werking van dat model dan aan een enkele tijdsperiode, en specifieke periodes moeten altijd worden overeengekomen met een juridisch adviseur in de rechtsgebieden waar u en uw klanten actief zijn.
Ongeveer tweederde van de organisaties in het rapport 'State of Information Security 2025' geeft aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.
De clausules over het managementsysteem bepalen de verwachtingen. U moet de behoeften van belanghebbenden (waaronder klanten en toezichthouders) begrijpen, wettelijke en contractuele vereisten identificeren, informatierisico's beoordelen en controlemechanismen selecteren om die risico's te beheersen. Vervolgens definieert u beleid en doelstellingen, implementeert u operationele controlemechanismen, bewaakt u de prestaties, voert u interne audits uit en stimuleert u continue verbetering. Bewaring en verwijdering vallen net als elke andere controlemechanisme binnen die lus en moeten in hetzelfde ritme worden beoordeeld als toegangsbeheer of kwetsbaarheidsafhandeling.
Bijlage A maakt de levenscyclus expliciet. De herziening van 2022 introduceerde en versterkte verschillende controles die samen bepalen hoe u over retentie moet denken. Samenvattingen van de ISO 27001-update van 2022 benadrukken nieuwe en herziene controles in Bijlage A met betrekking tot het verwijderen, back-uppen en loggen van informatie. Deze beïnvloeden allemaal hoe organisaties retentie en verwijdering vormgeven als onderdeel van de algehele controleset. Onafhankelijke overzichten van de wijzigingen van 2022, zoals die gepubliceerd door gespecialiseerde cybersecuritybronnen, benadrukken deze accentverschuiving.
Bijna alle organisaties in het ISMS.online-onderzoek van 2025 geven prioriteit aan het behalen of behouden van beveiligingscertificeringen zoals ISO 27001 of SOC 2.
- Bescherming van gegevens: ervoor zorgen dat belangrijke gegevens zo lang als nodig bewaard en beschermd worden.
- Classificatie van informatie: ervoor zorgen dat informatie geclassificeerd is, omdat de bewaring en vernietiging per klasse verschillen.
- Back-up van informatie: ervoor zorgen dat back-ups voldoen aan de vastgelegde bewaar- en herstelregels.
- Verwijderen van informatie: ervoor zorgen dat informatie wordt verwijderd wanneer deze niet langer nodig is, en dat verwijdering de kans op herstel verkleint.
- Veilige verwijdering of hergebruik van apparatuur: ervoor zorgen dat opslagmedia geen gegevens lekken bij hergebruik of vernietiging.
- Logging en monitoring: logs worden bewaard zolang dat nodig is voor beveiliging en naleving, en vervolgens op passende wijze verwijderd.
Voor MSP's spelen deze verwachtingen een rol in drie praktische aspecten.
U brengt privacyrechten, regels voor het bijhouden van gegevens en de verwachtingen van klanten in evenwicht door bewuste, gedocumenteerde beslissingen te nemen over gegevensbewaring, in plaats van engineers of accountmanagers te laten improviseren. ISO 27001 verwacht te zien hoe u in uw risicobeoordelingen, beleid en contracten de balans vindt tussen dataminimalisatie, verplichtingen voor het bijhouden van gegevens en het 'bewaar alles'-instinct.
Vaak word je heen en weer geslingerd tussen drie krachten:
- Privacywetgeving en verwachtingen ten aanzien van de gegevensbescherming van cliënten, die de nadruk leggen op dataminimalisatie en vastgelegde bewaartermijnen. Toezichthoudende autoriteiten zoals het Britse Information Commissioner's Office benadrukken expliciet opslagbeperking, dataminimalisatie en duidelijke bewaartermijnen in hun richtlijnen voor bewaring en verwijdering.
- Regels voor het bewaren van gegevens binnen sectoren en bedrijven, die voorschrijven dat bepaalde gegevens jarenlang bewaard moeten worden.
- Klanten en ingenieurs die standaard 'alles behouden' omdat dat veiliger voelt.
ISO 27001 verwacht dat u die spanning expliciet oplost in plaats van het ad hoc te laten gebeuren. Die oplossing zou zichtbaar moeten zijn in:
- Uw risicobeoordeling, waarin u het risico op onder- en overbehoud documenteert en de onderbouwing voor de gekozen periodes.
- Beleid en procedures waarin staat hoe lang verschillende soorten informatie worden bewaard en hoe deze worden verwijderd of gearchiveerd.
- Contracten, SLA's en overeenkomsten voor gegevensverwerking waarin is vastgelegd wie de bewaartermijnen bepaalt, hoe verzoeken om verwijdering worden behandeld en wat er gebeurt aan het einde van een contract.
U moet ook een duidelijk standpunt innemen over privacyrechten zoals gegevenswissing. Sommige frameworks staan u toe gegevens te bewaren wanneer u een wettelijke verplichting hebt of deze nodig hebt om juridische claims te verdedigen, zelfs als iemand om verwijdering vraagt. ISO 27001 staat hier niet los van, maar verwacht wel dat u die wettelijke grondslagen documenteert en overmatige bewaring als een risico op zich beschouwt.
Het omzetten van standaardtaal in een werkend levenscyclusmodel
U zet standaardtaal om in een werkend levenscyclusmodel door clausules en controlelijsten te vertalen naar een eenvoudige volgorde die laat zien waar data wordt aangemaakt, gebruikt, opgeslagen, gearchiveerd en verwijderd. Wanneer engineers en accountteams kunnen zien waar in die levenscyclus daadwerkelijke beslissingen worden genomen, is retentie niet langer een abstract argument over formuleringen, maar een concrete ontwerpdiscussie.
Teams begrijpen levenscycli veel gemakkelijker dan lange lijsten met controlereferenties. Als u de ISO 27001-eisen vertaalt naar een eenvoudige, herhaalbare levenscyclus, kunnen mensen zien waar beslissingen over behoud en verwijdering daadwerkelijk plaatsvinden.
Een eenvoudige levenscyclus kan er als volgt uitzien:
Stap 1 – Creëren en vastleggen
Klantgegevens komen eerst in uw systemen terecht via tickets, monitoring, onboardingformulieren, externe sessies of integraties. U bepaalt zelf wat u verzamelt en hoe het wordt geclassificeerd.
Stap 2 – Gebruiken en delen
Engineers en tools verwerken die gegevens voor ondersteuning, wijziging, monitoring, facturering of rapportage. Toegangscontrole en doelbinding spelen hierbij een rol.
Stap 3 – Bewaren en beschermen
Gegevens bevinden zich in actieve systemen, logs, databases en mailboxen en worden gerepliceerd naar back-ups, archieven en analyses. Er gelden bewaartermijnen en beveiligingsmaatregelen.
Stap 4 – Archiveren en beperken
Live data wordt om juridische of zakelijke redenen ingekort, samengevat of verplaatst naar langetermijnopslag. Wat online overblijft, wordt bewust ingekort.
Stap 5 – Verwijderen of anonimiseren
Informatie die niet langer nodig is, wordt veilig verwijderd of onomkeerbaar geanonimiseerd op primaire en secundaire kopieën, inclusief back-ups en replica's.
Elke stap is gekoppeld aan specifieke ISO 27001-controles en aan specifieke systemen en teams. Wanneer mensen die connectie zien, worden discussies over retentie minder abstract en meer gericht op ontwerp: welke controles zijn van toepassing op welke data, waar in de levenscyclus en met welk soort bewijs.
Zodra u dat mentale model hebt, is de volgende stap om dit om te zetten in een standaard retentiebeleid en -schema voor uw MSP, in plaats van dat elke klant of producteigenaar zijn eigen regels bedenkt.
ISO 27001 eenvoudig gemaakt
Een voorsprong van 81% vanaf dag één
Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.
Hoe kunt u een standaardretentiebeleid en -schema opstellen waarmee uw MSP zich kan verdedigen?
U ontwerpt een verdedigbaar retentiebeleid voor uw MSP door één risicogebaseerd schema te creëren dat alle belangrijke gegevenscategorieën bestrijkt, met behulp van een kleine set standaardtijdsperioden met duidelijke onderbouwingen, en dat schema vervolgens te verpakken in beleid, eigenaarschap en wijzigingsbeheer. Zo krijgt u één verhaal dat u kunt uitleggen aan auditors, klanten en engineers, in plaats van fragiele eenmalige overeenkomsten of tientallen op maat gemaakte regels die in de praktijk onmogelijk consistent te implementeren zijn.
Een verdedigbaar retentiebeleid probeert niet elk randgeval te voorspellen. Het definieert duidelijke standaardregels, gekoppeld aan regelgeving en risico, en biedt u een gestructureerde manier om gerechtvaardigde uitzonderingen af te handelen. Voor een MSP betekent dit dat er een schema en beleid moet worden ontworpen dat meerdere services en clients kan omvatten, maar tegelijkertijd eenvoudig genoeg is om te implementeren en uit te leggen.
Het uitgangspunt is een masterretentieschema. Dit is een enkel intern overzicht van:
- Welke categorieën informatie u bewaart, zoals beveiligingslogboeken, supporttickets, configuratiegegevens, monitoringgegevens, e-mails, contractuele gegevens en back-upimages.
- Het doel van elke categorie en of deze persoonlijke gegevens, gevoelige informatie of gegevens met expliciete wettelijke bewaarplicht bevat.
- De minimale en maximale bewaartermijnen, met de reden daarvoor (wettelijkheid, contract, zakelijke noodzaak, risicobereidheid).
- Wat moet er aan het einde van die periode gebeuren: verwijderen, archiveren in een andere opslag, anonimiseren of samenvatten?
In plaats van honderden op maat gemaakte periodes te bedenken, zijn de meeste MSP's beter af met een kleine set standaardperiodes, zoals dertig dagen, negentig dagen, één jaar, drie jaar, zeven jaar en 'contract einde plus X'. Elke categorie wordt standaard aan een van deze periodes gekoppeld, met gedocumenteerde onderbouwing.
Dit voorbeeld laat zien hoe een kleine set banden aan veel behoeften kan voldoen:
| Categorie | Typische band | Belangrijkste redenatie |
|---|---|---|
| Beveiligingslogboeken | Negentig dagen – één jaar | Detectie- en onderzoeksvensters |
| Ondersteuningstickets | Drie tot zeven jaar | Geschillen en servicegeschiedenis |
| Configuratiegegevens | Contract einde plus één | Herstel en probleemoplossing |
| Back-ups (afbeeldingen) | Negentig dagen – zeven jaar | Herstel en wettelijke verplichtingen |
| Contracten | Zeven jaar of langer | Juridische en financiële administratie |
Dit zijn voorbeelden, geen voorschriften, maar ze illustreren hoe je het aantal banden klein kunt houden en toch aan diverse behoeften kunt voldoen. Het belangrijkste punt is dat elke periode een duidelijk doel heeft en verdedigbaar is.
Van planning naar beleid en eigenaarschap
Je maakt van een retentieschema iets dat je MSP kan uitvoeren door het te omringen met beleid, duidelijke verantwoordelijkheid en eenvoudige workflows voor het overeenkomen en wijzigen van regels. Zonder dat zal zelfs een goed ontworpen schema na verloop van tijd afdrijven en zullen engineers stilletjes terugvallen op "alles bewaren".
Uw bewaar- en verwijderingsbeleid moet:
- Benoem de principes die u hanteert: minimalisatie, doelbinding, beveiliging, naleving van de wet en transparantie voor de klant.
- Verwijs expliciet naar het schema als de definitieve bron voor de bewaartermijnen en beschrijf hoe het schema wordt onderhouden.
- Koppel deze regels aan de ISO 27001-vereisten en andere kaders die u beweert te volgen.
- Zorg voor veilige verwijderingsmethoden en zorg ervoor dat de bewaartermijn alleen via een formeel besluitvormingsproces wordt verlengd.
Even belangrijk is het bepalen wie de eigenaar is van de planning. In veel MSP's is dit een gezamenlijke verantwoordelijkheid, maar iemand moet wel duidelijk verantwoording afleggen.
Je kunt eigendom uitleggen met een eenvoudig overzicht als dit:
| Rol | Primaire verantwoordelijkheid |
|---|---|
| Beveiligings-/complianceleider | Afstemming op normen, wetgeving en risicobereidheid |
| Operationeel leider | Technische implementatie over tools en platforms heen |
| Account-/juridische teams | Commerciële en contractuele impact van retentiekeuzes |
| Leiderschap/bestuur | Goedkeuring van belangrijke wijzigingen en risicoafwegingen |
Wijzigingen in bewaartermijnen of klantspecifieke uitzonderingen moeten een eenvoudige workflow doorlopen: voorstel, impactbeoordeling, risicobeoordeling, goedkeuring, implementatie en bewijs. Een ISMS-platform zoals ISMS.online kan hierbij helpen door het beleid en de planning op te slaan, goedkeuringen te volgen, elke regel te koppelen aan risico's en controles, en een duidelijk audittraject te bieden voor interne en externe auditors.
De rommelige realiteit van ongestructureerde data bestrijken
U dekt de rommelige realiteit van ongestructureerde data af door e-mail, chat, gedeelde schijven en persoonlijke werkruimten te beschouwen als hoogwaardige bronnen in uw bewaartermijn, en niet als bijzaak. Dit betekent dat u eenvoudige regels definieert die uw platforms kunnen afdwingen, engineers en accountteams helpt deze te begrijpen en realistische scenario's test, zodat u kunt uitleggen wat er met ongestructureerde data gebeurt wanneer klanten vertrekken, toezichthouders een onderzoek instellen of personen hun recht op gegevenswissing uitoefenen.
Ongestructureerde data ondermijnen vaak een anderszins overzichtelijke planning. E-mail, chat, gedeelde schijven en persoonlijke werkruimten kunnen grote hoeveelheden klantgegevens bevatten die zelden onder formele bewaartermijnen vallen.
Om uw planning en beleid werkelijk verdedigbaar te maken, moet u:
- Beschouw ongestructureerde opslag als een eersteklas gegevensbron in het schema, en niet als een bijzaak.
- Definieer bewaartermijnen die aansluiten bij de mogelijkheden van de door u gekozen platforms, zoals het bewaren van berichten in samenwerkingshulpmiddelen of het archiveren en vervolgens verwijderen van verouderde e-mails.
- Wees realistisch over wat engineers en accountteams kunnen volgen; te complexe regels op dit gebied worden waarschijnlijk genegeerd.
Voordat u het ontwerp als voltooid verklaart, bekijkt u een aantal realistische scenario's:
- Een vaste klant vertrekt en vraagt u uit te leggen wat er wanneer wordt verwijderd, wat er wordt gearchiveerd en wat u om juridische redenen moet bewaren.
- Een toezichthouder onderzoekt een incident dat een specifieke klant betreft en vraagt zich af hoe ver terug u kunt kijken en waarom.
- Een betrokkene maakt gebruik van het recht op wissen. U moet dan aantonen waar zijn of haar gegevens zich bevinden en wat u ermee hebt gedaan.
Als uw planning en beleid in deze scenario's duidelijke, geloofwaardige antwoorden kunnen opleveren, bent u klaar om het model aan te passen aan de diverse SLA's van klanten zonder dat u de controle verliest.
Duidelijke grenzen zorgen ervoor dat rommelige datagewoonten worden omgezet in beheersbare, controleerbare praktijken.
Hoe past u uw standaardmodel aan op de diverse SLA's van klanten zonder de controle te verliezen?
U past uw standaard retentiemodel aan diverse klant-SLA's aan door een kleine catalogus met vooraf gedefinieerde opties aan te bieden die allemaal aansluiten op uw hoofdschema, in plaats van in elk contract unieke aantallen te onderhandelen. Zo kunnen sales- en accountteams flexibel inspelen op de behoeften van de sector, terwijl operations en security één coherent levenscyclusmodel blijven hanteren. Zo voorkomt u dat u retentie belooft die u realistisch gezien niet kunt waarmaken.
Uit het rapport 'State of Information Security 2025' blijkt dat klanten steeds vaker van leveranciers verwachten dat zij zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG of SOC 2, in plaats van dat zij vertrouwen op algemene goede praktijken.
Met SLA's en contracten voor klanten voldoet uw interne ontwerp aan de externe verwachtingen. Als elke nieuwe deal op maat gemaakte retentiebeloftes oplevert, wordt uw planning al snel onhaalbaar. De oplossing is om uw standaardmodel te presenteren als een klein aantal duidelijke opties en gedeelde verantwoordelijkheden expliciet te maken.
In plaats van de verkoopafdeling of klanten willekeurige aantallen te laten kiezen, kunt u een catalogus maken met retentieopties voor belangrijke service-elementen:
- Voor logs: dertig, negentig of driehonderdvijfenzestig dagen aan online beveiligingslogs, met overeengekomen archiveringsopties.
- Voor back-ups: dagelijkse back-ups gedurende negentig dagen, plus maandelijkse images gedurende twaalf maanden, plus jaarlijkse images gedurende zeven jaar voor gereguleerde klanten.
- Voor ticketgegevens: standaard drie jaar en langere perioden voor sectoren met langere geschilvensters.
- Voor gehoste applicatiegegevens: contractduur plus een korte respijtperiode.
Elke optie sluit naadloos aan op een band in uw planning. Commerciële teams kunnen de afwegingen uitleggen en operationele teams weten precies hoe ze deze moeten implementeren.
Gedeelde verantwoordelijkheden zichtbaar maken
U maakt gedeelde verantwoordelijkheden zichtbaar door duidelijk te maken wie retentie definieert, wie verwijderingen in gang zet en wie juridische blokkeringen kan plaatsen, in plaats van ervan uit te gaan dat iedereen hetzelfde denkmodel hanteert. Duidelijke rollen voor u, uw klanten en eventuele externe leveranciers voorkomen onaangename verrassingen bij offboarding, onderzoeken of audits.
Verantwoordelijkheden voor het bewaren en verwijderen van gegevens worden vaak verondersteld in plaats van vastgelegd. Dat leidt tot frictie wanneer een klant verwacht dat gegevens verdwenen zijn, terwijl u ze nog in back-ups hebt staan, of wanneer ze ervan uitgaan dat u logs langer bewaart dan uw tools.
Met een eenvoudig RACI-model (Responsible, Accountable, Consulted, Informed) kunt u dit voorkomen. Voor elke belangrijke activiteit, zoals het definiëren van een bewaartermijn, het toekennen of weigeren van een verzoek tot verwijdering, het uitvoeren van een eindecontractwissing of het plaatsen van gegevens in de juridische bewaarplicht, kunt u het volgende vermelden:
- Waarvoor u verantwoordelijk bent, zoals het configureren van hulpmiddelen, het maken van back-ups, het uitvoeren van verwijderingstaken en het leveren van bewijs.
- Waar de klant verantwoordelijk voor is, bijvoorbeeld het bepalen hoe lang ze bepaalde gegevens willen bewaren en het schriftelijk opdragen om deze te verwijderen of te bewaren.
- Als de verantwoordelijkheid gedeeld is, bijvoorbeeld als u de capaciteiten levert, maar de klant bepaalt hoe deze worden ingezet.
- Wat externe dienstverleners doen en waar uw verplichting om toezicht op hen te houden, begint en eindigt.
Deze modellen zouden niet alleen in interne documenten moeten voorkomen. Ze zouden moeten worden weerspiegeld in hoofdovereenkomsten voor dienstverlening, SLA's en overeenkomsten voor gegevensverwerking. Duidelijke, standaardformuleringen over de verwerking van gegevens aan het einde van de service, verwijderingstermijnen, migratiehulp en bewijsverwachtingen maken offboarding voorspelbaarder en veel minder controversieel.
U moet ook eerlijk zijn over wat uw platforms wel en niet kunnen. Het beloven van point-in-time herstel voor back-ups gedurende tien jaar, terwijl uw tool en budget er maar drie ondersteunen, is niet alleen een commercieel risico; volgens ISO 27001 is het een probleem van controleontwerp en -effectiviteit.
Klanten helpen bij het kiezen en documenteren van afwegingen
U helpt klanten bij het kiezen van retentieopties en documenteert afwegingen door in begrijpelijke taal uit te leggen wat elk patroon betekent voor onderzoek, privacy, kosten en contractuele risico's. Zo verschuift de discussie van "kies een getal" naar "kies een uitkomst" en krijgt u schriftelijke beslissingen waarnaar u kunt verwijzen bij incidenten, audits en verlengingen.
Klanten komen zelden met een volledig beeld van hun retentiebehoeften. Je voegt echte waarde toe wanneer je hen helpt de implicaties van verschillende keuzes te begrijpen en die beslissingen duidelijk vastlegt, zodat ze niet bij elk incident of elke audit opnieuw aan bod komen.
U kunt goede beslissingen ondersteunen door:
- In heldere taal uitleggen wat de verschillende opties betekenen voor onderzoek, privacy en kosten.
- Klanten helpen om sectorspecifieke vereisten al vroeg in het verkoopproces te verwoorden, zodat u deze in realistische patronen kunt omzetten.
- Het documenteren van gekozen opties en de onderbouwing daarvan, niet alleen de cijfers.
Een klant in de financiële dienstverlening kan bijvoorbeeld kiezen voor een langere bewaartermijn van logs en tickets ter ondersteuning van fraudeonderzoeken, terwijl een klant in de gezondheidstechnologie kan kiezen voor een agressievere verwijdering van bepaalde gegevens om privacyrisico's te beperken. Beide opties passen binnen uw kader als ze bewust, gedocumenteerd en technisch implementeerbaar zijn.
Zodra u die patronen hebt, kunt u uw tools en processen daarop afstemmen. Dat is de volgende stap: ervoor zorgen dat back-up-, logging- en samenwerkingsplatformen daadwerkelijk afdwingen wat uw contracten en beleid nu voorschrijven.
Bevrijd jezelf van een berg spreadsheets
Integreer, breid uit en schaal uw compliance, zonder rommel. IO geeft u de veerkracht en het vertrouwen om veilig te groeien.
Hoe stemt u back-ups, logboeken en gehoste apps af op uw retentiemodel?
U stemt back-ups, logs en gehoste applicaties af op uw retentiemodel door elke invoer in uw planning om te zetten in concrete instellingen, scripts en workflows op de systemen die klantgegevens bevatten, en deze configuraties vervolgens in de loop van de tijd te monitoren. Het doel is dat uw tools de door u gekozen retentiebanden weerspiegelen, niet de standaardwaarden, en dat u deze afstemming kunt aantonen wanneer auditors of klanten ernaar vragen door te laten zien hoe beleid, contracten en ISO 27001-controles zich vertalen naar daadwerkelijke configuraties.
Een schema en een set SLA-patronen hebben weinig zin als de systemen die uw data opslaan iets anders doen. Voor MSP's is het moeilijkste werk vaak het vertalen van het model naar instellingen, scripts en workflows in een diverse toolset.
Back-ups hebben meestal de eerste prioriteit. Historisch gezien behandelden veel MSP's back-upsystemen als opslag die eenmalig geschreven en voor altijd uitgebreid kan worden. Onder ISO 27001 en moderne privacyverwachtingen is dat niet langer houdbaar. Zowel het commentaar van ISO 27001/27002 als discussies over privacystandaarden met betrekking tot dataminimalisatie en opslagbeperking wijzen erop dat onbeperkte back-upbewaring moeilijk te rechtvaardigen is, tenzij er een duidelijke wettelijke of contractuele verplichting is.
U moet voor elke back-updataset het volgende beslissen:
- Hoe vaak u kopieën maakt en met welke nauwkeurigheid.
- Hoeveel versies u bewaart en hoe lang u ze bewaart.
- Wanneer gegevens verlopen of verwijderd zijn uit de primaire en secundaire back-upopslag.
- Of encryptiesleutels vernietigd kunnen worden om oude gegevens ontoegankelijk te maken.
Deze beslissingen moeten worden weerspiegeld in back-upbeleid en niet alleen worden overgelaten aan standaardinstellingen. Ze moeten aansluiten bij de hersteldoelstellingen en wettelijke vereisten, en u moet auditors en klanten kunnen laten zien waar die instellingen zich bevinden en hoe u ze bewaakt.
Logboeken en archieven onder controle krijgen
U krijgt controle over logs en archieven door ze te classificeren, realistische bewaartermijnen in te stellen en uw log- en archieftools te gebruiken om die beslissingen te implementeren en te monitoren. Logs die ooit onschadelijk leken, kunnen een grote bedreiging vormen voor de privacy en opslag als ze voor onbepaalde tijd worden bewaard. Ze moeten daarom volgens hetzelfde schema als al het andere worden bewaard in plaats van op zichzelf te staan.
Logs vormen een veelvoorkomende valkuil. Beveiligingsteams willen vaak lange vensters om te helpen bij het opsporen van bedreigingen en het reageren op incidenten. Privacy- en risicoteams richten zich erop om identificeerbare gegevens niet langer te bewaren dan nodig is. Opslag- en prestatieteams maken zich zorgen over volume en kosten.
De weg hiernaartoe is:
- Classificeer logs op doel en gevoeligheid. Een authenticatielogboek verschilt van een uitgebreide debugtrace.
- Stel bewaartermijnen in die overeenkomen met de tijdsintervallen die u daadwerkelijk nodig hebt voor detectie, onderzoek en naleving, en onderbouw deze beslissingen vervolgens met risicobeoordelingen. Voor sommige MSP's kan dit betekenen dat beveiligingsincidenten enkele maanden duren en dat grote hoeveelheden debuggegevens korter duren.
- Gebruik hulpmiddelen voor logbeheer of beveiligingsinformatie en gebeurtenisbeheer om deze perioden te implementeren en om gegevens samen te vatten of te anonimiseren wanneer gedetailleerde geschiedenis niet langer nodig is.
Archieven, of het nu gaat om post, tickets of afbeeldingen, verdienen ook expliciete aandacht. Archiefsystemen kunnen gemakkelijk een langdurige opslagplaats worden voor gegevens die niemand durft te verwijderen. Om ze in de planning op te nemen, moeten we het volgende definiëren:
- Wat komt in aanmerking om gearchiveerd te worden en wat niet? Wat wordt volledig verwijderd?
- Hoe lang archieven bewaard worden en in welk formaat.
- Hoe archieven worden beschermd en wie er toegang toe heeft.
- Hoe verwijdering of anonimisering eruitziet aan het einde van de levensduur.
Door de antwoorden in uw ISMS vast te leggen en te koppelen aan controles en risico's verlopen de gesprekken met auditors en klanten veel soepeler.
Omgaan met multi-tenant- en cloud-realiteiten
U kunt omgaan met multi-tenant- en cloudrealiteit door logische scheidings- en verwijderingspatronen te ontwerpen die voldoen aan technische beperkingen. Vervolgens legt u deze patronen duidelijk uit in uw contracten en privacyverklaringen. U kunt de gegevens van één klant misschien niet fysiek isoleren op aanvraag, maar u kunt toch aan redelijke verwachtingen voldoen door gebruik te maken van tenant-ID's, encryptie en tijdsgebonden aggregatie.
Veel MSP's leveren diensten op multi-tenant platforms: logaggregators die gebeurtenissen van meerdere clients combineren, back-upsystemen die images naast elkaar opslaan, cloudservices die tenantgegevens co-loceren. Dat roept lastige vragen op wanneer één enkele klant vertrekt of rechten op zijn gegevens uitoefent.
U kunt deze realiteiten als volgt beheren:
- Ontwerp een logische scheiding, zoals tenant-ID's voor logboeken en gegevens, zodat u de informatie van één client kunt filteren en isoleren.
- Het kiezen van verwijderingsbenaderingen die passen bij de beperkingen van meerdere tenants, bijvoorbeeld het vernietigen van sleutels voor versleutelde datasets of het verwijderen van tenant-ID's uit samengevoegde logboeken na een bepaalde periode.
- Zorg dat contracten en privacyverklaringen duidelijk aangeven wat u wel en niet uit gedeelde omgevingen kunt verwijderen.
Het is ook belangrijk om retentiegerelateerde instellingen op te nemen in uw changemanagementproces. Wanneer tools worden geüpgraded of configuraties worden aangepast, moet iemand controleren of log-, back-up- en archiefretentie nog steeds aansluiten op uw planning. Zonder dat kan de moeizaam verworven afstemming na verloop van tijd ongemerkt verwateren.
Zodra uw systemen uw bewaartermijnen weerspiegelen, kunt u op geloofwaardige wijze praten over veilig verwijderen: niet alleen op delete drukken bij een record, maar ervoor zorgen dat de gegevens onherstelbaar zijn wanneer dat nodig is, zonder dat dit ten koste gaat van de beloftes voor herstel.
Hoe kunt u gegevens veilig verwijderen zonder de beloftes voor gegevensherstel te verbreken?
U bereikt veilige verwijdering zonder het herstel te ondermijnen door goedgekeurde methoden te definiëren voor actieve systemen, media en back-ups en deze vervolgens af te stemmen op uw bewaarschema en hersteldoelstellingen. In de praktijk betekent dit meestal het combineren van verwijdering op applicatieniveau, mediasanering en, voor versleutelde back-ups, sleutelvernietiging, met duidelijke regels over wanneer elke methode wordt gebruikt, hoe deze wordt geautoriseerd en hoe u aantoont dat verwijderd ook daadwerkelijk onherstelbaar is.
Veilig verwijderen is voor een MSP niet één enkele tool of techniek; het is een reeks handelingen die er samen voor zorgen dat informatie niet meer kan worden hersteld wanneer de tijd om is, terwijl de mogelijkheid om te herstellen wat klanten rechtmatig van u verwachten, behouden blijft.
De juiste aanpak verschilt per medium en context:
- In live-systemen kunt u records in applicaties en databases verwijderen of anonimiseren volgens uw eigen schema, met controletrajecten.
- Op opslagmedia, door middel van veilig overschrijven, cryptografisch wissen of fysieke vernietiging vóór hergebruik of verwijdering.
- Bij back-ups en replica's kunnen gegevens verlopen op basis van bewaarbeleid of kunnen sleutels worden vernietigd, waardoor oudere gecodeerde sets onleesbaar worden.
Voor elk belangrijk type gegevens en opslag dat u verwerkt, moet u definiëren welke methoden acceptabel zijn, in welke situaties en wie deze mag autoriseren. Deze definities moeten samen met andere operationele procedures in uw ISMS worden opgenomen en waar relevant in contracten worden opgenomen.
Bewijzen dat verwijderd echt verdwenen betekent
U bewijst dat verwijderen echt "weg" betekent door uw processen te testen, de resultaten vast te leggen en te laten zien hoe ze aansluiten op uw bewaartermijnen en wettelijke verplichtingen. Klanten en auditors vragen steeds vaker niet alleen wat uw verwijderingsprocedures zeggen, maar ook of ze werken. Beroepsorganisaties en brancherichtlijnen voor veilige gegevensverwijdering benadrukken niet alleen het hebben van gedocumenteerde procedures, maar ook het verifiëren of verwijdering technisch effectief is in de praktijk, bijvoorbeeld door verwijderingsmethoden te testen op representatieve systemen.
Klanten en accountants vragen zich steeds vaker af wat uw verwijderingsprocedures zeggen, maar ook of ze werken.
U kunt zelfvertrouwen opbouwen door:
- Het uitvoeren van verwijderingstests op representatieve systemen en back-upsets. Bijvoorbeeld het verwijderen van gegevens voor een testrecord, het vervolgens bevestigen van de afwezigheid in applicaties, het rapporteren van opslag en back-ups na de beoogde tijd.
- Aantonen dat back-uprotatie, vervaldatum en sleutelbeheer zich gedragen zoals bedoeld, ook voor onveranderlijke en off-site kopieën.
- Het vastleggen van deze tests, uitkomsten en eventuele corrigerende maatregelen als onderdeel van uw interne auditprogramma.
Het is ook essentieel om juridische bewaarplichten te integreren. Er zullen momenten zijn waarop u de verwijdering voor een specifieke cliënt, persoon of dataset moet pauzeren vanwege rechtszaken, onderzoeken of wettelijke instructies. Uw ISMS, ticketing- en back-upsystemen moeten het volgende ondersteunen:
- Gegevens of klanten markeren als 'in de wacht'.
- Voorkomen dat deze scopes automatisch worden verwijderd terwijl de hold actief is.
- Vastleggen wie de blokkering heeft geautoriseerd, waarom en voor hoe lang.
- Hervatting van normale bewaring en verwijdering zodra de vasthouding eindigt.
Zonder die integratie moeten technici improviseren en kan het zomaar gebeuren dat bewijsmateriaal onbedoeld wordt verwijderd of dat er ongecontroleerd veel langer wordt bewaard dan de bedoeling was.
Ingenieurs praktische begeleiding bieden
U geeft engineers praktische begeleiding door uw bewaar- en verwijderregels om te zetten in duidelijke, systeemspecifieke runbooks en checklists voor veelvoorkomende taken, met name op momenten zoals het offboarden van een klant of het uit bedrijf nemen van een systeem. Zonder die mate van detail worden zelfs goede beleidsregels inconsistent toegepast en kunt u auditors niet gemakkelijk laten zien hoe het werk wordt gedaan.
Beleid en risicobeoordelingen zijn noodzakelijk, maar ze bepalen niet waar een ingenieur op maandagochtend op moet klikken.
Om veilig verwijderen mogelijk te maken, moet u het volgende doen:
- Duidelijke draaiboeken voor veelvoorkomende taken, zoals het buiten gebruik stellen van een server, het wissen van een laptop die wordt gebruikt voor ondersteuning op afstand, het verwijderen van een client van een bewakingsplatform of het verwijderen van een tenant uit een back-upsysteem.
- Hulpmiddelspecifieke richtlijnen, waarbij wordt erkend dat verschillende back-up- of cloudplatforms verschillende mogelijkheden bieden en dat 'verwijderen' niet altijd is wat het lijkt.
- Eenvoudige controlelijsten voor activiteiten aan het einde van het contract, zodat technici precies weten welke stappen ze in alle systemen moeten nemen en hoe ze de voltooiing moeten vastleggen.
Een korte, herhaalbare checklist voor het verwijderen van een contract aan het einde van een contract zou er als volgt uit kunnen zien:
Stap 1 – Identificeer de systemen binnen het bereik
Maak een lijst van alle platforms, back-ups en archieven waarop de gegevens van de klant worden bewaard, inclusief gedeelde en multi-tenant tools.
Stap 2 – Voer de overeengekomen verwijderingen uit
Pas de geconfigureerde verwijderings- of anonimiseringsstappen toe in elk systeem, volgens uw goedgekeurde runbooks.
Stap 3 – Controleer afwezigheid en uitzonderingen
Controleer of de gegevens niet meer in de actieve systemen staan en of alle kopieën duidelijk zijn gedocumenteerd.
Stap 4 – Leg bewijs en goedkeuringen vast
Registreer tickets, rapporten en goedkeuringen, zodat u kunt laten zien wat er is gedaan, wanneer en door wie.
Deze runbooks kunnen in uw ISMS-platform worden opgeslagen, samen met de beleidsregels en het retentieschema die ze ondersteunen. Zo beschikt u, wanneer u een regel bijwerkt of een tool wijzigt, over één centrale plek om het proces te beheren en een duidelijke manier om auditors te laten zien hoe mensen weten wat ze moeten doen.
Nu veilig verwijderen operationeel is, is het zaak om overtuigend en zonder paniek aan te tonen dat uw retentie- en verwijderingsaanpak werkt wanneer klanten of auditors hierom vragen.
Beheer al uw compliance op één plek
ISMS.online ondersteunt meer dan 100 normen en voorschriften, waardoor u één platform krijgt voor al uw compliancebehoeften.
Hoe bewijst u uw retentie- en verwijderingsverhaal aan auditors en klanten?
U bewijst uw retentie- en verwijderingsverhaal door een duidelijke lijn te trekken van intentie naar uitvoering: gedocumenteerd beleid en planningen, gekoppeld aan ISO 27001-controles en klantbeloften, ondersteund door configuraties, tickets en reviews die aantonen dat u doet wat u belooft. Auditors en klanten willen coherentie, openhartigheid en bewijs dat u leert van hiaten, niet een fantasie van perfectie.
Ongeveer 41% van de organisaties die deelnamen aan het ISMS.online-onderzoek uit 2025 gaf aan dat het beheersen van risico's van derden en het bijhouden van de naleving door leveranciers een van hun grootste uitdagingen op het gebied van informatiebeveiliging is.
In ISO 27001 en bij veeleisende klantenaudits wordt zelden van u verwacht dat u perfect bent; u wordt gevraagd systematisch, risicobewust en eerlijk te zijn over zwakke punten. De toelichtingen van ISO zelf beschrijven de norm als een risicogebaseerd managementkader dat is gebaseerd op continue verbetering, in plaats van een eis voor feilloze controleprestaties, wat goed aansluit bij deze verwachting.
Om het verhaal van uw datalevenscyclus te bewijzen, laat u zien dat u een plan hebt, dat u het uitvoert en dat u het controleert en verbetert.
Een goed bewijspakket voor behoud en verwijdering bevat doorgaans:
- Beleid en normen met betrekking tot de levenscyclus van informatie, behoud, verwijdering, back-up en vernietiging.
- Het bewaartermijnschema en eventuele gedocumenteerde uitzonderingen.
- Voorbeelden van systeemconfiguraties met bewaarinstellingen in belangrijke tools.
- Registraties van verzoeken tot verwijdering, activiteiten aan het einde van het contract en vernietiging van media.
- Resultaten van interne tests of audits, met bevindingen en herstelmaatregelen.
Het doel is niet om auditors of klanten te bedelven onder screenshots. Het is bedoeld om een duidelijk overzicht te bieden van de intentie (beleid en risicobeoordeling), via het ontwerp (planning en SLA's), naar de uitvoering (instellingen en tickets) en naar het toezicht (metrieken en reviews).
Maak levenscyclusbeheer zichtbaar binnen uw MSP
U maakt levenscyclusbeheer zichtbaar binnen uw MSP door retentie en verwijdering te behandelen als een doorlopend beheeronderwerp, niet als een pre-audit-chaos. Wanneer leidinggevenden, auditors en klanten levenscyclusstatistieken naast andere beveiligingsindicatoren zien, begrijpen ze dat gegevens gedurende hun hele levenscyclus bij u worden beheerd, niet alleen op het moment van certificering.
U kunt levenscyclusbeheer op de volgende manier in het normale beheerritme brengen:
- Eenvoudige dashboards of rapporten bouwen die laten zien welke systemen zijn afgestemd op het bewaartermijnschema, waar er uitzonderingen zijn en waar acties achterstallig zijn.
- Het bijhouden van een aantal zinvolle KPI's, zoals de tijd die nodig is om verwijderingsverzoeken af te handelen, het percentage systemen met geverifieerde retentie-instellingen of het aantal retentiegerelateerde incidenten. U kunt er bijvoorbeeld naar streven dat meer dan 95% van de systemen in de scope een jaarlijks bevestigde retentieconfiguratie heeft.
- Het opnemen van levenscyclusonderwerpen in managementbeoordelingen naast andere ISO 27001-metrieken, incidenten en controleprestaties.
Hiermee bent u niet alleen beter voorbereid op externe controle, maar kunt u ook gemakkelijker opslag- en gereedschapskosten rechtvaardigen. U kunt het management namelijk precies laten zien welke retentiebeslissingen zij hebben genomen en wat het kost om deze te handhaven.
Het geeft u uw klanten bovendien een sterker verhaal: u behandelt hun gegevens niet als een bijzaak, maar als een beheerd bezit gedurende de hele levensduur ervan bij u.
Hergebruik van bewijsmateriaal en feedback geven op lessen
U vermindert de inspanning en verbetert uw controles wanneer u audits en klantvragen beschouwt als kansen om uw bewijsset en levenscyclusmodel te verfijnen, in plaats van eenmalige klusjes. Hergebruik en feedback zijn de momenten waarop de belofte van continue verbetering van ISO 27001 zichtbaar wordt en u klanten kunt laten zien dat hun feedback uw werkwijze verandert.
Met een zorgvuldig samengestelde set artefacten en rapporten kunt u veel efficiënter reageren op klantvragenlijsten en audits. In plaats van telkens opnieuw materialen te verzamelen, kunt u:
- Geef standaard, geredigeerde voorbeelden van verwijderingstickets, certificaten voor vernietiging van media en configuratie-exporten.
- Loop door uw levenscyclusmodel en planning en laat zien hoe deze van toepassing zijn op de services van die klant.
- Geef aan welke verbeteringen u onlangs heeft doorgevoerd op basis van geleerde lessen, auditbevindingen of feedback van klanten.
Continue verbetering is niet zomaar een slogan in ISO 27001. Het is een echte kracht als klanten zien dat u hun zorgen en wijzigingen in de regelgeving serieus neemt en deze verwerkt in updates van uw controlemechanismen.
Een ISMS-platform zoals ISMS.online kan dit veel eenvoudiger maken door:
- Wij fungeren als centrale plek voor uw beleid, bewaartermijnen, risico's, controleschema's, interne audits en actieplannen.
- Door afzonderlijke bewijsstukken te koppelen aan controles en clausules, kunt u snel gerichte pakketten voor verschillende doelgroepen samenstellen.
- Wij bieden eenvoudige rapportage- en beoordelingshulpmiddelen waarmee u zowel interne als externe belanghebbenden kunt laten zien hoe uw aanpak voor het bewaren en verwijderen van gegevens zich in de loop van de tijd ontwikkelt.
Tegen de tijd dat u dat verhaal helder kunt schetsen, is het verplaatsen van uw processen naar een speciaal ISMS-platform niet langer een luxe, maar een praktische volgende stap om alles op één lijn te houden naarmate u groeit.
Boek vandaag nog een demo met ISMS.online
ISMS.online helpt u bij het omzetten van dataretentie en -verwijdering van een kwetsbare verzameling gewoonten naar één enkel, controleerbaar systeem dat ISO 27001 en veeleisende SLA's van klanten ondersteunt. Wanneer u klaar bent om verder te gaan dan spreadsheets en ad-hoc runbooks, kunt u met een korte demo zien hoe uw huidige werkwijzen zich vertalen naar een levenscyclusmodel dat gemakkelijker te verdedigen is tegenover auditors en klanten.
Binnen het platform kunt u uw informatielevenscyclusbeleid documenteren, uw hoofdretentieschema definiëren en dit koppelen aan Annex A-controles, wettelijke verplichtingen en klantverplichtingen. U kunt eigenaarschap toewijzen, goedkeuringen voor uitzonderingen vastleggen en elke beslissing koppelen aan de risico's en controles die deze beïnvloedt. Met taken en workflows kunt u acties met betrekking tot retentie en verwijdering coördineren binnen de servicedesk, operationele en beveiligingsteams, met duidelijke audit trails in plaats van e-mailketens.
Wanneer klanten of certificeringsinstanties vragen hoe u omgaat met retentie en verwijdering, kunt u gericht bewijs genereren vanuit hetzelfde systeem dat u gebruikt voor uw ISMS, in plaats van te zoeken naar oude screenshots en tickets. Omdat ISMS.online is ontworpen voor doorlopend beheer in plaats van eenmalige certificeringsprojecten, ondersteunt het vanzelfsprekend de beoordelingen en verbeteringen die standaarden en toezichthouders tegenwoordig verwachten rond de levenscyclus van gegevens.
Herkent u uw eigen MSP in het plaatje van ad-hoc retentie, back-ups van "alles bewaren" en zenuwachtige antwoorden tijdens audits? Dan is dit hét moment om actie te ondernemen. Bent u klaar om uw datalevenscyclus te versterken? Kies dan ISMS.online als uw ISMS-platform en boek een korte demo. Zo ziet u hoe snel u uw huidige realiteit in kaart kunt brengen, een retentie- en verwijderingsframework kunt ontwerpen dat past bij uw klantenbestand en er vol vertrouwen mee aan de slag kunt.
Veelgestelde Vragen / FAQ
Hoe moet een MSP het bewaren en verwijderen van gegevens structureren zodat het voldoet aan ISO 27001 en verschillende SLA's van klanten?
Je krijgt de meeste controle en de minste nabewerking als je bouwt één ISO-afgestemd retentiekader binnen uw ISMS, en laat de SLA van de klant vervolgens kiezen uit een kleine set standaardopties die daarop kunnen worden aangesloten.
Begin met één intern retentiemodel
Ontwerp een hoofdretentieschema die uw organisatie bezit en die alle beheerde services omvat:
- Definieer een kleine set van gegevensklassen die in de meeste contracten voorkomen: servicetickets, monitoring- en beveiligingslogs, configuratiegegevens, documentatie, back-ups, e-mail en chat, gedeelde bestanden, contracten en financiële gegevens.
- Kies een beperkt aantal tijdsbanden (bijvoorbeeld 30 / 90 / 365 dagen, drie jaar, zeven jaar, “contract einde plus X”) in plaats van voor elke deal nieuwe periodes te verzinnen.
- Voor elke klasse, documenteer:
- De basis (wet of regelgeving, contract, sectorcode, geschillenvenster of interne risicobeslissing).
- De einde-levensduuractie (verwijderen, anonimiseren, archiveren of onder juridische bewaring plaatsen).
Wanneer dit schema in uw Information Security Management System (ISMS) wordt geïntegreerd, sluit het op natuurlijke wijze aan bij de focus van ISO 27001 op context, verplichtingen, risico en controle. Bovendien is het veel gemakkelijker te verdedigen tegenover auditors en klanten.
Bied SLA-patronen aan in plaats van eenmalige beloften
Stel dat schema aan klanten voor als een kort menu van SLA-patronen, in plaats van maatwerk in elk contract. Bijvoorbeeld:
- “Beveiligingslogs – standaard” → 12 maanden online, 12 maanden archief.
- “Beveiligingslogboeken – uitgebreid” → in totaal drie jaar voor gereguleerde sectoren.
- “Back-ups – operationeel” → 30-daags rollend plus maandelijks gedurende 12 maanden.
- “Back-ups – naleving” → zeven jaar bewaartermijn voor financiële gegevens.
Uw SLA's en gegevensverwerkingsovereenkomsten dan Verwijs naar deze patronen bij naam, met een uitzonderingsproces waar specifieke wet- of regelgeving iets anders vereist. Ingenieurs, sales- en juridische teams praten allemaal over dezelfde patronen in plaats van het herhalen van regels in e-mailthreads.
Als u de catalogus en goedkeuringen beheert in een platform zoals ISMS.online, kunt u de planning, toewijzingen en beslissingen live weergeven tijdens audits en aanbestedingen. Hierdoor verandert de vraag "hoe lang bewaren jullie onze data?" vaak van een zenuwachtige vraag in een bewijs dat uw ISMS gestructureerd en volwassen is.
Maak verantwoordelijkheden en afwegingen expliciet
Gebruik contracten, beveiligingsschema's en privacyverklaringen om een eenvoudig probleem op te lossen model van gedeelde verantwoordelijkheid:
- Wie selecteert het patroon voor elke service en gegevensklasse?
- Wie kan een verzoek tot verwijdering, export of juridische bewaring indienen en hoe worden deze verzoeken geverifieerd?
- Wie welke controles op elk platform uitvoert (u, de klant, of een externe leverancier).
- Hoe u omgaat met situaties waarin wettelijke plichten vereisen een langere bewaartermijn dan een voorkeur van de klant.
Die helderheid helpt uw accountteams om onder druk niet te veel te beloven en geeft u een helder overzicht van de ISO 27001-clausules over context (4), leiderschap (5) en planning (6). Wanneer alles in uw ISMS is vastgelegd, kunt u auditors en klanten verwijzen naar hetzelfde consistente raamwerk in plaats van beslissingen uit het geheugen te reconstrueren.
Welke ISO 27001:2022-clausules en bijlage A-beheersmaatregelen zijn het belangrijkst voor het bewaren en verwijderen van MSP-gegevens?
Voor een MSP bevinden behoud en verwijdering zich op de plaats waar context, risico, operaties en bewijs voldoen. Een strak samenspel van ISO 27001-clausules en Annex A-controles geeft u de ontwerpopdracht voor uw informatielevenscyclus.
Veranker uw aanpak in de kernzinnen
Uw model voor het bewaren en verwijderen van gegevens moet duidelijk terug te voeren zijn op de volgende clausules:
- Artikel 4 – Context van de organisatie: je hebt geïdentificeerd welke wetten, toezichthouders, contracten en sectornormen bepalen hoe lang u specifieke gegevens bewaart en hoe dat per rechtsgebied verschilt.
- Artikel 5 – Leiderschap: het management heeft een enkelvoudig retentiemodel, in plaats van beslissingen over te laten aan individuele verkoopovereenkomsten.
- Artikel 6 – Planning: behoud en verwijdering verschijnen in uw risicobeoordeling en risicobehandelingsplan, met inbegrip van spanningen tussen wettelijke taken, verwachtingen van de klant en operationele kosten.
- Artikel 8 – Werking: Procedures voor provisioning, logging, backup, support en offboarding verwijzen allemaal naar hetzelfde hoofdschema, zodat medewerkers geen ad-hoc beslissingen hoeven te nemen.
- Artikel 9 – Prestatiebeoordeling: U controleert of het schema en de controles nog steeds passend zijn en of deze worden nageleefd.
- Artikel 10 – Verbetering: Incidenten, klachten of auditbevindingen rondom overmatige retentie of mislukte verwijdering leiden tot meetbare wijzigingen in uw controles.
Als uw planning, procedures en risicoregister expliciet verwijzen naar deze clausules in uw ISMS, kunnen auditors zien dat het bewaren en verwijderen van gegevens deel uitmaakt van het systeem en niet aan de randen is toegevoegd.
Gebruik Bijlage A als praktische checklist
Een handvol Bijlage A 2022 controles dragen het grootste gewicht voor MSP's:
- A.5.32 – Bescherming van gegevens: welke gegevens u moet bewaren, hoe lang u ze moet bewaren en hoe u ze moet beschermen en opvragen.
- A.8.10 – Verwijdering van informatie: ervoor zorgen dat informatie wordt verwijderd of onomkeerbaar geanonimiseerd wanneer u deze niet langer nodig hebt.
- A.8.13 – Informatie back-up: Back-ups volgen gedocumenteerde bewaar- en herstelregels in plaats van 'alles voor altijd bewaren'.
- A.7.14 – Veilige verwijdering of hergebruik van apparatuur: het ontsmetten en vernietigen van schijven, tapes en apparaten waarop klantgegevens staan.
- A.8.15 – Loggen: en A.8.16 – Monitoring: hoe lang de boomstammen bewaard worden, hoe ze geroteerd worden en wanneer ze verwijderd worden.
Een eenvoudige manier om dit te operationaliseren is om annoteer uw bewaartermijnen en -procedures met deze controle-ID's, bewaar dan eenvoudig bewijs: de planning zelf, exporten van belangrijke configuraties, vernietigingscertificaten en reviewnotities. Door dit in een ISMS-platform zoals ISMS.online onder te brengen, kan dezelfde mapping worden gebruikt voor interne audits, ISO-certificering en veeleisende klantbeoordelingen, zonder dat u het elke keer opnieuw hoeft op te bouwen.
Hoe kan een MSP een realistisch schema voor gegevensretentie opstellen dat voor meerdere klanten en rechtsgebieden werkt?
Schema's die op MSP-schaal standhouden, beginnen vanaf wat u al bedient, en voeg daar vervolgens wetgeving, contracten en risico's aan toe totdat u een compacte structuur hebt die uw teams dagelijks kunnen runnen.
Breng eerst uw echte datalandschap in kaart
Begin met het opsommen van wat u daadwerkelijk voor een typische klant afhandelt:
- De oplossingen U beheert: servicedesk, hulpmiddelen voor bewaking en beheer op afstand, beveiligings- en prestatiebewaking, documentatiewiki's, wachtwoordkluizen, cloudportals, e-mail- en samenwerkingssuites, bestandsopslag, back-up- en DR-platformen en alle services van derden die u beheert.
- De ingangen die retentie bevorderen: klantcontracten en SLA's, sectorvereisten (bijvoorbeeld financiën, gezondheidszorg, publieke sector), privacyverplichtingen zoals AVG of CCPA en gebruikelijke geschil- of verjaringstermijnen in de landen waarin u actief bent.
- logisch gegevensklassen die zich herhalen voor meerdere clients: beveiligingslogboeken, operationele telemetrie, incidenttickets, configuratierecords, runbooks en documentatie, financiële documenten, onbewerkte back-ups, e-mail, chat en ongestructureerde bestanden.
Dit geeft je een concrete basis. Je ontwerpt niet in theorie; je bepaalt wat er gebeurt met specifieke gegevensklassen die je dagelijks ziet.
Comprimeer complexiteit in een kleine bibliotheek met tijdsbanden
Definieer vervolgens een beperkte set tijdsbanden die u aan klanten, toezichthouders en ingenieurs kunt uitleggen:
- Korte banden (bijvoorbeeld 7 / 30 / 90 dagen) voor ruisende telemetrie en tijdelijke diagnostische gegevens.
- Middellange termijnen (bijvoorbeeld één of drie jaar) afgestemd op serviceverplichtingen, contractvoorwaarden en typische geschilperiodes.
- Lange perioden (bijvoorbeeld zeven jaar) voor belastinggegevens of gegevens waarvoor een wettelijke bewaarplicht geldt.
- Relatieve banden zoals 'contract einde plus 6/12/24 maanden' voor huurderspecifieke inhoud en configuratie.
Voor elke gegevensklasse:
- Bepaal uw minimale retentie waar de wet of regelgeving een grens stelt.
- Kies een standaard periode die u in de meeste contracten zult voorstellen.
- Leg een vast rechtvaardiging in gewone taal met verwijzing naar specifieke regelgeving, sectorcodes, contracten of interne risicobeslissingen.
- Definieer de eindtoestand: verwijderen, anonimiseren, archiveren of onder juridische bewaring houden.
U kunt dit doorgaans in één tabel uitdrukken: 'gegevensklasse → retentieband → basis → actie aan het einde van de levensduur'. Wanneer die tabel in uw ISMS staat en is gekoppeld aan beleid, procedures en SLA-sjablonen, hoeven uw teams niet meer vanaf nul te onderhandelen en hebt u een verdedigbaar, ISO-conform verhaal, ongeacht of de klant zich in Manchester, Dublin of Sydney bevindt.
Een ISMS-platform als ISMS.online helpt u hierbij. Het biedt u één plek waar u de tabel, goedkeuringen en bewijsstukken kunt beheren en hetzelfde patroon kunt hergebruiken in alle ISO 27001, ISO 27701, SOC 2, NIS 2 en andere raamwerken.
Hoe kunnen MSP's tijdens ISO-audits en klantbeoordelingen aantonen dat ze gegevens, inclusief back-ups en logs, op een robuuste manier verwijderen?
Auditors en klanten willen zien dat u weet hoe 'goed' eruitziet en dat er een herhaalbaar spoor is dat aantoont dat het daadwerkelijk gebeurt. Dat doe je door je ontwerp zichtbaar te maken en te ondersteunen met alledaagse artefacten.
Zorg ervoor dat uw verwijderingsontwerp gemakkelijk te volgen is
Definieer uw verwachtingen in een taal die niet-specialisten kunnen begrijpen:
- Geschreven procedures voor het verwijderen en vernietigen van gegevens, met verwijzing naar uw bewaartermijnschema en de controlemaatregelen in Bijlage A, zoals A.8.10 (verwijdering) en A.7.14 (vernietiging van media).
- Einde-van-de-service-runbooks: waarin wordt beschreven wat er gebeurt met tickets, configuratie, toegang, documentatie, logboeken en back-ups wanneer u een klant uit het team verwijdert.
- Normen voor mediaverwerking: voor schijven, banden en andere media, inclusief de gevallen waarin leveranciers vernietigingscertificaten moeten overleggen.
- Transparant back-up- en logboekbewaarregels die laten zien hoe lang gegevens online blijven, hoe lang ze in het archief blijven en wanneer systemen verlopen of gegevens verwijderen.
Wanneer deze documenten samen in uw ISMS staan, kunt u reviewers begeleiden van het algemene beleid naar de stapsgewijze procedure en uiteindelijk naar de specifieke systeeminstellingen, zonder dat u door verspreide mappen hoeft te spitten.
Onderbouw het ontwerp met live operationeel bewijs
Verzamel een kleine set artefacten die de bedieningselementen in actie laten zien:
- ITSM-tickets of workflowrecords: die offboarding- en verwijderingsgebeurtenissen weergeven, met goedkeuringen, tijdstempels en verantwoordelijke teams.
- Rapporten en logboeken: van back-upplatforms, SIEM, opslagsystemen en cloudtenants die bevestigen dat vervaltaken, bewaarbeleid en verwijderingstaken zijn uitgevoerd.
- Vernietigingscertificaten: gekoppeld aan specifieke serienummers of activa-ID's, die laten zien hoe fysieke media zijn gereinigd of vernietigd.
- Configuratie-exporten of schermafbeeldingen: van bewaar- en vervalinstellingen in belangrijke platforms, zoals back-uptaken, hulpprogramma's voor logboekbeheer, regels voor e-mailbewaring en samenwerkingssuites.
- Uitvoer van periodieke tests, zoals het herstellen van de oudste back-up die u claimt te hebben, of het valideren dat gegevens buiten de bewaartermijn daadwerkelijk niet beschikbaar zijn.
Wanneer u afhankelijk bent van onveranderlijke back-ups of langetermijnarchieven van logs, documenteer dan de onderbouwing hiervan, zoals fraudeonderzoeken of sectorrichtlijnen, en registreer compenserende maatregelen, zoals sterke encryptie, beperkte toegang en speciale processen voor het bewaren van juridische gegevens.
Veel MSP's bundelen deze in een standaard bewijspakket Bijgehouden op een ISMS-platform zoals ISMS.online, zodat hetzelfde samengestelde materiaal gebruikt kan worden voor ISO-audits, klantonderzoeksvragenlijsten en verlengingsbeoordelingen. Dit verkort de voorbereidingstijd en laat zien dat u verwijdering als een gecontroleerd proces beschouwt, niet als een eenmalige klus.
Hoe moeten MSP's omgaan met conflicten tussen SLA's van klanten, wettelijke bewaarplichten en het risicogebaseerde model van ISO 27001?
Spanningen tussen wat een klant wil, wat de wet eist en wat goede beveiliging inhoudt zal vroeg of laat aan de oppervlakte komen. De veiligste manier is om een eenvoudige, gedocumenteerde hiërarchie toe te passen en je redenering vast te leggen in het ISMS.
Pas een duidelijke hiërarchie van voorrang toe
Wees het er intern over eens en geef vervolgens duidelijk aan dat uw beslissingen de volgende volgorde volgen:
- Wet en regelgeving – inclusief richtlijnen van toezichthouders en sectorregels.
- Contracten en SLA's – inclusief gegevensverwerkingsovereenkomsten en beveiligingsschema’s.
- Gedocumenteerde risicobehandelingsbeslissingen – het in evenwicht brengen van veiligheid, privacy en zakelijke behoeften.
Wanneer een klant om een zeer korte bewaartermijn of onmiddellijke verwijdering vraagt die in strijd is met belastingregels, registratieverwachtingen of wettelijke codes, kunt u het volgende doen:
- Leg uit dat je kan niet buiten de wet een contract sluiten, dus wettelijke plichten hebben voorrang op contractuele voorkeuren.
- Bied de meest compatibele patroon van uw standaard bewaartermijnen, zoals een kortere online bewaartermijn met een langer gecodeerd archief.
- Neem de discussie, uw beslissing en eventuele andere opmerkingen op. compenserende maatregelen zoals strengere toegangscontroles, encryptie, beperkte omvang van de gegevens of extra monitoring.
Als u dit consequent doet, voorkomt u dat verkoopgesprekken verplichtingen creëren waaraan uw operationele of juridische teams later niet meer met zekerheid kunnen voldoen.
Behandel deze beslissingen als onderdeel van het ISMS
Volgens ISO 27001 moet u deze conflicten binnen het systeem oplossen, en niet als bijzaak:
- Leg ze vast als risico's Geef in uw risicobeoordeling aan wanneer u gegevens langer moet bewaren dan sommige belanghebbenden willen, of wanneer u om commerciële redenen bewust genoegen neemt met een kortere bewaartermijn.
- Breng deze risico's en behandelingen in kaart met relevante Bijlage A-controles in uw Verklaring van Toepasselijkheid, zodat uw onderbouwing zichtbaar is bij audits.
- Definiëren beoordelingstriggers zoals nieuwe regelgeving, toetreding tot nieuwe sectoren of belangrijke technologische veranderingen. Zo kunt u laten zien dat uw standpunt herzien wordt en niet voor onbepaalde tijd vastligt.
- Train sales-, juridische en accountmanagers in deze hiërarchie, zodat ze het op een eenvoudige manier kunnen uitleggen en kunnen voorkomen dat er beloftes worden gedaan die uw ISMS ondermijnen.
Als u de risico's, beslissingen en ondersteunende documenten vastlegt op een ISMS-platform zoals ISMS.online, kunt u vragen van toezichthouders, auditvragen of uitdagingen van klanten beantwoorden met een goed onderbouwde positie in plaats van dat u door historische e-mailketens moet spitten.
Welke processen en controles helpen MSP's bij het automatiseren en aantonen van de verwijdering van gegevens aan het einde van het contract?
Aan het einde van het contract verstoppen vergeten kopieën zich vaak: testhuurders, oude back-ups, verweesde accounts of documentatie in persoonlijke archieven. standaard offboarding-playbook, doordachte automatisering en gedegen registraties houden dat onder controle en maken het eenvoudig om aan derden te demonstreren.
Voer één enkel offboarding-draaiboek uit voor alle klanten
Creëer er een offboarding-runbook die elke klant volgt, stem dit dan per dienst af:
- Begin met een hoofdlijst van systemen en opslaglocaties die u kunt beheren: servicedesk, RMM, bewakingshulpmiddelen, documentatieplatforms, wachtwoordkluizen, back-up- en DR-systemen, cloudtenants, e-mail- en samenwerkingshulpmiddelen, gedeelde schijven, apparaatbeheer en services van derden.
- Geef voor elke categorie de stappen aan: toegang intrekken of overdragen, overeengekomen gegevens exporteren, het juiste bewaarbeleid toepassen, verwijdering of anonimisering plannen en controleren op juridische beperkingen of openstaande geschillen.
- Toewijzen duidelijk eigendom Elke stap heeft dus een intern team of een leverancier die bij naam genoemd wordt.
Bouw dit runbook in uw ITSM- of ISMS-tool als een gestructureerde workflow of checklist, waardoor offboarding een voorspelbare reeks wordt in plaats van een geïmproviseerde klus die afhankelijk is van wie welk systeem kent.
Automatiseer herhaalbare acties en sluit af met een schoon verslag
Gebruik platformmogelijkheden en scripts om handmatige inspanningen en fouten te beperken:
- Binden accountuitschakeling en gegevensverval om einddata te contracteren waar tools dit ondersteunen.
- Centraal toepassen retentielabels en -beleid voor e-mail, chat en bestandsopslag, zodat gegevens volgens uw schema verouderen, zonder dat u er zelf iets aan hoeft te doen.
- Voer bulkacties uit via API's voor taken zoals het laten verlopen van back-uptaken, het opschonen van tenants of het verwijderen van oude configuraties, waar dat efficiënt en veilig is.
Rond elke offboarding af met een beknopte samenvatting record, vaak een ticket, waarop het volgende staat:
- Wat is er verwijderd of geanonimiseerd, in welke systemen en op welke data?
- Wat werd bewaard, hoe lang en op welke wettelijke of contractuele basis.
- Links of bijlagen naar rapporten, logboeken, schermafbeeldingen en vernietigingscertificaten.
- Elke uitzonderingen of beperkingen, met kruisverwijzingen naar uw bewaartermijnen en risico-register.
Door het runbook, de workflows en de registraties bij elkaar te houden in een ISMS-platform zoals ISMS.online, krijgt u een duidelijk antwoord wanneer een voormalige klant vraagt: "Wat is er met onze data gebeurd?", en het biedt auditors een herhaalbaar patroon dat aansluit bij de verwachtingen van ISO 27001 op het gebied van werking, prestatie-evaluatie en -verbetering. Het onderscheidt u ook op een subtiele manier van MSP's die nog steeds vertrouwen op ad-hoc spreadsheets en tribale kennis wanneer klanten vertrekken.
