In juli sprak ik twee bestuursleden van een stichting. Hun website was gebouwd door een vrijwilliger. Voor alles wat met de site te maken had, was het bestuur afhankelijk van die ene persoon, en die reageerde niet meer en nam niet op. In het jaarverslag stond wat het bestuur daar zelf op had bedacht: een oproep voor een webmaster die wel bereikbaar is.

Niemand had hier iets fout gedaan. Er was alleen nooit afgesproken van wie de website was.

Ik bouw en onderhoud websites voor kleine bedrijven en organisaties, dus ik verdien aan dit onderwerp. Lees dit stuk met die wetenschap. Mijn stelling is dat de digitale basis van een kleine organisatie zelden een technisch probleem is. Het is een probleem van eigenaarschap: het werk is wel ergens belegd, maar niemand in de organisatie merkt het als het niet gebeurt.

Vijf dingen kom ik steeds tegen.

Elk kun je in een middag controleren zonder technische kennis, en bij elk hoort één naam.

1. Het domein staat op naam van iemand anders
   Aan je domeinnaam hangen je website en al je mail. Wie als houder geregistreerd staat, heeft het voor het zeggen. Dat kan het bureau zijn dat de site ooit bouwde, of een medewerker die allang weg is.
   
   Dat hoeft geen kwade wil te zijn. In een bestelsysteem voor domeinen dat ik dit jaar onder handen had, kwam elk nieuw domein standaard op naam van de leverancier te staan. Het was de instelling die het minste werk kostte, en niemand had erbij stilgestaan wat dat voor de klant betekent. Sinds eind augustus wordt de klant daar zelf houder, en stopt een bestelling als dat niet lukt.

Zo controleer je het. Zoek een .nl-domein op in de Whois op sidn.nl. Daar staat via welke partij het domein loopt en, als de houder een organisatie is, de naam van die organisatie. Is de houder een privépersoon, dan staat er niets. Staat er iets anders dan de naam van je eigen organisatie, vraag dan schriftelijk aan die partij wie de houder is. Zoek daarna de laatste factuur van het domein op en kijk bij wie die binnenkomt.

Wie hoort dit te beheren? De directeur of de penningmeester. Het domein staat op naam van de organisatie, met een algemeen mailadres dat blijft bestaan als mensen vertrekken.

2. Mail die niet kan laten zien waar hij vandaan komt
   Eind september testte ik het contactformulier op de site van een klant. Het testbericht kwam niet in mijn inbox. De voor de hand liggende conclusie is dan dat het formulier stuk is. Dat was het niet. Het bericht was wel verstuurd en ook aangekomen, alleen in de spammap.
   
   De site verstuurde zijn mail rechtstreeks vanaf de webserver, zonder de digitale handtekening waaraan een ontvanger ziet dat een bericht echt van dat domein komt. Voor een spamfilter is dat een onbekende die zich voordoet als jouw organisatie. Sinds de site zijn mail verstuurt via een gewone mailbox van het domein, mét handtekening, komt hetzelfde testbericht in de inbox aan.
   
   Het vervelende is dat dit geen foutmelding geeft. De afzender denkt dat het verstuurd is, en de ontvanger mist niets wat hij niet verwachtte. Hetzelfde geldt voor facturen en herinneringen uit een boekhoudpakket en voor nieuwsbrieven: die systemen mailen namens jouw domein. Gmail eist sinds 1 februari 2024 van elke afzender zo’n controle, en schrijft erbij dat berichten zonder die controle als spam gemarkeerd of geweigerd kunnen worden.

Zo controleer je het. Maak een lijst van alles wat namens jou mailt: je eigen mailprogramma, het contactformulier, het boekhoudpakket, de nieuwsbrief. Stuur uit elk systeem een bericht naar een Gmail-adres. Kijk eerst of het in de inbox of in de spam staat. Open het daarna en klik onder de naam van de afzender op het pijltje. Staat bij “Verzonden door” en “Ondertekend door” je eigen domeinnaam, dan zit het goed. Staat er een vraagteken naast de afzender, dan niet.

