Nederlands
A retest verifies whether the vulnerabilities from an earlier pentest have been properly resolved. This page describes how a retest at DongIT works, what you prepare, what we do and within what timeframe a retest is meaningful. For more information about the service and process, see our retest page.
When is a retest needed
- After remediation of findings. When your team has resolved critical and high-risk findings, you want assurance that the fixes actually work.
- For an auditor or certifying body. External auditors often require evidence that reported vulnerabilities have been resolved, for example for ISO 27001, DigiD or NIS2 accountability.
- For go-live approval. When you want to deploy the patched version to production and need assurance that no residual risks remain.
- As part of a compliance cycle. Some regulations require verification that findings have been resolved in time (for example DORA for financial entities).
Preparation on your side
For an efficient retest you do the following in advance:
- Prioritize and fix findings. Address critical and high-risk findings first, followed by medium- and low-risk findings. Follow the remediation guidance from the initial report.
- Document fixes in Security Reporter. Update the status of each finding in the Security Reporter platform to "fixed" and add evidence (screenshots, code diffs, commit hashes or configuration changes).
- Ensure the test environment is production-representative. The retest is performed on the same environment as the initial pentest, with the fixes active. Other changes (new features, refactoring) should not be deployed unless explicitly in scope.
- Request the retest. Notify us through Security Reporter or via email that you are ready for retesting. We then schedule the retest execution.
What DongIT does during the retest
- Verification of each fix. Our pentesters review all findings marked as "fixed" and test whether the vulnerability has actually been resolved. We test with the same methodology as the initial pentest.
- Regression check. We verify that the fixes have not introduced new vulnerabilities, for example through incomplete input validation or side effects of code changes.
- Peer review of findings. As with the initial pentest, every retest finding is reviewed by a second pentester (four-eyes principle).
- Report update. After completion you receive an updated report through Security Reporter with the status of each finding: resolved, partially resolved or still open. New findings are reported separately.
Lead time and timeframe
- Lead time. A retest usually takes less time than the initial pentest because the scope is limited to verification of fixes. For an average web application this is 3 to 5 working days.
- Timeframe. A retest is generally meaningful within 3 to 6 months after the initial pentest. After that, there are often so many changes that a completely new pentest is more appropriate.
- Multiple retests. If findings remain open after the first retest, a second retest can be scheduled. This happens in consultation and depending on your remediation planning.
More information about the retest service? See our retest page. Contact us for a complimentary scoping conversation, or view our pentest packages.