2 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Pentest methodiek: welke standaarden er zijn, hoe de fasen verlopen en hoe u controleert of uw leverancier ze echt volgt
Een pentest methodiek is de gedocumenteerde, herhaalbare werkwijze die een tester volgt van scoping tot hertest, doorgaans gebouwd op publieke standaarden zoals PTES, de OWASP-testgidsen of NIST SP 800-115. Deze gids vergelijkt die standaarden, benoemt per fase de input, output en het bewijs, en laat zien hoe u een rapport uit een methodiek onderscheidt van een scannerexport.
Wat een pentest methodiek is, en waarom opdrachtgevers erop moeten letten
Een pentest methodiek is het gestructureerde geheel van fasen, testgevallen, beslisregels en rapportage-eisen dat bepaalt hoe een beveiligingstest wordt gescopet, uitgevoerd en vastgelegd. Zij legt vooraf vast wat wordt onderzocht en tot welke diepte, hoe de tester vaststelt dat een zwakte echt is en hoe ver hij die doorzet, en welk bewijs in het rapport terechtkomt. Zonder methodiek is een penetratietest een getalenteerd persoon die een week aan een systeem prikt. Met methodiek wordt het een herhaalbare beoordeling waarvan de dekking kan worden benoemd, vergeleken met de test van vorig jaar en verdedigd tegenover een auditor.
Drie termen worden door elkaar gebruikt en dat zou niet moeten. Een standaard is een publiek document dat door een externe partij wordt onderhouden (PTES, de OWASP Web Security Testing Guide, NIST SP 800-115, OSSTMM). Een methodiek, ook pentest methodologie genoemd, is de eigen werkwijze van het testbureau, die een of meer standaarden overneemt en daar scopingregels, kwaliteitscontroles en een rapportformaat aan toevoegt. Een checklist is waarmee de tester op de dag zelf werkt: de testgevallen van een standaard gekoppeld aan de assets in scope. Het onderscheid heeft gevolgen. PCI DSS v4.0.1 eis 11.4.1 verlangt een gedocumenteerde methodiek op basis van in de sector geaccepteerde benaderingen, DORA artikel 25 noemt penetratietesten expliciet, en een toezichthouder die onder NIS2 vraagt hoe de test is uitgevoerd, verwacht een methodiekverklaring en geen toolnaam. De definitie van een penetratietest en het overzicht van de zeven fases in gewone taal staan in onze uitleg, hieronder gelinkt; deze pagina gaat een laag dieper.
De pentest standaarden die in 2026 tellen
Zes publieke documenten liggen onder de meeste professionele methodieken. Elk is geschreven voor een ander doelwit en een andere lezer, en daarom combineren volwassen leveranciers ze in plaats van er een te kiezen.
PTES (Penetration Testing Execution Standard)
Door de community geschreven, met zeven onderdelen: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation en reporting. Onafhankelijk van het doelwit, en daarom de gebruikelijke ruggengraat voor het opdrachtproces; over specifieke testgevallen voor web of mobiel zegt het weinig.
OWASP Web Security Testing Guide (WSTG) v4.2
De referentie voor testgevallen van webapplicaties en API's. Versie 4.2 ordent ruim negentig tests in categorieën van information gathering en authenticatie tot bedrijfslogica, client-side en API-testen. Elke test heeft een identifier (bijvoorbeeld WSTG-ATHZ-02) die een rapport kan citeren. Versie 5 is in ontwikkeling.
OWASP MASTG en MASVS v2
De Mobile Application Security Testing Guide hoort bij de Mobile Application Security Verification Standard, waarvan versie 2 de maatregelen groepeert in opslag, cryptografie, authenticatie, netwerk, platforminteractie, codekwaliteit, weerbaarheid en privacy. De MASTG levert de iOS- en Android-procedures waarmee elke maatregel wordt geverifieerd.
De technische testgids van NIST
NIST SP 800-115 is de Amerikaanse federale Technical Guide to Information Security Testing and Assessment (2008). Paragraaf 5.2 beschrijft penetratietesten in vier fasen: planning, discovery, attack en reporting, waarbij attack terugkoppelt naar discovery. Aangehaald door FedRAMP, CMMC-assessoren en Amerikaanse toezichthouders, en daarom citeren rapporten voor de Amerikaanse markt het ook als de testgevallen van OWASP komen.
OSSTMM 3
De Open Source Security Testing Methodology Manual van ISECOM kiest een meetgerichte benadering: vijf kanalen (menselijk, fysiek, draadloos, telecommunicatie, datanetwerken) en de RAV, een numerieke uitdrukking van operationele beveiliging die twee tests van dezelfde scope vergelijkbaar maakt. Versie 3 dateert uit 2010 en een opvolger is nooit afgerond, maar het kanaalmodel blijft bruikbaar.
ISSAF en de PCI DSS Penetration Testing Guidance
Het Information Systems Security Assessment Framework (OISSG) wordt niet meer onderhouden, maar wordt nog aangehaald omdat het elke stap aan tooling en verwachte output koppelt. De Penetration Testing Guidance van de PCI Security Standards Council is zelf geen methodiek; zij definieert wat een PCI-test moet dekken (scope, segmentatie, applicatie- en netwerklaag, hertest) en waartoe de tester gekwalificeerd moet zijn.
Pentest methodologieën vergeleken
Geen enkel document dekt scoping, testgevallen en rapportage voor elk type doelwit; daarom stapelt een leveranciersmethodiek er doorgaans twee of drie.
| Standaard | Beheerder en status | Scope die hij het best dekt | Rol in een leveranciersmethodiek |
|---|---|---|---|
| PTES | Community; v1.0 plus technical guidelines, al jaren stabiel | Het opdrachtproces voor elk doelwit | Ruggengraat voor fasen, rules of engagement en rapportstructuur |
| OWASP WSTG v4.2 | OWASP; actief onderhouden, v5 in ontwikkeling | Webapplicaties en web-API's | Checklist van testgevallen en dekkingsmatrix voor applicatietests |
| OWASP MASTG / MASVS v2 | OWASP; actief onderhouden | iOS- en Android-applicaties | Mobiele testgevallen en verificatieniveaus (L1, L2, R) |
| NIST SP 800-115 | NIST; 2008, nog altijd de aangehaalde Amerikaanse federale gids | Netwerk-, systeem- en applicatietesten in een Amerikaanse toezichtcontext | Model met vier fasen, aangehaald voor FedRAMP, CMMC, HIPAA en staatstoezichthouders |
| OSSTMM 3 | ISECOM; 2010, geen opvolger afgerond | Operationele beveiliging over mensen, fysiek, draadloos, telecom en netwerken | Kanaalmodel voor scoping; vergelijkbare metrieken tussen tests |
| ISSAF | OISSG; niet onderhouden | Infrastructuurbeoordelingen | Historische referentie en toolingkaart |
| PCI DSS Penetration Testing Guidance | PCI SSC-supplement bij eis 11.4 | Cardholder data environment en segmentatie | Verplichte dekking bovenop PTES of NIST |
| CREST-richtlijnen en TIBER-EU | CREST-accreditatie van leden; ECB TIBER-EU, in 2025 herzien voor DORA TLPT | Geaccrediteerde programma's; intelligence-gestuurd red teaming van financiële entiteiten | Assurancelaag voor opdrachtgevers; threat-led testen onder DORA artikel 26 en 27 |
Het testproces, fase voor fase
De uitleg van de zeven fases in gewone taal staat in onze pentest-uitleg. Hier is de vraag anders: wat moet er per fase in, wat moet eruit komen en welk document bewijst dat het is gebeurd. Gebruik het als acceptatiechecklist voor de opgeleverde stukken.
1. Pre-engagement en scoping
Input: de inventaris van assets in scope, het zakelijke doel, compliance-eisen die dekking opleggen (PCI DSS-segmentatie, DORA-functies) en bekende kwetsbare systemen. Output: een ondertekend scope- en rules-of-engagement-document met testvensters, bron-IP-adressen, escalatiecontacten en kennisniveau (black, grey of white box). Bewijs: de ondertekende machtiging en scope waarnaar het rapport verwijst.
2. Threat modelling
Wordt vaak overgeslagen en is het eerste wat een methodiekgedreven leverancier terugbrengt. Input: de bedrijfsfuncties achter de assets, dataclassificaties, vertrouwensgrenzen en de aanvallersprofielen die voor u tellen. Output: een geprioriteerde lijst van wat de tester het hardst zal proberen te bereiken, wat bepaalt waar de consultantdagen heen gaan. Bewijs: een samenvatting van het dreigingsmodel of een kaart van het aanvalsoppervlak die uitlegt waarom de inspanning ging waar zij ging.
3. Intelligence gathering en discovery
Input: de scope plus, voor grey- en white-boxtests, documentatie, inloggegevens en architectuurschema's. Output: een geïnventariseerd aanvalsoppervlak (hosts, diensten, technologieën, rollen, endpoints, componenten van derden) en een lijst van assets die buiten het scopedocument zijn gevonden. Bewijs: een inventarisbijlage en een dekkingsmatrix die WSTG- of MASTG-categorieën aan elk onderdeel koppelt. Zonder inventaris kunt u niet zien wat niet is getest.
4. Vulnerability analysis
Input: het geïnventariseerde oppervlak en de toepasselijke testgevallen. Output: kandidaat-zwakheden, elk handmatig geverifieerd, met false positives verwijderd en scanneroutput afgezet tegen handmatig werk. Bewijs: de methodiekparagraaf vermeldt welke scanners zijn gebruikt, welke categorieën handmatig zijn uitgevoerd en welke niet van toepassing waren en waarom. Een rapport dat alleen tooloutput opsomt, is hier gestopt.
5. Exploitation
Input: geverifieerde zwakheden en de rules of engagement, in het bijzonder de uitsluitingen (denial of service, destructieve handelingen, wijziging van productiedata). Output: aangetoonde impact per bevinding, doorgezet tot proof of concept en niet verder. Bewijs: request-responseparen, schermafbeeldingen of commando-output, plus de CVSS v4.0-vectorstring achter elke ernst. Waar uitbuiten onveilig was, moet het rapport dat zeggen in plaats van de score op te blazen.
6. Post-exploitation en analyse van aanvalspaden
Input: de verkregen toegang. Output: de ketens die losse bevindingen verbinden tot zakelijke impact, paden voor privilege-escalatie en welke gevoelige data of systemen bereikbaar waren. Bewijs: het aanvalsverhaal, gekoppeld aan MITRE ATT&CK-techniek-ID's zodat uw detectieteam kan nagaan welke stappen in de logs zichtbaar waren. Hier worden losse medium-bevindingen terecht opgewaardeerd tot één kritiek pad.
7. Rapportage, bespreking en hertest
Input: alles hierboven plus de doelgroepen (bestuur, engineering, auditor). Output: managementsamenvatting, bevindingen met ernst, bewijs en herstelmaatregelen, de methodiek- en dekkingsverklaring, beperkingen en een hertestplan. Bewijs: het rapport, de bespreking en een hertestbrief die bevestigt welke bevindingen geverifieerd gesloten zijn. PCI DSS 11.4.4 verwacht dat uitbuitbare kwetsbaarheden worden hersteld en opnieuw getest; HackersHub neemt een verificatiehertest van medium en hogere bevindingen binnen 90 dagen op.
Waarom de testgevallen meebewegen met het doelwit: web, mobiel, netwerk, cloud, API en AI
Het opdrachtproces blijft gelijk voor elk doelwit; de testgevallen niet. Een webapplicatietest haalt zijn checklist uit de OWASP WSTG en de OWASP Top 10. Een mobiele test vervangt die door MASTG-procedures en een afgesproken MASVS-verificatieniveau. Een netwerk- of Active Directory-test steunt op PTES en NIST SP 800-115 voor de structuur en op MITRE ATT&CK voor de techniekencatalogus, omdat er voor infrastructuur geen testlijst in OWASP-stijl bestaat. Voor cloudtesten bestaat geen enkele publieke standaard: een geloofwaardige methodiek combineert de regels van de provider (het AWS-beleid voor klantpenetratietesten, de rules of engagement van Microsoft voor Azure, de voorwaarden van Google Cloud), de CIS Benchmarks voor configuratiebeoordeling en de WSTG of PTES voor de workloads erop. API-testen voegen de OWASP API Security Top 10 (2023) toe; applicaties met ingebouwde taalmodellen de OWASP Top 10 for LLM Applications (2025). Een leverancier die één methodiek noemt voor alle zes doelwitten heeft een proces beschreven, geen testgevallen. Vraag welke standaard de checklist levert per type asset.
Hoe een methodiek zichtbaar wordt in het pentestrapport
U kijkt zelden mee tijdens de test. Het rapport is de plek waar de methodiek zichtbaar wordt of niet. Een rapport uit een methodiek bevat deze onderdelen; een scannerexport bevat hooguit het eerste en het vijfde.
- Een methodiekverklaring die de gebruikte standaarden met versie benoemt (bijvoorbeeld 'OWASP WSTG v4.2, PTES, NIST SP 800-115'), het kennisniveau en het testvenster
- De ondertekende scope met expliciet de assets binnen en buiten scope, plus assets die buiten de scope zijn ontdekt
- Een dekkingsmatrix die toont welke categorieën uit de standaard zijn uitgevoerd, welke niet van toepassing waren en welke niet konden worden afgerond, met reden
- Bevindingen die naast een CWE- of CVE-referentie een standaard-ID citeren waar die bestaat (WSTG-ATHN-04, MASVS-STORAGE-1)
- Een CVSS v4.0-basisscore met de volledige vectorstring per bevinding, zodat de ernst onafhankelijk kan worden nagerekend
- Bewijs per bevinding en een aanvalsverhaal dat bevindingen tot ketens verbindt, waar relevant gekoppeld aan MITRE ATT&CK
- Een paragraaf met beperkingen die duidelijk benoemt welke tijd-, toegangs- of omgevingsfactoren de dekking verkleinden
- Bij naam genoemde testers met certificeringen, een gedocumenteerde collegiale toets voor oplevering en een hertestparagraaf met sluitingscriteria per ernstniveau
Hoe u controleert of een pentestleverancier echt een methodiek volgt
Elke offerte claimt een methodiek. Zes controles scheiden een gedocumenteerde werkwijze van een dia, en de antwoorden laten zien hoe het bureau zich gedraagt als er halverwege de test iets misgaat.
Vraag het methodiekdocument, niet de brochure
Een echte methodiek heeft fasedefinities, in- en uitgangscriteria, de overgenomen standaarden per type doelwit, bewijseisen en een rapportsjabloon. Een leverancier moet u er onder NDA doorheen willen leiden. Een grafiek van één pagina met zeven pictogrammen betekent dat de methodiek in het geheugen van de tester zit.
Vraag een geanonimiseerd voorbeeldrapport en zoek de dekkingsmatrix
Controleer op de onderdelen hierboven, vooral op een verklaring van wat niet is getest. Bureaus die vanuit een methodiek werken, documenteren hiaten zonder verlegenheid, omdat een hiaat een scopingbeslissing is.
Vraag hoe een niet-toepasselijke testcategorie wordt vastgelegd
Een tester die de WSTG op een API zonder browserclient toepast, moet de client-side categorie als niet van toepassing markeren en uitleggen waarom. Een leverancier die dit niet kan beschrijven, houdt geen dekking bij. Vraag bij mobiel tot welk MASVS-niveau zij testen en hoe dat in de scoping wordt afgesproken.
Vraag wie test, wie beoordeelt en of beiden worden genoemd
Verwacht een bij naam genoemde lead tester met actuele certificeringen (OSCP als basis; OSWE, OSEP of CREST-registraties voor specialistisch werk) en een tweede persoon die bevindingen en ernst beoordeelt voor vrijgave. Rapporten die alleen met een bedrijfsnaam zijn ondertekend, maken verantwoording onmogelijk.
Vraag wat er gebeurt als op dag twee een kritieke bevinding opduikt
Een methodiek definieert de escalatie: wie wordt gebeld, binnen welke tijd, wat wordt vastgelegd en of het testen op dat onderdeel doorgaat. Het antwoord moet overeenkomen met het rules-of-engagement-document dat zij voorstellen.
Vraag hoe de methodiek aansluit op de kaders waaraan u rapporteert
Voor PCI DSS: hoe de scoping eis 11.4.1 tot en met 11.4.7 dekt, inclusief segmentatie. Voor DORA: hoe de systemen achter kritieke of belangrijke functies worden gedekt. Voor SOC 2 of ISO 27001: hoe het rapport de auditor maatregel en bewijs laat koppelen. Een leverancier die dit eerder deed, heeft de koppeling klaarliggen.
Pentest standaarden en compliance: wat elk kader verwacht
Kaders verschillen in hoe voorschrijvend zij zijn. PCI DSS v4.0.1 is het meest expliciet: eis 11.4.1 verlangt een gedocumenteerde, in de sector geaccepteerde methodiek die de perimeter van de cardholder data environment en kritieke systemen dekt, van binnen en van buiten test, segmentatie valideert, zwakheden op applicatie- en netwerklaag behandelt, de dreigingen van de voorgaande twaalf maanden beoordeelt en resultaten en herstel bewaart; 11.4.2 en 11.4.3 leggen de jaarlijkse frequentie vast en 11.4.5 en 11.4.6 regelen segmentatietesten. ISO 27001:2022 maatregelen A.8.8 en A.8.29 worden aangetoond met tests waarvan de auditor scope en methode kan volgen, NIS2 artikel 21(2)(f) vraagt om beleid voor het beoordelen van de effectiviteit van maatregelen, en DORA artikel 25 noemt penetratietesten terwijl artikel 26 en 27 threat-led testen onder TIBER-EU definiëren. De DigiD-norm van Logius en NEN 7510 in de zorg verwachten eveneens testbewijs met een herleidbare methode.
Rapporteert u ook aan Amerikaanse klanten of toezichthouders, dan gelden dezelfde principes. FedRAMP schrijft voor Rev. 5 aanvalsvectoren en een rapportformaat voor onder maatregel CA-8, NYDFS 23 NYCRR 500.5 en de GLBA Safeguards Rule (16 CFR 314.4(d)(2)) vereisen jaarlijkse penetratietesten, HIPAA 45 CFR 164.308(a)(8) vraagt om periodieke technische evaluatie en CMMC 2.0 niveau 2 erft NIST SP 800-171 maatregel CA.L2-3.12.1. Eén goed gedocumenteerde methodiek bedient al deze kaders, mits de scopeverklaring de assets aan elk kader koppelt.
Hoe HackersHub zijn pentest methodiek toepast
Onze methodiek sluit aan op PTES voor het opdrachtproces, op de OWASP WSTG en MASTG voor applicatie- en mobiele testgevallen en op NIST SP 800-115 voor het fasemodel waarnaar Amerikaanse toezichthouders verwijzen. Elke tester heeft minimaal OSCP, met OSWE- en CREST-gecertificeerde testers in het team, en de lead tester wordt in het rapport bij naam genoemd. De scoping is maatwerk per opdracht en wordt schriftelijk vastgelegd voordat het testen begint. Rapporten bevatten een managementsamenvatting, CVSS-gescoorde bevindingen met bewijs, een aanvalsverhaal en geprioriteerde herstelmaatregelen, zo geschreven dat uw complianceteam elke bevinding kan herleiden naar het kader waaronder het rapporteert. Een verificatiehertest van medium en hogere bevindingen binnen 90 dagen is onderdeel van elke opdracht. Wij leveren vanuit Amsterdam voor opdrachtgevers in de EU en de Verenigde Staten, standaard op afstand en op locatie waar de scope dat vraagt.
Veelgestelde vragen
Gerelateerde gidsen en diensten
- Penetratietest laten uitvoeren door HackersHub
- Wat is een penetratietest? Betekenis en de zeven fases uitgelegd
- NIST SP 800-115 pentest: het model met vier fasen in de diepte
- Wat een pentestrapport moet bevatten
- Black box, grey box en white box pentest
- Soorten pentesten: netwerk, web, cloud, mobiel en meer
- PCI DSS pentest: Requirement 11.4 uitgelegd
- Een pentestbedrijf kiezen: waar u op let
Wilt u een penetratietest waarvan u de methodiek kunt controleren?
Wij scopen elke opdracht schriftelijk, testen volgens PTES, OWASP en NIST SP 800-115, noemen de testers in het rapport en nemen een verificatiehertest op. Bespreek uw scope met een penetratietester.