Wie hoort dit te beheren? Degene die over de leveranciers gaat. De instelling zelf doet de partij die het domein beheert, maar de lijst van systemen die namens jou mailen kan alleen iemand binnen de organisatie maken. Komt er een nieuw pakket bij, dan hoort deze test bij de ingebruikname.

3. De website is van niemand
   Dit jaar keek ik naar de site van een bedrijf die nog draaide op WordPress 5.2, een versie uit mei 2019. De programmeertaal eronder, PHP 7.2, krijgt sinds 30 november 2020 geen beveiligingsupdates meer. De site deed het gewoon. Dat is precies het probleem: een verouderde website valt niet om, dus er is nooit een moment waarop iemand moet ingrijpen.
   
   Bij de stichting uit de inleiding was het dezelfde situatie in een andere vorm. De site was er, maar alles wat je nodig hebt om hem te beheren lag bij één persoon. Dat merk je pas als die persoon niet meer opneemt.

Zo controleer je het. Stel drie vragen en schrijf de antwoorden op. Wie in de organisatie mag over de website beslissen? Waar staan de inloggegevens, en wie kan erbij? Wanneer is de software voor het laatst bijgewerkt, en door wie? Krijg je op een van de drie geen antwoord, dan weet je waar je moet beginnen.

Wie hoort dit te beheren? Eén persoon, bij naam. Dat hoeft geen technisch iemand te zijn. De eigenaar is niet degene die het werk doet, maar degene die merkt dat het niet gebeurt.

4. Back-ups die niemand heeft teruggezet
   In juni maakte ik een gehackte site schoon: ruim zevenduizend spampagina’s en drie beheerdersaccounts die er niet hoorden. De enige back-up was van februari, bijna vier maanden oud. Toen ik die later bekeek, stonden er al twee beheerders in die er niet hoorden. De site was dus al besmet op de dag dat de back-up werd gemaakt.
   
   Er was nog iets mee. Het bestand stond in een map op de website zelf en was zeven maanden lang voor iedereen te downloaden: 218 MB, met de complete database. Zes dagen later vond ik bij een andere organisatie hetzelfde: een back-up van 735 MB uit november vorig jaar, vrij op te halen voor wie de bestandsnaam kende. Of iemand dat heeft gedaan, was in beide gevallen niet meer met zekerheid vast te stellen.
   
   Het woord back-up stelt gerust, en daar zit het risico. Het zegt niets over hoe oud hij is, waar hij staat en of je er iets mee kunt.

Zo controleer je het. Vraag aan wie de back-ups maakt drie dingen. Van welke datum is de laatste? Waar staat hij, en is dat een andere plek dan de website zelf? En kun je die van vorige week deze maand terugzetten op een testadres? Kijk daarna zelf of je de site herkent. Pas dan weet je dat het werkt.

Wie hoort dit te beheren? De eigenaar uit punt 3 stelt de vraag, één keer per jaar. De leverancier doet het terugzetten. Een toezegging dat het geregeld is, telt niet als antwoord.

5. Toegang die blijft bestaan
   De site uit het vorige voorbeeld raakte in juli opnieuw besmet. In het logboek van de site stond dat de nieuwe onbekende beheerder was aangemaakt vanuit het account van de eigenaar zelf. Schoonmaken alleen is dus niet genoeg. Zolang wachtwoorden en accounts van vóór een inbraak blijven bestaan, weet je niet wie er nog in kan.
   
   In de back-up van februari stond bovendien een beheerdersaccount dat eind november was aangemaakt. Het had daar dus bijna drie maanden gestaan zonder dat het iemand opviel. Als een account van een inbreker zo lang onopgemerkt blijft, dan geldt dat ook voor het account van de stagiair van drie jaar geleden, van het vorige bureau en van de bestuurder die is afgetreden. Naar de lijst met gebruikers kijkt niemand, tot er een reden voor is.
   
   De stichting laat de andere kant zien. Toegang blijft niet alleen achter bij mensen die weg zijn. Hij raakt ook buiten bereik, als maar één persoon hem heeft.

Zo controleer je het. Schrijf alle plekken op waar je kunt inloggen: het domein, de hosting, de website, de mail, het boekhoudpakket, de sociale media, het bedrijfsprofiel bij Google. Zet erachter wie erin kan en wie beheerder is. Haal iedereen weg die er niet meer hoort, vervang wachtwoorden die gedeeld zijn, en zorg dat overal twee mensen beheerder zijn in plaats van één.

