Testautomatisering onder Nederlandse wet- en regelgeving: wat moet het mkb werkelijk aantonen?

Een groene pipeline is nuttig. Maar zodra klanten, toezichthouders of auditors vragen hoe een digitaal risico wordt beheerst, is “alle tests zijn geslaagd” geen volledig antwoord meer.

Voor veel mkb-bedrijven voelt wet- en regelgeving rond software als een verzameling afkortingen: AVG, AI Act, Cyberbeveiligingswet, DORA, NEN 7510 en BIO2. Daardoor ontstaan twee verkeerde reacties. De eerste is onderschatting: dit geldt alleen voor grote organisaties. De tweede is overreactie: wij moeten blijkbaar aan alles voldoen.

Beide zijn riskant.

Niet iedere regeling geldt rechtstreeks voor ieder mkb-bedrijf. De werkelijke verplichting hangt af van de sector, omvang, dienstverlening, verwerkte gegevens, gebruikte AI en positie in de keten. Een kleinere softwareleverancier kan bovendien buiten de directe reikwijdte van een wet vallen, maar via een bank, zorginstelling of overheidsorganisatie alsnog stevige eisen opgelegd krijgen.

De relevante vraag is daarom niet:

Aan welke lijst met regels moeten wij voldoen?

Maar:

Welke risico’s moeten wij beheersen, welk bewijs moeten wij daarvan bewaren en hoe helpt testautomatisering daarbij?

Eerst het belangrijkste onderscheid: wet, norm en contract zijn niet hetzelfde

Mkb-bedrijven doen er goed aan vier soorten verplichtingen uit elkaar te houden.

1. Rechtstreeks toepasselijke wetgeving
   Denk aan de AVG wanneer persoonsgegevens worden verwerkt, of aan de Cyberbeveiligingswet wanneer de organisatie binnen het wettelijke toepassingsbereik valt.

2. Sectorale regelgeving
   DORA richt zich op financiële entiteiten en hun digitale operationele weerbaarheid. Een willekeurig mkb-bedrijf valt daar niet automatisch onder.

3. Normen en baselines
   NEN 7510 is een norm voor informatiebeveiliging in de zorg. BIO2 is de baseline voor de overheid. Deze kaders zijn niet generiek van toepassing op ieder Nederlands bedrijf, maar kunnen door sector, opdracht of contract wel relevant worden.

4. Keten- en contracteisen
   Een klant die zelf onder toezicht staat, kan van leveranciers eisen dat zij beveiliging, continuïteit, logging, incidentafhandeling en testresultaten aantoonbaar beheersen. Voor veel mkb-leveranciers ontstaat de praktisch zwaarste druk hier.

Dit onderscheid voorkomt dat een bedrijf geld uitgeeft aan een breed complianceprogramma zonder eerst vast te stellen welke verplichtingen werkelijk gelden.

Welke regels kunnen voor het mkb relevant zijn?

1. De AVG: vrijwel altijd relevant zodra tests persoonsgegevens raken

De AVG geldt voor organisaties die persoonsgegevens verwerken. Dat raakt testautomatisering sneller dan teams denken. Productiedata wordt gekopieerd naar een testomgeving, logbestanden bevatten e-mailadressen, screenshots tonen klantgegevens of een performance-test genereert transacties met herleidbare gebruikersinformatie.

De testomgeving is juridisch geen vrijplaats. Ook daar moeten doelbinding, dataminimalisatie, passende beveiliging en bewaartermijnen worden gerespecteerd.

Voor management betekent dit onder meer:

• bepaal of persoonsgegevens in ontwikkel- en testprocessen noodzakelijk zijn;
• leg vast wie toegang heeft tot testdata en testresultaten;
• maak afspraken met externe test-, cloud- en toolingpartners;
• beoordeel of een verwerking met hoog privacyrisico een DPIA vereist;
• neem testomgevingen mee in het datalek- en verwijderproces.

Voor test- en ontwikkelteams vertaalt dit zich naar:

• synthetische data als standaard;
• maskering of anonimisering wanneer realistische data noodzakelijk is;
• geautomatiseerde controles op gevoelige gegevens in logs, rapportages en artefacten;
• beperkte toegang tot testomgevingen en secrets;
• automatische opschoning volgens bewaartermijnen;
• negatieve tests op autorisatie, gegevensscheiding en verwijdering.

Een functioneel geslaagde test kan dus alsnog een privacyprobleem veroorzaken wanneer de testdata onnodig echte persoonsgegevens bevat.

2. De Cyberbeveiligingswet: rechtstreeks voor sommigen, indirect voor veel meer bedrijven

