Een hertest verifieert of de kwetsbaarheden uit een eerdere pentest correct zijn verholpen. Deze pagina beschrijft hoe een hertest bij DongIT verloopt, wat u voorbereidt, wat wij doen en binnen welke termijn een hertest zinvol is. Voor meer informatie over de service en het proces, zie onze hertest-pagina.
Wanneer is een hertest nodig
- Na remediation van bevindingen. Wanneer uw team kritieke en hoge risico-bevindingen heeft verholpen, wilt u zekerheid dat de fixes daadwerkelijk werken.
- Voor auditor of certificerende instantie. Externe auditors vereisen vaak bewijs dat gemelde kwetsbaarheden zijn opgelost, bijvoorbeeld voor ISO 27001, DigiD of NIS2-verantwoording.
- Voor go-live goedkeuring. Wanneer u de aangepaste versie naar productie wilt uitrollen en wilt laten controleren of de afgesproken bevindingen zijn opgelost. Een hertest sluit andere of resterende risico’s niet uit.
- Als onderdeel van compliance-cyclus. Sommige regelgeving vereist verificatie dat bevindingen tijdig zijn verholpen (bijvoorbeeld DORA voor financiële entiteiten).
Voorbereiding aan uw kant
Voor een efficiënte hertest doet u het volgende voorafgaand:
- Prioriteer en fix bevindingen. Los eerst kritieke en hoge risico-bevindingen op, gevolgd door middelmatige en lage risico-bevindingen. Volg de remediation guidance uit de initiële rapportage.
- Documenteer fixes in Security Reporter. Werk de status van elke bevinding bij in het Security Reporter platform naar "gefixed" en voeg bewijs toe (screenshots, code-diffs, commit-hashes of configuratie-changes).
- Zorg dat testomgeving productie-representatief is. De hertest wordt uitgevoerd op dezelfde omgeving als de initiële pentest, met de fixes actief. Andere wijzigingen (nieuwe features, refactoring) mogen niet mee-gedeployed zijn tenzij expliciet in scope.
- Vraag de hertest aan. Meld ons via Security Reporter of via e-mail dat u klaar bent voor hertest. Wij plannen dan de hertest-uitvoering in.
Wat DongIT doet tijdens de hertest
- Verificatie van elke fix. Onze pentesters lopen alle als "gefixed" gemarkeerde bevindingen na en testen of de kwetsbaarheid daadwerkelijk is verholpen. Wij testen met dezelfde methodiek als de initiële pentest.
- Regression-check. Binnen de afgesproken hertestscope onderzoeken wij of de fixes zichtbare nieuwe problemen veroorzaken, bijvoorbeeld door onvolledige invoervalidatie of neveneffecten van codewijzigingen. Dit is geen volledige nieuwe pentest en biedt geen garantie dat alle nieuwe kwetsbaarheden worden gevonden.
- Peer-review van bevindingen. Zoals bij de initiële pentest wordt elke hertest-bevinding gecontroleerd door een tweede pentester (vier-ogen-principe).
- Rapportage-update. Na afronding ontvangt u een bijgewerkt rapport via Security Reporter met de status van elke bevinding: verholpen, deels verholpen of nog open. Ook nieuwe bevindingen worden apart gerapporteerd.
Doorlooptijd en termijn
- Doorlooptijd. Een hertest duurt doorgaans korter dan de initiële pentest omdat de scope beperkt is tot verificatie van fixes. Voor een gemiddelde webapplicatie is dit 3 tot 5 werkdagen.
- Termijn. Een hertest is doorgaans zinvol binnen 3 tot 6 maanden na de initiële pentest. Daarna zijn er vaak zoveel wijzigingen dat een volledig nieuwe pentest passender is.
- Meerdere hertests. Als na de eerste hertest nog bevindingen open staan, kan een tweede hertest worden gepland. Dit gebeurt in overleg en afhankelijk van uw remediation-planning.
Meer informatie over de hertest-service? Zie onze hertest-pagina. Neem contact op voor een kosteloos scope-gesprek, of bekijk onze pentestpakketten.
English