Wie hoort dit te beheren? Degene die ook de sleutel van het pand terugvraagt als iemand vertrekt. Bij een stichting is dat de secretaris.

Wat het kost om het uit te besteden

De controle zelf kost een middag per jaar en geen leverancier. De antwoorden komen van je leveranciers, de vragen moet je zelf stellen.

Het technische werk, dus updates, back-ups en bewaking, kun je uitbesteden. Wat dat kost, heb ik in september uitgezocht: ik zette de prijzen die achttien Nederlandse aanbieders van websites, hosting en onderhoud zelf publiceren naast elkaar. De vergelijking staat met alle bronnen op marketingmaatwerk.nl/wat-kost-een-website/. De maandtarieven voor onderhoud lopen daarin van 12,50 tot 119 euro excl. btw. De meeste zitten tussen 41 en 69 euro, dus tussen 492 en 828 euro per jaar. Hosting kost daarnaast 6 tot 30 euro per maand en een domein 10 tot 20 euro per jaar.

Zet daar de kosten van niets doen tegenover. Voor de gehackte site uit dit stuk heb ik een schone herinstallatie begroot op elf uur, met drie uur marge. Herstel gaat vaak per uur, en dat tarief publiceert bijna niemand. Het mijne is 95 euro excl. btw, dus 1.045 tot 1.330 euro. Daarvoor heb je bij de meeste aanbieders ruim een jaar tot ruim tweeënhalf jaar onderhoud.

De rekensom heeft twee kanttekeningen. Een onderhoudscontract is geen garantie dat je niet gehackt wordt, en herstel na een hack valt er lang niet altijd onder. Vraag ernaar voordat je tekent. En belangrijker: van de vijf punten kun je er maar twee kopen. Updates en back-ups kan een leverancier doen. Op wiens naam het domein staat, wie de eigenaar van de website is en wie er toegang heeft, zijn besluiten. Besteed je het werk uit zonder dat iemand in de organisatie eigenaar is, dan wordt de leverancier de nieuwe vrijwilliger die alles weet en die je moet kunnen bereiken.

Wat ik hiervan heb geleerd

Het gaat zelden mis door onkunde. In elk voorbeeld hierboven was er iemand die het werk kon doen. Het ging mis omdat niemand in de organisatie het als zijn taak zag om te vragen of het gebeurde.

Stilte bewijst niets. Mail in de spam geeft geen foutmelding, een verouderde site blijft draaien en een back-up bestaat tot je hem nodig hebt. Wie wacht op een signaal, wacht op het incident.

De leverancier is geen uitzondering. Een standaardinstelling die domeinen op naam van de leverancier zet, een formulier dat stuk lijkt terwijl de mail in de spam staat: daar zit geen kwade wil achter. Het zijn dingen die niemand controleert. Vraag dus door, ook bij iemand die je vertrouwt.

Eén naam per onderdeel en één middag per jaar is genoeg. Dat is geen IT-project. Het is dezelfde discipline als weten wie de sleutel van het pand heeft.

Boris Kusters bouwt en onderhoudt vanuit Enschede websites voor kleine bedrijven en organisaties.

^Noten

1. ^{Wat de Whois van een .nl-domein laat zien: SIDN, sidn.nl/nl-domeinnaam/uitleg-whois.}
2. ^{Eisen van Gmail aan afzenders sinds 1 februari 2024: Google, support.google.com/a/answer/81126. Controleren of een bericht is geverifieerd: support.google.com/mail/answer/180707.}
3. ^{WordPress 5.2 is uitgebracht op 7 mei 2019 (wordpress.org). PHP 7.2 wordt sinds 30 november 2020 niet meer ondersteund (php.net/eol.php).}
4. ^{Maandtarieven voor onderhoud, hosting en domein: gepubliceerde prijzen van achttien Nederlandse aanbieders, gecontroleerd op 6 september 2026. Volledige bronnenlijst met links: marketingmaatwerk.nl/wat-kost-een-website/#bronnen.}