31 oktober 2026 · 12 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Het pentest rapport: wat een goed rapport bevat, hoe auditors het lezen en hoe u een slecht rapport herkent
Het rapport is het enige dat een penetratietest overleeft. De testers vertrekken, de bevindingen worden verholpen, en twaalf maanden later is het rapport waarop uw auditor, uw klant en uw bestuur de opdracht beoordelen. Deze gids loopt sectie voor sectie door de opbouw van een rapport dat alle drie bedient, en legt uit wat het onderscheidt van een scanneruitdraai met een voorblad.
Waar een pentestrapport voor dient
Een pentestrapport heeft vier lezers met vier verschillende vragen. De bestuurlijke opdrachtgever wil weten hoe kwetsbaar de organisatie is en of het geld goed is besteed. De ontwikkel- en beheerteams willen precies weten wat er kapot is, hoe zij het reproduceren en hoe zij het herstellen. De complianceverantwoordelijke wil weten welke maatregel de bevinding raakt en of het bewijs de auditor zal overtuigen. De klant of toezichthouder die later een samenvatting ontvangt, wil zekerheid dat een deskundige, onafhankelijke partij de juiste dingen heeft getest en dat wat zij vond is afgehandeld. Een goed rapport beantwoordt alle vier zonder dat een van hen de secties van de anderen hoeft te lezen.
Het rapport is ook een juridisch en contractueel document. Het legt vast wat wel en niet is getest, onder welke spelregels, op welke data, door wie. Wanneer zes maanden later een inbraak plaatsvindt via een systeem dat buiten scope viel, bepaalt de scopesectie of de test toereikend was of dat de organisatie ervoor koos het systeem dat faalde niet te testen. Behandel het rapport als het verslag van een beslissing, niet alleen als een lijst kwetsbaarheden.
Omdat het rapport de opdracht overleeft, telt de structuur zwaarder dan de lengte. De secties hieronder zijn die waarover elke serieuze methodiek (PTES, OWASP WSTG, NIST SP 800-115 hoofdstuk 7 over rapportage, OSSTMM) het eens is, en die auditors hebben leren zoeken.
De opbouw van een goed pentest rapport
Acht secties, in de volgorde waarin een lezer ze tegenkomt. Ontbreekt er een, vraag dan waarom voordat u het rapport accepteert.
1. Managementsamenvatting
Een tot twee pagina's, geschreven voor iemand die de rest niet leest. Zij benoemt wat is getest en waarom, het algemene risicobeeld in gewone taal, het aantal bevindingen per ernst, de twee of drie kwesties die het meest tellen en wat zij een aanvaller zouden toestaan, en de aanbevolen prioriteiten. Geen CVE-nummers, geen toolnamen. Een goede toets voor de samenvatting: een bestuurslid kan de conclusie na één keer lezen correct navertellen.
2. Scope en spelregels (rules of engagement)
De exacte systemen, applicaties, IP-reeksen, omgevingen (productie, acceptatie), gebruikersrollen en verstrekte inloggegevens; wat expliciet is uitgesloten en waarom; de testdata en tijdvensters; de testpositie (extern, intern assumed breach, geauthenticeerd als welke rollen); de diepte (black, grey of white box); beperkingen zoals geen denial of service of geen social engineering; en het escalatiepad dat tijdens de test voor kritieke bevindingen is gebruikt. Ook de namen en certificeringen van de testers. Dit is de sectie die de auditor als tweede leest, na de samenvatting.
3. Methodiek
De gevolgde kaders (OWASP WSTG en ASVS voor web, OWASP MASVS en MASTG voor mobiel, PTES of NIST SP 800-115 voor infrastructuur, MITRE ATT&CK voor intern en red-team-werk), de uitgevoerde fasen, de verhouding tussen handmatig en geautomatiseerd werk, en de gebruikte tools met hun rol. De methodiek laat een lezer de dekking beoordelen: een webapplicatietest die onder methodiek alleen geautomatiseerd scannen noemt, heeft de bedrijfslogica niet getest, en het rapport moet dat zeggen.
4. Risicoclassificatie: CVSS v4.0 plus bedrijfscontext
Elke bevinding draagt een ernst. De huidige industriestandaard is CVSS v4.0, in november 2023 gepubliceerd door FIRST, die de basismetrieken scoort (aanvalsvector, complexiteit, aanvalsvereisten, benodigde rechten, gebruikersinteractie en impact op het kwetsbare en op achterliggende systemen) en toestaat de score met dreigings- en omgevingsmetrieken aan uw situatie aan te passen. Een goed rapport benoemt welke metriekgroepen zijn gebruikt (alleen CVSS-B, of CVSS-BTE met dreigings- en omgevingscontext) en voegt daarna een bedrijfscontextclassificatie toe: een middelhoge CVSS-bevinding op de betalingsdatabase is niet hetzelfde als een middelhoge op de marketingsite. Beide cijfers horen in het rapport, met de redenering.
5. Bevindingen met bewijs en reproductiestappen
Eén item per bevinding, in een vast format: titel, geraakt systeem, ernst (CVSS-vector en -score plus bedrijfsclassificatie), beschrijving van de zwakheid, het aanvalsscenario in één alinea, stapsgewijze reproductie met requests, responses, commando's en schermafbeeldingen, het bewijs van impact (welke gegevens of toegang daadwerkelijk zijn verkregen, waar nodig geanonimiseerd), de geraakte maatregel of eis (OWASP-categorie, CWE en de compliance-mapping) en het herstel. Reproductiestappen zijn het verschil tussen een bevinding die een engineer in een middag herstelt en een bevinding die een week aan vergaderingen oplevert.
6. Herstel met eigenaar en prioriteit
Elke bevinding krijgt een specifieke oplossing (niet 'implementeer invoervalidatie' maar welke parameter, welke codering, welke bibliotheekinstelling), een voorgestelde eigenaar per rol, een prioriteit die volgt uit de risicoclassificatie en, waar nuttig, een compenserende maatregel voor de periode tot de oplossing live gaat. Een geconsolideerde hersteltabel, gesorteerd op prioriteit, is wat de engineering lead aan de muur hangt. Strategische aanbevelingen (de drie grondoorzaken achter twintig bevindingen) horen in een aparte korte sectie en zijn vaak de waardevolste pagina van het rapport.
7. Hertestsectie
Na het herstel verifieert de tester elke oplossing en voegt het resultaat toe: opgelost, deels opgelost (met wat resteert) of niet opgelost. De hertestsectie legt per bevinding de datum, de methode en het bewijs vast, zodat het rapport een gesloten cirkel wordt. Compliancekaders die bewijs van herstel vereisen, zoals PCI DSS v4.0.1 Requirement 11.4.4, worden door deze sectie beantwoord en door niets anders.
8. Attestatiebrief
Een brief van een tot twee pagina's, los van het volledige rapport, die vastlegt wie wat heeft getest, wanneer, volgens welke methodiek, het aantal bevindingen per ernst en hun herstelstatus na hertest, ondertekend door het testbureau. Zij bevat geen technische details en kan met klanten, auditors, verzekeraars en toezichthouders worden gedeeld zonder de bevindingen bloot te geven. De meeste organisaties hebben dit document vaker nodig dan het volledige rapport.
Hoe auditors en toezichthouders het rapport lezen
Elk kader heeft een lezer met een specifieke vraag. Een rapport dat met die vragen in gedachten is geschreven, wordt één keer gearchiveerd; een rapport zonder die vragen levert vervolgverzoeken op.
ISO 27001:2022
De certificerende auditor toetst bijlage A-maatregelen A.8.8 (technische kwetsbaarheden), A.8.29 (beveiligingstesten in ontwikkeling en acceptatie) en A.5.36 (naleving van beleid en normen). Hij wil een scope zien die aansluit op de ISMS-scope, een datum binnen de auditperiode, bevindingen die via uw proces voor corrigerende maatregelen zijn gevolgd, en de hertest.
SOC 2
De service auditor koppelt het rapport aan de Trust Services Criteria, doorgaans CC4.1 (monitoringactiviteiten) en CC7.1 (detectie van kwetsbaarheden en configuratiewijzigingen). Hij zoekt een maatregel die tijdens de beoordelingsperiode werkte, dus de testdatum en de hersteldata tellen, en het spoor van bevinding naar ticket dat laat zien dat het management reageerde.
DORA en NIS2
Financiële toezichthouders lezen tegen DORA artikel 24 en 25: dekt de test de ICT-systemen achter kritieke of belangrijke functies, waren de testers onafhankelijk en zijn bevindingen verholpen. NIS2-toezichthouders lezen tegen artikel 21(2)(f): beoordeelt de organisatie de doeltreffendheid van haar maatregelen. Beide verwachten een managementsamenvatting die het bestuur heeft gezien.
DigiD en BIO
De Register EDP-auditor leest het rapport als bewijs voor specifieke normen in de DigiD-norm van Logius of de BIO. Hij heeft een scope nodig die de volledige aansluiting of het volledige systeem dekt, een recente test op de productierelease, en bevindingen gekoppeld aan normnummers zodat hij elke norm naar bewijs kan herleiden zonder zelf de technische details te interpreteren.
PCI DSS v4.0.1
De QSA leest tegen Requirement 11.4: een gedocumenteerde methodiek (11.4.1), interne en externe tests minimaal jaarlijks en na significante wijzigingen (11.4.2, 11.4.3), herstel en hertest van misbruikbare kwetsbaarheden (11.4.4) en segmenteringstests (11.4.5). De scope moet de kaarthouderomgeving en de segmenteringsmaatregelen eromheen dekken.
AVG en de Autoriteit Persoonsgegevens
Na een datalek kan de toezichthouder vragen welk testen is uitgevoerd onder artikel 32(1)(d), dat een procedure vereist om de doeltreffendheid van beveiligingsmaatregelen regelmatig te testen. De scopesectie, de data en het herstelspoor tonen aan dat de procedure bestond en is gevolgd.
Een goed rapport versus een scanneruitdraai met een voorblad
Veel documenten die als pentestrapport worden verkocht, zijn de uitvoer van een geautomatiseerde scanner, licht bewerkt. De verschillen zijn in vijf minuten zichtbaar als u weet waar u moet kijken.
| Sectie | Goed rapport | Scanneruitdraai |
|---|---|---|
| Managementsamenvatting | Risicobeeld in gewone taal, de kwesties die tellen, prioriteiten | Grafiek met aantallen bevindingen per ernst, geen verhaal |
| Scope | Exacte systemen, rollen, data, uitsluitingen, testers bij naam | Lijst van gescande IP-adressen of URL's, geen rollen, geen testers |
| Methodiek | Kaders bij naam, handmatige fasen beschreven, rol van tools toegelicht | Toolnaam en versie, niets meer |
| Bevindingen | Aanvalsscenario, reproductiestappen, bewijs van daadwerkelijke impact, bedrijfscontext | Generieke pluginbeschrijving, CVSS-basisscore uit de database gekopieerd, geen bewijs van misbruikbaarheid |
| Bedrijfslogica en autorisatie | Getest en gerapporteerd, vaak de ernstigste bevindingen | Afwezig, omdat scanners ze niet kunnen testen |
| Herstel | Specifieke oplossing per bevinding, eigenaar, prioriteit, grondoorzaken | Standaardtekst van de leverancier: update naar de laatste versie |
| Hertest | Verificatie per bevinding met bewijs en datum | Opnieuw scannen, of niets |
| Attestatie | Ondertekende brief met scope, methode en herstelstatus | Geen |
Hoe u het rapport veilig deelt
Een pentestrapport is een kaart van uw zwakke plekken. Behandel het ook zo.
- Teken vóór de opdracht een wederzijdse geheimhoudingsovereenkomst met het testbureau, die het rapport, het bewijs en alle tijdens het testen verkregen gegevens dekt, met een vastgelegde bewaar- en vernietigingstermijn voor de kopieën van de tester
- Ontvang het rapport via een versleuteld kanaal, niet als e-mailbijlage; bewaar het op een afgeschermde locatie met toegangslogging, niet op een gedeelde schijf
- Deel de attestatiebrief, niet het volledige rapport, met klanten, prospects, verzekeraars en de meeste auditors; de brief bewijst dat de test heeft plaatsgevonden en dat bevindingen zijn verholpen, zonder prijs te geven hoe uw systemen falen
- Wanneer een klant of toezichthouder meer eist, lever dan een geanonimiseerde versie: managementsamenvatting, scope, methodiek en de titels van de bevindingen met ernst en herstelstatus, zonder reproductiestappen en bewijs
- Vraag de tester persoonsgegevens en inloggegevens uit schermafbeeldingen te verwijderen vóór oplevering; bewijs van impact moet tonen dat gegevens bereikbaar waren, niet de gegevens zelf
- Spreek af hoe lang het testbureau zijn werkgegevens en het rapport bewaart (doorgaans tot de hertest is afgerond plus een korte periode) en vraag om schriftelijke bevestiging van verwijdering
- Bewaar uw eigen exemplaren minimaal zo lang als de auditcycli die erop steunen; ISO 27001- en SOC 2-auditors vragen naar het rapport van vorig jaar én het huidige
- Versioneer het rapport: het origineel, het hertestaddendum en de attestatiebrief zijn drie documenten met drie data, en auditors willen alle drie zien
Wat een rapport van HackersHub bevat
Elk rapport van HackersHub volgt de opbouw hierboven. De managementsamenvatting wordt geschreven door de lead tester, niet gegenereerd, en vóór oplevering beoordeeld op gewone taal. De scopesectie legt de systemen, rollen, data, uitsluitingen en de testers bij naam met hun certificeringen vast; de lead tester heeft minimaal OSCP, en het team beschikt over OSWE- en CREST-kwalificaties waar de opdracht daarom vraagt. De methodieksectie benoemt de kaders per onderdeel en geeft aan waar het handmatige testen zich concentreerde.
Bevindingen dragen een CVSS v4.0-vector en -score, een bedrijfscontextclassificatie die tijdens de opdracht met u is afgestemd, het aanvalsscenario, volledige reproductiestappen met geanonimiseerd bewijs, de CWE- en OWASP-categorie en de compliance-mapping naar de kaders die u bij de scoping heeft genoemd (ISO 27001 bijlage A, SOC 2-criteria, PCI DSS-requirements, DORA-artikelen, NIS2, de DigiD-norm, de BIO- of NEN 7510-maatregelen). Kritieke en hoge bevindingen worden tijdens de test geëscaleerd, niet bewaard voor het rapport. De hersteltabel is gesorteerd op prioriteit met voorgestelde eigenaren, en een korte grondoorzakensectie legt uit wat de bevindingen verbindt.
De hertest is onderdeel van elke opdracht. Nadat u heeft hersteld, verifiëren wij elke bevinding en voegen wij de resultaten met bewijs en datum toe, en wij geven de attestatiebrief af zodra de hertest is afgerond. U ontvangt het volledige rapport, het hertestaddendum en de attestatiebrief via een versleuteld kanaal, met onze bewaar- en verwijdertermijnen vastgelegd in het contract. Wij publiceren geen downloadbaar voorbeeldrapport, omdat elk echt rapport de zwakke plekken van een klant bevat; wij lopen wel met toekomstige klanten een geanonimiseerde opbouw door tijdens een scopinggesprek.
Veelgestelde vragen
Wilt u een rapport dat uw auditor, uw engineers en uw bestuur alle drie kunnen gebruiken?
Elke opdracht van HackersHub eindigt met een gestructureerd rapport, een geverifieerde hertest en een attestatiebrief, gekoppeld aan de kaders die u bij de scoping noemt. Praat met een expert.