Back to Penetration Testing

Pentest Retest: Written Confirmation That Your Fix Works

A retest is a targeted repeat by the same ethical hacker, who tries to break in again exactly where the vulnerability was.

Every Sectricity pentest includes one retest per finding, confirmed in writing, when it takes place within 90 days of the report. Later, or a report from another provider? We can retest that too, based on the original report and results.

How a retest works4 steps

From finding to confirmed fix

  1. 1We find a flawThe report shows how it can be exploited and what to do first
  2. 2Your team applies the fixYou let us know when it is ready
  3. 3The same ethical hacker tests againExactly where the flaw was, including workarounds and variants
  4. 4Confirmed: the flaw is closedIn writing and per finding, usable for your auditor
Included within 90 days of every Sectricity pentest

When do you request a retest?

Your team has addressed findings from a pentest and wants confirmation the fixes hold
An auditor (NIS2, ISO 27001, SOC 2) requests written proof of remediation
You have rolled out a patch and want to know whether the vulnerability is effectively closed
Your internal scan or tooling no longer reports an issue, but you want human validation
You are preparing a new release and want to confirm that vulnerable components are no longer exploitable
You received a pentest report from another provider and want to know which findings are still open

Why is human validation essential in a retest?

Scanners confirm the signal, not the fix

A scanner detects whether a known vulnerability signature is present. If the signature disappears after a patch, the scanner reports no problem. But a human tester attempts the attack again, including variants and alternative paths. That depth is the difference between a report that says 'not detected' and a person who says 'not exploitable'.

Tooling misses context and attack chains

Automated testing tools, including AI-driven solutions, improve rapidly at finding known patterns. They do not understand how the original vulnerability worked in your specific application, which workarounds the attacker could take, or whether the fix introduces a new weak point. A hacker who knows the original exploit path tests all variants.

Business logic fixes are not scannable

Flaws in business logic, access control and authorisation are missed by scanners at discovery, and equally so at validation. If your fix adjusts an authorisation rule or rewrites a flow, a manual retester is the only reliable way to confirm the abuse path is closed.

Audit-ready evidence requires a human signature

A NIS2 auditor or ISO 27001 reviewer does not accept scanner output as proof of remediation. A written retest report from an experienced ethical hacker, with a per-finding confirmation of open or closed status, is the document your compliance team can hand over.

How does a retest at Sectricity work?

Define scope

We use the original pentest report as the starting point. Together you decide which findings are retested: all critical and high-risk items, a selection, or an extended delta including new components.

Targeted retesting

The same techniques as the original test, focused on the specific vulnerabilities. The hacker actively attempts to bypass the fix, including related attack vectors noted during the first test.

Validation report

Per finding a clear status: closed, partially closed, or still open. With technical substantiation, reproduction evidence and an updated CVSS score where relevant.

Audit package

Executive summary for management. Technical confirmation for your development team. Compliance documentation for your auditor. All in one report, ready to use.

Retest vs. validating internally: what is the difference?

Internal validation

Confirms a fix at the signal level. Does not test active exploitability. Does not validate business logic fixes. No audit-ready report. Human verification depends on internal expertise.

Scanner or tooling

Confirms signature absence. Does not test exploitability. Cannot validate logic or authorisation fixes. Output is not accepted as audit evidence. No human verification.

Sectricity Retest

Confirms fix at signal level. Tests active exploitability. Validates business logic and authorisation fixes. Delivers audit-ready report. Always human-verified by an experienced ethical hacker.

Frequently asked questions

A retest is a targeted repetition of a pentest, carried out after your team has addressed the findings. An experienced ethical hacker attempts to exploit the specific vulnerabilities from the original report again. The goal is not to discover new vulnerabilities but to confirm that the fixes are effective and no longer exploitable.

After confirmation that fixes have been implemented, we typically schedule the retest within five to ten working days. For urgent situations such as an upcoming audit or planned release, we align timing to your deadline.

That is a useful first step, especially for vulnerabilities with a clear signature. But scanners validate the signal, not exploitability. Business logic flaws, IDOR and authorisation issues are not reliably validated by automated tools. A human retest confirms the attack itself no longer succeeds.

NIS2 requires demonstrable technical controls and evidence that risks are managed and followed up. A written retest report from an experienced pentester is the strongest proof that a found vulnerability has been effectively remediated. ISO 27001 Annex A requires comparable validation of corrective measures.

We document that in the report with technical details explaining why the fix is insufficient and an updated remediation recommendation. A further retest of that same finding is agreed together.

Yes. We then need the original report and the results of that test. We first have to work out where and how each flaw was found, so this takes more work than the retest included in our own pentests. Based on the report we agree on scope and approach together.

Certain your fix works?

Request a retest and get written confirmation per finding.