De Nederlandse Cyberbeveiligingswet, waarmee de Europese NIS2-richtlijn is ingevoerd, is op 15 augustus 2026 in werking getreden. De wet geldt voor organisaties binnen aangewezen kritieke sectoren en brengt onder meer registratie, risicobeheer, beveiligingsmaatregelen, incidentmelding en bestuurlijke betrokkenheid met zich mee.

Niet elk mkb-bedrijf valt rechtstreeks onder de wet. Omvang, sector en type dienstverlening zijn bepalend en er bestaan uitzonderingen en bijzondere aanwijzingsmogelijkheden. Dat moet juridisch per organisatie worden vastgesteld.

Toch kan de wet ook buiten haar directe toepassingsbereik gevolgen hebben. Organisaties die er wél onder vallen, moeten risico’s in hun toeleveringsketen beheersen. Zij zullen daarom scherper kijken naar softwareleveranciers, managed-serviceproviders, hostingpartijen en andere digitale partners.

Een mkb-leverancier kan dan vragen krijgen als:

• Hoe worden beveiligingswijzigingen getest voordat ze naar productie gaan?
• Kunnen jullie aantonen welke versie, configuratie en afhankelijkheden zijn getest?
• Worden kwetsbaarheden en mislukte beveiligingscontroles zichtbaar opgevolgd?
• Hoe testen jullie herstel, back-ups en continuïteit?
• Welke kritieke leveranciers en open-sourcecomponenten zitten in de keten?
• Kunnen testresultaten worden gekoppeld aan risico’s en beheersmaatregelen?

Hier verandert testautomatisering van intern engineeringgereedschap in aantoonbare ketenbeheersing.

3. De AI Act: relevant door het gebruik én de bestemming van AI

De Europese AI Act werkt risicogestuurd. De verplichtingen verschillen naar gelang een organisatie aanbieder, gebruiksverantwoordelijke, importeur of distributeur is en welk type AI-systeem wordt ingezet. Niet iedere AI-functie is een hoog-risicosysteem.

Voor mkb-bedrijven is vooral van belang dat “wij gebruiken alleen een externe AI-dienst” niet automatisch betekent dat er geen verantwoordelijkheid bestaat. De toepassing kan bepalend zijn. AI voor tekstsuggesties heeft een ander risicoprofiel dan AI die kandidaten selecteert, kredietwaardigheid beoordeelt of beslissingen in een gereguleerd proces ondersteunt.

Bij hoog-risico-AI legt de verordening nadruk op onder meer risicobeheer, datakwaliteit, technische documentatie, logging, menselijke controle, nauwkeurigheid, robuustheid en cybersecurity. Voor aanbieders horen daar expliciete test- en validatieprocedures bij vóór, tijdens en na ontwikkeling bij.

Testteams moeten daarom verder kijken dan één verwacht antwoord. Relevante controles zijn bijvoorbeeld:

• prestaties per relevante gebruikersgroep en scenario;
• reproduceerbaarheid en versiebeheer van modellen, prompts en datasets;
• afwijkend gedrag bij onvolledige, gemanipuleerde of vijandige invoer;
• grenzen waarbinnen menselijke tussenkomst vereist is;
• logging van input, output, modelversie en besliscontext;
• regressie na wijzigingen aan model, prompt, data of externe dienst;
• veilige fallback wanneer de AI-dienst faalt of onbetrouwbare output geeft.

Een traditionele pass/fail-test is daarvoor vaak te beperkt. AI-systemen vragen om vooraf vastgestelde toleranties, scenarioverdelingen, monitoring en expliciete acceptatie van restrisico.

4. DORA: geen algemene mkb-wet, maar wel voelbaar in de financiële keten

DORA is sinds 17 januari 2025 van toepassing. De verordening richt zich op digitale operationele weerbaarheid in de financiële sector. Zij omvat onder meer ICT-risicobeheer, incidenten, weerbaarheidstesten en risico’s van externe ICT-dienstverleners.

Een mkb-bedrijf buiten de financiële sector valt niet alleen door het leveren van software automatisch volledig onder DORA. Maar banken, verzekeraars, betaalinstellingen en andere financiële klanten moeten hun leveranciersrisico’s wel beheersen en contractueel vastleggen.

Daardoor kunnen leveranciers worden gevraagd om bewijs over:

• beschikbaarheid en herstelbaarheid;
• incidentdetectie en -opvolging;
• wijzigingsbeheer en scheiding van verantwoordelijkheden;
• periodieke tests van kritieke processen;
• afhankelijkheden en onderaannemers;
• toegang tot informatie voor audits en toezicht.

Voor een leverancier is het inefficiënt om voor iedere financiële klant een losse bewijsset te bouwen. Een herbruikbaar control-to-evidence-model is sterker: per beheersmaatregel wordt vastgelegd welke test, log, goedkeuring of rapportage het bewijs levert.

