Nederlands
Get a pentest retest
Your development team has resolved the findings from a pentest. But have the vulnerabilities actually been fixed? For auditors, supervisory authorities and enterprise clients a retest is the demonstrable confirmation. Without this validation it remains unclear whether the fix has structurally removed the problem or only cosmetically masked it.
DongIT performs retests on findings from our own pentests and on reports from other pentest parties. The retest is performed by OSCP-certified ethical hackers under our four-eyes principle. Reporting via Security Reporter with clear status per finding (resolved, mitigated, accepted risk). Directly usable for your ISMS, NIS2 reporting, DigiD assessment or other compliance purposes.
For DongIT clients the retest request runs through the Security Reporter portal. For reports from other parties we deliver an independent validation. In both cases you receive a structured retest report that aligns with the original pentest report.
What is a retest and why is it needed?
A retest is a targeted validation of previously identified vulnerabilities. It is not a full new pentest, but a structured verification of whether the applied security measures are effective and whether they have been structurally implemented. For each finding a retest establishes:
- Is the vulnerability actually resolved? The original attack technique no longer works.
- Is the solution structural? Not just this one endpoint, but the underlying pattern in the codebase.
- Are there no regressions? The fix has not introduced new vulnerabilities.
A retest is particularly valuable in three situations:
- Compliance audit. Auditors for ISO 27001, DigiD, NIS2 and DORA require demonstrable evidence that critical findings have been resolved, not just "scheduled".
- Enterprise client. Your clients want to see a statement that their previously reported risks have actually been mitigated.
- Internal assurance. You want to know demonstrably that your development team has resolved findings the right way, not just "on paper".
The retest report aligns with the original pentest report and provides clear status per finding: resolved, mitigated, accepted risk or new issue.
How a retest works at DongIT
For DongIT clients with an active pentest relationship, the retest request runs entirely through the Security Reporter portal. Four simple steps lead to an efficient retest.
Log in to Security Reporter
Go to the Reporter portal with your own user account. Open the pentest for which you want to request a retest.
Click "Request Retest" on each finding
Per finding, select whether you want to request a retest. You can choose to include all critical findings or only specific items.
Describe the remediation per finding
Fill in how you resolved the vulnerability or mitigated the risk. Concrete details significantly accelerate the retest (see guidelines below).
Receive the retest report
Our pentester validates the fixes under the four-eyes principle. You receive a supplementary report in Security Reporter with status per finding, directly usable for your auditor.
What to provide for an efficient retest
The duration and efficiency of your retest depend heavily on the quality of the documentation you provide. A pentester needs context to know exactly what to validate. Our guideline per finding:
What has changed?
Describe the solution concretely. Not "fixed" but "input validation added with allow-list approach for parameter X".
Where was it changed?
Refer to files, code lines, endpoints or commits. For infrastructure: server addresses and configuration files.
How was it changed?
Screenshots of modified code, references to Git commits or explanation of design choices. For accepted risk: rationale why.
Examples of good and poor submissions
The examples below illustrate the difference between minimal and useful remediation documentation. The quality of your submission directly determines the duration of the retest.
Example 1: parameter abuse
Finding: Via the parameter jobalert_action on /nl/jobs/alert, unauthorized methods can be invoked.
Poor submission: "Fixed."
Good evidence: "Resolved by implementing an allow-list of permitted methods in the controller. See Figure 1."
Example 2: cookie attributes not set
Finding: Attributes Secure and HttpOnly are missing on PHPSESSID.
Poor submission: "Fixed."
Good evidence: "Modified in php.ini. Secure and HttpOnly are activated for all session cookies. See Figure 2."
Example 3: SQL injection via unsafe query
Finding: Non-parameterized query on line 89 in controllers/pagesController.php.
Poor submission: "Advice applied."
Good evidence: "Queries parameterized with PDO prepared statements. All input is bound via bind parameters. See Figure 3."
Example 4: Server-Side Request Forgery (SSRF)
Finding: SSRF possible via url parameter in /include/seotool/index.php.
Good evidence: "Directory /include/seotool has been fully removed because the functionality is no longer used. An alternative would have been input validation on the URL parameter with an allow-list for permitted hosts."
Example 5: Reflected Cross-Site Scripting (XSS)
Finding: Reflected XSS in /include/menuitem.demo.inc.php.
Good evidence: "Output filtering applied on line 10 of the script with htmlspecialchars(). See Figure 4."
Example 6: passwords stored in plaintext
Finding: Login credentials are stored in readable format in dbacc2.auth_logs.
Good evidence: "Log entries have been modified so passwords are no longer stored. Existing entries with password data have been removed. See Figure 5."
Example 7: publicly accessible NFS share with credentials
Finding: NFS share on 10.0.0.118 contains credential files without access control.
Good evidence: "Access to the NFS share is restricted via network segmentation and authentication. In addition, the passwords on the external systems that used these credentials have been rotated."
Example 8: accepted risk
Finding: Outdated version of jQuery in use with known vulnerabilities.
Poor submission: "Later."
Good evidence: "Vulnerability accepted as residual risk. Rationale: affected functions are not invoked in our codebase (see audit log). Upgrade is scheduled for Q1 2027. Compensating control: additional WAF rule activated that blocks exploitation attempts."
The last category is important: not every finding needs to be resolved immediately, provided the accepted risk is well-substantiated. Our retest report explicitly identifies accepted risks so your auditor can take them into account.
Retest on reports from other pentest parties
Even if the original pentest was performed by another party, you can turn to DongIT for an independent retest. This situation is common: an organization changes pentest partners, wants an independent second opinion or bought a pentest from a party that does not offer a retest service.
What we need:
- The original pentest report (PDF or similar)
- Documentation of the remediation per finding
- Access to the environment to be tested
Our security expert:
- Assesses the quality and currency of the original report
- Validates whether the findings are valid and reproducible
- Performs a targeted retest on each finding
You receive a DongIT retest report in Security Reporter. This stands on its own and can be shared with auditors, clients or internal stakeholders, regardless of who performed the original pentest.
What does a retest cost?
Retests are performed on time and materials at our standard hourly rate. The time required depends on three factors:
- Number of findings being revalidated
- Type of vulnerabilities (simple config check vs complex business logic verification)
- Quality and completeness of your remediation documentation
Indication: a retest for a medium-sized web application typically takes 8 to 12 hours, provided the original pentest was performed by DongIT and the remediation documentation is complete. For reports from other parties the indication is higher due to the additional review step.
Efficient retest?
The quality of your remediation documentation directly determines the duration. Concrete descriptions, screenshots and commit references significantly accelerate the retest.
Frequently asked questions about retesting
Below are the most frequently asked questions about retesting. For a complete overview please visit our FAQ page.
What is the difference between a retest and a new pentest?
A retest validates only the previously identified findings, not new ones. If there have been significant changes to your application, architecture or scope since then, we recommend a new pentest instead of (or in addition to) a retest. In case of doubt we discuss during the intake what fits your situation best.
Within what timeframe can a retest be requested?
We recommend requesting a retest within 6 months of the original pentest. For a longer period findings may have become outdated due to architecture or dependency changes. For DigiD, NIS2 and ISO 27001, strict deadlines often apply within which the retest must be completed.
Does the same pentester perform the retest?
Where possible we have the retest performed by a different pentester than the one who reported the original finding. This safeguards independence. All retests follow the four-eyes principle with peer review.
What if a finding is not fully resolved?
The retest report distinguishes between "resolved", "partially mitigated", "accepted risk" and "residual risk". For the latter two categories we explicitly document the rationale. Your auditor can then assess whether this status is acceptable.
Can I have all findings retested at once or step by step?
Both are possible. For efficiency we recommend a bundled retest when multiple findings have been resolved. For critical findings with a short compliance deadline, an interim retest per finding is also possible.
Can you also retest findings from scanners or bug bounty?
Yes. For findings from vulnerability scans or bug bounty programs we can perform a retest. We apply the same quality standards as for pentest findings, and document the status in a separate report.
What if a client has commissioned a pentest themselves?
If you deliver pentest services to an end client and they request an independent retest, you can engage DongIT as a neutral third party. We fully respect the confidentiality between you and your client and deliver an objective validation.
How long does a retest typically take?
Active testing time 4 to 20 hours, depending on the number and complexity of findings. Total duration from request to final report is typically 1 to 2 weeks, provided the remediation documentation is complete.
Ready to validate your remediation?
Want to request a retest on a DongIT pentest? Log in to Security Reporter and click "Request Retest". Do you have a pentest report from another party and want an independent retest? Contact us for a complimentary intake conversation. Response within one business day.