Sterk wachtwoordbeleid: wat moet erin staan?

Geplaatst op: 16 juni 2026

Een sterk wachtwoordbeleid bevat minimale lengte- en complexiteitsvereisten, regels voor wachtwoordbeheer, een duidelijke positie over multi-factor authenticatie en richtlijnen over hoe medewerkers worden ondersteund bij naleving. Het is de schriftelijke basis waarop je de toegangsbeveiliging van je organisatie bouwt. Hieronder beantwoorden we de meest gestelde vragen over wat er precies in moet staan.

Welke minimale eisen moet een wachtwoord voldoen?

Een wachtwoord moet minimaal 12 tekens lang zijn en bestaan uit een combinatie van hoofdletters, kleine letters, cijfers en speciale tekens. Hoe langer een wachtwoord, hoe moeilijker het te kraken is. Voor gevoelige systemen en beheerdersaccounts geldt een minimum van 16 tekens als goede richtlijn binnen een sterk wachtwoordbeleid.

Bij het opstellen van wachtwoordvereisten is het verstandig om verder te kijken dan alleen lengte en complexiteit. Hedendaagse richtlijnen, waaronder die van het NIST (het Amerikaanse instituut voor standaarden), raden aan om ook te controleren of een nieuw wachtwoord voorkomt in bekende lijsten van gecompromitteerde wachtwoorden. Veelgebruikte woorden, namen, datums en toetsenbordpatronen zoals “qwerty123” moeten expliciet worden verboden.

Concrete minimale wachtwoordvereisten voor een beleid zijn:

• Minimaal 12 tekens (16 voor beheerdersaccounts)
• Gebruik van minimaal drie van de vier tekensoorten: hoofdletters, kleine letters, cijfers en speciale tekens
• Geen gebruik van de gebruikersnaam, bedrijfsnaam of voor de hand liggende variaties daarop
• Geen hergebruik van de laatste vijf tot tien wachtwoorden
• Geen gebruik van bekende gecompromitteerde wachtwoorden

Het is ook verstandig om in je cybersecuritybeleid op te nemen wat er gebeurt bij meerdere mislukte inlogpogingen. Een automatische vergrendeling na vijf tot tien pogingen vermindert het risico op brute-force aanvallen aanzienlijk.

Moet een wachtwoordbeleid ook multi-factor authenticatie verplichten?

Ja, een modern wachtwoordbeleid moet het gebruik van multi-factor authenticatie (MFA) verplicht stellen, in ieder geval voor alle externe toegang, beheerdersaccounts en systemen met gevoelige gegevens. Een wachtwoord alleen biedt onvoldoende bescherming tegen phishing, credential stuffing en andere aanvalstechnieken waarbij inloggegevens worden gestolen of geraden.

MFA voegt een tweede verificatiestap toe die losstaat van het wachtwoord, zoals een authenticator-app, een sms-code of een hardwaresleutel. Zelfs als een aanvaller het wachtwoord heeft bemachtigd, kan hij zonder die tweede factor niet inloggen. Dit maakt MFA een van de meest effectieve beveiligingsmaatregelen die je kunt nemen.

De NIS2-richtlijn, die via de Cyberbeveiligingswet in Nederland wordt omgezet, benoemt het gebruik van multi-factor authenticatie of continue authenticatie expliciet als minimummaatregel voor organisaties die onder de wet vallen. Dit maakt het voor veel organisaties niet alleen een best practice, maar een wettelijke verplichting.

In je wachtwoordbeleid leg je vast:

• Voor welke systemen en accounts MFA verplicht is
• Welke MFA-methoden zijn toegestaan (bij voorkeur een authenticator-app boven sms)
• Hoe wordt omgegaan met verlies van het MFA-apparaat
• Wie verantwoordelijk is voor het beheer van MFA-toegang

Hoe vaak moeten wachtwoorden worden vernieuwd?

Wachtwoorden hoeven niet meer op vaste intervallen te worden vernieuwd, tenzij er aanwijzingen zijn dat een account is gecompromitteerd. Dit is een verschuiving ten opzichte van het oudere advies om wachtwoorden elke 30, 60 of 90 dagen te wijzigen. Gedwongen periodieke vernieuwing leidt in de praktijk tot zwakkere wachtwoorden, omdat medewerkers gaan werken met kleine variaties op hun vorige wachtwoord.

De huidige aanpak is risicogebaseerd: verander een wachtwoord direct wanneer er een vermoeden is van een datalek, wanneer een medewerker de organisatie verlaat, of wanneer een systeem is gecompromitteerd. Combineer dit met MFA en een wachtwoordmanager, dan is de noodzaak voor verplichte periodieke vernieuwing grotendeels vervallen.

In je wachtwoordbeleid neem je op onder welke omstandigheden een wachtwoord direct moet worden gewijzigd:

• Na een (vermoedelijk) beveiligingsincident
• Bij het verlaten van de organisatie door een medewerker
• Na gebruik op een onvertrouwd apparaat of netwerk
• Wanneer een account is opgenomen in een bekende datalekkendatabase

Wat moet er in een wachtwoordbeleid staan over wachtwoordbeheer?

Een wachtwoordbeleid moet duidelijk regelen hoe medewerkers hun wachtwoorden opslaan en beheren. Het gebruik van een goedgekeurde wachtwoordmanager moet verplicht worden gesteld. Wachtwoorden opschrijven op papier, opslaan in een onbeveiligd tekstbestand of delen via e-mail of chat is expliciet verboden.

Een wachtwoordmanager lost een fundamenteel probleem op: mensen kunnen onmogelijk tientallen unieke, complexe wachtwoorden onthouden. Zonder hulpmiddel gaan ze wachtwoorden hergebruiken, wat een groot risico vormt. Als één dienst wordt gehackt en het wachtwoord komt op straat te liggen, zijn alle andere accounts met hetzelfde wachtwoord direct kwetsbaar.

In het beleid leg je vast:

• Welke wachtwoordmanager(s) zijn goedgekeurd voor gebruik binnen de organisatie
• Dat wachtwoorden nooit mogen worden gedeeld, ook niet met collega’s of IT-beheerders
• Hoe gedeelde accounts worden beheerd (bij voorkeur via een team-vault in de wachtwoordmanager)
• Wat de procedure is als een medewerker vermoedt dat zijn wachtwoord is uitgelekt
• Hoe tijdelijke wachtwoorden worden uitgegeven en hoe snel deze moeten worden gewijzigd na eerste gebruik

Gedeelde accounts vormen een apart aandachtspunt. Wanneer meerdere mensen inloggen met dezelfde inloggegevens, is het onmogelijk om achteraf te achterhalen wie welke handeling heeft uitgevoerd. Streef ernaar gedeelde accounts te elimineren; als dat niet mogelijk is, leg dan vast hoe de toegang wordt beheerd en gelogd.

Hoe zorg je dat medewerkers het wachtwoordbeleid ook naleven?

Naleving van een wachtwoordbeleid bereik je door een combinatie van technische afdwinging, heldere communicatie en bewustzijnstraining. Beleid dat alleen op papier bestaat maar niet technisch wordt afgedwongen, wordt in de praktijk zelden consequent gevolgd. Zorg er dus voor dat de systemen zelf de wachtwoordvereisten controleren en MFA verplichten.

Technische maatregelen die naleving ondersteunen:

• Wachtwoordcomplexiteit afdwingen via het identity managementsysteem of Active Directory
• MFA verplichten op systeemniveau, zodat inloggen zonder tweede factor onmogelijk is
• Automatische vergrendeling van accounts na herhaalde mislukte inlogpogingen
• Integratie van een goedgekeurde wachtwoordmanager in de werkplek van medewerkers

Naast technische maatregelen is bewustzijn onmisbaar. Medewerkers die begrijpen waarom een sterk wachtwoordbeleid belangrijk is, zijn eerder geneigd het te volgen. Leg in trainingen uit wat de gevolgen zijn van een gecompromitteerd account, wat phishing is en hoe aanvallers gestolen wachtwoorden inzetten. Een phishingsimulatie kan hierbij een krachtig hulpmiddel zijn: het maakt abstract gevaar concreet en toont medewerkers hoe eenvoudig het is om in een nep-e-mail te trappen.

Zorg tot slot dat het beleid vindbaar, begrijpelijk en actueel is. Een wachtwoordbeleid dat in juridisch jargon is geschreven en ergens diep in een intranet staat, bereikt niemand. Communiceer bij iedere update wat er verandert en waarom, en maak het voor medewerkers zo eenvoudig mogelijk om het goede gedrag te vertonen.

Hoe Q-Cyber helpt met een sterk wachtwoordbeleid

Wij helpen organisaties bij het opstellen, toetsen en implementeren van een wachtwoordbeleid dat aansluit op de werkelijkheid van de organisatie en voldoet aan relevante wet- en regelgeving, waaronder de NIS2-vereisten voor toegangsbeveiliging en multi-factor authenticatie. Onze aanpak is pragmatisch: geen standaard sjablonen, maar beleid dat werkt in jouw specifieke context.

Wat we concreet voor je kunnen doen:

• Beleid opstellen: We schrijven een helder, praktisch wachtwoordbeleid dat aansluit bij je organisatie en voldoet aan actuele beveiligingsstandaarden
• Gap-analyse: We brengen in kaart waar je huidige beleid of technische inrichting tekortschiet ten opzichte van de NIS2-vereisten voor toegangsbeveiliging
• Bewustzijnstraining: We verzorgen trainingen voor medewerkers en bestuurders zodat het beleid ook in de praktijk wordt nageleefd
• Phishing- en beveiligingstests: We testen hoe medewerkers reageren op social engineering en welke technische kwetsbaarheden er zijn in de huidige toegangsbeveiliging
• Virtuele CISO: Via Continuous-Q bieden we doorlopend advies en begeleiding, zodat je cybersecuritybeleid actueel blijft

We werken volledig onafhankelijk, zonder binding aan softwarepartijen of leveranciers, zodat ons advies altijd in jouw belang is. Wil je weten hoe jouw wachtwoordbeleid er nu voor staat of hoe je het kunt versterken? Neem contact met ons op en we kijken samen wat er nodig is.

Lees meer

Wat is het verschil tussen een incident en een datalek?

Geplaatst op: 15 juni 2026

Een incident en een datalek zijn niet hetzelfde, hoewel ze nauw met elkaar samenhangen. Een beveiligingsincident is elke gebeurtenis die de beschikbaarheid, integriteit of vertrouwelijkheid van informatie bedreigt. Een datalek is een specifiek type incident waarbij persoonsgegevens daadwerkelijk zijn blootgesteld, verloren zijn gegaan of onrechtmatig zijn verwerkt. Het onderscheid bepaalt welke wettelijke verplichtingen op jou als organisatie van toepassing zijn. In de rest van dit artikel beantwoorden we de meest gestelde vragen over dit verschil en wat het voor jouw organisatie betekent.

Wanneer wordt een incident een datalek?

Een incident wordt een datalek op het moment dat er persoonsgegevens bij betrokken zijn en die gegevens zijn blootgesteld aan onbevoegde toegang, verlies, vernietiging of onrechtmatige verwerking. Niet elk incident leidt automatisch tot een datalek. Het gaat specifiek om situaties waarbij de vertrouwelijkheid, integriteit of beschikbaarheid van persoonsgegevens in het geding is.

De Algemene Verordening Gegevensbescherming (AVG) definieert een datalek als een inbreuk op de beveiliging die per ongeluk of op onrechtmatige wijze leidt tot vernietiging, verlies, wijziging of ongeoorloofde verstrekking van persoonsgegevens. Dat klinkt technisch, maar in de praktijk gaat het om concrete situaties zoals:

• Een ransomware-aanval waarbij klantgegevens zijn versleuteld of gestolen
• Een medewerker die een laptop met persoonsgegevens verliest
• Een verkeerd geadresseerde e-mail met persoonlijke informatie van klanten
• Een database die door een configuratiefout publiek toegankelijk is geworden
• Ongeautoriseerde toegang tot een systeem met medische of financiële gegevens

Het cruciale verschil zit in de aanwezigheid van persoonsgegevens. Een DDoS-aanval die een webshop platlegt, is een ernstig incident, maar wordt pas een datalek als daarbij ook klantgegevens zijn buitgemaakt of ingezien. De geldende regelgeving rondom cybersecurity maakt dit onderscheid expliciet, omdat de meldplicht en de bijbehorende verplichtingen sterk verschillen, afhankelijk van de aard van het incident.

Wat zijn voorbeelden van een beveiligingsincident zonder datalek?