5. NEN 7510: relevant voor zorgorganisaties en hun leveranciers

NEN 7510 biedt een normatief kader voor informatiebeveiliging in de zorg. De norm is niet simpelweg een algemene wet voor alle mkb-bedrijven. Voor zorgorganisaties, beheerders van gezondheidsinformatie en leveranciers in de zorgketen kan zij echter rechtstreeks vanuit sectorverplichtingen, contracten en klantverwachtingen zwaar meewegen.

Testautomatisering kan hier bewijs leveren voor bijvoorbeeld:

• toegangsbeveiliging en functiescheiding;
• bescherming van gezondheidsgegevens;
• logging en controleerbaarheid;
• veilige configuratie en wijziging;
• continuïteit en herstel;
• tijdige verwijdering of afscherming van gegevens.

De fout die teams vaak maken, is alleen het normale gebruikerspad automatiseren. Juist in een zorgcontext zijn misbruikscenario’s, ongeautoriseerde toegang, foutieve gegevensscheiding en falende logging minstens zo belangrijk.

6. BIO2: vooral relevant wanneer het mkb voor de overheid werkt

BIO2 is de vernieuwde Baseline Informatiebeveiliging Overheid. Het is geen algemene mkb-regel. Voor bedrijven die software ontwikkelen, beheren of hosten voor overheidsorganisaties kan BIO2 wel onderdeel worden van aanbestedingen, contractvoorwaarden en leveranciersbeoordelingen.

Daarmee komt een praktische eis op tafel: een leverancier moet niet alleen zeggen dat een maatregel is geïmplementeerd, maar vaak ook kunnen laten zien dat deze consequent werkt.

Een screenshot van één geslaagde test is daarvoor zwak bewijs. Sterker zijn versioneerbare testdefinities, onveranderbare resultaten, gekoppelde changes, formele uitzonderingen en een zichtbare opvolging van fouten.

Wanneer wordt een groene pipeline werkelijk bewijs?

Een pipeline is geen bewijs omdat hij groen is. Hij wordt bruikbaar bewijs wanneer een derde kan reconstrueren:

1. Welk risico werd beheerst?
   Bijvoorbeeld ongeautoriseerde toegang tot gezondheidsgegevens.

2. Welke beheersmaatregel hoorde daarbij?
   Bijvoorbeeld functiescheiding en afdwingbare autorisatieregels.

3. Welke test controleerde die maatregel?
   Inclusief negatieve scenario’s en relevante rollen.

4. Wat is precies getest?
   Codeversie, configuratie, omgeving, testdata en afhankelijkheden.

5. Wat was het resultaat?
   Niet alleen geslaagd of mislukt, maar ook afwijkingen, toleranties en uitgesloten scenario’s.

6. Wie accepteerde het restrisico?
   Een technische uitzondering mag niet stilzwijgend veranderen in een bedrijfsbesluit.

7. Is het bewijs integer en terugvindbaar?
   Resultaten moeten voldoende lang, veilig en controleerbaar worden bewaard.

Dit vraagt geen duur complianceplatform als eerste stap. Het vraagt vooral discipline in de koppeling tussen risico, maatregel, test en besluit.

Een werkbaar model voor het mkb

Voor de meeste mkb-bedrijven is een risicogestuurde aanpak haalbaarder dan een enorme generieke controleset.

Stap 1 — Bepaal de reikwijdte

Breng samen met juridische, privacy- en securitykennis in kaart:

• in welke sector het bedrijf en zijn klanten actief zijn;
• welke persoonsgegevens en bijzondere gegevens worden verwerkt;
• of AI wordt ontwikkeld, geïntegreerd of gebruikt;
• welke diensten bedrijfskritiek zijn;
• welke contractuele normen en auditrechten gelden;
• of de organisatie rechtstreeks onder sectorspecifieke regels valt.

Stap 2 — Kies de kritieke bedrijfsrisico’s

Begin niet met honderd controles. Selecteer bijvoorbeeld de tien risico’s die klanten, bedrijfscontinuïteit of betrokken personen werkelijk kunnen schaden.

Stap 3 — Koppel risico’s aan geautomatiseerd bewijs

Leg per risico vast:

• de eigenaar;
• de beheersmaatregel;
• de geautomatiseerde en handmatige controles;
• de testfrequentie;
• de bewaarplaats van resultaten;
• de escalatie bij falen;
• de persoon die uitzonderingen mag accepteren.

Stap 4 — Maak de pipeline controleerbaar

Zorg minimaal voor:

• versioneerbare tests en configuraties;
• herleidbaarheid naar change of release;
• beveiligde opslag van resultaten;
• inzicht in overgeslagen en instabiele tests;
• bescherming van secrets en testdata;
• expliciete goedkeuring voor uitzonderingen;
• periodieke controle of tests nog het bedoelde risico afdekken.

Stap 5 — Test ook de organisatie

Niet iedere beheersmaatregel past in code. Herstelprocedures, incidentrespons, communicatie en besluitvorming moeten worden geoefend. Automatiseer waar het betrouwbaar kan, maar doe niet alsof een geautomatiseerde test menselijke paraatheid bewijst.

Een realistisch 90-dagenplan

Dag 1–30: toepasselijkheid en grootste gaten

• wijs één verantwoordelijke vanuit management aan;
• stel vast welke wetgeving, normen en contracten relevant zijn;
• inventariseer testdata, kritieke systemen, AI-gebruik en ketenpartners;
• controleer of productiegegevens onnodig in testomgevingen staan;
• selecteer de tien belangrijkste digitale risico’s.

Dag 31–60: bewijs organiseren

• koppel risico’s aan maatregelen en bestaande tests;
• voeg ontbrekende security-, privacy- en hersteltests toe;
• registreer versies, omgevingen, resultaten en uitzonderingen;
• bepaal bewaartermijnen en toegangsrechten;
• maak duidelijk wie falende controles beoordeelt.

Dag 61–90: aantoonbaarheid oefenen

• kies één kritieke release en bouw daarvoor een volledige bewijsset;
• laat iemand buiten het ontwikkelteam reconstrueren wat is getest;
• oefen een incident- of herstelscenario;
• bespreek resterende risico’s met directie of proceseigenaar;
• verbeter alleen die onderdelen die aantoonbaar onvoldoende werken.

Wat het management niet aan het testteam moet delegeren

Testprofessionals kunnen controles automatiseren en de kwaliteit van bewijs verhogen. Zij kunnen echter niet zelfstandig bepalen welk bedrijfsrisico aanvaardbaar is.

Het management blijft verantwoordelijk voor:

• de toepasselijkheid van wet- en regelgeving;
• prioriteiten en beschikbare middelen;
• eigenaarschap van kritieke risico’s;
• acceptatie van restrisico;
• afspraken met klanten en leveranciers;
• opvolging wanneer controles structureel falen.

“De pipeline was groen” mag daarom nooit het eindpunt van bestuurlijke verantwoording zijn.

Conclusie: begin niet bij compliance, begin bij bewijs

Voor het mkb is het onhaalbaar en onnodig om iedere denkbare norm volledig in een testframework te vertalen. De betere route is smaller en scherper:

1. bepaal wat werkelijk van toepassing is;
2. selecteer de risico’s die ertoe doen;
3. koppel ieder risico aan een concrete maatregel;
4. automatiseer herhaalbare controles;
5. bewaar bewijs dat een ander kan begrijpen;
6. laat management beslissen over uitzonderingen en restrisico.

Goede testautomatisering versnelt dan niet alleen softwareontwikkeling. Zij maakt zichtbaar of een organisatie haar digitale beloften werkelijk kan waarmaken.

Een groene pipeline zegt: de uitgevoerde tests zijn geslaagd.

Een volwassen bewijsmodel zegt: dit risico, in deze versie, onder deze omstandigheden, is met deze controle onderzocht—en dit is wat wij met de uitkomst hebben gedaan.

Dat verschil wordt voor steeds meer mkb-bedrijven bepalend voor vertrouwen, toegang tot ketens en het behouden van klanten.

Kader: snelle toepasselijkheidscheck

Deze tabel is een startpunt, geen juridische kwalificatie. Laat de toepasselijkheid bij twijfel beoordelen door een deskundige.

Bronnen en actualiteit

Dit artikel is inhoudelijk gecontroleerd op 15 augustus 2026. Wetgeving, uitvoeringsregels en officiële uitleg kunnen veranderen.

• NCSC — Cyberbeveiligingswet (NIS2)
• NCSC — De Cyberbeveiligingswet en toeleveranciers
• NCSC — Zorgplicht
• EUR-Lex — Verordening (EU) 2024/1689 (AI Act)
• De Nederlandsche Bank — DORA
• Autoriteit Persoonsgegevens — De AVG in het kort
• Autoriteit Persoonsgegevens — DPIA
• Digitale Overheid — Baseline Informatiebeveiliging Overheid
• NEN — informatie over NEN 7510 en ondersteuning voor het mkb

Redactionele disclaimer: dit artikel biedt algemene informatie en is geen juridisch advies. De concrete verplichtingen hangen af van sector, omvang, dienstverlening, contracten, gegevensverwerking en de rol van de organisatie in de keten.