English
Pentest hertest laten uitvoeren
Uw ontwikkelteam heeft de bevindingen uit een pentest verholpen. Maar zijn de kwetsbaarheden ook daadwerkelijk opgelost? Voor auditors, toezichthouders en enterprise-klanten is een hertest de aantoonbare bevestiging. Zonder deze validatie blijft onduidelijk of de fix het probleem structureel heeft weggenomen of alleen cosmetisch heeft gemaskeerd.
DongIT voert hertesten uit op bevindingen uit onze eigen pentesten én op rapporten van andere pentestpartijen. De hertest wordt uitgevoerd door OSCP-gecertificeerde ethical hackers volgens ons vier-ogen-principe. Rapportage via Security Reporter met heldere status per bevinding (opgelost, gemitigeerd, resterend risico). Direct bruikbaar voor uw ISMS, NIS2-verantwoording, DigiD-assessment of andere compliance-doeleinden.
Voor DongIT-klanten verloopt de hertest-aanvraag via het Security Reporter-portaal. Voor rapporten van andere partijen leveren wij een onafhankelijke validatie. In beide gevallen ontvangt u een gestructureerde hertest-rapportage die aansluit op het oorspronkelijke pentest-rapport.
Wat is een hertest en waarom is die nodig?
Een hertest is een gerichte controle van eerder gevonden kwetsbaarheden. Het is géén volledige nieuwe pentest, maar een gestructureerde validatie of de aangebrachte beveiligingsmaatregelen effectief zijn én of ze structureel zijn geïmplementeerd. Bij een hertest wordt per bevinding vastgesteld:
- Is de kwetsbaarheid daadwerkelijk verholpen? De oorspronkelijke aanvalstechniek werkt niet meer.
- Is de oplossing structureel? Niet alleen deze ene endpoint, maar het onderliggende patroon in de codebase.
- Zijn er geen regressies? De fix heeft geen nieuwe kwetsbaarheden geïntroduceerd.
Een hertest is bijzonder waardevol in drie situaties:
- Compliance-audit. Auditors voor ISO 27001, DigiD, NIS2 en DORA vragen om aantoonbaar bewijs dat kritieke bevindingen zijn opgelost, niet alleen "gepland".
- Enterprise-klant. Uw opdrachtgevers willen een verklaring zien dat hun eerder gerapporteerde risico's daadwerkelijk zijn gemitigeerd.
- Interne zekerheid. U wilt aantoonbaar weten dat uw ontwikkelteam de bevindingen op de juiste manier heeft opgelost, niet alleen "op papier".
De hertest-rapportage sluit aan op het oorspronkelijke pentest-rapport en biedt heldere status per bevinding: opgelost, gemitigeerd, resterend risico of nieuwe issue.
Zo werkt een hertest bij DongIT
Voor DongIT-klanten met een lopende pentest-relatie verloopt de hertest-aanvraag volledig via het Security Reporter-portaal. Vier eenvoudige stappen leiden tot een efficiënte hertest.
Log in op Security Reporter
Ga naar het Reporter-portaal met uw eigen gebruikersaccount. Open de pentest waarop u een hertest wilt laten uitvoeren.
Klik "Request Retest" bij elke bevinding
Selecteer per bevinding of u een hertest wilt aanvragen. U kunt kiezen om alle kritieke bevindingen mee te nemen of alleen specifieke items.
Beschrijf de remediation per bevinding
Vul in hoe u de kwetsbaarheid heeft verholpen of het risico heeft gemitigeerd. Concrete details versnellen de hertest aanzienlijk (zie richtlijnen hieronder).
Ontvang de hertest-rapportage
Onze pentester valideert de fixes volgens vier-ogen-principe. U ontvangt een aanvullende rapportage in Security Reporter met status per bevinding, direct bruikbaar voor uw auditor.
Wat aanleveren voor een efficiënte hertest
De doorlooptijd en efficiëntie van uw hertest hangt sterk af van de kwaliteit van de aangeleverde documentatie. Een pentester heeft context nodig om precies te weten wat hij moet valideren. Onze richtlijn per bevinding:
Wat is er gewijzigd?
Beschrijf de oplossing concreet. Geen "gefixed" maar "input-validatie toegevoegd met whitelist-benadering voor de parameter X".
Waar is dit aangepast?
Verwijs naar bestanden, code-regels, endpoints of commits. Voor infrastructuur: server-adressen en configuratiebestanden.
Hoe is het aangepast?
Screenshots van aangepaste code, referenties naar Git commits of uitleg van ontwerpkeuzes. Bij geaccepteerd risico: onderbouwing waarom.
Voorbeelden van goede en slechte aanleveringen
Onderstaande voorbeelden illustreren het verschil tussen minimale en bruikbare remediation-documentatie. De kwaliteit van uw aanlevering bepaalt direct de doorlooptijd van de hertest.
Voorbeeld 1: parameter-misbruik
Bevinding: Via de parameter jobalert_action op /nl/jobs/alert kunnen onbevoegde methodes worden aangeroepen.
Slechte aanlevering: "Gefixed."
Goede bewijsvoering: "Opgelost door het instellen van een whitelist met toegestane methoden in de controller. Zie Figuur 1."
Voorbeeld 2: cookie-attributen niet ingesteld
Bevinding: Attributen Secure en HttpOnly ontbreken op PHPSESSID.
Slechte aanlevering: "Gefixed."
Goede bewijsvoering: "Aangepast in php.ini. Secure en HttpOnly zijn geactiveerd voor alle sessie-cookies. Zie Figuur 2."
Voorbeeld 3: SQL-injection via onveilige query
Bevinding: Niet-geparametriseerde query op regel 89 in controllers/pagesController.php.
Slechte aanlevering: "Advies toegepast."
Goede bewijsvoering: "Query's geparametriseerd met PDO prepared statements. Alle input wordt via bind-parameters gebonden. Zie Figuur 3."
Voorbeeld 4: Server-Side Request Forgery (SSRF)
Bevinding: SSRF mogelijk via url-parameter in /include/seotool/index.php.
Goede bewijsvoering: "Directory /include/seotool is volledig verwijderd omdat de functionaliteit niet meer wordt gebruikt. Alternatief was inputvalidatie op de URL-parameter met whitelist voor toegestane hosts."
Voorbeeld 5: Reflected Cross-Site Scripting (XSS)
Bevinding: Reflected XSS in /include/menuitem.demo.inc.php.
Goede bewijsvoering: "Output-filtering toegepast op regel 10 van het script met htmlspecialchars(). Zie Figuur 4."
Voorbeeld 6: wachtwoorden in plaintext opgeslagen
Bevinding: Inloggegevens worden in leesbaar formaat opgeslagen in dbacc2.auth_logs.
Goede bewijsvoering: "Logregels zijn aangepast zodat wachtwoorden niet meer worden opgeslagen. Bestaande regels met wachtwoord-data zijn verwijderd. Zie Figuur 5."
Voorbeeld 7: openbare NFS-share met credentials
Bevinding: NFS-share op 10.0.0.118 bevat credentials-bestanden zonder toegangscontrole.
Goede bewijsvoering: "Toegang tot de NFS-share afgeschermd via netwerksegmentatie en authenticatie. Aanvullend zijn de wachtwoorden op de externe systemen die deze credentials gebruikten geroteerd."
Voorbeeld 8: geaccepteerd risico
Bevinding: Verouderde versie van jQuery in gebruik met bekende kwetsbaarheden.
Slechte aanlevering: "Later."
Goede bewijsvoering: "Kwetsbaarheid geaccepteerd als resterend risico. Onderbouwing: getroffen functies worden niet aangeroepen in onze codebase (zie audit-log). Upgrade staat gepland voor Q1 2027. Compensatie: aanvullende WAF-regel geactiveerd die exploitatie-pogingen blokkeert."
De laatste categorie is belangrijk: niet elke bevinding hoeft direct opgelost te worden, mits het geaccepteerde risico goed is onderbouwd. Onze hertest-rapportage benoemt geaccepteerde risico's expliciet zodat uw auditor daar rekening mee kan houden.
Hertest op rapporten van andere pentestpartijen
Ook als de oorspronkelijke pentest is uitgevoerd door een andere partij, kunt u bij DongIT terecht voor een onafhankelijke hertest. Deze situatie komt regelmatig voor: een organisatie wisselt van pentestpartij, wil onafhankelijke second opinion of heeft een pentest gekocht bij een partij die geen hertest-service biedt.
Wat wij nodig hebben:
- Het oorspronkelijke pentest-rapport (PDF of vergelijkbaar)
- Documentatie van de remediation per bevinding
- Toegang tot de te testen omgeving
Onze beveiligingsexpert:
- Beoordeelt de kwaliteit en actualiteit van het originele rapport
- Valideert of de bevindingen valide en reproduceerbaar zijn
- Voert een gerichte hertest uit op elke bevinding
U ontvangt een DongIT hertest-rapportage in Security Reporter. Deze staat op zichzelf en kan door u worden gedeeld met auditors, klanten of interne stakeholders, ongeacht wie de oorspronkelijke pentest uitvoerde.
Wat kost een hertest?
Hertesten worden uitgevoerd op nacalculatie tegen ons standaard uurtarief. De benodigde tijd hangt af van drie factoren:
- Aantal bevindingen dat opnieuw wordt gevalideerd
- Type kwetsbaarheden (eenvoudige config-check vs complexe business logic-verificatie)
- Kwaliteit en volledigheid van uw remediation-documentatie
Indicatie: een hertest voor een middelgrote webapplicatie duurt gemiddeld 8 tot 12 uur, mits de originele pentest is uitgevoerd door DongIT en de remediation-documentatie compleet is. Voor rapporten van andere partijen ligt de indicatie hoger vanwege de extra beoordelingsstap.
Efficiënte hertest?
Kwaliteit van uw remediation-documentatie bepaalt direct de doorlooptijd. Concrete beschrijvingen, screenshots en commit-referenties versnellen de hertest aanzienlijk.
Veelgestelde vragen over hertesten
Hieronder de meest gestelde vragen over hertesten. Voor een volledig overzicht kunt u onze FAQ-pagina raadplegen.
Wat is het verschil tussen een hertest en een nieuwe pentest?
Een hertest valideert alleen de eerder gevonden bevindingen, geen nieuwe. Als er sindsdien significante wijzigingen zijn in uw applicatie, architectuur of scope, adviseren wij een nieuwe pentest in plaats van (of naast) een hertest. Bij twijfel bespreken wij in het intakegesprek wat voor uw situatie het beste past.
Binnen welke termijn kan een hertest worden aangevraagd?
Wij adviseren om een hertest binnen 6 maanden na de oorspronkelijke pentest aan te vragen. Bij een langere periode kunnen bevindingen zijn achterhaald door architectuur- of dependency-wijzigingen. Voor DigiD, NIS2 en ISO 27001 gelden vaak strikte deadlines waarbinnen de hertest afgerond moet zijn.
Voert dezelfde pentester de hertest uit?
Waar mogelijk voeren wij de hertest uit door een andere pentester dan die de oorspronkelijke bevinding rapporteerde. Dit borgt onafhankelijkheid. Alle hertesten volgen wel het vier-ogen-principe met peer-review.
Wat als een bevinding niet volledig is opgelost?
De hertest-rapportage maakt onderscheid tussen "opgelost", "gedeeltelijk gemitigeerd", "geaccepteerd risico" en "resterend risico". Voor de laatste twee categorieën documenteren wij expliciet de onderbouwing. Uw auditor kan dan zelf beoordelen of deze status acceptabel is.
Kan ik alle bevindingen tegelijk laten hertesten of stap voor stap?
Beide is mogelijk. Voor efficiëntie adviseren wij een gebundelde hertest wanneer meerdere bevindingen zijn verholpen. Voor kritieke bevindingen met korte compliance-deadline kan ook een tussentijdse hertest per bevinding.
Kunnen jullie ook hertesten voor bevindingen van scanners of bug bounty?
Ja. Voor bevindingen uit vulnerability scans of bug bounty-programma's kunnen wij een hertest uitvoeren. Wij hanteren dezelfde kwaliteitsstandaarden als bij pentest-bevindingen, en documenteren de status in een aparte rapportage.
Wat als een klant zelf een pentest heeft laten uitvoeren?
Als u pentest-diensten levert aan een eindklant en zij vragen om een onafhankelijke hertest, kunt u DongIT inschakelen als neutrale derde partij. Wij respecteren volledig de vertrouwelijkheid tussen u en uw klant en leveren een objectieve validatie.
Hoe lang duurt een hertest doorgaans?
Actieve testtijd 4 tot 20 uur, afhankelijk van aantal en complexiteit van bevindingen. Totale doorlooptijd van aanvraag tot definitieve rapportage is typisch 1 tot 2 weken, mits de remediation-documentatie volledig is.
Klaar om uw remediation te valideren?
Wilt u een hertest aanvragen op een DongIT-pentest? Log in bij Security Reporter en klik "Request Retest". Heeft u een pentest-rapport van een andere partij en wilt u een onafhankelijke hertest? Neem contact op voor een kosteloos intakegesprek. Reactie binnen één werkdag.