Een beveiligingsincident zonder datalek is een verstoring of aanval waarbij de veiligheid van systemen in het geding is, maar waarbij geen persoonsgegevens zijn blootgesteld of gelekt. Dit type incident vereist interne opvolging, maar leidt niet automatisch tot een meldplicht bij de Autoriteit Persoonsgegevens.

Voorbeelden van beveiligingsincidenten die geen datalek zijn:

• DDoS-aanval op een website: de dienst valt uit, maar er worden geen gegevens gestolen of ingezien
• Malware op een geïsoleerde server: de infectie wordt snel ingedamd voordat persoonsgegevens bereikbaar waren
• Phishing-poging die mislukt: een medewerker herkent de aanval en klikt niet op de link
• Ongeautoriseerde inlogpoging die wordt geblokkeerd: het systeem detecteert de poging en weigert toegang
• Stroomstoring die systemen tijdelijk onbeschikbaar maakt: de beschikbaarheid is aangetast, maar gegevens zijn niet gelekt

Het onderscheid is in de praktijk niet altijd direct duidelijk. Bij een ransomware-aanval is het bijvoorbeeld lang niet altijd meteen zeker of aanvallers ook daadwerkelijk gegevens hebben ingezien of geëxfiltreerd. In dat geval moet je als organisatie onderzoeken wat er precies is gebeurd voordat je kunt concluderen of er sprake is van een datalek. Juist in die eerste uren en dagen is een gestructureerde aanpak essentieel.

Moet je een datalek altijd melden bij de Autoriteit Persoonsgegevens?

Nee, niet elk datalek hoef je te melden bij de Autoriteit Persoonsgegevens (AP). Onder de AVG geldt een meldplicht alleen als het datalek waarschijnlijk een risico oplevert voor de rechten en vrijheden van de betrokken personen. Is dat risico verwaarloosbaar, dan volstaat interne documentatie.

Er zijn drie niveaus te onderscheiden:

1. Geen meldplicht: het datalek levert waarschijnlijk geen risico op voor betrokkenen. Wel verplicht intern vastleggen in het datalekregister.
2. Melding bij de AP verplicht: het datalek levert waarschijnlijk een risico op. De melding moet binnen 72 uur na ontdekking plaatsvinden.
3. Melding bij de AP én bij betrokkenen verplicht: het datalek levert waarschijnlijk een hoog risico op voor betrokkenen. Denk aan gelekte medische gegevens of financiële informatie.

Factoren die bepalen of een risico aanwezig is, zijn onder meer de aard van de gegevens (zijn het gevoelige categorieën zoals gezondheidsdata of BSN-nummers?), het aantal betrokkenen, de waarschijnlijkheid dat de gegevens zijn ingezien door onbevoegden en de mogelijke gevolgen voor de betrokkenen.

Naast de AVG-meldplicht geldt voor organisaties die onder de NIS2-richtlijn vallen een aanvullende meldplicht voor significante cyberincidenten. Deze melding gaat naar het NCSC en de relevante toezichthouder, en kent een eerste melding binnen 24 uur na ontdekking, een vervolgmelding binnen 72 uur en een eindverslag uiterlijk één maand na de eerste melding. Dit is een andere meldplicht dan die van de AVG en staat er los van.

Hoe reageer je op een incident dat mogelijk een datalek is?

Reageer op een mogelijk datalek door direct drie stappen te zetten: beheers het incident, stel vast of er persoonsgegevens bij betrokken zijn, en bepaal of melding verplicht is. Snelheid is cruciaal, want de wettelijke termijnen beginnen te lopen vanaf het moment van ontdekking, niet vanaf het moment van bevestiging.

Een gestructureerde aanpak ziet er als volgt uit:

1. Indammen: isoleer het getroffen systeem of de betrokken account om verdere schade te voorkomen. Schakel geen systemen uit voordat forensisch onderzoek mogelijk is geweest.
2. Onderzoeken: breng in kaart wat er is gebeurd, welke systemen zijn geraakt en of persoonsgegevens zijn betrokken. Leg alles vast.
3. Beoordelen: bepaal of het incident kwalificeert als datalek en wat het risiconiveau is voor betrokkenen.
4. Melden (indien van toepassing): bij een meldplichtig datalek moet je binnen 72 uur bij de Autoriteit Persoonsgegevens melden. Wacht niet tot je alle details hebt. Een initiële melding met de beschikbare informatie is beter dan een te late melding.
5. Documenteren: registreer het incident in je interne datalekregister, ook als melding niet verplicht was.
6. Herstellen en leren: herstel de normale bedrijfsvoering en analyseer hoe het incident kon ontstaan om herhaling te voorkomen.

Een goede voorbereiding op cyberincidenten begint lang voordat een incident plaatsvindt. Organisaties die beschikken over een actueel incidentresponsplan, duidelijke interne communicatielijnen en getraind personeel kunnen aanzienlijk sneller en effectiever reageren.

Wie is verantwoordelijk voor het afhandelen van een datalek?

De verwerkingsverantwoordelijke is primair verantwoordelijk voor het afhandelen van een datalek. Dat is de organisatie die het doel en de middelen van de gegevensverwerking bepaalt. Verwerkers, zoals externe leveranciers die namens jou gegevens verwerken, zijn verplicht een datalek onverwijld te melden aan de verwerkingsverantwoordelijke, maar de eindverantwoordelijkheid ligt bij de verwerkingsverantwoordelijke.

Binnen de organisatie zelf ligt de operationele verantwoordelijkheid doorgaans bij de Functionaris Gegevensbescherming (FG) of de privacy officer, in samenwerking met de IT-afdeling en het management. Maar de bestuurlijke verantwoordelijkheid ligt nadrukkelijk bij het bestuur zelf. Dit is ook het uitgangspunt van de NIS2-richtlijn: bestuurders zijn verantwoordelijk voor beslissingen over informatiebeveiliging en moeten voldoende kennis hebben om weloverwogen keuzes te maken.

Voor organisaties met een externe leverancier die persoonsgegevens verwerkt, is het essentieel dat de verwerkersovereenkomst duidelijke afspraken bevat over:

• De termijn waarbinnen de verwerker een incident meldt aan de verwerkingsverantwoordelijke
• Welke informatie de verwerker moet aanleveren bij een incident
• Hoe samenwerking bij onderzoek en herstel is geregeld

In de praktijk zien we dat verantwoordelijkheden bij een datalek snel onduidelijk worden, zeker bij complexe ketens met meerdere leveranciers. Het is daarom verstandig om vooraf te bepalen wie welke rol heeft, en dit vast te leggen in beleid en procedures.

Hoe Q-Cyber helpt bij incidenten en datalekken

Het verschil tussen een incident en een datalek begrijpen is één ding. Weten wat je moet doen als het zover is, en ervoor zorgen dat je organisatie voorbereid is, is een ander verhaal. Wij helpen organisaties bij het hele traject: van preventie tot respons.

Wat wij concreet bieden:

• Incidentresponsbeleid: wij schrijven beleid op maat zodat iedereen binnen de organisatie weet wat te doen bij een (mogelijk) datalek
• NIS2-begeleiding: wij begeleiden organisaties bij de implementatie van de meldplicht en zorgplicht onder de Cyberbeveiligingswet
• Vulnerability scans en pentests: via onze pentestdiensten brengen we kwetsbaarheden in kaart voordat aanvallers dat doen
• Virtuele CISO: via Continuous-Q hebben organisaties toegang tot een team van specialisten dat structureel meekijkt en adviseert
• Trainingen voor bestuurders en medewerkers: zodat de juiste mensen weten hoe ze moeten handelen bij een incident

Wil je weten hoe jouw organisatie er nu voor staat en wat je kunt doen om beter voorbereid te zijn op incidenten en datalekken? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Multi-factor authenticatie: waarom en hoe?

Geplaatst op: 15 juni 2026

Multi-factor authenticatie (MFA) is een beveiligingsmethode waarbij je minimaal twee verschillende verificatiestappen doorloopt om toegang te krijgen tot een account of systeem. Alleen een wachtwoord is niet langer voldoende: aanvallers kunnen wachtwoorden stelen, raden of kopen zonder dat jij het merkt. MFA voegt een extra laag toe die een aanvaller tegenhoudt, zelfs als het wachtwoord al bekend is. In dit artikel beantwoorden we de meest gestelde vragen over hoe MFA werkt, welke vormen er zijn en hoe je het succesvol invoert in je organisatie.

Hoe werkt multi-factor authenticatie technisch gezien?

Multi-factor authenticatie werkt door twee of meer onafhankelijke verificatiefactoren te combineren uit verschillende categorieën: iets wat je weet, iets wat je hebt, en iets wat je bent. Pas als beide factoren correct zijn geverifieerd, krijgt een gebruiker toegang. Het systeem controleert elke factor afzonderlijk via een authenticatieserver of identiteitsprovider.

In de praktijk verloopt het proces als volgt. Een gebruiker voert eerst het wachtwoord in, de eerste factor. Daarna ontvangt diezelfde gebruiker een tijdelijke code via een authenticator-app, sms of hardwaretoken, de tweede factor. Beide stappen moeten slagen voordat toegang wordt verleend.

De kracht van dit systeem zit in de onafhankelijkheid van de factoren. Een aanvaller die het wachtwoord heeft bemachtigd, heeft nog steeds geen toegang tot het fysieke apparaat of de biometrische eigenschap die de tweede factor vormt. Authenticator-apps zoals Google Authenticator of Microsoft Authenticator genereren codes op basis van een gedeeld geheim en een tijdstempel, zodat elke code slechts dertig seconden geldig is. Deze tijdgebonden eenmalige wachtwoorden worden TOTP-codes genoemd en zijn een van de meest gebruikte vormen van MFA.

Wat zijn de meest gebruikte vormen van MFA?

De meest gebruikte vormen van MFA zijn sms-codes, authenticator-apps, hardwaretokens, pushberichten en biometrie. Elke methode verschilt in gebruiksgemak en beveiligingsniveau. Voor de meeste organisaties bieden authenticator-apps de beste balans tussen veiligheid en praktische inzetbaarheid.

• Sms-codes (OTP via sms): Een eenmalige code wordt naar het telefoonnummer van de gebruiker gestuurd. Eenvoudig in gebruik, maar vatbaar voor sim-swapping en onderschepping.
• Authenticator-apps (TOTP): Apps zoals Microsoft Authenticator of Authy genereren tijdgebonden codes lokaal op het apparaat. Veiliger dan sms en breed ondersteund.
• Hardwaretokens (FIDO2/WebAuthn): Fysieke apparaten zoals een YubiKey die je in de USB-poort steekt of via NFC gebruikt. Bieden de hoogste beveiliging en zijn phishing-resistent.
• Pushberichten: De gebruiker ontvangt een melding op een vertrouwd apparaat en keurt de inlogpoging goed of af. Snel en gebruiksvriendelijk, maar kwetsbaar voor MFA-fatigue-aanvallen waarbij aanvallers herhaaldelijk meldingen sturen.
• Biometrie: Vingerafdruk, gezichtsherkenning of irisscanning. Wordt vaak als tweede factor ingezet op mobiele apparaten in combinatie met een wachtwoord.

Voor organisaties die werken met gevoelige systemen of onder regelgeving zoals NIS2-verplichtingen vallen, zijn phishing-resistente methoden zoals FIDO2-tokens de aanbevolen keuze. Voor de meeste medewerkers in een kantooromgeving is een authenticator-app een praktische en veilige oplossing.

Waarom is een sterk wachtwoord alleen niet meer voldoende?

Een sterk wachtwoord alleen is niet meer voldoende omdat wachtwoorden op talloze manieren kunnen worden gestolen zonder dat de gebruiker iets fout doet. Datalekken bij externe diensten, phishing-aanvallen, keyloggers en credential stuffing maken het mogelijk dat zelfs complexe wachtwoorden in handen van aanvallers vallen. MFA is de belangrijkste aanvullende maatregel om accounts te beschermen wanneer een wachtwoord gecompromitteerd is.

Wachtwoorden hebben een fundamentele zwakte: ze zijn statische kennis. Zodra een aanvaller een wachtwoord heeft, heeft hij onbeperkte toegang totdat het wachtwoord wordt gewijzigd. En gebruikers weten vaak niet dat hun wachtwoord al lang op straat ligt. Op het dark web worden miljarden gestolen inloggegevens verhandeld als gevolg van datalekken bij grote platforms.

