Wat is penetratietesten?

Penetratietesten (pentesten) is een gecontroleerde, geautoriseerde beveiligingsbeoordeling waarbij gekwalificeerde testers aanvallen uit de praktijk simuleren op uw systemen, applicaties of netwerken om exploiteerbare kwetsbaarheden te identificeren voordat kwaadwillende actoren ze vinden. In tegenstelling tot geautomatiseerde kwetsbaarheidsscans omvat penetratietesten handmatige exploitatiepogingen, creatieve aanvalsketens en bedrijfslogicatesten die geautomatiseerde tools niet kunnen repliceren. Het doel is om daadwerkelijke beveiligingszwakheden te vinden en aan te tonen, hun bedrijfsimpact te beoordelen en bruikbare herstelrichtlijnen te bieden.

Wat is het verschil tussen penetratietesten en kwetsbaarheidsscanning?

Kwetsbaarheidsscanning is een geautomatiseerd proces dat bekende kwetsbaarheden identificeert door systeemconfiguraties en softwareversies te vergelijken met een database van bekende problemen. Het is snel, breed en kan frequent worden uitgevoerd, maar produceert vals-positieven en kan de daadwerkelijke exploiteerbaarheid niet beoordelen. Penetratietesten is een handmatig, vakkundig proces waarbij testers actief proberen kwetsbaarheden te exploiteren, bevindingen aan elkaar te koppelen en de reele impact te beoordelen. Pentesten vinden bedrijfslogicafouten, authenticatieomzeilingen en complexe aanvalspaden die scanners missen. De meeste beveiligingsprogramma's hebben beide nodig — regelmatige geautomatiseerde scanning aangevuld met periodieke handmatige penetratietesten.

Hoe vaak moet een bedrijf penetratietesten uitvoeren?

Best practice is om penetratietesten minstens jaarlijks uit te voeren, met aanvullende testen bij significante wijzigingen aan uw applicatie, infrastructuur of architectuur. Veel complianceframeworks vereisen jaarlijkse testen: ISO 27001 (Annex A.8.8), SOC 2 (CC7.1), PCI DSS (Vereiste 11.3) en NIS2 (Artikel 21). Organisaties met een hoog risicoprofiel of frequente releases testen mogelijk elk kwartaal. Continue penetratietestdiensten, waarbij testers een doorlopende opdracht onderhouden, worden steeds gebruikelijker voor SaaS-bedrijven met snelle ontwikkelcycli.

Wat zijn de verschillende soorten penetratietesten?

De belangrijkste soorten zijn: black-boxtesten (testers hebben geen voorkennis van het systeem, simuleren een externe aanvaller); white-boxtesten (testers hebben volledige toegang tot broncode, architectuur en documentatie, waardoor diepere analyse mogelijk is); grey-boxtesten (testers hebben gedeeltelijke kennis, doorgaans toegang op gebruikersniveau, simuleren een geauthenticeerde aanvaller); externe testen (gericht op internetgerichte systemen — webapplicaties, API's, e-mail, DNS); interne testen (simuleren een insiderdreiging of post-breach-scenario binnen het netwerk); en applicatiespecifieke testen (gericht op webapplicaties, mobiele apps, API's of cloudinfrastructuur).

Wat bevat een penetratietestrapport?

Een uitgebreid pentestrapport bevat: een managementsamenvatting met risiconiveauoverzicht en belangrijkste bevindingen; methodologiebeschrijving (scope, tools, aanpak); gedetailleerde bevindingen met ernstclassificaties (Kritiek, Hoog, Gemiddeld, Laag, Informatief); proof-of-concept-bewijs dat elke kwetsbaarheid aantoont; bedrijfsimpactbeoordeling per bevinding; specifieke herstelaanbevelingen geprioriteerd op ernst; en een hertestbevestiging nadat fixes zijn toegepast. Het rapport dient een dubbel doel — als technische herstalgids voor uw engineeringteam en als compliancebewijs voor auditors en kopers.

Hoe verhoudt penetratietesten zich tot ISO 27001?

