31 oktober 2026 · 10 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
De hertest na een pentest: wat hij verifieert, wanneer u hem plant en welk bewijs auditors accepteren als herstelverificatie
Een pentestrapport is een lijst met open deuren. Zolang niemand die deuren opnieuw probeert, weet u niet welke daadwerkelijk dicht zitten. De hertest is die tweede poging, en het is het bewijsstuk waar auditors, verzekeraars en klanten als eerste om vragen. Deze gids legt uit wat een hertest pentest omvat, hoe u hem timet en wanneer het het verkeerde instrument is.
Wat een hertest is, en wat het niet is
Een hertest na een pentest (ook wel herstelverificatie, remediation testing of fix-verificatie genoemd) is een vervolgopdracht waarin de oorspronkelijke testers elke bevinding uit het eerste rapport opnieuw proberen te reproduceren nadat uw team de fixes heeft doorgevoerd. Per bevinding legt de tester een van drie uitkomsten vast: hersteld (het oorspronkelijke aanvalspad werkt niet meer en een triviale variant evenmin), gedeeltelijk hersteld (de specifieke proof of concept faalt, maar de onderliggende zwakte is nog bereikbaar) of niet hersteld. Het resultaat is een bijgewerkt rapport waarin elke bevinding een verificatiestatus, een verificatiedatum en het bewijs achter het oordeel draagt.
Een hertest is geen nieuwe penetratietest. De tester inventariseert het aanvalsoppervlak niet opnieuw, zoekt niet naar nieuwe kwetsbaarheidsklassen en doorloopt niet de volledige methodiek. Het is een gerichte oefening per bevinding, en daarom kost hij een fractie van de oorspronkelijke inspanning en moet hij binnen een afgebakend venster plaatsvinden. Hoe groter de tijd tussen test en hertest, hoe verder de omgeving is weggedreven en hoe minder de hertest zegt over de huidige staat van het systeem.
Dat onderscheid is relevant voor compliance. Een auditor die een rapport ziet met twaalf bevindingen en geen afsluitbewijs, behandelt alle twaalf als open. Hetzelfde rapport met een gedateerde verificatiebijlage die tien herstelde bevindingen toont, één gedeeltelijk hersteld met een compenserende maatregel en één geaccepteerd als gedocumenteerd risico, is een gesloten cirkel. De meeste normenkaders die een penetratietest vereisen, vereisen die cirkel, niet alleen de test.
Wat de hertest verifieert, per bevinding
Goede herstelverificatie is meer dan het opnieuw afspelen van de oorspronkelijke exploit. Dit zijn de controles die een competente tester voor elk punt op de lijst uitvoert.
1. Het oorspronkelijke aanvalspad is gesloten
De exacte proof of concept uit het rapport wordt herhaald tegen hetzelfde doel, vanuit dezelfde testpositie en met dezelfde rechten. Geeft het verzoek dat eerder een databasefout teruggaf nu een nette 400, of stopt de privilege-escalatie die eerder een domain-admin-token opleverde nu bij een standaardgebruiker, dan slaagt de primaire controle. Dit is het minimum, en op zichzelf is het niet genoeg.
2. Triviale varianten zijn ook gesloten
Een fix die één payload blokkeert maar niet de URL-gecodeerde tweeling, of die één endpoint patcht maar het zuster-endpoint met identieke logica ongemoeid laat, is een gedeeltelijke fix. De tester besteedt een begrensde hoeveelheid tijd, doorgaans 30 tot 60 minuten per bevinding, aan de voor de hand liggende varianten: alternatieve coderingen, aangrenzende parameters, andere rollen, andere hosts in hetzelfde cluster. Een hertest die alleen de oorspronkelijke payload herhaalt, beloont cosmetische fixes.
3. De oorzaak is aangepakt, niet alleen het symptoom
Een SQL-injectie die is opgelost met een regel in de web application firewall is een andere uitkomst dan een die is opgelost met geparametriseerde queries. Beide kunnen controle één doorstaan. De tester documenteert welk type fix is toegepast, omdat auditors onder PCI DSS en beoordelaars onder ISO 27001 A.8.8 onderscheid maken tussen een kwetsbaarheid die is gecorrigeerd en een die alleen is afgeschermd.
4. De fix heeft geen regressie geïntroduceerd
Hardening breekt vaak iets ernaast. Een aangescherpt CORS-beleid dat nu op foutpaden elke origin reflecteert, een nieuwe autorisatiecontrole die met een method override te omzeilen is, of een gepatchte bibliotheek die via een transitieve afhankelijkheid een bekende CVE terugbrengt: het zijn alle regressies die een hertest binnen de grenzen van de oorspronkelijke bevinding moet opmerken.
5. Compenserende maatregelen compenseren daadwerkelijk
Waar een bevinding niet binnen het venster bij de bron kan worden opgelost (een legacy-component, een leveranciersafhankelijkheid, een wijzigingsstop), documenteren organisaties een compenserende maatregel. De hertest valideert de maatregel, niet het papier: is netwerksegmentatie de maatregel, dan probeert de tester het systeem te bereiken vanuit de segmenten die geblokkeerd zouden moeten zijn.
Hertest versus nieuwe penetratietest: welke heeft u nodig
Het verkeerde instrument kiezen verspilt geld in de ene richting en laat blootstelling liggen in de andere. De tabel laat zien waar de grens ligt.
| Situatie | Hertest volstaat | Nieuwe test vereist |
|---|---|---|
| Fixes doorgevoerd op de bevindingen in het rapport, geen andere wijzigingen | Ja | Nee |
| Timing | Binnen 30 tot 90 dagen na het oorspronkelijke rapport | Meer dan 90 tot 120 dagen verstreken, of de omgeving is wezenlijk veranderd |
| Grote release van de geteste applicatie (nieuwe functies, nieuwe rollen, nieuwe authenticatieflow) | Nee | Ja, minimaal gescopet op het gewijzigde oppervlak |
| Infrastructuurwijziging (migratie naar nieuw cloudaccount, nieuwe identity provider, herontworpen netwerk) | Nee | Ja |
| Fix doorgevoerd door het component volledig te vervangen (nieuw framework, nieuw leveranciersproduct) | Nee | Ja, voor het nieuwe component |
| Compliancecyclus (jaarlijks ISO 27001, PCI DSS 11.4.2 en 11.4.3, DORA art. 24) | Alleen als afsluiting van de vorige test | Ja, de jaarlijkse test zelf |
| Significante wijziging onder PCI DSS v4.0.1 Req. 11.4 (nieuwe betaalflow, nieuwe segmentatie) | Nee | Ja, als wijzigingsgestuurde test |
Wat de normenkaders zeggen over herstelverificatie
De meeste normenkaders gebruiken het woord hertest niet. Ze beschrijven een gesloten cirkel tussen bevinding, correctie en verificatie. Dit zijn de bepalingen die auditors aanhalen.
PCI DSS v4.0.1, Requirement 11.4
Req. 11.4.1 vereist een gedocumenteerde methodiek met een vastgelegde aanpak voor het beoordelen en aanpakken van het risico van gevonden exploiteerbare kwetsbaarheden. Req. 11.4.4 vereist dat exploiteerbare kwetsbaarheden uit de penetratietest worden gecorrigeerd conform de risicobeoordeling van de entiteit, en dat de penetratietest wordt herhaald om de correcties te verifiëren. Req. 11.4.5 stelt dezelfde verwachting voor segmentatiemaatregelen. Een QSA vraagt het hertestbewijs per bevinding op.
ISO/IEC 27001:2022, Annex A.8.8 en A.8.29
A.8.8 (beheer van technische kwetsbaarheden) verwacht dat informatie over kwetsbaarheden wordt verkregen, de blootstelling wordt beoordeeld en passende maatregelen worden genomen. A.8.29 (beveiligingstesten in ontwikkeling en acceptatie) verwacht gedefinieerde en geïmplementeerde testprocessen. Certificerende auditors lezen de twee samen: de test identificeert, de hertest bewijst dat de maatregel effectief was.
DORA, artikel 24 en 25
Artikel 24 vereist dat financiële entiteiten procedures hebben om alle via testen blootgelegde kwesties te prioriteren, classificeren en herstellen, en interne validatiemethodieken om vast te stellen dat alle geïdentificeerde zwakheden volledig zijn aangepakt. Die validatie-eis is in alles behalve naam een hertestverplichting. Voor TLPT onder artikel 26 maken het herstelplan en de opvolging deel uit van de afsluiting met de toezichthouder.
SOC 2, Common Criteria CC7 en CC4
CC7.1 betreft het detecteren van kwetsbaarheden en configuratiewijzigingen; CC4.2 vereist dat tekortkomingen in de interne beheersing worden beoordeeld en gecommuniceerd aan de verantwoordelijken voor corrigerende actie. Een service auditor die de werking over een periode van twaalf maanden toetst, trekt een steekproef uit uw pentestbevindingen en vraagt bewijs dat elk tot afsluiting is gevolgd en geverifieerd.
NIS2, artikel 21(2)
Artikel 21(2)(e) vereist beleid voor de afhandeling en openbaarmaking van kwetsbaarheden, en artikel 21(2)(f) vereist procedures om de effectiviteit van maatregelen voor cyberbeveiligingsrisicobeheer te beoordelen. Een nationale toezichthouder die een essentiële entiteit beoordeelt, verwacht dat het testprogramma aantoont dat geïdentificeerde kwetsbaarheden zijn afgehandeld, wat in de praktijk hertestbewijs betekent.
NIST SP 800-115, sectie 8
De technische NIST-gids voor beveiligingstesten beschrijft de activiteiten na het testen: rapportage, herstel en de aanbeveling om herstel te verifiëren met vervolgtesten. Amerikaanse federale programma's (FedRAMP Rev. 5 maatregel CA-8, CMMC 2.0 Level 2 via NIST SP 800-171 Rev. 3) erven deze verwachting.
Wat auditors willen zien: het verificatiedossier
Een auditor kan uw fixes niet verifiëren. Hij verifieert dat een onafhankelijke partij dat deed, en dat het verslag gedateerd, specifiek en volledig is. Houd het volgende gereed voor elke penetratietest in de auditperiode.
- Het oorspronkelijke rapport met elke bevinding uniek geïdentificeerd (ID, titel, ernst, getroffen systeem, testpositie, datum van waarneming)
- Een gedateerde verificatiebijlage of bijgewerkt rapport waarin elke bevinding een status draagt: hersteld, gedeeltelijk hersteld, niet hersteld of risico geaccepteerd
- Bewijs per herstelde bevinding: het herhaalde verzoek of de herhaalde handeling, de nieuwe respons, een schermafbeelding of logfragment en de naam van de tester
- Voor gedeeltelijk herstelde bevindingen: wat nog werkt, wat het restrisico is en de afgesproken vervolgstap met datum
- Voor geaccepteerde risico's: de ondertekende acceptatie door de risico-eigenaar, de onderbouwing, de herzieningsdatum en de eventuele compenserende maatregel, met het hertestresultaat voor die maatregel
- Een attestatiebrief op briefpapier van het testbedrijf met samenvatting van scope, data, methodiek, testers bij naam en afsluitstatus; dit is wat klanten en verzekeraars meestal willen in plaats van het volledige rapport
- Het ticketspoor dat elke bevinding koppelt aan een wijzigingsrecord in uw eigen systemen, zodat de auditor van rapport naar fix naar verificatie kan volgen
- Een tijdlijn met de oorspronkelijke testdatum, de hersteldeadline per ernst en de hertestdatum, waarmee u aantoont dat het venster is gehaald
De hertest timen: het venster van 30 tot 90 dagen en wat het bepaalt
De meeste volwassen programma's plannen de hertest tussen 30 en 90 dagen na het eindrapport. De ondergrens wordt bepaald door hoe lang realistische fixes duren: een kritieke bevinding in een webapplicatie is vaak in dagen te patchen, maar een Active Directory-privilegepad dat een herontwerp van tiering vergt, kost weken. De bovengrens wordt bepaald door drift. Na ongeveer 90 dagen is er zoveel code en configuratie veranderd dat de hertest niet meer over het huidige systeem gaat, en de meeste normenkaders en veel klantcontracten beginnen de oorspronkelijke bevindingen dan als verouderd te behandelen.
Ernst zou het schema binnen dat venster moeten sturen. Een gangbare en verdedigbare aanpak is een hertest van kritieke en hoge bevindingen na 30 dagen en van middelhoge en lage na 90 dagen, beide vastgelegd in het rapport voordat de test begint, zodat het herstelteam naar bekende deadlines werkt. PCI DSS laat de timing aan de risicobeoordeling van de entiteit, maar QSA's verwachten dat kritieke bevindingen voortvarend worden opgepakt; ISO 27001-auditors kijken naar consistentie met uw eigen beleid voor kwetsbaarheidsbeheer, dat doorgaans doelen van 14 tot 30 dagen voor kritieke bevindingen stelt.
Twee praktische opmerkingen. Ten eerste: wacht niet tot alles is opgelost voordat u de hertest aanvraagt; een hertest met drie open punten en een heldere status per punt is een beter auditstuk dan een rapport dat zes maanden onafgesloten blijft liggen. Ten tweede: leg het hertestvenster vast in de oorspronkelijke opdrachtomschrijving. Hertesten die achteraf worden onderhandeld, zijn de hertesten die het venster missen.
Gedeeltelijke fixes, compenserende maatregelen en wanneer een hertest niet volstaat
Gedeeltelijke fixes zijn na volledig herstel de meest voorkomende hertestuitkomst, en juist daar verdient de hertest zichzelf terug. Typische patronen: een invoervalidatie toegepast op het formulierveld maar niet op het API-endpoint erachter; een wachtwoordbeleid aangescherpt voor nieuwe accounts maar niet afgedwongen op bestaande; een kwetsbare bibliotheek bijgewerkt in één service maar nog aanwezig in een gedeelde basis-image. Het rapport moet het restpad precies genoeg benoemen om het ontwikkelteam in staat te stellen het zonder derde ronde te sluiten.
Compenserende maatregelen zijn legitiem wanneer de oorzaak niet binnen het venster kan worden opgelost, mits ze specifiek, getest en in tijd begrensd zijn. Een compenserende maatregel is geen regel in een risicoregister; het is een mechanisme dat de tester kan proberen te verslaan. Is de maatregel een WAF-regel, dan omvat de hertest omzeilingspogingen. Is de maatregel segmentatie, dan omvat de hertest bereikbaarheidstests vanuit de relevante segmenten. Is de maatregel monitoring, dan bevestigt de hertest dat de detectie afging en dat iemand haar ontving.
Een hertest houdt op het juiste instrument te zijn wanneer de wijziging groter is dan de bevinding. Een grote release die nieuwe functies, rollen of een authenticatieflow toevoegt, creëert aanvalsoppervlak dat de oorspronkelijke test nooit heeft gezien. Een migratie naar een nieuw cloudaccount of een nieuwe identity provider verandert de vertrouwensgrenzen waarbinnen de oorspronkelijke bevindingen waren geformuleerd. Het vervangen van een kwetsbaar component door een ander product maakt de oorspronkelijke bevinding irrelevant en laat het nieuwe product ongetest. In elk van die gevallen is het juiste antwoord een nieuwe, gescopete penetratietest van het gewijzigde oppervlak, met de hertest van de oorspronkelijke bevindingen daarin opgenomen waar ze nog van toepassing zijn.
Hoe HackersHub de hertest aanpakt
Elke penetratietest van HackersHub omvat één hertestronde van alle bevindingen, in de opdrachtomschrijving ingepland op een met u afgesproken datum, normaal gesproken tussen 30 en 90 dagen na het eindrapport. Dezelfde tester die het probleem vond, verifieert de fix bij naam, omdat degene die het aanvalspad bouwde het snelst de varianten ervan aftast. Per bevinding ontvangt u de verificatiestatus, het bewijs en een heldere verklaring van wat, als er iets is, nog bereikbaar is.
Het resultaat is een bijgewerkt rapport met gedateerde verificatiebijlage plus een attestatiebrief van één pagina, ondertekend door de lead tester, zo geschreven dat u haar zonder het volledige rapport kunt overhandigen aan een QSA, een ISO 27001-certificerende auditor, een SOC 2-service auditor of het third-party-risk-team van een klant. Is een bevinding gedeeltelijk hersteld of gedekt door een compenserende maatregel, dan zeggen wij dat onomwonden en benoemen het restpad; dat maakt de brief geloofwaardig wanneer een auditor haar naast het rapport legt.
Is de omgeving tussen test en hertest wezenlijk veranderd, dan vertellen wij u dat een hertest niet de zekerheid geeft waarvoor u betaalt en stellen wij in plaats daarvan een gescopete test van het gewijzigde oppervlak voor. Onze testers zijn OSCP-gecertificeerd en worden in elk rapport bij naam genoemd. Meer dan tien jaar offensive security heeft ons geleerd dat een eerlijk uitgevoerde hertest meer waard is voor een beveiligingsprogramma dan een schoon rapport dat niemand heeft gecontroleerd.
Veelgestelde vragen
Een penetratietest nodig die de cirkel sluit?
Elke opdracht van HackersHub omvat een hertestronde en een auditklare verificatiebijlage, uitgevoerd door dezelfde tester bij naam. Praat met een expert over scope en timing.