Bovendien hergebruiken veel mensen wachtwoorden op meerdere diensten. Een datalek bij een relatief onschuldige webshop kan daardoor toegang geven tot bedrijfssystemen. MFA doorbreekt deze keten: zelfs als een aanvaller beschikt over het juiste wachtwoord, stuit hij op een tweede verificatiestap waarvoor hij het fysieke apparaat of de biometrische eigenschap van de gebruiker nodig heeft.

Wanneer moet een organisatie MFA verplicht stellen?

Een organisatie moet MFA minimaal verplicht stellen voor alle accounts met toegang tot gevoelige systemen, bedrijfsdata, e-mail en cloudomgevingen. In de praktijk betekent dit dat MFA voor vrijwel alle medewerkers van toepassing is. Organisaties die onder NIS2 of andere regelgeving vallen, zijn wettelijk verplicht MFA als onderdeel van hun toegangsbeheer te implementeren.

Als prioritering handig is, begin dan met deze situaties:

1. Beheerdersaccounts en privileged access: Accounts met verhoogde rechten zijn het meest aantrekkelijk voor aanvallers. MFA is hier absoluut noodzakelijk.
2. Remote toegang en VPN: Medewerkers die van buiten het kantoornetwerk inloggen, brengen extra risico met zich mee. MFA is hier een minimumvereiste.
3. Clouddiensten en SaaS-applicaties: Microsoft 365, Google Workspace en vergelijkbare platforms zijn populaire doelwitten. Activeer MFA via de beheerdersinstellingen van het platform.
4. E-mail: Toegang tot zakelijke e-mail geeft aanvallers een startpunt voor verdere aanvallen en social engineering. MFA op e-mail is een basismaatregel.
5. Alle overige medewerkers: Na de bovenstaande groepen is een organisatiebrede uitrol de logische vervolgstap.

De NIS2-richtlijn noemt het gebruik van multi-factorauthenticatie expliciet als een van de minimummaatregelen die organisaties moeten treffen in het kader van hun zorgplicht. Wachten tot er een incident plaatsvindt is geen optie.

Hoe implementeer je MFA zonder weerstand van medewerkers?

MFA invoeren zonder weerstand lukt het best door te starten met communicatie en uitleg, een gebruiksvriendelijke methode te kiezen, en de uitrol gefaseerd te doen. Medewerkers verzetten zich zelden tegen MFA zelf, maar wel tegen onduidelijkheid, extra gedoe en het gevoel dat hun iets wordt opgedrongen zonder uitleg.

Praktische stappen voor een soepele implementatie:

• Communiceer het waarom: Leg uit wat MFA doet en waarom het noodzakelijk is. Medewerkers die begrijpen wat ze beschermen, zijn bereidwilliger om mee te werken.
• Kies voor gebruiksvriendelijke tools: Een authenticator-app met pushberichten heeft minder wrijving dan het handmatig overtypen van codes. Maak het zo eenvoudig mogelijk.
• Bied ondersteuning bij de installatie: Organiseer een korte sessie of stapsgewijze handleiding. Veel weerstand ontstaat doordat mensen niet weten hoe ze de app moeten instellen.
• Faseer de uitrol: Begin met een pilotgroep, verzamel feedback, en rol daarna organisatiebreed uit. Zo kun je knelpunten vroeg opsporen.
• Stel duidelijke deadlines: Geef medewerkers de tijd om te wennen, maar maak MFA na de overgangsperiode verplicht. Vrijblijvendheid leidt tot achterblijvers.

Weerstand neemt snel af zodra medewerkers merken dat het inloggen met MFA slechts een paar seconden extra kost. Het helpt ook om MFA te framen als een maatregel die hen persoonlijk beschermt, niet alleen de organisatie.

Biedt MFA ook bescherming tegen phishing?

Standaard MFA biedt gedeeltelijke bescherming tegen phishing, maar is niet volledig phishing-resistent. Aanvallers kunnen via geavanceerde phishing-technieken zoals real-time proxy-aanvallen zowel het wachtwoord als de MFA-code onderscheppen. Alleen phishing-resistente MFA-methoden zoals FIDO2-hardwaretokens of passkeys bieden volledige bescherming tegen dit type aanval.

Bij een klassieke phishing-aanval lokt een aanvaller de gebruiker naar een nepwebsite die er identiek uitziet als de echte dienst. De gebruiker voert het wachtwoord in en de aanvaller stuurt dit direct door naar de echte site. Als de gebruiker vervolgens ook de MFA-code invult op de nepsite, heeft de aanvaller binnen dertig seconden toegang tot het echte account. Dit type aanval wordt een adversary-in-the-middle-aanval genoemd.

FIDO2-tokens en passkeys lossen dit probleem op doordat de authenticatie cryptografisch is gebonden aan het exacte domein van de website. Een nepdomein levert nooit een geldige authenticatie op, ongeacht wat de gebruiker invult. Dit maakt deze methoden fundamenteel veiliger dan op codes gebaseerde MFA.

Voor de meeste organisaties geldt: elke vorm van MFA is beter dan geen MFA. Maar voor systemen met hoge risico’s, zoals financieel beheer, beheerderstoegang of verwerking van persoonsgegevens, is investeren in phishing-resistente authenticatie de verstandige keuze. Een gerichte pentest kan inzicht geven in hoe kwetsbaar de huidige inloginfrastructuur werkelijk is.

Hoe Q-Cyber helpt met multi-factor authenticatie

Q-Cyber helpt organisaties bij het opzetten en verankeren van sterke authenticatieoplossingen als onderdeel van een bredere cybersecuritystrategie. We combineren technische kennis met beleidsmatige expertise, zodat MFA niet alleen technisch correct wordt ingericht maar ook organisatorisch wordt geborgd.

Wat we concreet voor jouw organisatie kunnen doen:

• Beoordelen welke MFA-methoden passen bij jouw risicoprofiel en werkprocessen
• Begeleiden bij de technische implementatie van MFA in cloudomgevingen zoals Microsoft 365 of Google Workspace
• Schrijven van toegangsbeleid en MFA-procedures die aansluiten op NIS2-vereisten
• Verzorgen van bewustwordingstrainingen zodat medewerkers begrijpen waarom MFA noodzakelijk is
• Uitvoeren van phishing-simulaties via Q-Cyber Scans om te testen hoe weerbaar medewerkers zijn
• Ondersteunen via Continuous-Q, onze virtuele CISO-dienst, voor doorlopend advies en toezicht op toegangsbeveiliging

We werken onafhankelijk, zonder binding aan softwarepartijen, en geven altijd pragmatisch advies dat aansluit op jouw situatie. Wil je weten waar jouw organisatie nu staat en welke stappen als eerste gezet moeten worden? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe voer je een risicoanalyse uit voor informatiebeveiliging?

Geplaatst op: 12 juni 2026

Een risicoanalyse voor informatiebeveiliging voer je uit door systematisch te inventariseren welke informatieassets je organisatie heeft, welke dreigingen daarop van toepassing zijn, hoe groot de kans en impact van die dreigingen zijn, en welke beheersmaatregelen nodig zijn om de risico’s tot een aanvaardbaar niveau te reduceren. Dit proces vormt de basis van elke serieuze beveiligingsstrategie. In dit artikel beantwoorden we de meest gestelde vragen over het uitvoeren van een cybersecurity-risicoanalyse, van de concrete stappen tot de wettelijke verplichtingen onder NIS2.

Welke stappen doorloop je bij een risicoanalyse voor informatiebeveiliging?

Een risicoanalyse voor informatiebeveiliging bestaat uit vijf opeenvolgende stappen: het inventariseren van informatieassets, het identificeren van dreigingen en kwetsbaarheden, het beoordelen van kans en impact, het bepalen van beheersmaatregelen, en het documenteren en monitoren van de resultaten. Samen vormen deze stappen een gestructureerde risicobeoordeling die herhaalbaar en auditeerbaar is.

Stap 1: Inventariseer je informatieassets

Begin met een volledig overzicht van alle informatieassets binnen je organisatie. Denk aan systemen, applicaties, databases, netwerken, maar ook aan processen en mensen die toegang hebben tot gevoelige informatie. Zonder dit overzicht is het onmogelijk om te bepalen wat je precies moet beschermen.

Stap 2: Identificeer dreigingen en kwetsbaarheden

Breng per asset in kaart welke dreigingen relevant zijn, zoals ransomware, phishing, ongeautoriseerde toegang of menselijke fouten. Koppel hieraan de kwetsbaarheden die deze dreigingen mogelijk maken, bijvoorbeeld verouderde software, zwak wachtwoordbeleid of ontbrekende netwerkscheiding.

Stap 3: Beoordeel kans en impact

Wijs aan elk geïdentificeerd risico een score toe op basis van de kans dat het zich voordoet en de impact als het daadwerkelijk gebeurt. Dit levert een risicorangschikking op waarmee je prioriteiten kunt stellen.

Stap 4: Bepaal beheersmaatregelen

Kies voor elk significant risico passende maatregelen: technisch, organisatorisch of procedureel. Denk aan toegangsbeveiliging, encryptie, back-upbeleid, bewustzijnstrainingen of contractuele afspraken met leveranciers. Zorg dat de maatregel in verhouding staat tot het risico.

Stap 5: Documenteer en monitor

Leg alle bevindingen, beslissingen en maatregelen vast in een risicoregister. Dit document is niet alleen intern waardevol, maar ook essentieel bij audits en toezicht. Plan vervolgmomenten in om de analyse actueel te houden.

Wat zijn de meest voorkomende informatiebeveiligingsrisico’s voor organisaties?

De meest voorkomende informatiebeveiligingsrisico’s voor organisaties zijn ransomware-aanvallen, phishing en social engineering, onveilige toegang door zwak identiteitsbeheer, kwetsbaarheden in de toeleveringsketen en menselijke fouten door gebrek aan bewustzijn. Deze risico’s gelden voor vrijwel elke sector en organisatieomvang.

Ransomware blijft een van de meest destructieve dreigingen. Aanvallers versleutelen bedrijfsdata en eisen losgeld, waarbij de schade niet alleen financieel is, maar ook de continuïteit van dienstverlening direct raakt. Phishing is vaak het toegangsmiddel: medewerkers worden misleid om inloggegevens te delen of schadelijke bijlagen te openen.

Zwak identiteits- en toegangsbeheer vergroot de aanvalsoppervlakte aanzienlijk. Wanneer medewerkers meer rechten hebben dan nodig, of wanneer multi-factorauthenticatie ontbreekt, kunnen aanvallers eenvoudig lateraal door een netwerk bewegen. Dat is precies waarom NIS2 het gebruik van multi-factorauthenticatie als minimumvereiste stelt.

Supply chain-risico’s worden steeds relevanter. Een kwetsbaarheid bij een leverancier kan directe gevolgen hebben voor jouw organisatie, zelfs als je eigen systemen goed beveiligd zijn. Organisaties dienen daarom niet alleen hun eigen beveiligingsmaatregelen te beoordelen, maar ook die van hun toeleveranciers in kaart te brengen.

Hoe bepaal je de kans en impact van een beveiligingsrisico?

De kans en impact van een beveiligingsrisico bepaal je door elk risico te scoren op twee assen: hoe waarschijnlijk is het dat de dreiging zich voordoet, en hoe ernstig zijn de gevolgen als dat gebeurt? De combinatie van beide scores levert een risiconiveau op dat je gebruikt om prioriteiten te stellen.

Voor de kansschatting kijk je naar factoren zoals de aanwezigheid van kwetsbaarheden, de motivatie en het vermogen van potentiële aanvallers, en de effectiviteit van bestaande beveiligingsmaatregelen. Een systeem dat aan het internet is blootgesteld en bekende kwetsbaarheden bevat, heeft een hogere kans op misbruik dan een geïsoleerd intern systeem.

De impactbeoordeling richt zich op de gevolgen voor vertrouwelijkheid, integriteit en beschikbaarheid van informatie. Denk aan operationele schade zoals uitval van dienstverlening, financiële schade door herstelkosten of boetes, reputatieschade en mogelijke juridische consequenties. Voor organisaties die onder de Cyberbeveiligingswet vallen, is het ook relevant om te beoordelen of een incident meldingsplichtig zou zijn.

In de praktijk werken organisaties vaak met een risicomatrix van drie bij drie of vijf bij vijf, waarbij kans en impact elk worden gescoord op een schaal van laag naar hoog. Risico’s in het hoogste kwadrant vragen om directe actie; risico’s in het laagste kwadrant kunnen worden geaccepteerd of periodiek worden gemonitord.

Wat is het verschil tussen een risicoanalyse en een vulnerability scan?

