Twintig beveiligingsvragen voor je webbureau

Zo haal je meer uit het gesprek

Stuur de vragen vooraf en vraag om korte, concrete antwoorden. Laat de beheerder per onderwerp aangeven: wat weten we, wat is gecontroleerd en wat moeten we nog uitzoeken? Je hebt meestal meer aan een overzicht met vijf open punten dan aan een technisch rapport waarin niet duidelijk wordt wie iets gaat doen.

Vraag nooit om wachtwoorden, geheime sleutels of complete klantbestanden als bewijs. Het bestaan van een toegang of reservekopie kan op een andere manier worden aangetoond. Een scherm met gevoelige informatie hoeft niet onbeperkt te worden gedeeld. Spreek af welke veilige samenvatting of afgeschermde demonstratie voldoende is.

De actuele aanleiding kan een melding zoals de PHP-kwetsbaarheid van oktober 2026 zijn. Laat dat incident dan afzonderlijk beoordelen. Deze twintig vragen gaan verder: zij helpen je begrijpen hoe het beheer structureel georganiseerd is, ook wanneer er even geen nieuwsbericht rondgaat.

De eerste vijf vragen: wie weet wat er draait?

1. Welke onderdelen gebruiken we werkelijk?

Vraag om een overzicht in begrijpelijke taal: websiteplatform, hosting, belangrijke uitbreidingen en externe koppelingen. Niet iedere interne bibliotheek hoeft op het ondernemersoverzicht te staan. Wel moet duidelijk zijn welke onderdelen de website nodig heeft om haar belangrijkste functies uit te voeren.

Een bruikbaar antwoord kan zijn: “Dit is de live website, dit is de testomgeving en deze drie koppelingen verzorgen aanvragen, mail en afspraken.” Vraag erbij wanneer dat overzicht voor het laatst is gecontroleerd. Een oude inventaris kan een goed startpunt zijn, maar moet niet ongemerkt als actuele werkelijkheid worden gebruikt.

Wat je wilt zien is samenhang. Als iedere leverancier alleen zijn eigen stukje noemt, vraag dan wie het totale overzicht bewaakt. De uitleg over WordPress, PHP en plugins kan helpen om onderdelen niet op één hoop te gooien.

2. Wie is verantwoordelijk voor elk onderdeel?

“De hosting doet dat” is pas een antwoord wanneer duidelijk is wat “dat” precies betekent. De hoster kan verantwoordelijk zijn voor de infrastructuur, terwijl een andere partij het websiteplatform of maatwerk onderhoudt. Laat de verdeling opschrijven met een herkenbare verantwoordelijke per onderdeel.

Een fictief goed antwoord: “Wij beoordelen updates van de website. De hoster beheert het serverplatform. Bij een melding controleert onze beheerder of beide acties nodig zijn.” Het gaat niet om die exacte verdeling, maar om het voorkomen van een gat tussen leveranciers.

Vraag ook wie jou informeert als meerdere partijen betrokken zijn. Je wilt bij een storing niet zelf technische conclusies moeten doorgeven tussen drie helpdesks. Eén afgesproken contactroute kan veel verwarring voorkomen, zonder dat één partij daarmee alle technische werkzaamheden overneemt.

3. Hoe controleren jullie welke versie live staat?

Een screenshot uit een beheeromgeving kan nuttig zijn, maar vraag of die werkelijk bij de live website hoort. Er kunnen meerdere omgevingen bestaan met verschillende instellingen. Een versie op een laptop of testserver bewijst niet wat bezoekers op dat moment gebruiken.

Een bruikbaar antwoord noemt de gecontroleerde omgeving, het moment en de manier van vaststellen. Het hoeft geen geheime configuratie te bevatten. Bijvoorbeeld: “Op deze datum is de productieomgeving gecontroleerd; deze versie is actief; de testomgeving staat apart.”

Bij een specifieke kwetsbaarheid hoort de beheerder die waarneming naast de oorspronkelijke melding te leggen. Alleen een versienummer noemen kan onvoldoende zijn wanneer de getroffen omstandigheden ook van configuratie afhangen. Vraag daarom om een conclusie met onderbouwing, niet om een los nummer dat jij zelf moet interpreteren.

4. Hoe komen belangrijke beveiligingsmeldingen bij jullie terecht?

Het is verstandig te vragen wie meldingen volgt en hoe wordt bepaald of ze relevant zijn. Een algemene nieuwsbrief kan informeren, maar is nog geen uitgewerkt beheerproces. Je wilt weten hoe een melding over een gebruikt onderdeel leidt tot beoordeling van jouw omgeving.

Een fictief antwoord: “De beheerder controleert de melding tegen onze inventaris, bepaalt de prioriteit en registreert wat nodig is.” Vraag wat er gebeurt als die beheerder afwezig is. Beschikbaarheid van een werkwijze mag niet volledig afhangen van één persoon die toevallig een bericht ziet.

Je hoeft geen onrealistische belofte van onmiddellijke reactie te eisen. Wel kun je om concrete afspraken vragen die passen bij je bedrijfsrisico. Als die afspraken niet in de huidige overeenkomst staan, laat dat dan expliciet benoemen in plaats van ze te veronderstellen.

5. Wat gebeurt er als een onderdeel niet meer goed onderhouden kan worden?

Een plugin, koppeling of maatwerkonderdeel kan een beheerprobleem worden. Vraag hoe zoiets wordt gesignaleerd en welke keuzes dan worden voorgelegd. Niet iedere beperking vraagt direct een complete herbouw. Soms kan een onderdeel worden vervangen of een ongebruikte functie worden verwijderd.

Een bruikbaar antwoord beschrijft alternatieven en gevolgen. “Dit onderdeel blokkeert onderhoud; we onderzoeken behoud, vervanging of vereenvoudiging” is nuttiger dan “alles moet nieuw”. Laat ook vastleggen welke tijdelijke maatregelen nodig zijn terwijl een structurele keuze wordt gemaakt.

Bekijk bij een mogelijke herbouw onze gids over website overstappen zonder onnodig SEO-verlies. Een acute technische maatregel en een nieuwe website zijn afzonderlijke besluiten. Je moet kunnen begrijpen waarom beide wel of niet nodig zijn.

Vragen zes tot tien: toegang en wijzigingsbeheer

6. Wie kan de website en de gekoppelde accounts aanpassen?

Vraag om een overzicht van rollen en verantwoordelijken, niet om hun wachtwoorden. Welke medewerkers, leveranciers en technische koppelingen hebben toegang? Is duidelijk waarom zij die nodig hebben? Een algemeen gedeeld account kan het achteraf lastiger maken om een wijziging aan iemand toe te schrijven.

Een goed antwoord kan zijn: “Dit zijn de actieve beheerrollen, tijdelijke toegang wordt na de opdracht ingetrokken en deze persoon controleert het overzicht.” Vraag hoe oud-medewerkers en voormalige leveranciers worden afgehandeld. Juist toegang die ooit handig was, kan later vergeten worden.

Het doel is geen maximaal aantal accounts of één vaste oplossing. Het doel is dat toegang een duidelijke reden, eigenaar en beëindigingsmogelijkheid heeft. Laat onduidelijke vermeldingen onderzoeken voordat je aanneemt dat iemand nog steeds toegang nodig heeft.

7. Hoe worden belangrijke accounts extra beschermd?

Laat je beheerder uitleggen welke accountbeveiliging wordt gebruikt en hoe herstel werkt wanneer iemand zijn toegang verliest. Een extra inlogstap heeft weinig praktische waarde als niemand weet waar de herstelprocedure is vastgelegd of wie bevoegd is die te gebruiken.

Vraag om een demonstratie zonder codes of geheime herstelgegevens te delen. Een bruikbaar antwoord beschrijft de instelling en de verantwoordelijke. Ook wil je weten wat er gebeurt als een telefoon zoekraakt of een beheerder vertrekt. Dat zijn gewone bedrijfssituaties, geen theoretische uitzondering.

Neem domeinregistratie en hosting mee in het gesprek. Alleen het websitebeheer goed inrichten is niet genoeg wanneer belangrijke instellingen elders met onduidelijke toegang worden beheerd. Welke maatregelen passend zijn, moet worden beoordeeld binnen de mogelijkheden van de gebruikte aanbieders.

8. Waar worden sleutels en wachtwoorden beheerd?

Het antwoord hoort geen lijst met geheime waarden te zijn. Je wilt weten welk proces wordt gebruikt, wie toegang krijgt en hoe vervanging wordt geregeld. Vraag expliciet of gegevens in chats, losse documenten of codebestanden terechtkomen en hoe dat wordt voorkomen of hersteld.

Een fictief goed antwoord: “We delen geen werkelijke sleutels in projectnotities; bevoegde beheerders gebruiken een afgesproken opslag en registreren alleen verwijzingen.” De precieze technische oplossing kan verschillen. Het belangrijke punt is dat delen en intrekken niet afhankelijk zijn van improvisatie.

Wordt AI gebruikt bij het beheer, vraag dan wat daarvoor wordt gedeeld. Een fout uitleggen vereist niet automatisch een volledig instellingenbestand. Ons artikel over AI en websitebeveiliging helpt je onderscheid maken tussen nuttige context en toegang die je niet wilt verspreiden.

9. Hoe testen jullie een wijziging voordat die live gaat?

Vraag naar het proces dat bij jouw website past. Niet iedere wijziging heeft een volledige acceptatieomgeving nodig, maar een aanpassing aan inloggen of betalen verdient andere controles dan een tekstcorrectie. Een algemeen antwoord als “wij testen altijd” zegt te weinig over die afweging.

Een bruikbaar antwoord noemt welke functies gecontroleerd worden, met welke testgegevens en in welke omgeving. Vraag ook wat niet getest kon worden. Dat laatste is belangrijk: een beperking moet zichtbaar blijven tot iemand haar heeft opgelost of bewust geaccepteerd.

Voor technisch onderhoud beschrijft PHP updaten met aandacht voor continuïteit een gerichte aanpak. Gebruik die uitleg niet als opdracht om zelf instellingen te veranderen. Het is voorbereiding op een gesprek met de beheerder die de omgeving en afhankelijkheden kent.

10. Wie besluit dat een wijziging klaar is voor publicatie?

Er moet duidelijk zijn wie de inhoud goedkeurt, wie de technische controle uitvoert en wie daadwerkelijk publiceert. Die rollen kunnen bij een klein bedrijf deels bij dezelfde persoon liggen. Het onderscheid blijft nuttig, omdat een mooi ontwerp nog niet bewijst dat de functies goed werken.

Vraag welke redenen aanleiding zijn om niet te publiceren. Een ontbrekende test, onverwachte fout of onduidelijke terugvalmogelijkheid kan eerst aandacht vragen. Als alleen de afgesproken datum telt, is er geen echte kwaliteitsgrens.

Een fictief sterk antwoord: “We publiceren wanneer deze controles afgerond zijn; deze open punten moeten eerst worden opgelost; deze persoon geeft akkoord.” Vraag na publicatie om een korte bevestiging van wat live is gecontroleerd. Daarmee voorkom je dat “klaargezet” en “gepubliceerd” in de communicatie door elkaar lopen.

Vragen elf tot vijftien: herstel en bedrijfscontinuïteit

11. Wat wordt er precies geback-upt?

“Er is een backup” laat veel open. Vraag welke onderdelen daarin zitten: bestanden, inhoud, instellingen en gegevens die bij gekoppelde functies horen. Een kopie van de zichtbare pagina's is niet automatisch voldoende om een complete website met accounts of aanvragen terug te brengen.

Een bruikbaar antwoord maakt ook duidelijk welke onderdelen niet in die kopie zitten. Misschien bewaart een externe aanbieder bepaalde gegevens. Dat is niet per definitie verkeerd, maar moet bekend zijn. Anders verwacht je bij herstel iets dat nooit is opgeslagen.

Vraag om een beknopt overzicht zonder de backup zelf te ontvangen als daar klantgegevens in staan. Meer uitleg over het verschil tussen bewaren en kunnen herstellen vind je in backup en hersteltest.

12. Wanneer is voor het laatst een hersteltest gedaan?

Een opgeslagen bestand is nog geen aangetoonde herstelmogelijkheid. Vraag of de beheerder heeft gecontroleerd dat de relevante onderdelen teruggezet kunnen worden en hoe dat is vastgesteld. Zo'n proef moet in een geschikte, afgesproken omgeving gebeuren, niet door zomaar de live website te overschrijven.

Een fictief goed antwoord bevat de datum, omvang en uitkomst van de test. Bijvoorbeeld dat een testkopie is teruggezet en welke functies daarna zijn gecontroleerd. Laat ook noemen welke koppelingen buiten de test vielen.

Ontbreekt een recente proef, trek dan niet meteen een conclusie over totale onveiligheid. Maak er een concrete actie van: wat moet getest worden, wie voert dat uit en wanneer wordt het resultaat besproken? Een zichtbaar open punt is beter dan een ononderbouwd vinkje.

13. Hoe melden wij een storing en wie beoordeelt haar?

Vraag naar één duidelijke meldroute en de afspraken die daarbij gelden. Een storing melden via de privételefoon van iemand die op vakantie is, is geen heldere regeling. Tegelijk moet je geen permanente bereikbaarheid aannemen als die nooit is afgesproken.

Laat onderscheid maken tussen ontvangst, beoordeling en herstel. Een melding ontvangen betekent niet dat de oorzaak al bekend is. Een reactie betekent niet dat de site al werkt. Heldere woorden voorkomen dat je een toezegging anders begrijpt dan de leverancier.

Bespreek je eigen praktijk. Wanneer is uitval voor jou het meest vervelend? Welke functie heeft voorrang? Een afspraakformulier en een informatief artikel hebben mogelijk verschillende impact. Gebruik dat gesprek om passende afspraken te maken, niet om een standaardbelofte uit een andere offerte over te nemen.

14. Wat doen jullie bij vermoedens van ongewenste toegang?

Vraag naar de eerste besluitvorming: wie onderzoekt, wie mag maatregelen nemen en hoe wordt informatie vastgelegd? Het is belangrijk dat een haastige opruimactie niet het enige antwoord is. Een vermoeden moet beoordeeld worden zonder meteen ongefundeerde conclusies over een datalek te trekken.

Een bruikbaar antwoord beschrijft de verantwoordelijke en de route voor verdere beoordeling. Vraag ook hoe jij wordt geïnformeerd en welke externe deskundigheid eventueel nodig is. Specifieke juridische verplichtingen hangen van de situatie af en horen bij een passende beoordeling, niet bij een algemeen blogantwoord.

Spreek af dat gevoelige gegevens niet ongecontroleerd in een groepschat worden gedeeld. Een incident kan al onrustig genoeg zijn. Een afgesproken communicatieplek en duidelijke eigenaar helpen voorkomen dat aannames, screenshots en instructies door elkaar gaan lopen.

15. Hoe controleren we dat aanvragen en afspraken blijven werken?

Een bereikbare homepage is niet hetzelfde als een werkend bedrijfsproces. Vraag welke routes periodiek of na relevante wijzigingen worden nagekeken. Denk aan contact, offerte, afspraak, bevestigingsmail en eventuele toegang tot klantinformatie.

Een fictief goed antwoord: “Na een wijziging aan het formulier controleren we verzending, bevestiging en de afgesproken bestemming met herkenbare testgegevens.” Vraag hoe dubbele aanvragen of onbedoelde echte boekingen worden voorkomen tijdens die proef.

Maak zelf ook een korte lijst van de drie functies waarvan uitval het meest zou kosten. Die informatie helpt de beheerder prioriteiten kiezen. De technische controle moet aansluiten op hoe jouw bedrijf de website gebruikt, niet alleen op wat gemakkelijk automatisch te meten is.

De laatste vijf vragen: grenzen, bewijs en samenwerking

16. Wat doet onze extra beveiligingsdienst wel en niet?

Een firewall, CDN of beveiligingsplugin kan een nuttige rol hebben. Vraag welke rol dat in jouw inrichting is. Laat niet alleen de productnaam noemen. Je wilt begrijpen welke problemen het onderdeel adresseert en welke verantwoordelijkheden daarnaast blijven bestaan.

Een sterk antwoord benoemt ook grenzen. Een extra laag is niet automatisch een vervanging voor onderhoud van de website zelf. Bij Cloudflare en PHP-veiligheid leggen we uit hoe je daar zonder absolute claims over kunt praten.

Vraag welke instellingen daadwerkelijk actief zijn en wanneer ze zijn beoordeeld. Het bezit van een abonnement zegt niet genoeg over de inrichting. Laat een beheerder uitleggen wat gecontroleerd is, zonder je te overspoelen met screenshots die geen verband hebben met jouw website.

17. Welke gegevens verzamelen we en waarom?

Een website kan formulieren, statistieken en externe koppelingen gebruiken. Vraag welk doel ieder gegeven dient, waar het terechtkomt en wie er toegang toe heeft. Meer verzamelen is niet vanzelf beter voor het bedrijf. Onnodige gegevens kunnen het beheer juist ingewikkelder maken.

Een bruikbaar antwoord koppelt gegevens aan een concrete functie. Bijvoorbeeld contactgegevens om een aanvraag te beantwoorden, met een afgesproken bestemming. Laat aparte doeleinden ook apart bespreken. Een aanvraag behandelen en marketing versturen zijn niet zonder meer dezelfde activiteit.

Vraag bij twijfel om een passende privacybeoordeling. Deze vragenlijst geeft geen algemeen juridisch akkoord op jouw inrichting. Zij helpt zichtbaar maken welke keuzes nog ontbreken en voorkomt dat een technische koppeling automatisch als toestemming voor ieder mogelijk gebruik wordt behandeld.

18. Wat is inbegrepen en welke afspraken ontbreken nog?

Lees woorden als beheer, onderhoud en beveiliging samen met de concrete werkzaamheden. Welke updates, controles en ondersteuning zijn afgesproken? Wat gebeurt er bij extra werk? Welke reactietijden zijn daadwerkelijk bevestigd? Een algemeen pakketlabel beantwoordt die vragen niet.

Dat geldt ook bij een betaalbaar maandmodel. In ons artikel over een website voor €75 per maand onderscheiden we het aanbod van onbevestigde servicebeloften. Een aantrekkelijk bedrag is alleen goed te beoordelen als de opdracht en grenzen duidelijk zijn.

Vraag om ontbrekende afspraken te markeren in plaats van ze mondeling in te vullen. Dan kun je bewust besluiten of een aanvullende afspraak nodig is. Een open vraag is niet hetzelfde als een gebrek, zolang duidelijk is wie haar beantwoordt voordat je erop vertrouwt.

19. Wat ontvang ik als ik van leverancier wissel?

Vraag welke informatie, bestanden en toegangen worden overgedragen en welke onderdelen bij een aparte aanbieder horen. “Alles is van jou” klinkt prettig, maar kan praktisch onduidelijk blijven. Je wilt weten wat je nodig hebt om verder te kunnen en welke handelingen daarvoor vereist zijn.

Een fictief goed antwoord noemt de overdrachtsstappen en maakt onderscheid tussen website, domein, mail en externe diensten. Vraag ook hoe tijdelijke toegang na de overdracht wordt beëindigd. De samenwerking netjes afronden is onderdeel van beheer.

Je hoeft niet te wachten tot er onenigheid is om dit te bespreken. Dezelfde duidelijkheid helpt wanneer een medewerker vertrekt of het bedrijf verandert. Een overdraagbare inrichting geeft rust zonder dat je daarom meteen van leverancier hoeft te wisselen.

20. Welk bewijs krijg ik na belangrijk werk?

Vraag om een korte samenvatting met de wijziging, omgeving, uitgevoerde controles en resterende open punten. Dat hoeft geen uitgebreid technisch rapport te zijn. Het moet jou en een volgende beheerder wel helpen begrijpen wat werkelijk is gebeurd.

Een bruikbaar antwoord onderscheidt plan, uitvoering en live controle. “Update klaargezet” betekent iets anders dan “update actief en formulier nagekeken”. Vraag om die precisie, ook wanneer AI een deel van het werk uitvoert. De formulering in een verslag moet aansluiten op het bewijs.

Bewaar de samenvattingen bij de websiteafspraken. Na enkele maanden ontstaat zo een bruikbaar beeld van het beheer. Niet omdat iedere handeling groot gemaakt wordt, maar omdat belangrijke beslissingen terug te vinden zijn zonder oude gesprekken te moeten reconstrueren.

Hoe beoordeel je de antwoorden zonder technisch expert te zijn?

Wij zouden antwoorden in drie groepen verdelen. Eerst: helder en onderbouwd. Daarna: logisch, maar nog niet aangetoond. Ten slotte: onbekend of tegenstrijdig. Zo voorkom je dat alles in één vaag oordeel “goed” of “slecht” verdwijnt. Het tweede vak vraagt vaak een gerichte controle. Het derde vraagt eerst opheldering.

Maak vervolgens een kleine actielijst met eigenaar, eerstvolgende stap en moment van terugkoppeling. Begin bij onderwerpen die direct toegang, herstel of belangrijke klantprocessen raken. Een ontbrekende beschrijving van een minder belangrijke pagina hoeft niet dezelfde prioriteit te krijgen als onduidelijkheid over wie je domein kan beheren.

Dit is een beslisroute, geen puntensysteem voor veiligheid. Twintig mooie antwoorden bewijzen niet dat er nergens een probleem bestaat. Ze maken het wel eenvoudiger om verantwoordelijkheid, bewijs en ontbrekende afspraken te zien. Daar kun je als ondernemer gericht op sturen.

Veelgestelde vragen

Meer uitleg bij de vragen

• De PHP-melding van oktober 2026.
• Website zonder PHP: techniek kiezen op functie.
• PHP updaten met een controleplan.
• WordPress, PHP en plugins begrijpen.
• Cloudflare en de grenzen van aanvullende bescherming.
• Backup en hersteltest praktisch bespreken.
• AI gebruiken met begrensde toegang.
• Een website voor €75 per maand beoordelen.
• Overstappen met behoud van waardevolle routes.

Voor de technische basis vind je informatie bij technische SEO en onze WordPress-dienst. Je kunt zelfstandig verder bij zelf leren, onze prijzen bekijken of lezen wie wij zijn. Het doel blijft hetzelfde: je hoeft niet alles zelf te kunnen bouwen, maar je moet wel begrijpen wat er voor jouw website geregeld is.