Retesting

  1. Home
  2. Retesting

Why Request a Retest After a Pentest?

The results of a pentest (penetration test) may reveal vulnerabilities in a web application, API, or network. Based on the pentest report, developers or administrators take action to remediate these security issues or mitigate associated risks.

To ensure that the identified vulnerabilities have been effectively and adequately resolved, it is highly recommended to perform a retest. A retest confirms that no security risks remain and helps meet compliance requirements from customers, auditors, or certification bodies.

What is a Retest?

A retest is a focused follow-up to a previously performed pentest. It is not a full new penetration test. During the retest, a security expert checks whether the applied security measures are effective and structurally implemented. The retest process includes:

  • Verifying whether vulnerabilities have been properly remediated;
  • Confirming that the solution is structurally implemented (not a temporary fix);
  • Delivering a new retest report with documented proof of the resolved findings.

The retest report builds on the original pentest report and clearly outlines the current security status of your application or environment.

How Much Does a Retest Cost?

A retest is billed on a time and materials basis at our standard hourly rate. The time required depends on:

  • The number of resolved vulnerabilities;
  • The type and severity of the issues;
  • The quality and completeness of the provided documentation.

Example: A retest for a medium-sized web application typically takes 8 to 12 hours, assuming DongIT performed the original pentest. Please note that this can vary depending on the complexity of the original findings.

Retesting a Pentest Performed by Another Provider

Even if a different provider performed your original pentest, DongIT could still conduct an independent retest. In that case, you will need to submit the original pentest report. Our security experts will:

  • Assess the quality and validity of the original findings;
  • Verify whether the issues are still relevant;
  • Perform a detailed retest based on the provided documentation.

Looking for confidence in your remediation? Let DongIT perform your retest and receive a clear, evidence-based report.

Request a Retest via the Reporter Portal

Need a retest based on findings from a previous pentest? You can easily request this via the DongIT Reporter Portal.

  1. Log in to the Reporter Portal.
  2. Navigate to the relevant Finding in your pentest assessment.
  3. Click on "Request Retest" for each finding you want to have retested.
  4. In the comment box, provide a description of how the vulnerability was remediated or mitigated.

Request retest

What to Submit for a Retest?

To ensure an efficient and smooth retest process, providing clear and complete documentation for each finding is important. For every issue, include:

  • What was changed? Describe the fix in concrete terms.
  • Where was the change made? Refer to file paths, code lines, or endpoints.
  • How was it changed? Provide technical details or configuration updates (such as screenshots of updated code, Git commit references, and/or explanations of design decisions or accepted risks).

Based on this input, a pentester will assess whether the vulnerability has been effectively and structurally resolved.

Examples of Proper Retest Documentation

1. Parameter Abuse

Finding: The jobalert_action parameter on /nl/jobs/alert allowed unauthorized access to internal methods.
Poor submission: Fixed.
Proper submission: Resolved by implementing a whitelist of allowed methods. See attached screenshot (Figure 1).

whitelist_methods
Figure 1: Whitelisted methods.

2. Missing Cookie Attributes

Finding: The PHPSESSID cookie lacked the Secure and HttpOnly attributes.
Poor submission: Fixed.
Proper submission: Updated in php.ini. Attributes Secure and HttpOnly are now enabled. See Figure 2.

cookie_settings
Figure 2: Updated cookie settings.

3. SQL Injection

Finding: Unparameterized query found on line 89 in controllers/pagesController.php.
Poor submission: Advice followed.
Proper submission: Queries have been parameterized using PDO. See screenshot (Figure 3).

parametrisering_query
Figure 3: Parameterized queries in use.

4. Server-Side Request Forgery (SSRF)

Finding: SSRF possible via url parameter in /include/seotool/index.php.
Proper submission: The /include/seotool directory has been removed from the project.

5. Reflected Cross-Site Scripting (XSS)

Finding: Reflected XSS in /include/menuitem.demo.inc.php.
Proper submission: Input is now filtered on line 10 of the script. See screenshot (Figure 4).

reflected_xss
Figure 4: Input filtering implemented.

6. Passwords Stored in Plaintext

Finding: Login attempts, including plaintext passwords, were logged in dbacc2.auth_logs.
Proper submission: Logging behavior updated, passwords are no longer stored. Old entries have been deleted (Figure 5).

foutieve_inlogpogingen
Figure 5: Insecure logs have been removed.

7. Publicly Accessible NFS Share

Finding: Unsecured NFS share on 10.0.0.118 exposed credentials.
Proper submission: Access now restricted; password for affected account updated on gw2012.acme.local.

8. Outdated Software in Use

Finding: Deprecated jQuery version detected.
Proper submission: Vulnerability acknowledged; resolution is pending (low-risk).

Important Notes

❗ The more complete your documentation, the more efficiently a retest can be executed.
❗ If you have questions or uncertainties, please contact us via the Reporter Portal or your DongIT contact.