Een risicoanalyse is een breed, strategisch proces waarbij je alle informatiebeveiligingsrisico’s voor een organisatie in kaart brengt en prioriteert. Een vulnerability scan is een technisch instrument dat specifiek zoekt naar bekende kwetsbaarheden in systemen, applicaties of netwerken. De scan is een input voor de risicoanalyse, niet een vervanging ervan.

Een vulnerability scan levert een lijst van technische zwaktes op, zoals verouderde softwareversies, verkeerde configuraties of ontbrekende patches. Het is een objectieve meting van de technische staat van je omgeving op een bepaald moment. Wat de scan niet doet, is beoordelen hoe groot de kans is dat een kwetsbaarheid wordt uitgebuit, wat de impact zou zijn, of welke organisatorische en procedurele risico’s er naast de technische risico’s bestaan.

De risicoanalyse plaatst de uitkomsten van een scan in een bredere context. Een kwetsbaarheid in een intern systeem zonder internetverbinding heeft een ander risiconiveau dan dezelfde kwetsbaarheid in een publiek toegankelijke applicatie. Bovendien omvat een volledige risicobeoordeling ook niet-technische risico’s, zoals onvoldoende beleid, ongetraind personeel of zwakke leveranciersafspraken.

Voor een betrouwbaar beeld van je beveiligingspositie zijn beide instrumenten nodig. Een penetratietest of vulnerability scan geeft technische diepgang, terwijl de risicoanalyse het strategische kader biedt om bevindingen te wegen en te vertalen naar concrete maatregelen.

Wanneer is een risicoanalyse verplicht onder NIS2?

Een risicoanalyse is verplicht onder NIS2 voor alle organisaties die onder de Cyberbeveiligingswet vallen. De zorgplicht die deze wet oplegt, vereist uitdrukkelijk dat organisaties een risicobeoordeling uitvoeren als basis voor de te nemen beveiligingsmaatregelen. Zonder gedocumenteerde risicoanalyse is het onmogelijk om aan de zorgplicht te voldoen.

De Cyberbeveiligingswet (Cbw) is de Nederlandse implementatie van de Europese NIS2-richtlijn. De wet verplicht organisaties om passende en evenredige technische en organisatorische maatregelen te nemen om de continuïteit van hun dienstverlening te waarborgen en informatie te beschermen. Het startpunt van die maatregelen is altijd een risicobeoordeling: je kunt immers geen passende maatregel kiezen zonder eerst te weten wat de risico’s zijn.

Concreet schrijft NIS2 voor dat organisaties beleid opstellen voor risicoanalyse en beveiliging van informatiesystemen. Dit beleid moet aantoonbaar zijn en periodiek worden herzien. Essentiële en belangrijke entiteiten, waaronder gemeenten, provincies, waterschappen en veel bedrijven in kritieke sectoren, zijn hier direct aan gebonden.

Naast de risicoanalyse als zodanig vereist NIS2 ook dat specifieke domeinen worden meegenomen in de beoordeling: bedrijfscontinuïteit, supply chain-beveiliging, cryptografie, toegangsbeheer en personeelsbeveiliging. Een risicoanalyse die alleen technische systemen omvat, is daarmee onvolledig. In Nederland vallen naar schatting meer dan 10.000 organisaties direct onder NIS2, en een veelvoud daarvan krijgt indirect met de eisen te maken via hun toeleveringsketens.

Hoe vaak moet je een risicoanalyse voor informatiebeveiliging herhalen?

Een risicoanalyse voor informatiebeveiliging moet minimaal jaarlijks worden herhaald en bovendien bij elke significante wijziging in de organisatie, de technische omgeving of het dreigingslandschap. Een eenmalige analyse is onvoldoende, omdat risico’s voortdurend veranderen door nieuwe dreigingen, nieuwe systemen en nieuwe werkwijzen.

De jaarlijkse herhaling zorgt ervoor dat de risicoanalyse actueel blijft en aansluit bij de werkelijke situatie van de organisatie. Dreigingen zoals ransomware en phishing evolueren snel, en kwetsbaarheden die vorig jaar niet bestonden, kunnen vandaag al actief worden uitgebuit. Wie zijn risicoanalyse niet bijhoudt, werkt met een verouderd beeld en neemt beslissingen op basis van onjuiste aannames.

Naast de periodieke herhaling zijn er specifieke aanleidingen die een tussentijdse herziening vereisen:

• Implementatie van nieuwe systemen of applicaties
• Wijzigingen in de organisatiestructuur of werkprocessen
• Uitbreiding of wijziging van de toeleveringsketen
• Een beveiligingsincident dat nieuwe kwetsbaarheden heeft blootgelegd
• Wijzigingen in wet- en regelgeving, zoals de inwerkingtreding van de Cyberbeveiligingswet
• Signalen van het NCSC over nieuwe actieve dreigingen in jouw sector

Voor organisaties die onder de Cyberbeveiligingswet vallen, is de regelmaat van de risicoanalyse ook een toezichtskwestie. Toezichthouders zoals de Rijksinspectie Digitale Infrastructuur (RDI) zullen bij controles verwachten dat een organisatie niet alleen een actuele risicoanalyse kan overleggen, maar ook kan aantonen hoe bevindingen zijn vertaald naar concrete maatregelen en hoe de analyse in de loop der tijd is bijgehouden.

Hoe Q-Cyber helpt met risicoanalyse en informatiebeveiliging

Een risicoanalyse uitvoeren klinkt overzichtelijk op papier, maar in de praktijk vraagt het om de juiste combinatie van technische kennis, beleidsexpertise en inzicht in het dreigingslandschap. Wij begeleiden organisaties door dit proces van begin tot eind, onafhankelijk en zonder binding aan softwarepartijen of andere toeleveranciers.

Wat wij bieden:

• Gap-analyse en risicobeoordeling: We brengen de huidige staat van je informatiebeveiliging in kaart en identificeren de belangrijkste risico’s op basis van jouw specifieke context en sector.
• NIS2-begeleiding: We beoordelen of jouw organisatie onder de Cyberbeveiligingswet valt, welke verplichtingen van toepassing zijn en hoe je risicoanalyse aansluit op de wettelijke zorgplicht.
• Beleid op maat: We schrijven het benodigde informatiebeveiligingsbeleid, inclusief het risicoanalysebeleid dat NIS2 vereist, afgestemd op jouw organisatie.
• Technische toetsing: Via vulnerability scans en penetratietests leveren we de technische input die een gedegen risicoanalyse onderbouwt.
• Virtuele CISO via Continuous-Q: Voor organisaties die structurele ondersteuning nodig hebben, bieden we een team van specialisten dat de risicoanalyse en het bredere beveiligingsprogramma doorlopend beheert.

Wacht niet tot de Cyberbeveiligingswet van kracht is. De risico’s zijn er nu al, en een tijdige risicoanalyse geeft je de voorsprong die je nodig hebt. Neem contact op en we kijken samen waar je organisatie staat.

Lees meer

Wat is de 3-2-1 back-upregel?

Geplaatst op: 12 juni 2026

De 3-2-1 back-upregel is een bewezen strategie voor gegevensbeveiliging waarbij je drie kopieën van je data bewaart, op twee verschillende opslagmedia, waarvan één kopie zich op een externe locatie bevindt. Deze aanpak zorgt ervoor dat je altijd een werkende back-up hebt, ook als een locatie of opslagmedium uitvalt door brand, diefstal, technisch falen of een cyberaanval. In dit artikel beantwoorden we de meest gestelde vragen over de 3-2-1 back-upstrategie, van de praktische uitvoering tot de verplichtingen onder de NIS2-wetgeving.

Hoe werkt de 3-2-1 back-upregel in de praktijk?

De 3-2-1 back-upregel werkt als volgt: je bewaart drie kopieën van je gegevens (de originele data plus twee back-ups), slaat deze op op twee verschillende soorten opslagmedia, en zorgt ervoor dat één kopie zich op een externe locatie bevindt, los van je primaire omgeving. Dit principe beschermt je tegen vrijwel elk scenario van dataverlies.

In de praktijk ziet dit er voor een gemiddelde organisatie zo uit:

• Kopie 1: De actieve, werkende data op je primaire server of werkstation
• Kopie 2: Een lokale back-up op een NAS-apparaat, externe schijf of secundaire server binnen hetzelfde kantoor
• Kopie 3: Een offsite back-up, bijvoorbeeld in een cloudomgeving of op een fysieke locatie elders

Het sleutelwoord is spreiding. Door de drie kopieën bewust te verdelen over verschillende media en locaties, verklein je de kans dat één incident alle back-ups tegelijk treft. Een brand op kantoor verwoest misschien kopie 1 en 2, maar kopie 3 in de cloud blijft intact. Een ransomware-aanval die je lokale netwerk versleutelt, kan een geïsoleerde cloudback-up niet bereiken als die verbinding correct is beveiligd.

De kracht van de 3-2-1 back-upregel zit in de eenvoud: het is een duidelijk, controleerbaar kader dat je kunt toepassen ongeacht de omvang van je organisatie.

Welke opslagmedia zijn geschikt voor een 3-2-1 back-upstrategie?

Voor een effectieve 3-2-1 back-upstrategie zijn interne harde schijven of SSD’s, NAS-systemen (Network Attached Storage), externe harde schijven, tapemedia en cloudopslag de meest gebruikte opslagmedia. De twee media in de regel moeten echt van elkaar verschillen, zodat een defect in het ene type geen invloed heeft op het andere.

Lokale opslagopties

Een NAS-apparaat is een populaire keuze als tweede kopie: het is snel toegankelijk, schaalbaar en biedt mogelijkheden voor automatische back-ups. Externe harde schijven zijn betaalbaar en eenvoudig te gebruiken, maar zijn gevoeliger voor fysieke schade en menselijke fouten. Tapeopslag is minder gangbaar voor kleinere organisaties, maar wordt in grotere omgevingen nog steeds gebruikt vanwege de hoge opslagcapaciteit en lange levensduur.

Cloudopslag als offsite back-up

Cloudopslag is tegenwoordig de meest praktische invulling van de offsite-kopie. Diensten als Microsoft Azure Backup, Amazon S3 of gespecialiseerde back-upplatforms bieden versleuteling, automatische replicatie en geografische spreiding. Een belangrijk aandachtspunt: zorg dat de cloudback-up niet rechtstreeks gekoppeld is aan je primaire netwerk. Een aanvaller die toegang heeft tot je omgeving, kan anders ook de cloudback-up bereiken en versleutelen of verwijderen.

De keuze van media hangt af van je herstelsnelheid (RTO), de hoeveelheid data die je maximaal mag verliezen (RPO) en het budget. Een combinatie van een lokale NAS voor snelle herstelacties en een cloudomgeving voor offsite bescherming is voor veel organisaties de meest evenwichtige aanpak.

Wat zijn de grootste risico’s zonder een 3-2-1 back-upstrategie?

Zonder een 3-2-1 back-upstrategie loop je het risico dat één incident, of dat nu ransomware, hardware-uitval, brand of menselijke fout is, leidt tot permanent en volledig dataverlies. Organisaties zonder gestructureerde back-upbeveiliging zijn kwetsbaar voor langdurige uitval, financiële schade en reputatieschade die soms onherstelbaar is.

De meest voorkomende risico’s zijn:

• Ransomware: Aanvallers versleutelen niet alleen je primaire data, maar richten zich steeds vaker ook op lokale back-ups. Zonder een geïsoleerde offsite-kopie heb je geen hersteloptie zonder losgeld te betalen.
• Hardware-uitval: Harde schijven hebben een beperkte levensduur. Als je enige back-up op hetzelfde apparaat staat als je originele data, verlies je alles bij een schijfdefect.
• Menselijke fouten: Per ongeluk verwijderde bestanden of overschreven data zijn een van de meest voorkomende oorzaken van dataverlies. Zonder meerdere back-upversies is herstel onmogelijk.
• Fysieke calamiteiten: Brand, overstroming of diefstal kan een complete kantooromgeving treffen. Alleen een offsite-kopie overleeft zo’n scenario.
• Geen getest herstelproces: Organisaties die wel back-ups maken maar nooit testen, ontdekken vaak pas tijdens een crisis dat de back-up corrupt of onvolledig is.

De financiële en operationele gevolgen van dataverlies zijn aanzienlijk. Denk aan stilstaande processen, verloren klantdata, juridische aansprakelijkheid en herstelkosten die snel in de tienduizenden euro’s lopen. Een solide back-upstrategie is daarmee niet alleen een technische maatregel, maar een bedrijfskritische investering.