ISO 27001:2022 behandelt penetratietesten via Annex A-controle A.8.8 (Beheer van technische kwetsbaarheden), die vereist dat organisaties technische kwetsbaarheden identificeren en aanpakken, en A.5.36 (Conformiteit met beleid, regels en normen), wat onafhankelijke beveiligingstesten omvat. Hoewel ISO 27001 penetratietesten niet expliciet bij naam verplicht, verwachten certificeringsauditors bewijs van technische kwetsbaarheidsbeoordeling die verder gaat dan geautomatiseerde scanning. Jaarlijkse penetratietesten zijn de de facto standaard geworden voor ISO 27001-gecertificeerde organisaties.

Zijn penetratietesten vereist door NIS2 en DORA?

NIS2 Artikel 21 vereist passende beveiligingsmaatregelen, waaronder kwetsbaarheidsbehandeling en beveiligingstesten, wat toezichthouders interpreteren als inclusief penetratietesten. DORA gaat verder met expliciete vereisten: Artikel 25 verplicht 'geavanceerde testen van ICT-tools, -systemen en -processen op basis van dreigingsgestuurde penetratietesten (TLPT)' voor significante financiele entiteiten. Door DORA verplichte TLPT moet het TIBER-EU-framework volgen en worden uitgevoerd door gekwalificeerde externe testers. Zelfs entiteiten die niet onder verplichte TLPT onder DORA vallen, moeten regelmatige penetratietesten uitvoeren als onderdeel van hun digitale operationele weerbaarheidstestprogramma.

Hoe moeten pentestresultaten worden gedeeld met kopers en partners?

Penetratietestresultaten bevatten gevoelige informatie over uw kwetsbaarheden en moeten zorgvuldig worden gedeeld. Best practices omvatten: het publiceren van een samenvatting (niet het volledige rapport) op uw Trust Center met belangrijkste bevindingen en herstelstatus; het delen van volledige rapporten alleen onder NDA via beveiligde Trust Center-toegang; het verstrekken van attestatiebrieven van het testbedrijf die bevestigen dat de test is uitgevoerd en bevindingen zijn verholpen; het opnemen van pentestfrequentie en -scope in uw beveiligingsdocumentatie; en het beschikbaar stellen van het testbedrijf voor referentiegesprekken met kopers indien nodig. Deel nooit onbewerkte pentestrapportage openbaar — ze vormen een routekaart voor aanvallers als kwetsbaarheden niet volledig zijn verholpen.

Penetratietesten: wat het is, hoe het werkt en waarom B2B-bedrijven het nodig hebben

Published 7 mrt 2026

By Emre Salmanoglu

Penetratietesten: wat het is, hoe het werkt en waarom B2B-bedrijven het nodig hebben

Een praktische gids over penetratietesten — wat het is, de verschillende soorten, hoe het proces werkt, hoe vaak u moet testen, wat u met resultaten doet en hoe pentesten passen binnen complianceframeworks zoals ISO 27001, SOC 2, NIS2 en DORA.

penetratietesten

beveiligingstesten

kwetsbaarheidsbeheer

compliance

ISO 27001

SOC 2

Penetratietesten: wat het is, hoe het werkt en waarom B2B-bedrijven het nodig hebben

Penetratietesten zijn een gecontroleerde beveiligingsbeoordeling waarbij gekwalificeerde testers aanvallen uit de praktijk simuleren op uw systemen, applicaties of netwerken. Het doel is eenvoudig: exploiteerbare kwetsbaarheden vinden voordat aanvallers dat doen.

Voor B2B-softwarebedrijven dienen penetratietesten twee doelen. Ten eerste verbetert het de beveiliging direct door zwakheden te identificeren die geautomatiseerde tools missen — bedrijfslogicafouten, authenticatieomzeilingen, complexe aanvalsketens. Ten tweede levert het bewijs dat zakelijke kopers, auditors en toezichthouders vereisen. Een recent penetratietestrapport is een van de meest gevraagde documenten in beveiligingsbeoordelingen van leveranciers.

Deze gids behandelt hoe penetratietesten werken, de verschillende soorten, hoe het past binnen complianceframeworks en hoe u resultaten deelt met kopers.

Hoe penetratietesten werken

Het penetratietestproces

