Voorbeeld pentestrapport: hoe ziet een goed rapport eruit?

Een pentestrapport dat eindigt in een lade is geld weggegooid. Een goed rapport is opgebouwd in lagen — geschikt voor zowel een bestuur dat naar risico kijkt, als voor een ontwikkelaar die dezelfde dag wil patchen. Op deze pagina leest u de structuur die Resync hanteert, met een voorbeeldbevinding ter illustratie. Onderaan staat een sample-rapport als PDF.

De structuur in vogelvlucht

1. Managementsamenvatting

De eerste twee pagina's zijn voor bestuur, MT, CISO of opdrachtgever — niet voor ontwikkelaars. De samenvatting beschrijft in begrijpelijke taal wat we hebben getest, wat we hebben gevonden, hoe ernstig dat is, en wat dat in zakelijke zin betekent. Geen jargon. Geen lange tabel met CVE-nummers. Geen 200-pagina-scanner-output.

Wat erin staat:

• Risico-overzicht in begrijpelijke taal, met directe relatie tot bedrijfsdoelen
• Aantal en ernst van de gevonden kwetsbaarheden (kritiek, hoog, medium, laag)
• Bedrijfsmatige impact per categorie — wat zou er kunnen gebeuren
• Strategische aanbevelingen en compliance-context (NIS2, AVG, ISO 27001, NEN 7510)
• Slotoordeel: aanbevolen vervolgstappen en termijn

2. Technische bevindingen

Per bevinding hetzelfde patroon: u kunt elke bevinding zelfstandig openen, lezen, reproduceren en oplossen. Elk item is opgebouwd uit zes elementen:

• Titel en categorie (bv. "Insecure Direct Object Reference op klanten-endpoint")
• Ernst (Kritiek, Hoog, Medium, Laag) met CVSS-score en motivatie
• Reproductiestappen — letterlijk de stappen die een aanvaller of ontwikkelaar volgt om de bevinding te reproduceren
• Bewijs — screenshots, HTTP request/response logs, eventuele exploit-snippets
• Impact in technische én bedrijfsmatige termen
• Aanbeveling — concreet, met code- of configuratievoorbeeld waar nuttig

Voorbeeldbevinding (geanonimiseerd)

Dit is één voorbeeld; een typisch rapport bevat 3 tot 15 bevindingen, afhankelijk van de scope.

3. Prioritering naar impact

Niet elke bevinding is even urgent. Het rapport sorteert bevindingen op een combinatie van twee assen: hoe makkelijk uitbuitbaar (van buitenaf, geautoriseerd, vereist sociale engineering) en hoe groot de impact als het wel gebeurt (data-exfiltratie, account takeover, beschikbaarheidsverlies). Daaruit volgt een aanbevolen behandelvolgorde — die ook in de managementsamenvatting terugkomt.

4. Hertest-verklaring

Nadat uw team de bevindingen heeft verholpen, testen we opnieuw — niet de hele applicatie, maar specifiek de bevindingen. Per bevinding noteren we de status: opgelost, gemitigeerd, of open. De hertest-verklaring wordt als losse PDF aan het rapport gehecht, met datum en handtekening. Bruikbaar als bewijs richting auditors, klanten of toezichthouders.

Wat een goed rapport níét is

• Geen 200 pagina's vol scanner-output. Een goed rapport is doorgaans 30–60 pagina's, waarvan de helft technische diepte en de helft management-leesbaar.
• Geen lijst met "potential issues" zonder context.
• Geen generieke OWASP-links als aanbeveling — wel concrete, voor uw applicatie geschreven adviezen.
• Geen open einde — elk traject sluit af met een hertest-verklaring.

Het sample-rapport sturen we per e-mail, ongated, na een korte intake-aanvraag. Op die manier kunnen we het rapport koppelen aan uw situatie — relevanter dan een algemene PDF die niemand ooit nakijkt.

Klaar om uw eigen rapport te laten maken?

Voor de scope-categorieën en het complete proces verwijzen we naar de pagina penetratietest laten uitvoeren. Voor het prijsmodel: wat kost een penetratietest.