Is de 3-2-1 back-upregel voldoende voor moderne cyberdreigingen?

De 3-2-1 back-upregel biedt een sterke basis, maar is op zichzelf niet altijd voldoende voor de meest geavanceerde moderne dreigingen. Aanvallers die zich richten op back-upinfrastructuur, of malware die langere tijd sluimert voordat ze actief worden, vragen om uitbreidingen op het klassieke 3-2-1 model.

Een veelgebruikte uitbreiding is de 3-2-1-1-0 regel, waarbij de extra “1” staat voor één offline of air-gapped kopie (volledig losgekoppeld van elk netwerk) en de “0” staat voor nul fouten bij herstelverificatie. Een air-gapped back-up is onbereikbaar voor ransomware, zelfs als een aanvaller volledige toegang heeft tot je netwerkomgeving.

Andere aanvullende maatregelen die de weerbaarheid vergroten:

• Immutable storage: Back-ups die gedurende een ingestelde periode niet kunnen worden gewijzigd of verwijderd, ook niet door beheerders.
• Langere retentieperiodes: Sommige malware blijft weken of maanden inactief. Back-ups van slechts enkele dagen zijn dan onbruikbaar als herstelpunt.
• Versleuteling van back-ups: Zowel tijdens transport als in rust, zodat gestolen back-updata niet bruikbaar is voor een aanvaller.
• Toegangsbeheer: Beperk wie back-ups kan beheren of verwijderen via strikte rechtenstructuren en multi-factorauthenticatie.

De 3-2-1 back-upregel blijft een essentieel fundament, maar organisaties die te maken hebben met gevoelige data of een verhoogd risicoprofiel, doen er goed aan dit fundament verder uit te bouwen.

Hoe vaak moet je een back-up testen om zeker te zijn van herstel?

Je moet back-ups minimaal één keer per kwartaal testen, maar voor kritieke systemen geldt dat maandelijkse of zelfs wekelijkse herstelproeven de voorkeur verdienen. Een back-up die nooit is getest, biedt geen garantie op herstel, ongeacht hoe zorgvuldig de back-upstrategie is opgezet.

Testen betekent niet alleen controleren of de back-up bestaat, maar daadwerkelijk het herstelproces doorlopen. Dit omvat:

1. Hersteltest in een geïsoleerde omgeving: Zet de back-up terug op een testserver of in een sandbox, zodat je productiesystemen niet worden verstoord.
2. Verificatie van data-integriteit: Controleer of de herstelde bestanden volledig en bruikbaar zijn, niet alleen aanwezig.
3. Meting van hersteltijd: Houd bij hoe lang het herstel duurt en vergelijk dit met je vastgestelde RTO (Recovery Time Objective).
4. Documentatie van het resultaat: Leg bevindingen vast en pas het back-upproces aan als er problemen zijn geconstateerd.

Naast periodieke tests is het verstandig om ook na elke grote systeemwijziging, softwareupdate of infrastructuurverandering een hersteltest uit te voeren. De omgeving verandert continu, en een back-up die werkte voor de wijziging, werkt niet automatisch daarna ook nog.

Organisaties die hun continuïteitsbeleid serieus nemen, plannen hersteltests in als vaste terugkerende activiteit en documenteren de resultaten als onderdeel van hun informatiebeveiligingsbeleid.

Wat zijn de verplichtingen rondom back-ups onder NIS2?

Onder de NIS2-richtlijn, en de Nederlandse uitwerking daarvan in de Cyberbeveiligingswet (Cbw), zijn organisaties verplicht passende maatregelen te nemen voor bedrijfscontinuïteit en crisisbeheer, waaronder een aantoonbaar werkend back-up- en herstelbeleid. Back-ups zijn daarmee geen optionele maatregel, maar een expliciet onderdeel van de wettelijke zorgplicht.

De NIS2-zorgplicht schrijft voor dat organisaties beleid opstellen en implementeren voor:

• Bedrijfscontinuïteit, waaronder back-upbeheer en noodherstel
• Risicoanalyse en beveiliging van informatiesystemen
• Beveiligingsmaatregelen voor toegangsbeheer en cryptografie
• Beveiliging van de toeleveringsketen, inclusief de back-upinfrastructuur van leveranciers

Concreet betekent dit dat het niet voldoende is om back-ups te maken. Organisaties moeten ook kunnen aantonen dat het back-upbeleid is gedocumenteerd, dat herstelprocedures zijn getest en dat de verantwoordelijkheden duidelijk zijn belegd. Bij een incident waarbij data verloren gaat, kan de toezichthouder vragen om bewijs van een adequaat back-upproces.

Voor organisaties in de publieke sector geldt bovendien dat de BIO2 (Baseline Informatiebeveiliging Overheid 2) als normatief kader fungeert voor de invulling van de NIS2-zorgplicht. Continuïteitsmaatregelen, waaronder back-upbeleid, zijn hierin expliciet opgenomen. Meer informatie over de bredere verplichtingen vind je op de NIS2-regelgeving pagina.

De Cyberbeveiligingswet is per 4 juni 2025 ingediend bij de Tweede Kamer en de inwerkingtreding wordt verwacht in Q2 2026. Organisaties die nu al voldoen aan de 3-2-1 back-upregel en hun herstelprocessen documenteren, lopen voor op de wettelijke verplichting en zijn beter beschermd tegen de risico’s die er nu al zijn.

Hoe Q-Cyber helpt met je back-upstrategie en NIS2-compliance

Een goede back-upstrategie is meer dan een technische instelling. Het vraagt om beleid, verantwoordelijkheden, herstelplannen en aantoonbare naleving van wet- en regelgeving zoals NIS2. Wij helpen organisaties om dit volledig en pragmatisch in te richten, zonder onnodige complexiteit en zonder binding aan softwarepartijen.

Wat wij voor je kunnen doen:

• Gap-analyse: We brengen in kaart waar je back-upstrategie tekortschiet ten opzichte van de NIS2-zorgplicht en best practices zoals de 3-2-1 regel
• Beleidsvorming: We schrijven een concreet en compliant back-up- en herstelbeleid dat aansluit op jouw organisatie en risicoprofiel
• Technisch advies: We adviseren onafhankelijk over de juiste combinatie van opslagmedia, cloudoplossingen en offsite-opties
• Hersteltest begeleiding: We begeleiden en documenteren hersteltests zodat je aantoonbaar voldoet aan de continuïteitsvereisten
• NIS2-begeleiding: We ondersteunen je bij het volledige NIS2-traject, van registratie tot bestuurstraining en toezichtsvoorbereiding

Wacht niet tot de wet in werking treedt. De risico’s zijn er nu al, en wie nu in actie komt, is straks beter beschermd en beter voorbereid op toezicht. Neem contact op en ontdek hoe we jouw organisatie kunnen helpen.

Lees meer

Hoe maak je een back-upstrategie voor je bedrijf?

Geplaatst op: 11 juni 2026

Een goede back-upstrategie voor je bedrijf bestaat uit drie kernonderdelen: meerdere kopieën van je data op verschillende locaties, een duidelijke back-upfrequentie afgestemd op je bedrijfsprocessen, en een getest herstelplan. Zonder die drie elementen is een back-up in naam aanwezig, maar biedt het geen echte bescherming. In dit artikel beantwoorden we de meest gestelde vragen over het opzetten van een solide back-upplan voor je organisatie.

Wat zijn de belangrijkste onderdelen van een back-upstrategie?

Een back-upstrategie voor een bedrijf bestaat uit vijf essentiële onderdelen: welke data je back-upt, hoe vaak, waar je de kopieën opslaat, hoe lang je ze bewaart, en hoe je ze terugzet. Ontbreekt één van deze elementen, dan heb je geen strategie maar een losse maatregel die je op het verkeerde moment in de steek kan laten.

Elk onderdeel verdient concrete invulling. Begin met een data-inventarisatie: welke bestanden, databases en systemen zijn bedrijfskritisch? Denk aan klantgegevens, financiële administratie, configuratiebestanden en e-mailarchief. Bepaal daarna per categorie hoe snel je die data weer nodig hebt na een incident. Dit noem je de Recovery Time Objective (RTO) en de Recovery Point Objective (RPO). De RTO geeft aan hoe lang je het maximaal zonder die data kunt stellen. De RPO bepaalt hoeveel dataverlies acceptabel is, uitgedrukt in tijd.

Naast de technische kant speelt ook de organisatorische kant mee. Wie is verantwoordelijk voor het uitvoeren en controleren van back-ups? Hoe lang bewaar je versies? En wat doe je bij een ransomware-aanval waarbij ook de back-ups versleuteld zijn? Een doordacht back-upplan in lijn met regelgeving zoals NIS2 dwingt je om al deze vragen vooraf te beantwoorden in plaats van tijdens een crisis.

Wat is de 3-2-1-regel en hoe pas je die toe?

De 3-2-1-regel is de meest gebruikte richtlijn voor een betrouwbare back-upstrategie: maak 3 kopieën van je data, sla ze op 2 verschillende typen media op, en bewaar 1 kopie op een externe locatie. Deze aanpak zorgt ervoor dat geen enkel enkelvoudig incident, of het nu gaat om een harde schijf die uitvalt, een brand of een cyberaanval, al je data tegelijk kan vernietigen.

In de praktijk werkt dit als volgt voor een gemiddeld bedrijf:

• Kopie 1: de actieve productiedata op je primaire systeem of server
• Kopie 2: een lokale back-up op een NAS-apparaat of externe schijf op kantoor
• Kopie 3: een offsite back-up in de cloud of op een fysieke locatie buiten je pand

De kracht van de 3-2-1-regel zit in de spreiding van risico. Als je server crasht, staat er nog een lokale kopie. Als je kantoor afbrandt, heb je nog de cloudback-up. Sommige organisaties breiden dit uit naar de 3-2-1-1-regel, waarbij de vierde kopie offline of air-gapped bewaard wordt, volledig losgekoppeld van het netwerk. Dit biedt extra bescherming tegen ransomware die actieve back-upverbindingen kan bereiken en versleutelen.

Wat is het verschil tussen een lokale, cloud- en hybride back-up?

Het verschil zit in waar je de back-updata opslaat en hoe je die beheert. Een lokale back-up staat op hardware binnen je eigen organisatie, een cloudback-up staat bij een externe aanbieder op afstand, en een hybride back-up combineert beide. Elk type heeft eigen voordelen en beperkingen, afhankelijk van je herstelsnelheid, budget en risicobereidheid.

Lokale back-up

Lokale back-ups zijn snel te herstellen omdat de data zich fysiek dichtbij bevindt. Ze zijn doorgaans goedkoper in gebruik en vereisen geen internetverbinding. Het nadeel is kwetsbaarheid voor fysieke incidenten zoals brand, diefstal of een overstroming. Ook ransomware kan lokale back-ups bereiken als ze verbonden zijn met het netwerk.

Cloudback-up

Cloudback-ups zijn geografisch gescheiden van je primaire locatie, wat ze robuust maakt tegen fysieke rampen. Ze schalen makkelijk mee met groeiende datavolumes en zijn toegankelijk vanaf elke locatie. Het herstel kan echter trager zijn bij grote datahoeveelheden, en je bent afhankelijk van een stabiele internetverbinding en de continuïteit van de cloudaanbieder.

Hybride back-up

De hybride aanpak combineert de snelheid van lokale opslag met de veiligheid van de cloud. Dit is voor de meeste bedrijven de meest volwassen back-upstrategie. Je herstelt kleine incidenten snel via de lokale kopie, terwijl de cloudback-up bescherming biedt bij grote calamiteiten. Veel moderne back-upoplossingen bieden hybride functionaliteit standaard aan.

Hoe vaak moet je een back-up maken van bedrijfsdata?

Hoe vaak je een bedrijfsback-up moet maken, hangt af van hoe snel je data verandert en hoeveel dataverlies je kunt accepteren. Voor de meeste bedrijven geldt: maak dagelijks een back-up van operationele data en wekelijks een volledige systeemback-up. Kritische systemen, zoals databases die doorlopend wijzigen, vereisen vaak continue of uurlijkse back-ups.

Een handige vuistregel is om terug te redeneren vanuit je RPO. Als je maximaal vier uur aan transacties kunt missen, moet je minstens elke vier uur een back-up draaien. Als één dag verlies acceptabel is voor een bepaalde categorie data, volstaat een nachtelijke back-up.

Concreet ziet een veelgebruikte back-upfrequentie er als volgt uit:

• Continu of elk uur: databases, kassasystemen, CRM-data
• Dagelijks: e-mail, projectbestanden, klantdossiers
• Wekelijks: volledige systeemimages, archief
• Maandelijks: langetermijnarchief voor compliance en audits

Houd ook rekening met bewaarperiodes. Niet elke back-up hoef je eeuwig te bewaren, maar sommige sectoren hebben wettelijke bewaartermijnen voor bepaalde data. Stem je back-upfrequentie en retentiebeleid op elkaar af zodat je altijd kunt aantonen wat er wanneer beschikbaar was.

Hoe test je of een back-up daadwerkelijk werkt?

Een back-up testen doe je door een hersteltest uit te voeren: herstel bestanden of systemen vanuit de back-up naar een testomgeving en controleer of de data volledig, correct en bruikbaar is. Een back-up die nooit getest is, is geen betrouwbare back-up. De enige manier om zeker te weten dat je back-up werkt, is door het herstelproces daadwerkelijk te doorlopen.

Veel bedrijven ontdekken pas tijdens een echte crisis dat hun back-up onvolledig was, verouderd of niet meer leesbaar door een softwarewijziging. Om dat te voorkomen, plan je regelmatige hersteltests in als vast onderdeel van je back-upstrategie.

Een praktische testaanpak ziet er zo uit:

1. Bestandsherstel: herstel maandelijks willekeurige bestanden en controleer of ze correct openen
2. Systeemherstel: herstel elk kwartaal een volledig systeem of virtuele machine naar een testomgeving
3. Disaster recovery test: simuleer jaarlijks een volledig uitvalscenario en meet de werkelijke hersteltijd
4. Documenteer de resultaten: leg vast wat er getest is, hoe lang het duurde en of er knelpunten waren

Naast technische tests is het ook verstandig om het herstelproces te laten uitvoeren door iemand die het niet dagelijks doet. Als alleen de beheerder weet hoe het moet, ontstaat er een afhankelijkheid die bij ziekte of vertrek problemen geeft. Een doorlopend beveiligingsprogramma kan helpen om dit soort kwetsbaarheden structureel te monitoren.

Welke back-upfouten maken bedrijven het vaakst?

De meest gemaakte back-upfouten zijn: geen hersteltest uitvoeren, back-ups opslaan op hetzelfde netwerk als de productieomgeving, te lange intervallen tussen back-ups, en geen back-up maken van cloudapplicaties zoals Microsoft 365 of Google Workspace. Deze fouten maken een back-upstrategie kwetsbaar op precies de momenten dat je er het meest op rekent.

Hieronder de meest voorkomende valkuilen op een rij:

• Geen hersteltests: back-ups worden aangemaakt maar nooit gevalideerd, waardoor fouten onopgemerkt blijven
• Back-ups op hetzelfde netwerk: bij een ransomware-aanval worden ook de back-ups versleuteld
• Aanname dat clouddata automatisch back-upt: SaaS-platformen bieden doorgaans geen volledige back-upbescherming, de verantwoordelijkheid ligt bij de gebruiker
• Geen versiebeheer: zonder meerdere versies kun je niet teruggaan naar een punt vóór een infectie of fout
• Back-upverantwoordelijkheid niet belegd: niemand controleert actief of de back-ups daadwerkelijk draaien en slagen
• Encryptie vergeten: back-updata die onversleuteld wordt opgeslagen of verstuurd, is een beveiligingsrisico op zichzelf

Een bijkomend risico is dat bedrijven hun back-upstrategie eenmalig inrichten en daarna niet meer aanpassen. Terwijl de organisatie groeit, nieuwe systemen toevoegt of overstapt naar andere software, blijft de back-upopzet achter. Periodieke evaluatie, minimaal één keer per jaar, is noodzakelijk om je data back-upbeveiliging actueel te houden.

Hoe Q-Cyber helpt met je back-upstrategie en databeveiliging

Een back-upstrategie is geen losstaande maatregel, maar onderdeel van een bredere aanpak van cyberweerbaarheid. Wij helpen organisaties om databeveiliging en bedrijfscontinuïteit structureel te verankeren, niet als technische checklist maar als levende capaciteit die aansluit op de risico’s die jouw organisatie daadwerkelijk loopt.

Wat wij voor je kunnen doen:

• Gap-analyse: we brengen in kaart waar je huidige back-upstrategie tekortschiet ten opzichte van best practices en regelgeving zoals NIS2
• Beleidsvorming: we schrijven een concreet back-up- en herstelbeleid dat aansluit op jouw organisatiestructuur en risicobereidheid
• Technisch advies: we adviseren onafhankelijk over de juiste tools en architectuur, zonder binding aan softwarepartijen
• Herstelscenario’s testen: via onze security tests simuleren we aanvalsscenario’s om te valideren of je back-up- en herstelproces standhouden onder druk
• Virtuele CISO: via Continuous-Q® denken onze specialisten structureel met je mee over back-upbeheer, incidentrespons en bredere cyberveiligheid

Wil je weten hoe jouw huidige back-upstrategie scoort en waar de grootste risico’s zitten? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat zijn de rechten van betrokkenen onder de AVG?

Geplaatst op: 11 juni 2026

De AVG kent betrokkenen zeven concrete rechten toe die hen controle geven over hun persoonsgegevens. Dit zijn het recht op inzage, rectificatie, vergetelheid, beperking van verwerking, dataportabiliteit, bezwaar en het recht om niet onderworpen te worden aan geautomatiseerde besluitvorming. Deze rechten gelden voor iedereen van wie een organisatie persoonsgegevens verwerkt, ongeacht of het gaat om klanten, medewerkers of bezoekers. In dit artikel beantwoorden we de meest gestelde vragen over deze privacyrechten, van hoe je een verzoek indient tot wat de gevolgen zijn als een organisatie deze rechten negeert.

Welke rechten geeft de AVG aan betrokkenen?

De AVG geeft betrokkenen zeven rechten: het recht op inzage, rectificatie, vergetelheid (wissing), beperking van verwerking, dataportabiliteit, bezwaar en het recht om niet uitsluitend te worden beoordeeld op basis van geautomatiseerde verwerking. Samen vormen deze rechten een fundament voor transparantie en zeggenschap over persoonsgegevens.

Elk recht heeft een eigen toepassingsgebied en voorwaarden. Het recht op inzage stelt iemand in staat te weten welke gegevens een organisatie over hem of haar bewaart en waarvoor die worden gebruikt. Het recht op rectificatie zorgt ervoor dat onjuiste of onvolledige gegevens gecorrigeerd kunnen worden. Het recht op vergetelheid biedt de mogelijkheid om verwijdering van gegevens te verzoeken onder specifieke omstandigheden.

Daarnaast geeft de AVG betrokkenen het recht om de verwerking van hun gegevens te laten beperken, zodat gegevens tijdelijk niet worden gebruikt terwijl een geschil wordt opgelost. Het recht op dataportabiliteit maakt het mogelijk gegevens in een gestructureerd, machineleesbaar formaat op te vragen en door te sturen naar een andere partij. Tot slot kunnen betrokkenen bezwaar maken tegen verwerking op basis van gerechtvaardigde belangen of voor direct marketingdoeleinden.

Voor organisaties die vallen onder relevante privacywetgeving is het essentieel dat er processen bestaan om al deze rechten tijdig en correct af te handelen.

Hoe kan een betrokkene een inzageverzoek indienen?

Een betrokkene kan een inzageverzoek indienen door contact op te nemen met de verwerkingsverantwoordelijke organisatie, via welk communicatiekanaal dan ook. Er is geen verplicht formulier of vaste procedure; een e-mail, brief of mondeling verzoek volstaat. De organisatie moet het verzoek binnen één maand beantwoorden.

Bij een inzageverzoek heeft de betrokkene recht op een kopie van de verwerkte persoonsgegevens, maar ook op informatie over de verwerkingsdoeleinden, de categorieën gegevens, de ontvangers aan wie de gegevens zijn verstrekt, de bewaartermijnen en of er geautomatiseerde besluitvorming plaatsvindt. De organisatie mag vragen om de identiteit van de verzoeker te bevestigen, maar mag dit niet als obstakel gebruiken om een verzoek te vertragen of te weigeren.

In de meeste gevallen is een inzageverzoek kosteloos. Alleen bij kennelijk ongegronde of buitensporige verzoeken, bijvoorbeeld als iemand herhaaldelijk identieke verzoeken indient, mag een organisatie een redelijke vergoeding vragen of het verzoek weigeren. De bewijslast voor dat oordeel ligt bij de organisatie, niet bij de betrokkene.

Wat houdt het recht op vergetelheid precies in?

Het recht op vergetelheid, ook wel het recht op wissing genoemd, houdt in dat een betrokkene een organisatie kan verzoeken zijn of haar persoonsgegevens te verwijderen. Dit recht is echter niet absoluut: het geldt alleen onder specifieke omstandigheden die in de AVG zijn vastgelegd.

Een verzoek tot vergetelheid is gegrond wanneer:

• de gegevens niet langer noodzakelijk zijn voor het doel waarvoor ze zijn verzameld;
• de betrokkene zijn toestemming intrekt en er geen andere rechtsgrond voor verwerking is;
• de betrokkene bezwaar maakt tegen de verwerking en er geen dwingende gerechtvaardigde gronden zijn;
• de gegevens onrechtmatig zijn verwerkt;
• wissing verplicht is op grond van een wettelijke verplichting.

Organisaties hoeven niet altijd gehoor te geven aan een wisverzoek. Wanneer de verwerking noodzakelijk is voor de uitoefening van vrijheid van meningsuiting, voor naleving van een wettelijke verplichting, voor archiveringsdoeleinden in het algemeen belang, of voor de instelling of verdediging van rechtsvorderingen, mag de organisatie de gegevens bewaren. Het recht op vergetelheid vraagt dus altijd om een zorgvuldige afweging van belangen.

Wanneer mag een organisatie een AVG-verzoek weigeren?

Een organisatie mag een verzoek van een betrokkene weigeren wanneer het verzoek kennelijk ongegrond of buitensporig is, of wanneer een wettelijke uitzondering van toepassing is. De organisatie moet de weigering altijd schriftelijk motiveren en de betrokkene informeren over de mogelijkheid om een klacht in te dienen bij de Autoriteit Persoonsgegevens.

Concrete situaties waarin een weigering gerechtvaardigd kan zijn:

• Wettelijke bewaarplicht: als de organisatie verplicht is gegevens te bewaren, bijvoorbeeld op grond van belasting- of boekhoudwetgeving, kan een wisverzoek niet worden ingewilligd voor die specifieke gegevens.
• Vrijheid van meningsuiting en informatie: journalistieke of academische verwerking kan zwaarder wegen dan het recht op vergetelheid.
• Volksgezondheid of wetenschappelijk onderzoek: gegevens die noodzakelijk zijn voor onderzoek in het algemeen belang mogen onder voorwaarden worden bewaard.
• Rechtsvorderingen: als gegevens nodig zijn voor een lopende juridische procedure, kan wissing worden geweigerd.
• Herhaalde of misbruikende verzoeken: bij aantoonbaar buitensporige verzoeken mag een organisatie een vergoeding vragen of weigeren, mits zij de buitensporigheid kan aantonen.

Wat een organisatie nooit mag, is een verzoek stilzwijgend negeren. Zelfs bij een terechte weigering geldt een informatieplicht richting de betrokkene.

Hoe verschilt het recht op dataportabiliteit van het recht op inzage?

Het recht op inzage geeft een betrokkene toegang tot zijn of haar persoonsgegevens en informatie over hoe die worden verwerkt. Het recht op dataportabiliteit gaat een stap verder: het geeft de betrokkene het recht die gegevens te ontvangen in een gestructureerd, veelgebruikt en machineleesbaar formaat, en ze rechtstreeks door te sturen naar een andere verwerkingsverantwoordelijke.

Er zijn twee belangrijke praktische verschillen:

• Toepassingsgebied: dataportabiliteit geldt alleen voor gegevens die de betrokkene zelf heeft verstrekt en die worden verwerkt op basis van toestemming of een overeenkomst. Het recht op inzage geldt voor alle persoonsgegevens die een organisatie verwerkt, ongeacht de rechtsgrond.
• Doel: inzage is bedoeld voor transparantie en controle. Dataportabiliteit is bedoeld om overstappen te vergemakkelijken, bijvoorbeeld van de ene app of dienstverlener naar de andere.