Een typische penetratietest volgt een gestructureerde methodologie:

1. Scoping en planning

Definieer wat binnen de scope valt (applicaties, netwerken, API's, cloudinfrastructuur)
Leg de testmethodologie en regels van betrokkenheid vast
Stel het testvenster en communicatieprotocollen in
Verkrijg schriftelijke autorisatie (cruciaal — testen zonder autorisatie is illegaal)

2. Verkenning

Verzamel informatie over het doelwit (domeinnamen, IP-bereiken, technologiestack)
Breng het aanvalsoppervlak in kaart (blootgestelde diensten, toegangspunten, authenticatiemechanismen)
Identificeer potentiele kwetsbaarheidsgebieden op basis van technologie en architectuur

3. Kwetsbaarheidsidentificatie

Gebruik geautomatiseerde scantools om bekende kwetsbaarheden te identificeren
Handmatige testen voor bedrijfslogicafouten, toegangscontroleproblemen en configuratiezwakheden
Beoordeel authenticatie- en sessiebeheersmechanismen
Test invoervalidatie en gegevensverwerking

4. Exploitatie

Probeer geidentificeerde kwetsbaarheden te exploiteren om te bevestigen dat ze echt zijn
Koppel meerdere bevindingen aan elkaar om reele aanvalsscenario's te demonstreren
Beoordeel wat een aanvaller via elke kwetsbaarheid zou kunnen bereiken
Documenteer proof-of-concept-bewijs voor elke bevinding

5. Post-exploitatie

Beoordeel de impact van succesvolle exploitatie (gegevenstoegang, privilegeverhoging, laterale beweging)
Bepaal welke gevoelige gegevens of systemen gecompromitteerd zouden kunnen worden
Evalueer detectie- en responsmogelijkheden — hebben monitoringtools de test gedetecteerd?

6. Rapportage en herstel

Lever gedetailleerd rapport met bevindingen, ernstclassificaties en herstelrichtlijnen
Presenteer resultaten aan technische en leidinggevende stakeholders
Ondersteun herstelwerkzaamheden met verduidelijking en begeleiding
Voer hertesten uit om te verifieren dat fixes effectief zijn

Soorten penetratietesten

Op kennisniveau

Type	Kennis van tester	Simuleert	Meest geschikt voor
Black box	Geen voorinformatie	Externe aanvaller	Realistische aanvalssimulatie
White box	Volledige toegang (broncode, architectuur)	Insiderdreiging of diepgaande analyse	Uitgebreide testen op codeniveau
Grey box	Gedeeltelijke toegang (gebruikersreferenties, beperkte documentatie)	Geauthenticeerde aanvaller	Applicatiebeveiligingstesten

Op doelwit

Webapplicatietesten

OWASP Top 10-kwetsbaarheden (injectie, gebroken authenticatie, XSS, enz.)
Bedrijfslogicafouten (prijsmanipulatie, workflowomzeilingen)
API-beveiliging (authenticatie, autorisatie, invoervalidatie)
Sessiebeheer en toegangscontrole

Netwerk-/infrastructuurtesten

Externe perimetertesten (internetgerichte systemen)
Interne netwerktesten (simulatie van post-breach of insider)
Draadloze netwerkbeveiliging
Beoordeling van cloudinfrastructuurconfiguratie

Mobiele applicatietesten

Client-side beveiliging (gegevensopslag, certificaatpinning)
API-communicatiebeveiliging
Authenticatie en sessieafhandeling
Platformspecifieke kwetsbaarheden (iOS, Android)

Cloudbeveiligingstesten

Beoordeling van cloudconfiguratie (IAM, opslag, netwerken)
Container- en Kubernetes-beveiliging
Serverloze functiebeveiliging
Cloud-native aanvalspaden

Gespecialiseerde testen

Social engineering

Phishingsimulaties
Fysieke beveiligingstesten
Vishing (voice phishing)-beoordelingen

Red team-beoordelingen

Volledige adversarysimulatie
Doelgebaseerd (niet kwetsbaarheidsgebaseerd)
Test detectie en respons, niet alleen preventie
Doorgaans langere opdrachten (weken tot maanden)

Dreigingsgestuurde penetratietesten (TLPT)

Intelligence-gestuurde testen gebaseerd op echte dreigingsactor-TTP's
Vereist door DORA voor significante financiele entiteiten
Volgt het TIBER-EU- of equivalent framework
Uitgevoerd door gekwalificeerde externe aanbieders

Penetratietesten en compliance

ISO 27001

Controle	Vereiste	Hoe pentesten hieraan voldoen
A.8.8	Beheer van technische kwetsbaarheden	Jaarlijkse pentesten identificeren technische kwetsbaarheden voorbij geautomatiseerde scanning
A.5.36	Conformiteit met beleid en normen	Onafhankelijke beveiligingstesten valideren dat controles werken zoals ontworpen
A.8.9	Configuratiebeheer	Pentesten onthullen verkeerde configuraties die kwetsbaarheden creeren

SOC 2

Trust Services Criteria	Vereiste	Hoe pentesten hieraan voldoen
CC7.1	Detectie van kwetsbaarheden	Pentesten tonen actieve kwetsbaarheidsidentificatie aan
CC4.1	Monitoring van controles	Testen verifieren dat beveiligingscontroles effectief zijn
CC3.2	Risicobeoordeling	Pentestbevindingen voeden het risicobeoordelingsproces

NIS2

Artikel	Vereiste	Hoe pentesten hieraan voldoen
Artikel 21(2)(d)	Toeleveringsketenbeveiliging	Pentesten van kritieke leveranciers valideren hun beveiliging
Artikel 21(2)(e)	Kwetsbaarheidsbehandeling	Pentesten identificeren kwetsbaarheden voor herstel
Artikel 21(2)(f)	Effectiviteitsbeoordeling	Pentesten beoordelen de effectiviteit van beveiligingsmaatregelen

DORA

Artikel	Vereiste	Hoe pentesten hieraan voldoen
Artikel 24	Algemene vereisten voor ICT-testen	Regelmatige pentesten als onderdeel van digitale weerbaarheidstesten
Artikel 25	Dreigingsgestuurde penetratietesten	TLPT vereist voor significante entiteiten (TIBER-EU-framework)
Artikel 26	Vereisten voor testers	TLPT moet gekwalificeerde externe testers inzetten

Een penetratietestleverancier kiezen

Belangrijkste evaluatiecriteria

Kwalificaties en certificeringen

CREST-geaccrediteerd bedrijf en gecertificeerde testers (CRT, CCT)
OSCP-, OSCE-, OSWE-gecertificeerde individuen
CHECK (VK) of gelijkwaardig nationaal schema-lidmaatschap
Branche-ervaring relevant voor uw technologiestack

Methodologie

Volgt gevestigde frameworks (OWASP, PTES, NIST SP 800-115)
Combineert geautomatiseerde en handmatige testen
Omvat bedrijfslogicatesten, niet alleen kwetsbaarheidsscanning
Biedt duidelijke scoping en regels van betrokkenheid

Rapportagekwaliteit

Managementsamenvatting toegankelijk voor niet-technische stakeholders
Gedetailleerde technische bevindingen met proof-of-concept-bewijs
Risicogewaardeerde bevindingen (Kritiek, Hoog, Gemiddeld, Laag)
Specifieke, bruikbare herstelaanbevelingen
Hertest inbegrepen om fixes te verifieren

Compliance-afstemming

Ervaring met uw regelgevingsvereisten (ISO 27001, SOC 2, NIS2, DORA)
Rapporten opgemaakt voor auditorbeoordeling
Attestatiebrieven beschikbaar voor kopersverzoeken
TIBER-EU-gekwalificeerd voor DORA TLPT-vereisten

Kostenoverwegingen

Penetratietestkosten varieren aanzienlijk op basis van scope:

Webapplicatietest (enkele app): EUR 5.000-EUR 20.000
Netwerk-/infrastructuurtest (extern + intern): EUR 8.000-EUR 25.000
Uitgebreide opdracht (applicaties + infrastructuur + cloud): EUR 15.000-EUR 50.000
Red team-beoordeling: EUR 30.000-EUR 100.000+
TLPT (TIBER-EU): EUR 50.000-EUR 200.000+

Jaarlijkse testen voor een typisch B2B SaaS-bedrijf (webapplicatie + API + cloudinfrastructuur) liggen doorgaans tussen EUR 10.000 en EUR 30.000.

Wat te doen met pentestresultaten

Intern herstel

Triage bevindingen op ernst: Pak Kritieke en Hoge bevindingen onmiddellijk aan
Wijs eigenaarschap toe: Elke bevinding heeft een eigenaar en een hersteldatum nodig
Volg herstel: Gebruik uw issue tracker om te garanderen dat bevindingen worden opgelost
Hertest: Laat het testbedrijf verifieren dat fixes effectief zijn
Werk het risicoregister bij: Voer bevindingen in uw risicobeheerproces in
Beoordeel grondoorzaken: Identificeer systeemfouten die meerdere bevindingen hebben veroorzaakt

Resultaten delen

Via uw Trust Center:

Publiceer een pentestsamenvatting (datum, scope, tester, belangrijkste verholpen bevindingen)
Beveilig volledige rapporten achter NDA-toegang
Neem attestatiebrieven van het testbedrijf op
Toon uw testfrequentie en methodologie

In beveiligingsvragenlijsten:

Verwijs naar uw meest recente testdatum en -scope
Bevestig dat Kritieke en Hoge bevindingen zijn verholpen
Verstrek de attestatiebrief van het testbedrijf
Deel het volledige rapport onder NDA indien gevraagd

Voor compliance-auditors:

Verstrek het volledige rapport met herstelbewijs
Toon hertestresultaten die fixes bevestigen
Demonstreer integratie met uw kwetsbaarheidsbeheerprogramma
Koppel bevindingen aan relevante controleframeworks

Veelgemaakte fouten bij penetratietesten

Te beperkt testen

Alleen de hoofdwebapplicatie testen terwijl API's, beheerderspanelen, staging-omgevingen en cloudinfrastructuur worden genegeerd. Aanvallers zoeken de zwakste schakel, niet de sterkste.

Eenmalig testen en vergeten

Een enkele jaarlijkse test creëert een momentopname in de tijd. Continue ontwikkeling betekent dat regelmatig nieuwe kwetsbaarheden worden geintroduceerd. Overweeg continue penetratietesten voor applicaties met frequente releases.

Herstel negeren

Een pentestrapport is waardeloos als bevindingen niet worden hersteld. Volg bevindingen als beveiligingsbugs met SLA's: Kritiek binnen 48 uur, Hoog binnen 2 weken, Gemiddeld binnen 30 dagen.

Alleen op prijs kiezen

De goedkoopste pentest levert vaak de minste waarde. Een team dat geautomatiseerde scanners draait en de output herverpakt als een "penetratietest" biedt weinig meer dan wat uw eigen scantools opleveren.

Resultaten niet delen

Het achterhouden van pentestresultaten betekent dat kopers vragenlijsten moeten sturen om informatie te verkrijgen die u al heeft. Publiceer samenvattingen op uw Trust Center om inkomende beveiligingsbeoordelingsverzoeken te verminderen.

Hoe Orbiq penetratietestprogramma's ondersteunt

Trust Center: Publiceer pentestsamenvattingen, attestatiebrieven en herstelstatus voor zelfservice door kopers
Bewijsbeheer: Centraliseer pentestrapporten, hersteltracking en hertestbewijs gekoppeld aan complianceframeworks
AI-gestuurde vragenlijsten: Beantwoord automatisch pentestgerelateerde vragen in beveiligingsvragenlijsten op basis van uw gedocumenteerde bewijs
Continue monitoring: Volg de voortgang van herstel en waarschuw wanneer hertestdeadlines naderen

Verder lezen

Beveiligingsvragenlijst — Hoe pentestresultaten verschijnen in leveranciersbeoordelingen
ISO 27001-certificering — Het certificeringsframework dat kwetsbaarheidstesten vereist
Compliance-automatisering — Automatisering van het bewijstraject van pentesten
Trust Center — Pentestresultaten publiceren voor due diligence door kopers

Deze gids wordt onderhouden door het Orbiq-team. Laatst bijgewerkt: maart 2026.