Je wilt één kleine wijziging aan je website laten doen. Een telefoonnummer aanpassen, een storing laten nakijken, een verlopen certificaat oplossen. Niets bijzonders. Totdat blijkt dat niemand precies weet waar de website eigenlijk wordt beheerd. De domeinnaam staat ergens anders dan de hosting. De DNS is ooit ingesteld door een vorige leverancier. Het beheerdersaccount staat op een oud e-mailadres. De back-ups zouden er moeten zijn, maar niemand weet waar. En de enige persoon die het waarschijnlijk wél wist, is niet meer beschikbaar.
Dan verandert een kleine wijziging ineens in een zoektocht. En dat is het moment waarop duidelijk wordt dat een website niet alleen bestaat uit pagina’s, teksten en techniek. Een website bestaat ook uit toegang, eigenaarschap, afspraken en overdraagbaarheid. Wie die zaken niet op orde heeft, merkt dat meestal pas wanneer er iets moet gebeuren. Daarom de sleutelvraag: wie heeft de sleutels van je website?
Een website heeft meer sleutels dan je denkt
Bij toegang tot de website denken veel mensen aan het inlogscherm van WordPress, Drupal of een ander CMS. Dat is logisch, maar het is maar één sleutel aan een veel grotere sleutelbos. Er is toegang tot de domeinnaam, de hostingomgeving, DNS-instellingen, e-mailconfiguratie, SSL-certificaten, back-ups, betaalde plugins, externe koppelingen, statistiekensoftware, CDN’s en soms ook ontwikkelomgevingen of versiebeheer.
Juist die versnippering maakt websitebeheer kwetsbaar. De domeinnaam staat bij partij A, de hosting bij partij B, de e-mail bij Microsoft of Google, het CMS is gebouwd door een vorige leverancier en de betaalde plugin-licentie staat op het privé e-mailadres van iemand die inmiddels ergens anders werkt. Geen van die onderdelen is op zichzelf uitzonderlijk. Samen vormen ze wel een risico.
Dat risico wordt vaak pas zichtbaar als er haast is. Zolang alles functioneert, lijkt overzicht minder belangrijk. Maar bij een storing, hack, verhuizing of leverancierswissel is overzicht precies wat bepaalt of je binnen een uur kunt handelen of eerst drie dagen moet reconstrueren hoe alles ooit is ingericht.
De domeinnaam, een detail..?
De domeinnaam is een goed voorbeeld. Wie de domeinnaam beheerst, beheerst in praktische zin een belangrijk deel van de digitale bereikbaarheid van de organisatie. Zonder toegang tot de registrar of het juiste verhuistoken kun je een domeinnaam niet zomaar verhuizen. Voor .nl-domeinen beschrijft SIDN dat de huidige registrar beschikt over het verhuistoken dat nodig is voor een verhuizing, en dat deze registrar verplicht is het token binnen vijf dagen na aanvraag over te dragen.
Vijf dagen klinkt overzichtelijk als alles rustig is. Het voelt anders wanneer een website niet goed bereikbaar is, een leverancier niet reageert of een e-mailomgeving moet worden hersteld. Dan wil je niet pas hoeven uitzoeken wie de registrar is, welk e-mailadres als administratief contact staat geregistreerd en of dat e-mailadres nog bestaat.
Een praktische controle is eenvoudig: weet je waar je domeinnaam geregistreerd staat, op wiens naam deze staat, welk e-mailadres eraan gekoppeld is en wie bevoegd is om wijzigingen te laten uitvoeren? Als het antwoord vaag is, is dat geen administratief detail maar een continuïteitsrisico.
Toegang = verantwoordelijkheid
Toegang moet niet alleen beschikbaar zijn, maar ook begrensd. Te weinig toegang is riskant, omdat de organisatie afhankelijk kan worden van een te kleine groep personen. Te veel toegang is net zo riskant, omdat meer mensen dan nodig instellingen kunnen wijzigen, data kunnen inzien of per ongeluk schade kunnen veroorzaken.
Daarom gaat goed toegangsbeheer over drie vragen:
- Wie heeft toegang
- Waarom heeft die persoon toegang
- Wat gebeurt er wanneer die toegang niet meer nodig is?
Het NCSC noemt beheer de toegang niet voor niets als een van de vijf basisprincipes voor digitale veiligheid, naast onder meer risico’s in kaart brengen, systemen beschermen en voorbereiden op incidenten.
In de praktijk ontbreekt vooral het laatste deel: het opruimen. Accounts van oude medewerkers blijven bestaan. Leveranciers behouden beheerdersrechten terwijl hun opdracht al lang is afgerond. Tijdelijke accounts worden permanente accounts. En soms gebruikt iedereen hetzelfde beheerdersaccount, omdat dat ooit handig leek.
Dat laatste is vooral problematisch omdat je dan niet meer goed kunt herleiden wie wat heeft gedaan. Als vier mensen met hetzelfde account werken, is er technisch misschien wel toegang geregeld, maar organisatorisch juist niet. Continuïteit vraagt niet alleen om een werkend wachtwoord, maar om een beheersbare inrichting.
Tweefactorauthenticatie is geen luxe meer
Een apart punt is multifactorauthenticatie, vaak MFA of 2FA genoemd. Daarbij is een wachtwoord alleen niet genoeg en is bijvoorbeeld ook een code, passkey of appbevestiging nodig. Volgens het NCSC maakt MFA het voor cybercriminelen veel moeilijker om toegang te krijgen tot accounts, systemen en gevoelige gegevens.
Voor websitebeheer is dat relevant omdat veel kritieke onderdelen via webaccounts worden beheerd. Denk aan hostingpanels, domeinaccounts, CMS-beheer, e-mailbeheer, cloudopslag en betaalde diensten. Als één van die accounts wordt overgenomen, kan de schade groot zijn. Soms gaat het niet eens direct om de website zelf, maar om de mogelijkheid om DNS te wijzigen, e-mail om te leiden of back-ups te verwijderen.
MFA moet dan wel praktisch worden ingericht. Als de tweede factor alleen op de telefoon van één externe beheerder staat, is het probleem niet opgelost maar verplaatst. De beveiliging is beter, de afhankelijkheid groter. Een volwassen inrichting zorgt dus ook voor herstelcodes, overdrachtsafspraken en een manier om toegang te herstellen zonder paniek.
Back-ups zijn pas waardevol als iemand weet hoe je ze terugzet
Veel organisaties denken bij continuïteit als eerste aan back-ups. Dat is terecht, maar ook hier zit een valkuil. Het bestaan van een back-up is niet hetzelfde als een herstelbare website. Je moet weten waar de back-ups staan, hoe vaak ze worden gemaakt, hoe lang ze worden bewaard, wat ze precies bevatten, wie ze kan terugzetten en of ze functioneel zijn..
Het NCSC omschrijft een back-up als een reservekopie waarmee je data of systemen kunt herstellen als het origineel beschadigd is of verdwenen. Zonder back-up ben je kwetsbaar voor cyberaanvallen zoals ransomware, maar ook voor menselijke fouten en ongelukken.
Voor websitebeheer is vooral dat laatste herkenbaar. Niet elk incident is een aanval. Soms verwijdert iemand per ongeluk content. Soms breekt een update een onderdeel van de site. Soms wordt een configuratie aangepast zonder dat duidelijk is hoe die teruggezet moet worden. In zulke gevallen is een goede back-up geen technisch extraatje, maar het verschil tussen herstellen en opnieuw bouwen.
Een nuttige vraag is daarom niet: Hebben we back-ups? maar: Wanneer hebben we voor het laatst getest of we de website kunnen herstellen? Die test hoeft niet ingewikkeld te zijn, maar moet wel echt worden uitgevoerd. Een back-up die nooit is getest, is vooral een aanname.
De kwetsbaarheid zit vaak in normale situaties
Het lastige aan dit onderwerp is dat een probleem zelden begint met een spectaculaire crisis. Veel continuïteitsproblemen ontstaan uit gewone situaties:
Een website is ooit snel opgezet -> een leverancier heeft uit goede service alles geregeld -> een medewerker had technisch inzicht en nam vanzelf de rol van beheerder op zich -> een domeinnaam werd jaren geleden geregistreerd met het e-mailadres dat toen beschikbaar was.
Kortom: iedereen deed het best mogelijke, maar niemand overzag het complete landschap.
Daarom is wie heeft de sleutels? ook geen beschuldigende vraag. Het is een volwassen beheervraag. Als een organisatie afhankelijk is van haar website, nieuwsbrief, formulieren, reserveringen, online betalingen of vindbaarheid in Google, dan hoort het beheer daarvan niet volledig in hoofden, mailboxen en losse accounts te zitten.
De Cybersecuritymonitor 2025, gepubliceerd door het CBS en toegelicht door het NCSC in 2026, laat bovendien zien dat de weerbaarheid tussen grote en kleine bedrijven sterk verschilt. In 2025 nam 86 procent van de grote bedrijven tien of meer van twaalf onderzochte cybersecuritymaatregelen, tegenover 13 procent van de bedrijven met 2 tot 10 werknemers. Dat zegt niet dat kleinere organisaties onverantwoord werken. Het laat wel zien dat structureel digitaal beheer bij kleinere organisaties sneller onder druk staat, juist omdat tijd, budget en specialistische kennis beperkter zijn.
Wat je minimaal wilt vastleggen
Een praktisch startpunt is een kort continuïteitsoverzicht. Geen dik handboek dat niemand leest, maar een document dat bij een incident meteen bruikbaar is. Daarin leg je ten minste vast waar de domeinnaam staat, wie toegang heeft tot de hosting, waar de DNS wordt beheerd, welke CMS-accounts bestaan, waar back-ups staan, welke externe diensten gekoppeld zijn en wie beslissingsbevoegd is bij wijzigingen.
Daar hoort ook bij dat toegang periodiek wordt gecontroleerd. Bestaan alle accounts nog terecht? Zijn oude leveranciers verwijderd? Kloppen de contactgegevens bij de domeinnaam? Is MFA ingesteld en beheersbaar? Zijn herstelcodes beschikbaar voor de juiste personen? Is duidelijk wie gebeld moet worden als de website offline is?
Dit soort vragen zijn niet spannend, maar wel bepalend. Continuïteit bestaat voor een groot deel uit saaie duidelijkheid. Wie dat vooraf regelt, hoeft tijdens een storing minder te improviseren.
De echte vraag is niet technisch
De titelvraag blijft bewust eenvoudig: wie heeft de sleutels van je website? Maar daarachter zit een bredere vraag. Is de website een beheerd bedrijfsmiddel, of een verzameling losse afspraken die toevallig nog werkt?
Voor veel organisaties is dat tweede dichter bij de werkelijkheid dan prettig is. Niet omdat er sprake is van nalatigheid, maar omdat websites vaak organisch groeien. Er komt een plugin bij, een extra koppeling, een nieuwe hostingpartij, een andere beheerder, een analyticsaccount, een beveiligingstool, een formulierenmodule. Na een paar jaar weet niemand meer precies waar de grenzen liggen.
Daarom begint continuïteit niet met een grote technische ingreep. Het begint met overzicht, eigenaarschap en afspraken. Wie kan erbij? Wie mag wat doen? Waar staat wat? Wat gebeurt er als iemand uitvalt? En hoe snel kunnen we herstellen als er iets misgaat?
De meeste organisaties gaan de sleutels pas zoeken wanneer ze die dringend nodig hebben. Dat is precies het moment waarop je liever het antwoord op de vraag paraat hebt: Wie heeft de sleutels van de website.