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.
From finding to confirmed fix
- 1We find a flawThe report shows how it can be exploited and what to do first
- 2Your team applies the fixYou let us know when it is ready
- 3The same ethical hacker tests againExactly where the flaw was, including workarounds and variants
- 4Confirmed: the flaw is closedIn writing and per finding, usable for your auditor
When do you request a retest?
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
Certain your fix works?
Request a retest and get written confirmation per finding.