Een goede back-up is je laatste verdedigingslinie als ransomware toeslaat. Voor een mkb in Nederland betekent dat vandaag de dag drie dingen: drie kopieën van je data, op twee verschillende media, waarvan één offsite én immutable. In dit artikel lees je hoe je de 3-2-1 regel stap voor stap inricht, wat immutable opslag precies doet, en hoe je binnen 24 uur test of je herstel écht werkt. Geen marketingverhaal, een concrete checklist die je morgen kunt oppakken.
Waarom is de 3-2-1 regel voor het mkb geen optie meer?
De 3-2-1 regel bestaat al sinds 2007 in de informatiebeveiliging, maar veel mkb-bedrijven vullen hem in de praktijk nog te losjes in. Drie kopieën van je data, op twee verschillende soorten media, één kopie offsite. Het klinkt simpel, maar de meeste mkb-omgevingen die wij zien hebben twee kopieën op dezelfde NAS, of drie kopieën op één cloudprovider. Dat is geen 3-2-1, dat is 1-1-1 in een dun jasje.
De cijfers liegen niet. Volgens het NCSC Nederland is ransomware al jaren de meest voorkomende aanval op het Nederlandse bedrijfsleven, en in 2025 is het aantal meldingen bij mkb doelwitten opnieuw gestegen. Het Digital Trust Center (DTC), onderdeel van het ministerie van Economische Zaken, schat dat één op de vijf mkb-bedrijven na een geslaagde ransomware-aanval binnen twee jaar failliet gaat. De combinatie van losgeld, uitval van productie, en reputatieschade is voor een mkb vaak niet te overzien.
NIS2 maakt de druk groter. De Europese NIS2-richtlijn is in Nederland vertaald naar de Cyberbeveiligingswet, en sinds 2026 vallen ook middelgrote bedrijven in meer sectoren onder het toezicht. Een van de kernverplichtingen is dat je aantoonbaar passende technische maatregelen neemt, inclusief back-up en herstel. Voor ISO 27001 geldt hetzelfde, alleen daar heet de control in Annex A iets anders. Wie vandaag zijn back-ups niet op orde heeft, krijgt dat bij een audit of een incident dubbel en dwars terug.
Wat is een immutable backup, en waarom werkt het tegen ransomware?
Een immutable backup is een back-up die je na het schrijven niet meer wijzigt of verwijdert, gedurende een vooraf ingestelde periode. Er zijn drie technische opties die dat mogelijk maken. De eerste is write-once-read-many (WORM) opslag in object storage, denk aan AWS S3 Object Lock of Azure Blob Immutable Blob. De tweede is air-gapped tapes die fysiek los van het netwerk staan. De derde is een dedicated immutable appliance die via cryptografische hashes vastlegt dat een set bestanden op tijdstip X niet meer aangepast mag worden.
De reden dat dit werkt tegen ransomware is simpel. Traditionele back-ups die op een gemounte netwerkshare staan, versleutelen of verwijderen moderne ransomware-varianten binnen enkele minuten. Daarom gaan aanvallers tegenwoordig eerst op zoek naar back-up credentials en mount-points, vóór ze de productieservers aanvallen. Als jouw back-up immutable is opgeslagen, kan de aanvaller die wel zien maar niet aanraken. De restore werkt, je bedrijf staat weer, het losgeld hoeft niet betaald te worden.
Een vaak gehoorde tegenwerping is dat immutable opslag duur of complex zou zijn. Dat valt in de praktijk mee. Een S3 bucket met Object Lock in combinatie met een korte retention policy van 30 dagen kost enkele tientallen euro’s per maand voor een mkb dataset. Er zijn ook Nederlandse aanbieders die immutable back-up als dienst leveren, inclusief het beheer van de retentieperiodes. De CISA Stop Ransomware Guide, opgesteld samen met het NCSC-UK, de NSA en andere partners, noemt immutable back-ups expliciet als één van de drie minimale maatregelen die elke organisatie zou moeten nemen.
3-2-1 voor het mkb: zo richt je het stap voor stap in
De volgende stappen werken voor een typisch mkb met 50 tot 200 medewerkers, een file server, een paar applicatieservers, en data in SaaS-diensten. De tijdsinvestering is ongeveer twee tot drie dagen werk, verdeeld over een week.
Stap één is inventariseren. Breng in kaart welke data je hebt, waar die staat, en wat het ergste is dat kan gebeuren als je die data verliest. Onderscheid daarbij drie categorieën: bedrijfskritisch (klantdata, financiële administratie, productiedata), operationeel (interne documentatie, e-mailarchief), en archiveerbaar (oude projecten, logbestanden). Alleen de eerste twee categorieën hoeven in een 3-2-1 schema te zitten. De rest mag best een keer verloren gaan.
Stap twee is de drie kopieën. Kopie één is je productiedata, die op je eigen opslag staat en waarmee je dagelijks werkt. Kopie twee is een lokale back-up op een ander medium, bijvoorbeeld een tweede NAS of een USB-schijf die je alleen tijdens het back-upvenster aansluit. Kopie drie is de offsite kopie, bij voorkeur in een cloud object store met Object Lock ingeschakeld, of tapes die je fysiek naar een andere locatie brengt. Wat je ook kiest, zorg dat de drie kopieën fysiek van elkaar gescheiden zijn en niet allemaal op dezelfde infrastructuur draaien.
Stap drie is de immutable laag. Zet op minimaal één van de drie kopieën een onwijzigbaarheidsslot. In de praktijk betekent dat een retention policy van minimaal 30 dagen op je cloud back-up, of een tape-rotatieschema waarbij je de oudste tapes pas na een maand overschrijft. Voor ISO 27001 en NIS2 is het belangrijk dat je deze instellingen ook aantoont. Een dashboard of rapportage dat laat zien welke back-up immutable is en tot wanneer, is daarbij onmisbaar. De vulnerability management aanpak voor het mkb van NetCaptain werkt volgens hetzelfde principe: je wilt niet één momentopname, je wilt een doorlopende controle. Wie die combinatie van scans, monitoring, en een robuust back-up schema inzet, dekt het overgrote deel van de operationele cyberrisicos af waar een mkb mee te maken krijgt.
Stap vier is het automatiseren van het schema. Handmatig wisselen van tapes of USB-schijven is foutgevoelig. Gebruik een back-uptool die het hele schema zelf afhandelt, inclusief retentie en verificatie. In de praktijk kom je dan uit bij oplossingen als Veeam, Nakivo, of de ingebouwde mogelijkheden van Microsoft 365 back-up. Voor cloud-native back-up van SaaS-data is een aparte oplossing nodig, omdat de meeste SaaS-providers zelf geen complete restore van data van enkele weken oud aanbieden.
Herstel testen binnen 24 uur: hoe je dat organiseert
Een back-up die je nog nooit getest hebt, is geen back-up. Het is een bestand dat op een goede dag blijkt onleesbaar te zijn. Daarom is het testen van herstel net zo belangrijk als het maken van de back-up zelf. In de praktijk zien we dat mkb-bedrijven die hun herstel testen, hun downtime na een incident met een factor drie tot vijf weten te beperken ten opzichte van bedrijven die dat niet doen.
De norm die je kunt aanhouden is dat je elk kwartaal een volledige hersteltest doet, en dat je binnen 24 uur een kritisch systeem kunt terugzetten naar een werkende staat. Dat betekent niet dat je binnen 24 uur je hele bedrijf draaiend hebt, wel dat je de kernprocessen kunt opstarten. Het NIST SP 800-34 Rev. 1 (Guide for Cybersecurity Event Recovery) beschrijft hoe je dit soort Recovery Time Objectives (RTO) en Recovery Point Objectives (RPO) onderbouwt en meet.
De test zelf hoeft niet ingewikkeld te zijn. Kies één kritisch systeem, bijvoorbeeld je financiële administratie of je klantdatabase. Verwijder de productie-versie, restore vanuit je immutable back-up, en kijk of de applicatie normaal werkt met de herstelde data. Noteer de tijd die het hele proces kost, de stappen die je moest ondernemen, en de problemen die je onderweg tegenkwam. Die notitie is je runbook, en die heb je nodig als het écht misgaat.
Een praktische tip die we vaak geven: wissel per kwartaal van systeem. De ene keer test je de financiële administratie, de andere keer je CRM, dan je file server, dan een specifieke applicatieserver. Zo bouw je in een jaar tijd ervaring op met alle kritieke systemen, en weet je precies welke het langst duren om te herstellen. Die kennis is goud waard op het moment dat de druk hoog is. ENISA’s Threat Landscape Ransomware rapport bevestigt dat organisaties die regelmatig oefenen significant sneller herstellen dan organisaties die pas tijdens een incident voor het eerst een restore proberen.
De vijf fouten die wij het vaakst zien bij mkb-back-ups
Fout één: alle back-ups op dezelfde infrastructuur. De productieserver, de NAS, en de cloud back-up draaien allemaal op dezelfde hypervisor of dezelfde cloud account. Als een aanvaller met admin-rechten die ene omgeving raakt, ben je alles kwijt. Spreid bewust over verschillende leveranciers of verschillende accounts.
Fout twee: de back-up wel versleutelen, maar de sleutel op dezelfde plek bewaren. Het komt nog steeds voor dat de encryptiesleutel van de back-up op een USB-stick in dezelfde kluis ligt als de back-up zelf, of erger, in dezelfde map op dezelfde server. Bij ransomware met maandenlange dwell time is dat een uitnodiging. Bewaar de sleutel offline, op een andere fysieke locatie, en test regelmatig of je er nog bij kunt.
Fout drie: geen monitoring op de back-up zelf. Een back-up die al twee weken niet meer draait, levert geen waarschuwing op. In plaats daarvan kom je er pas achter als je de restore nodig hebt. Zet alerts aan op mislukte jobs, en laat iemand in je team daar dagelijks naar kijken. Voor mkb-bedrijven kan dat ook een MSP of een dienstverlener zijn, zolang er maar iemand eigenaar is van die controle.
Fout vier: de cloud back-up vergeten. Veel mkb-data staat tegenwoordig in Microsoft 365, Google Workspace, of een SaaS-applicatie. De provider zelf bewaart die data niet oneindig, en een verwijderd bestand is na een paar weken echt weg. Een aparte SaaS back-up, met immutable opslag als doel, is geen luxe meer maar een standaard onderdeel van het 3-2-1 schema.
Fout vijf: denken dat een keer per jaar testen voldoende is. In een jaar kan er veel veranderen in je IT-landschap. Nieuwe servers, een andere SaaS-leverancier, een overstap naar een nieuwe cloud. Als je alleen in januari test, weet je in december niet meer of je schema nog werkt. Eén keer per kwartaal is het minimum, en voor aantoonbare security richting auditors en verzekeraars is dat ook de norm die zij hanteren.
Wat kun je morgen al doen: een korte checklist?
De volgende vier acties passen in een middag werk, en geven je al een flinke stap richting een volwassen 3-2-1 back-up strategie. Begin met inventariseren welke data je écht niet kunt missen, en waar die nu staat. Zet daarna een immutable back-up op voor die data, met een retention van minimaal 30 dagen. Test tot slot of je restore binnen 24 uur lukt, en leg vast wie dat in een echt incident zou doen.
Voor de langere termijn is het zinvol om dit onderdeel te maken van je bredere cybersecurity-aanpak. NIS2 vraagt om aantoonbare maatregelen, ISO 27001 vraagt om een Information Security Management System, en cyberverzekeraars vragen steeds vaker om bewijs van werkende back-ups. Een volwassen back-up strategie is dus niet alleen een technische maatregel, het is een stukje NIS2-compliance dat je in één keer goed kunt regelen.
Wil je sparren over hoe je dit in jouw organisatie aanpakt, of wil je een second opinion op je huidige back-up schema? Een vrijblijvend kennismakingsgesprek met een NetCaptain-expert duurt 30 minuten, en levert je meestal twee of drie concrete aandachtspunten op waar je direct mee aan de slag kunt. Voor een eerste indicatie van waar je nu staat, is er de gratis CyberScan, een korte online vragenlijst die je in vijf minuten invult.
Veelgestelde vragen over 3-2-1 back-ups voor het mkb
Wat is het verschil tussen 3-2-1 en 3-2-1-1-0?
Het klassieke 3-2-1 schema is drie kopieën, op twee media, één offsite. De toevoegingen die je steeds vaker ziet, de 1 en de 0, staan voor: één immutable kopie, en nul fouten na verificatie. Voor de meeste mkb-bedrijven is de stap van 3-2-1 naar 3-2-1-1-0 voldoende, en die extra 1-0 maakt je schema pas echt robuust tegen moderne ransomware.
Hoeveel kost een goede immutable back-up voor een mkb?
Voor een mkb met 50 tot 200 medewerkers en een paar terabytes aan data mag je rekenen op een vast maandbedrag in de ordegrootte van honderd tot enkele honderden euro’s, inclusief cloud object storage met Object Lock. Dat is een fractie van wat een ransomware-incident kost, en je kunt het opnemen als vaste security-uitgave. De exacte prijs hangt af van de hoeveelheid data, de retentieperiode, en of je kiest voor self-hosting of een managed dienst.
Kan ik mijn bestaande back-up immutable maken zonder alles opnieuw op te zetten?
Ja, in de meeste gevallen wel. De meeste moderne back-upsoftware ondersteunt het schrijven naar S3-compatible object storage met Object Lock, en dat is een kwestie van een nieuwe opslaglocatie toevoegen aan je bestaande job. De data migreren kost wat tijd, maar de aanpassing in de software is een middag werk.
Moet ik ook een back-up maken van mijn cloud data, zoals Microsoft 365?
Ja, absoluut. Microsoft bewaart verwijderde data in Microsoft 365 standaard maar 30 tot 90 dagen, en daarna is het echt weg. Voor data die je langer wilt bewaren, of waarvan je een aparte immutable kopie wilt, heb je een derde partij nodig die specifiek SaaS back-ups aanbiedt. Dat is een apart budget, maar essentieel voor een volledig 3-2-1 schema.
Hoe vaak moet ik mijn herstel testen?
Minimaal elk kwartaal, en bij voorkeur wisselend per systeem. Eén test per jaar op hetzelfde systeem geeft je te weinig informatie over je algehele recovery-capaciteit. Noteer de tijdsduur en de problemen, en gebruik die informatie om je runbook te verbeteren.