Een voorbeeld: een klant van een streamingdienst heeft recht op inzage in alle gegevens die de dienst over hem bewaart, inclusief kijkgedrag en betalingsgegevens. Het recht op dataportabiliteit stelt hem in staat zijn profiel en voorkeuren mee te nemen naar een concurrent, maar alleen als die gegevens door hemzelf zijn verstrekt en de verwerking op toestemming of contract berust.

Wat zijn de gevolgen als een organisatie AVG-rechten negeert?

Als een organisatie de rechten van betrokkenen negeert of structureel niet naleeft, riskeert zij forse boetes van de Autoriteit Persoonsgegevens, reputatieschade en civiele aansprakelijkheid. De AVG kent boetes tot 20 miljoen euro of 4% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.

De Autoriteit Persoonsgegevens kan optreden naar aanleiding van een klacht van een betrokkene, maar ook op eigen initiatief. Naast financiële sancties kan de toezichthouder ook een verwerkingsverbod opleggen, wat voor veel organisaties operationeel ingrijpend is. Betrokkenen hebben bovendien het recht om schadevergoeding te eisen als zij aantoonbaar schade hebben geleden door een schending van hun privacyrechten.

In de praktijk zijn de reputatiegevolgen vaak even zwaar als de financiële. Consumenten en zakelijke partners hechten steeds meer waarde aan zorgvuldige omgang met persoonsgegevens. Een organisatie die herhaaldelijk AVG-verzoeken negeert of afwijst zonder goede motivering, beschadigt het vertrouwen van klanten en partners structureel.

AVG-compliance is ook nauw verwant aan bredere beveiligingsverplichtingen. Organisaties die werken aan NIS2-naleving merken dat privacy en informatiebeveiliging steeds meer verweven zijn: wie zijn databeheer op orde heeft, staat ook sterker bij een beveiligingsaudit.

Hoe Q-Cyber helpt met AVG-compliance en privacyrechten

Wij begrijpen dat de AVG voor veel organisaties een complex geheel vormt, zeker wanneer privacyverplichtingen samenkomen met bredere cybersecurityeisen zoals NIS2. Q-Cyber helpt organisaties om hun informatiebeheer en beveiligingsbeleid zo in te richten dat zij structureel voldoen aan zowel privacywetgeving als cybersecurityregelgeving.

Wat wij concreet bieden:

• Gap-analyses die inzichtelijk maken waar uw organisatie tekortschiet in de naleving van AVG-verplichtingen en beveiligingseisen.
• Beleidsschrijving op maat, waaronder procedures voor het afhandelen van inzageverzoeken, wisverzoeken en andere rechten van betrokkenen.
• Trainingen voor bestuurders en medewerkers over privacyrechten, meldplichten en beveiligingsverantwoordelijkheden.
• Pragmatisch advies zonder binding aan softwarepartijen, zodat onze aanbevelingen altijd in uw belang zijn.
• Ondersteuning via ons Continuous-Q programma, waarbij een team van specialisten uw organisatie doorlopend begeleidt op het gebied van cybersecurity en compliance.

Wilt u weten hoe uw organisatie er nu voor staat? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat is business continuity management?

Geplaatst op: 10 juni 2026

Business continuity management (BCM) is een gestructureerde aanpak waarmee organisaties ervoor zorgen dat kritieke bedrijfsprocessen kunnen blijven functioneren tijdens en na een verstoring, zoals een cyberaanval, brand of stroomuitval. Het doel is niet alleen overleven in een crisis, maar ook het borgen van de continuïteit van dienstverlening op de lange termijn. BCM omvat beleid, plannen, tests en verantwoordelijkheden die samen een robuust continuïteitsplan vormen. In dit artikel beantwoorden we de meest gestelde vragen over bedrijfscontinuïteit.

Wat onderscheidt business continuity management van crisismanagement?

Business continuity management en crisismanagement overlappen elkaar, maar zijn niet hetzelfde. BCM richt zich op het vooraf plannen en inrichten van processen zodat de organisatie tijdens een verstoring blijft functioneren. Crisismanagement gaat over de acute respons op een onverwachte situatie: wie doet wat, hoe communiceer je, en hoe beperk je de schade op het moment zelf.

Een handige manier om het onderscheid te begrijpen: BCM is de voorbereiding, crisismanagement is de uitvoering. Een sterk bedrijfscontinuïteitsplan maakt crisismanagement effectiever, omdat rollen, escalatiepaden en uitwijkprocedures al vastliggen voordat de crisis uitbreekt.

BCM heeft een bredere scope dan crisismanagement. Waar crisismanagement stopt zodra de acute situatie onder controle is, loopt BCM door tot de organisatie volledig is hersteld en de geleerde lessen zijn verwerkt in het beleid. Denk aan het herstel van systemen, het hervatten van klantcommunicatie en het evalueren van wat beter had gekund. Beide disciplines zijn onmisbaar, maar ze vullen elkaar aan in plaats van elkaar te vervangen.

Welke onderdelen vormen een business continuity plan?

Een business continuity plan (BCP) bestaat uit een aantal vaste bouwstenen die samen de organisatie in staat stellen om gecontroleerd te reageren op verstoringen. De kern van elk goed continuïteitsplan is een risicobeoordeling die inzicht geeft in welke processen kritiek zijn en welke dreigingen de grootste impact hebben.

De belangrijkste onderdelen van een BCM-plan zijn:

• Business Impact Analysis (BIA): een analyse van welke processen het meest kritiek zijn en wat de maximale uitvaltijd per proces mag zijn.
• Risicoanalyse: een inventarisatie van mogelijke verstoringen en de kans dat deze zich voordoen.
• Herstelstrategieën: concrete maatregelen om kritieke processen te herstellen of te continueren, zoals uitwijklocaties, back-upprocedures of alternatieve leveranciers.
• Rollen en verantwoordelijkheden: wie is waarvoor verantwoordelijk tijdens een verstoring, inclusief een duidelijke escalatiestructuur.
• Communicatieplan: hoe communiceer je intern en extern tijdens een incident, en wie is de woordvoerder.
• Test- en oefenplan: periodieke oefeningen om te controleren of het plan in de praktijk werkt en om medewerkers voor te bereiden.
• Evaluatie en actualisatie: een cyclus om het plan up-to-date te houden na wijzigingen in de organisatie of het dreigingslandschap.

Een BCM-plan is geen statisch document. Het vraagt regelmatige aandacht, zeker wanneer de organisatie groeit, nieuwe systemen in gebruik neemt of te maken krijgt met nieuwe risico’s zoals aanvallen op de toeleveringsketen.

Wanneer is business continuity management verplicht?

BCM is wettelijk verplicht voor organisaties die vallen onder de NIS2-richtlijn, in Nederland geïmplementeerd via de Cyberbeveiligingswet (Cbw). Deze wet schrijft voor dat essentiële en belangrijke entiteiten aantoonbare maatregelen nemen voor bedrijfscontinuïteit en crisisbeheer als onderdeel van hun zorgplicht. In Nederland vallen ruim 10.000 organisaties direct onder NIS2.

Naast NIS2 zijn er andere kaders die BCM verplicht of sterk aanbevolen maken:

• NIS2 / Cyberbeveiligingswet: verplicht voor essentiële en belangrijke entiteiten in sectoren zoals energie, transport, gezondheidszorg, financiën en digitale infrastructuur.
• BIO2 (Baseline Informatiebeveiliging Overheid): het normenkader voor de gehele overheid, wettelijk verankerd onder de Cbw. Continuïteitsbeheer is hier een expliciet onderdeel van.
• ISO 27001 / NEN-EN-ISO/IEC 27002: internationale informatiebeveiligingsnormen die BCM als vereiste opnemen voor organisaties die een certificering nastreven.
• Sectorspecifieke regelgeving: in de zorg geldt onder meer NEN 7510, waarbij continuïteit van zorgprocessen een centrale eis is.

Ook organisaties die niet direct onder een wettelijke verplichting vallen, maar leveren aan NIS2-entiteiten, krijgen steeds vaker te maken met contractuele eisen op het gebied van bedrijfscontinuïteit. De NIS2-zorgplicht vereist namelijk dat organisaties ook inzicht hebben in de continuïteitsmaatregelen van hun leveranciers.

Hoe verschilt BCM van een IT disaster recovery plan?

Een IT disaster recovery plan (DRP) is een onderdeel van BCM, maar geen synoniem. Het disaster recovery plan richt zich specifiek op het herstellen van IT-systemen, data en infrastructuur na een technische storing of cyberaanval. BCM heeft een bredere reikwijdte: het omvat alle kritieke bedrijfsprocessen, inclusief mensen, locaties, leveranciers en communicatie.

Het verschil wordt duidelijk aan de hand van een voorbeeld. Stel dat een ransomware-aanval de systemen van een organisatie platgooit. Het DRP beschrijft hoe de IT-afdeling de systemen herstelt, back-ups terugzet en de infrastructuur opnieuw inricht. Het BCM-plan beschrijft daarnaast hoe de organisatie in de tussentijd blijft functioneren: welke processen kunnen handmatig worden uitgevoerd, hoe worden klanten geïnformeerd, en welke medewerkers nemen welke taken over.

Een goed beveiligingstestprogramma helpt overigens ook bij het valideren van herstelplannen: door gesimuleerde aanvallen te testen, ontdek je of de recovery procedures in de praktijk werken zoals verwacht. Samengevat geldt: elk DRP maakt deel uit van een BCM-plan, maar een BCM-plan gaat altijd verder dan alleen IT-herstel.

Wat zijn veelgemaakte fouten bij het opstellen van een BCM-plan?

De meest voorkomende fout bij business continuity management is dat het plan wordt opgesteld als een eenmalige exercitie en daarna in een la verdwijnt. Een BCM-plan dat niet regelmatig wordt getest, bijgewerkt en gecommuniceerd, biedt in een echte crisis weinig houvast.

Andere veelgemaakte fouten zijn:

• Geen of onvolledige Business Impact Analysis: zonder een grondige BIA weet je niet welke processen echt kritiek zijn, waardoor herstelprioriteiten verkeerd worden gesteld.
• Te veel focus op IT, te weinig op mensen en processen: continuïteit hangt niet alleen af van systemen, maar ook van medewerkers, fysieke locaties en externe leveranciers.
• Onrealistische hersteltijden: organisaties stellen soms Recovery Time Objectives (RTO’s) vast die technisch niet haalbaar zijn, zonder dit te toetsen.
• Geen betrokkenheid van het bestuur: BCM werkt alleen als het bestuur verantwoordelijkheid neemt en het plan actief ondersteunt. Zowel NIS2 als de BIO2 leggen die verantwoordelijkheid expliciet bij de bestuurders.
• Leveranciers buiten beschouwing laten: organisaties vergeten vaak dat verstoringen bij toeleveranciers ook hun eigen continuïteit kunnen bedreigen. Supply chain security is een integraal onderdeel van risicobeheer.
• Niet oefenen: een plan dat nooit is getest, bevat vrijwel altijd blinde vlekken die pas in een echte crisis zichtbaar worden.

Hoe begin je met het implementeren van business continuity management?

Begin met een risicobeoordeling en een Business Impact Analysis om inzicht te krijgen in welke processen kritiek zijn en welke dreigingen de grootste impact hebben. Vanuit die basis bouw je stapsgewijs een BCM-programma op dat past bij de omvang en het risicoprofiel van je organisatie.

Een praktische aanpak voor implementatie:

1. Bepaal de scope: welke processen, systemen en locaties vallen onder het BCM-programma?
2. Voer een BIA en risicoanalyse uit: breng de kritieke processen in kaart en bepaal de maximale uitvaltijd per proces.
3. Stel herstelstrategieën op: kies concrete maatregelen per risico, zoals uitwijkprocedures, back-uplocaties of alternatieve leveranciers.
4. Schrijf het BCM-plan: leg rollen, verantwoordelijkheden, procedures en communicatielijnen vast in een helder document.
5. Train medewerkers en het bestuur: zorg dat iedereen weet wat zijn of haar rol is. Bestuurders moeten in staat zijn om weloverwogen beslissingen te nemen tijdens een crisis.
6. Test en oefen regelmatig: simuleer scenario’s om te controleren of het plan werkt en om verbeterpunten te identificeren.
7. Evalueer en actualiseer: pas het plan aan na elke oefening, na een incident of bij organisatiewijzigingen.

Voor organisaties die onder NIS2 vallen, is het verstandig om de implementatie van BCM te combineren met de bredere NIS2-compliance aanpak. De NIS2-regelgeving vereist namelijk dat bedrijfscontinuïteit aantoonbaar is ingebed in beleid en processen, en dat dit periodiek wordt getoetst.

