Een website security checklist hoort niet aan het einde van de build te komen. De checklist moet bepalen hoe de website wordt gepland, ontwikkeld, getest en overgedragen.
Voor Nederlandse mkb-bedrijven is de website vaak de publieke laag voor leadgeneratie, klantenservice, recruitment, e-commerce of klantportalen. Als security pas bij de lancering wordt opgepakt, wordt het ontwikkelproces meestal lastiger te beheersen. Teams ontdekken zwakke admin-toegang, verouderde plugins, ontbrekende logging, onduidelijk back-up-eigenaarschap of onveilige scripts van derden nadat ontwerp- en ontwikkelbeslissingen al zijn genomen.
Deze website security checklist geeft IT-managers, CTOs, Heads of Product en founders van Nederlandse mkb-bedrijven een praktische manier om het websiteontwikkelproces vóór lancering te verbeteren. Voor een breder planningsmodel koppelt u deze checklist aan onze websiteontwikkelingsgids, zodat security vanaf het begin onderdeel wordt van scope, architectuur, QA en eigenaarschap.
TL;DR
Een security baseline voor Nederlandse mkb-websites moet beginnen met drie fixes: HTTPS/TLS correct afdwingen, CMS- en serveradmin-toegang beschermen met MFA, en CMS, plugins, thema’s en dependencies patchen. Daarna controleert u 28 checks voor authenticatie, TLS, secure coding, patching, browserheaders, logging, back-ups, CMS-hardening en scripts van derden. Gebruik NCSC NL-richtlijnen als Nederlands referentiepunt.
● Los TLS, admin-authenticatie en patching op vóór cosmetische of performancewerkzaamheden.
● Behandel een RED-finding in toegangsbeheer of TLS als een actief securityrisico.
● Koppel findings aan ISO 27001:2022-controls wanneer bewijs nodig is voor procurement of certificering.
● Gebruik deze checklist als de technische securitylaag. Gebruik voor privacy en consent de AVG-compliance checklist.
Waarom websitebeveiliging specifiek belangrijk is voor Nederlandse mkb-bedrijven
Een website security checklist is een gestructureerde review van de controls die toegang, transportbeveiliging, code, dependencies, logging, back-ups, CMS-configuratie en scripts van derden beschermen. Nederlandse mkb-bedrijven draaien vaak bedrijfskritische websites met beperkte interne securitycapaciteit. Die combinatie levert een praktisch probleem op: de website wordt misschien beheerd door marketing, een extern bureau, een freelance developer of een klein IT-team, maar de securityverantwoordelijkheid blijft bij het bedrijf liggen.
De meest voorkomende zwakke plekken zijn zelden exotisch. Meestal gaat het om eenvoudige controls die niet zijn afgerond: voorspelbare CMS-admin-URLs, geen MFA, oude plugins, verouderde TLS, ontbrekende securityheaders, geen geteste back-up of geen duidelijk incidentproces.
De NCSC NL-richtlijnen voor webapplicaties zijn hier nuttig omdat ze zijn geschreven voor organisaties die webapplicaties ontwikkelen, beheren, inkopen of uitbesteden. Ze ondersteunen leveranciersafspraken, toezicht en praktische security-eisen, niet alleen interne engineeringreviews.
De 3 securityfixes die Nederlandse mkb-websites nu nodig hebben
1. TLS-configuratie en HTTPS
Elke pagina moet via HTTPS laden, HTTP moet doorverwijzen naar HTTPS en er mogen geen mixed-content-waarschuwingen zijn. TLS 1.0 en TLS 1.1 moeten worden uitgeschakeld. NCSC NL onderhoudt actuele TLS-richtlijnen en biedt de nieuwste versie van de TLS-richtlijn via de TLS-pagina.
Eerst oplossen: controleer HTTPS-redirects, certificaatgeldigheid, ondersteuning voor TLS-versies en HSTS.
Typische inspanning: minder dan één dag voor een standaardwebsite wanneer hostingtoegang beschikbaar is.
2. CMS- en admin-authenticatie
Een CMS-adminpaneel met alleen een wachtwoord is te zwak voor een zakelijke website. MFA moet zijn ingeschakeld voor alle CMS-admingebruikers, servertoegang, hostingcontrolpanels en deploymenttools.
Eerst oplossen: schakel MFA in, verwijder standaard admin-gebruikersnamen, beperk admin-toegang en voeg brute-force-bescherming toe.
Typische inspanning: dezelfde dag voor de meeste WordPress- of CMS-gebaseerde websites.
3. CMS-, plugin-, thema- en dependency-patching
Niet-gepatchte software is een van de makkelijkste websiterisico’s om te verkleinen. Bij WordPress ligt het probleem vaak niet bij WordPress core zelf. De laag met meer risico bestaat uit plugins, thema’s, verlaten extensies en oude dependencies waar niemand eigenaar van is.
Eerst oplossen: update CMS core, plugins, thema’s, npm/composer-dependencies en verwijder inactieve plugins.
Typische inspanning: één dag voor standaardsites; langer wanneer updates custom code of integraties raken.
De website security checklist: 28 checks in 7 secties
Gebruik de checklist als basisreview. Markeer elk item als GREEN, AMBER of RED.
GREEN betekent dat de control is geïmplementeerd en bewezen. AMBER betekent gedeeltelijk geïmplementeerd of niet gedocumenteerd. RED betekent ontbrekend, verouderd of actief risicovol. Een RED-item in authenticatie, TLS of patching moet worden opgelost voordat niet-securitygerelateerd websitewerk doorgaat.
| Sectie | Gebied | Checks | Prioriteit |
|---|---|---|---|
| A | Authenticatie en toegangsbeheer | 4 | Hoogste |
| B | Transportbeveiliging en TLS | 4 | Hoogste |
| C | Inputvalidatie en secure coding | 4 | Hoog |
| D | Dependency- en patchbeheer | 4 | Hoogste |
| E | Securityheaders en browserbescherming | 3 | Middel |
| F | Logging, monitoring en incidentrespons | 4 | Hoog |
| G | CMS-hardening en integraties van derden | 4 | Hoog |
Website security checklist: alle 7 secties
A. Authenticatie en toegangsbeheer
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| A1 | MFA is ingeschakeld voor alle CMS-adminaccounts, servertoegang en hostingcontrolpanels. | Screenshot van MFA-beleid of admin-gebruikersinstellingen | CMS-owner / DevOps / hostingbeheerder |
| A2 | Standaard CMS-admingebruikersnamen zoals “admin” zijn gewijzigd. | Gebruikerslijst met niet-standaard adminaccounts | CMS-owner / developer |
| A3 | CMS-adminlogin is niet alleen via een voorspelbaar standaardpad bereikbaar, of is beschermd met MFA, IP-allowlisting of een gelijkwaardige control. | Admin-toegangsregel of CMS-securityconfiguratie | Developer / DevOps / hostingbeheerder |
| A4 | Brute-force-bescherming is ingeschakeld op login-endpoints via rate limiting, lockout, CAPTCHA of gelijkwaardige controls. | Configuratie van securityplugin, WAF of serverregel | Developer / DevOps / CMS-owner |
B. Transportbeveiliging en TLS
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| B1 | De volledige website wordt via HTTPS aangeboden, HTTP verwijst door naar HTTPS en er zijn geen mixed-content-waarschuwingen. | Browsertest en crawlrapport | Hostingprovider / DevOps / developer |
| B2 | TLS 1.2 is de minimaal geaccepteerde versie, TLS 1.0 en 1.1 zijn uitgeschakeld en TLS 1.3 heeft de voorkeur waar dit wordt ondersteund. | TLS-scanresultaat | Hostingprovider / DevOps |
| B3 | SSL/TLS-certificaten zijn geldig, uitgegeven door een vertrouwde CA, dekken de vereiste subdomeinen en worden automatisch vernieuwd. | Certificaatrapport | Hostingprovider / DevOps |
| B4 | HSTS is ingeschakeld met een passende max-age-waarde. HSTS preload kan worden overwogen voor websites met hogere security-eisen. | Responseheader-rapport | DevOps / hostingbeheerder |
C. Inputvalidatie en secure coding
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| C1 | Formulieren, URL-parameters, zoekvelden en andere gebruikersinput worden gevalideerd en gesanitized vóór verwerking. | Secure coding review of testresultaat | Backend developer / QA |
| C2 | File uploads beperken bestandstypen, scannen geüploade bestanden en voorkomen dat uitvoerbare bestanden worden geüpload of aangeboden. | Uploadconfiguratie en testresultaat | Backend developer / DevOps / QA |
| C3 | API-endpoints zijn geauthenticeerd en rate-limited. Niet-geauthenticeerde endpoints stellen geen persoonsgegevens bloot en staan geen write-acties toe. | API-toegangscontrolereview | Backend developer / DevOps |
| C4 | Content Security Policy is geconfigureerd om het risico op cross-site scripting en kwaadaardige scriptinjectie te verkleinen. | CSP-headeroutput | Developer / DevOps |
D. Dependency- en patchbeheer
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| D1 | CMS core draait op de nieuwste stabiele versie, met snelle toepassing van security-updates. | CMS-versierapport | CMS-owner / developer |
| D2 | Plugins, thema’s en extensies zijn bijgewerkt; inactieve plugins zijn verwijderd. | Plugin-inventarisatie | CMS-owner / developer |
| D3 | JavaScript-libraries, npm/composer-packages en andere dependencies worden bijgehouden en bijgewerkt. | Dependency-inventarisatie | Frontend developer / backend developer |
| D4 | Vulnerability scanning draait minimaal elk kwartaal en na belangrijke websitewijzigingen. Critical en high findings hebben herstel-SLA’s. | Scanrapporten en hersteltracker | DevOps / security owner / product owner |
E. Securityheaders en browser-level bescherming
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| E1 | HTTP-securityheaders zijn geconfigureerd, waaronder CSP, X-Content-Type-Options, Referrer-Policy en frame-controls. | Headerscan | Developer / DevOps |
| E2 | Clickjacking-bescherming is ingeschakeld via X-Frame-Options of de CSP-richtlijn frame-ancestors. | Headerscan | |
| E3 | Gevoelige pagina’s cachen geen geauthenticeerde gebruikersdata of formulierinzendingen in de browser. | Cache-Control-review |
F. Logging, monitoring en incidentrespons
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| F1 | Logs registreren mislukte loginpogingen, admin-acties, bestandswijzigingen en foutmeldingen. Logs zijn beschermd en worden minimaal 90 dagen bewaard. | Logretentiebeleid | DevOps / hostingbeheerder / security owner |
| F2 | Er zijn alerts voor herhaald mislukte logins, nieuwe admingebruikers, plugininstallaties en onverwachte bestandswijzigingen. | Alertconfiguratie | DevOps / security owner |
| F3 | Een gedocumenteerd incidentproces legt uit wie wordt geïnformeerd, hoe de website wordt ingeperkt en wanneer de Autoriteit Persoonsgegevens moet worden geïnformeerd als persoonsgegevens betrokken zijn. | Incidentresponsdocument | Product owner / IT-manager / security owner |
| F4 | Website- en databaseback-ups draaien minimaal dagelijks, worden off-server opgeslagen en herstel is in de afgelopen 12 maanden getest. | Bewijs van back-up- en hersteltest | Hostingprovider / DevOps / IT-manager |
AVG Artikel 33 vereist melding aan de toezichthoudende autoriteit zonder onredelijke vertraging en, waar mogelijk, binnen 72 uur nadat een organisatie kennis heeft genomen van een datalek met persoonsgegevens, tenzij het onwaarschijnlijk is dat het datalek een risico oplevert voor de rechten en vrijheden van mensen.
G. CMS-hardening en integraties van derden
| # | Security check | Bewijs om te verzamelen | Wie lost dit op |
|---|---|---|---|
| G1 | CMS-configuratie is gehard: directory listing is uitgeschakeld, foutmeldingen tonen geen versies en PHP-uitvoering is waar relevant uitgeschakeld in uploaddirectories. | CMS-/serverconfiguratie | Developer / DevOps / CMS-owner |
| G2 | Scripts van derden, zoals analytics, chattools en marketingpixels, worden beheerd via consent en tag management. | Tag- en consentreview | Marketing owner / developer / privacy owner |
| G3 | Subresource Integrity wordt gebruikt waar dit passend is voor scripts van derden die vanuit CDNs worden geladen. | Script tag-review | Frontend developer |
| G4 | Hosting gebruikt least privilege: elke applicatie heeft een dedicated gebruiker en de webserver draait niet als root. | Hostingrechtenreview | DevOps / hostingbeheerder |
Wilt u risico uit de websitebuild halen vóór lancering?
Sunbytes kan uw CMS-setup, admin-toegang, TLS-configuratie, patch-eigenaarschap, logging, back-ups en scripts van derden reviewen vóór sprint één of vóór de pre-launch overdracht.
Review uw website ontwikkelplan met Sunbytes →
Waar deze checklist op aansluit: NCSC NL en ISO 27001:2022
De NCSC NL-richtlijnen geven het Nederlandse referentiekader voor webapplicatiebeveiliging. ISO 27001:2022 helpt teams om securitycontrols om te zetten in bewijs voor procurement, certificering, leveranciersreviews en interne audits.
Voor een websiteontwikkelproject is deze mapping belangrijk omdat security daardoor verandert van een vage eis in acceptatiecriteria. In plaats van te vragen of de website “secure” is, kan het team vragen of MFA, TLS, logging, patching, back-uptests en controls voor scripts van derden zijn geïmplementeerd en bewezen.
| Checklistsectie | NCSC NL-gebied | Voorbeelden van ISO 27001:2022-controls |
|---|---|---|
| A. Authenticatie en toegangsbeheer | Authenticatie, toegangsbeheer | A.8.5 secure authentication, A.8.2 privileged access rights |
| B. Transportbeveiliging en TLS | TLS en cryptografie | A.8.24 use of cryptography |
| C. Inputvalidatie en secure coding | Secure coding, inputvalidatie | A.8.26 application security requirements, A.8.28 secure coding |
| D. Dependency- en patchbeheer | Vulnerability- en patchbeheer | A.8.8 management of technical vulnerabilities, A.8.19 software on operational systems |
| E. Securityheaders | Browser-level bescherming | A.8.27 secure system architecture and engineering principles |
| F. Logging en incidentrespons | Logging, monitoring, continuïteit | A.8.15 logging, A.8.16 monitoring activities, A.5.26 incident response, A.8.13 backup |
| G. CMS-hardening en derden | Configuratie en third-party components | A.8.9 configuration management, A.8.30 outsourced development |
Wanneer u verder moet gaan dan de checklist: NIS2 en het volgende securityniveau
Deze checklist is een technische baseline voor Nederlandse mkb-websites. Het is geen volledig NIS2-complianceprogramma.
Als uw organisatie binnen de scope van NIS2 valt als essentiële of belangrijke entiteit, wordt websitebeveiliging onderdeel van een breder risicomanagementsysteem. Dat kan strengere leveranciersgovernance, incidentrapportage, business continuity, vulnerability handling, toegangsbeheer en gedocumenteerde securitymaatregelen omvatten.
Voor mkb-bedrijven buiten de NIS2-scope creëert de checklist nog steeds een verdedigbare baseline. Uw team ziet praktisch wat onder controle is, wat ontbreekt en wat als eerste moet worden opgelost.
Hoe Sunbytes de security baseline voor Nederlandse mkb-websites oplevert
Een secure website ontstaat niet door controls aan het einde toe te voegen. De basis ligt in vroege buildbeslissingen: CMS-eigenaarschap, pluginselectie, hostingsetup, toegangsbeheer, formulierafhandeling, logging, back-uptests en releaseverantwoordelijkheid.
Sunbytes gebruikt deze checklist binnen Digital Transformation Solutions om Nederlandse en Europese bedrijven te helpen websitebeveiligingseisen om te zetten in sprint-ready ontwikkeltaken vóór lancering. Cybersecurity Solutions ondersteunt de controllaag wanneer NCSC NL-alignment, ISO 27001-bewijs, toegangsbeheer of herstelplanning nodig is. Accelerate Workforce Solutions ondersteunt de mensenlaag wanneer gecontroleerde development-, QA- of securitycapaciteit nodig is om fixes te implementeren.
Met 15+ jaar ervaring, 300+ projecten opgeleverd, ISO-gecertificeerde delivery en DORA-gemeten resultaten helpt Sunbytes teams om van een checklist met risico’s naar een websiteontwikkelplan te gaan dat ze kunnen shippen en onderhouden.
Review uw websiteontwikkelplan met Sunbytes →
FAQs
Securityteams identificeren en prioriteren findings. Development, DevOps, hosting of CMS-owners lossen ze meestal op. TLS, headers, dependency-updates, beperkingen voor file uploads, logging en CMS-hardening moeten als sprintwerk worden toegewezen met een eigenaar, deadline en bewijs van hertest.
WordPress kan veilig genoeg zijn wanneer het goed wordt geconfigureerd, gepatcht en gemonitord. Het hogere risico ligt meestal niet bij WordPress core, maar bij zwakke admin-toegang, verouderde plugins, verlaten thema’s, slechte hostingconfiguratie en ontbrekende back-ups. Een managed WordPress-setup moet MFA, automatische security-updates, plugin-inventarisatie, vulnerability scanning en geharde admin-toegang bevatten.
NCSC NL publiceert ICT-beveiligingsrichtlijnen voor webapplicaties: een praktische gids voor het veilig ontwikkelen, beheren en aanbieden van webapplicaties en ondersteunende infrastructuur. De richtlijnen kunnen door zowel klanten als leveranciers worden gebruikt bij het vastleggen van security-eisen voor webapplicaties.
Een penetratietest is nuttig wanneer uw website gevoelige data, financiële transacties, gebruikersaccounts of complexe custom functionaliteit verwerkt. Voor mkb-websites met een lager risico kan een vulnerability scan en configuratiereview de eerste stap zijn. Hier is het verschil tussen security assessment versus vulnerabilityscan belangrijk: een scan vindt technische findings, terwijl een assessment helpt om risico, eigenaarschap en herstel te prioriteren. . Als u binnen de scope van NIS2 valt of zich voorbereidt op enterprise procurement, kan een penetratietest onderdeel worden van het verwachte bewijs.
Voer minimaal elk kwartaal een basisreview uit voor internet-facing websites, na grote wijzigingen en vóór de lancering van nieuwe functionaliteit die gebruikersdata verwerkt. Doe ook een review na pluginwijzigingen, hostingmigratie, CMS-upgrades, betaalintegraties of nieuwe scripts van derden. De praktische regel: controleer na elke wijziging die authenticatie, datastromen, code, hosting of tracking raakt.
Deze checklist is een self-assessment tool. CyberCheck is een begeleide security baseline assessment door Sunbytes. CyberCheck reviewt dezelfde controlgebieden, voegt specialistische interpretatie toe, prioriteert findings en zet het resultaat om in een herstelplan met effort-schattingen.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