Hoe Q-Cyber helpt met business continuity management

BCM is een complex vraagstuk dat technische kennis, beleidsexpertise en organisatorisch inzicht vereist. Wij ondersteunen organisaties bij het opzetten, testen en verbeteren van hun bedrijfscontinuïteitsbeleid, van de eerste risicoanalyse tot een volledig geïmplementeerd en getest continuïteitsplan.

Wat wij concreet bieden:

• Uitvoeren van een Business Impact Analysis en risicoanalyse op maat
• Schrijven van BCM-beleid en continuïteitsplannen die aansluiten op NIS2 en BIO2-vereisten
• Gap-analyses om te bepalen waar je organisatie nu staat en wat er nog ontbreekt
• Trainingen voor bestuurders en medewerkers, zodat iedereen zijn rol kent
• Begeleiding bij het testen en oefenen van het BCM-plan via gesimuleerde scenario’s
• Virtuele CISO-diensten voor organisaties die structurele ondersteuning nodig hebben bij risicobeheer en continuïteitsplanning

Wij werken onafhankelijk, zonder binding aan softwarepartijen, en leveren pragmatisch advies dat direct toepasbaar is. Wil je weten waar jouw organisatie staat op het gebied van bedrijfscontinuïteit? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat is een penetratietest en wanneer heb je die nodig?

Geplaatst op: 10 juni 2026

Een penetratietest, ook wel pentest genoemd, is een gesimuleerde cyberaanval op een systeem, netwerk of applicatie waarbij beveiligingsexperts proberen in te breken zoals een echte aanvaller dat zou doen. Het doel is om kwetsbaarheden te ontdekken voordat kwaadwillenden dat doen. Een pentest geeft je een realistisch beeld van hoe weerbaar je organisatie werkelijk is, niet alleen op papier maar ook in de praktijk.

In dit artikel beantwoorden we de meest gestelde vragen over penetratietesten: van hoe ze werken en wat ze kosten tot wanneer ze verplicht zijn en wat je met de resultaten doet.

Hoe werkt een penetratietest in de praktijk?

Een penetratietest verloopt in een aantal vaste fasen: verkenning, aanval, exploitatie en rapportage. De tester brengt eerst het doelwit in kaart, zoekt vervolgens naar zwakke plekken, probeert die actief te misbruiken en legt alle bevindingen vast in een gedetailleerd rapport. Het hele proces is gecontroleerd en vooraf afgestemd met de opdrachtgever.

In de verkenningsfase verzamelt de tester informatie over het systeem: welke poorten staan open, welke software draait er, zijn er bekende kwetsbaarheden in de gebruikte versies? Dit kan op passieve wijze (openbare bronnen) of actief (directe interactie met het systeem).

Daarna volgt de aanvalsfase. De tester probeert via gevonden zwakke plekken toegang te krijgen tot systemen, data of netwerksegmenten. Dit kan technisch zijn, zoals het misbruiken van een softwarekwetsbaarheid, maar ook via social engineering, zoals een phishingtest. Juist de combinatie van technische en menselijke aanvalsvectoren maakt een pentest zo waardevol.

Na de exploitatiefase wordt alles gedocumenteerd. De tester beschrijft niet alleen wat er mogelijk was, maar ook hoe groot de impact zou zijn geweest bij een echte aanval. Dit vormt de basis voor het eindrapport dat de opdrachtgever ontvangt.

Wat is het verschil tussen een penetratietest en een vulnerability scan?

Een vulnerability scan is een geautomatiseerde controle die bekende kwetsbaarheden in kaart brengt, maar niet actief probeert die te misbruiken. Een penetratietest gaat een stap verder: een menselijke expert probeert de gevonden kwetsbaarheden ook daadwerkelijk te exploiteren om te bepalen welke risico’s echt uitnutbaar zijn. Een scan vertelt je wat er mogelijk mis is; een pentest laat zien wat een aanvaller er in de praktijk mee kan.

Dit onderscheid is belangrijk voor de keuze tussen beide methoden. Een vulnerability scan is sneller, goedkoper en goed geschikt als periodieke basiscontrole. Je krijgt een breed overzicht van technische zwaktes in je omgeving. Nadeel is dat geautomatiseerde tools context missen: ze kunnen niet beoordelen of een kwetsbaarheid in jouw specifieke omgeving ook echt gevaarlijk is.

Een penetratietest vereist menselijke expertise en duurt langer, maar levert een veel rijker beeld op. De tester denkt als een aanvaller, combineert meerdere kwetsbaarheden en ontdekt aanvalspaden die een scanner nooit zou vinden. Voor organisaties die serieuze risico’s willen begrijpen en aantoonbaar willen maken dat hun beveiliging stand houdt, is een pentest de betere keuze.

In de praktijk vullen beide methoden elkaar aan. Veel organisaties voeren regelmatig vulnerability scans uit als continu vangnet en plannen een of meerdere keren per jaar een volledige penetratietest voor diepgaande validatie.

Wanneer is een penetratietest verplicht of sterk aanbevolen?

Een penetratietest is verplicht of sterk aanbevolen in een aantal situaties: wanneer wetgeving zoals NIS2 of ISO 27001 dit vereist, na grote technische wijzigingen, bij de lancering van een nieuwe applicatie of na een beveiligingsincident. Organisaties die onder de Cyberbeveiligingswet vallen, zijn verplicht aantoonbare technische maatregelen te treffen, waarbij een pentest een van de meest concrete bewijsmiddelen is.

De NIS2-richtlijn, die in Nederland via de Cyberbeveiligingswet wordt ingevoerd, verplicht essentiële en belangrijke entiteiten tot uitgebreid cyberrisicobeheer. Hoewel de wet geen expliciete verplichting tot een jaarlijkse pentest bevat, is een periodieke penetratietest een logische en breed geaccepteerde invulling van de zorgplicht. Organisaties die hier niet aan voldoen, lopen het risico op boetes tot 10 miljoen euro of 2% van hun wereldwijde jaaromzet.

Buiten wettelijke verplichtingen zijn er situaties waarbij een pentest sterk aanbevolen is:

• Voor de livegang van een nieuwe applicatie of webshop
• Na een fusie, overname of grote infrastructuurwijziging
• Wanneer je klanten of partners om een beveiligingsaudit vragen
• Na een beveiligingsincident of datalek
• Bij het afsluiten van een cyberverzekering, die steeds vaker een recente pentest vereist
• Wanneer medewerkers toegang hebben tot gevoelige klant- of persoonsgegevens

Organisaties die werken met kritieke infrastructuur, medische data of financiële systemen doen er goed aan minimaal jaarlijks een penetratietest uit te voeren, ongeacht wettelijke verplichtingen.

Wat kost een penetratietest gemiddeld?

De kosten van een penetratietest variëren sterk en liggen doorgaans tussen de 2.000 en 20.000 euro, afhankelijk van de omvang, het type test en de complexiteit van de omgeving. Kleinere webapplicaties of gerichte tests zijn goedkoper; uitgebreide infrastructuurtests of red team-oefeningen kosten aanzienlijk meer. Een vaste prijs noemen is lastig zonder inzicht in de scope.

De belangrijkste factoren die de prijs bepalen zijn:

• Scope en omvang: Hoeveel systemen, applicaties of netwerksegmenten worden getest?
• Type pentest: Een webapplicatietest is doorgaans goedkoper dan een volledige infrastructuurtest of een red team-engagement
• Black box, grey box of white box: Bij een black box test heeft de tester geen voorkennis; bij white box krijgt de tester volledige documentatie. Hoe meer kennis vooraf, hoe efficiënter de test
• Diepgang van de rapportage: Uitgebreide rapporten met hersteladvies kosten meer tijd en dus meer geld
• Hertest: Wordt na het oplossen van kwetsbaarheden een nieuwe test uitgevoerd om te controleren of het herstel correct is?

Goedkoop is niet altijd voordelig. Een penetratietest die alleen een geautomatiseerde scan nabootst, voegt weinig waarde toe. De meerwaarde zit in de menselijke expertise die aanvalspaden combineert en contextgevoelig beoordeelt. Vraag altijd naar de methodiek en de achtergrond van de testers voordat je een keuze maakt op basis van prijs.

Wie mag een penetratietest uitvoeren?

Een penetratietest mag wettelijk worden uitgevoerd door elke partij die daartoe door de eigenaar van het systeem is gemachtigd. Er bestaat in Nederland geen formele certificeringsverplichting voor pentesters, maar in de praktijk zijn erkende certificeringen zoals OSCP, CEH of CREST een sterke indicator van vakbekwaamheid. Kies altijd een partij met aantoonbare ervaring en een duidelijk contract over de scope.

Het ontbreken van een wettelijke certificeringsverplichting betekent niet dat iedereen geschikt is. Een goede pentester beschikt over diepgaande technische kennis van netwerken, applicaties en aanvalstechnieken, maar ook over het vermogen om bevindingen begrijpelijk te rapporteren voor niet-technische stakeholders. De combinatie van technische vaardigheid en communicatieve helderheid is wat een goede tester onderscheidt.

Let bij de keuze van een uitvoerende partij op:

• Relevante certificeringen van de individuele testers (niet alleen het bedrijf)
• Ervaring in jouw sector of met vergelijkbare systemen
• Een heldere en schriftelijke opdrachtovereenkomst met vastgelegde scope
• Vertrouwelijkheidsafspraken over gevonden kwetsbaarheden
• De mogelijkheid tot een hertest na het doorvoeren van verbeteringen

Sommige organisaties kiezen voor een intern red team voor continue security testing. Voor de meeste organisaties is een externe partij beter: die kijkt met frisse ogen en heeft geen blinde vlekken door gewenning aan de eigen omgeving.

Wat gebeurt er na een penetratietest met de resultaten?

Na een penetratietest ontvang je een gedetailleerd rapport met alle gevonden kwetsbaarheden, de ernst ervan (vaak uitgedrukt in een CVSS-score of een eigen risicoclassificatie) en concrete aanbevelingen voor herstel. De volgende stap is het prioriteren en oplossen van die kwetsbaarheden, gevolgd door een hertest om te bevestigen dat het herstel effectief is.

Een goed pentest-rapport bevat doorgaans twee lagen: een managementsamenvatting voor bestuurders en een technisch gedeelte voor de IT-afdeling. De samenvatting beschrijft het algehele risiconiveau en de meest kritieke bevindingen. Het technische gedeelte gaat dieper in op elke kwetsbaarheid, inclusief hoe die is gevonden, wat de impact is en hoe je die oplost.

Na ontvangst van het rapport doorloop je idealiter de volgende stappen:

1. Prioriteer bevindingen: Pak kritieke en hoge risico’s als eerste aan, ongeacht de complexiteit van het herstel
2. Wijs eigenaarschap toe: Bepaal wie verantwoordelijk is voor het oplossen van elke bevinding
3. Plan herstelmaatregelen: Stel een realistische tijdlijn op en zorg voor voldoende capaciteit
4. Voer een hertest uit: Laat de tester controleren of de kwetsbaarheden daadwerkelijk zijn verholpen
5. Documenteer de actie: Leg vast wat er is gevonden, wat er is gedaan en wanneer, zodat je dit kunt aantonen richting toezichthouders of klanten

De resultaten van een pentest zijn ook waardevol als input voor bredere verbeteringen: beleid, bewustwording, architectuurkeuzes en trainingen. Een pentest is geen eindpunt maar een startpunt voor structurele verbetering van je digitale weerbaarheid.

Hoe Q-Cyber helpt met penetratietesten

Wij voeren penetratietesten uit voor organisaties die serieus willen weten hoe weerbaar zij zijn tegen echte cyberaanvallen. Onze aanpak combineert technische diepgang met heldere rapportage, zodat zowel IT-teams als bestuurders direct weten wat er speelt en wat er moet gebeuren.

Wat wij bieden:

• Webapplicatie- en infrastructuurtests door gecertificeerde ethical hackers
• Phishingtests om de menselijke factor in kaart te brengen
• Red team-simulaties voor organisaties die een realistisch aanvalsscenario willen testen
• Heldere rapportage met een managementsamenvatting en technisch hersteladvies
• Hertest na het doorvoeren van verbeteringen
• Begeleiding bij NIS2-compliance, inclusief het vertalen van pentest-uitkomsten naar beleidsmaatregelen

We werken volledig onafhankelijk, zonder binding aan softwarepartijen of leveranciers. Dat betekent dat ons advies altijd in jouw belang is, niet in dat van een product dat we willen verkopen. Wil je weten hoe weerbaar jouw organisatie is? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer