Back to Penetration Testing
    Pentest Retest

    Pentest Retest: 100% Confirmation That Your Fix Works

    After a pentest your team knows what is vulnerable. But knowing whether the fix actually holds is a different question. Sometimes teams address findings with internal resources, basic scanners or available tooling. These give a signal, but not certainty: a tool that no longer detects the vulnerability does not prove that an attacker cannot still get through.

    A retest is a targeted repetition by the same ethical hacker: someone who knows the original vulnerability, understands the context and actively tries to break in again at exactly that point. Only then do you have the confirmation your technical team, your management and your auditor can rely on.

    Request a RetestContact Us

    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

    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 a certified 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 a certified ethical hacker.

    Frequently Asked Questions

    A retest is a targeted repetition of a pentest, carried out after your team has addressed the findings. A certified 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 Article 21 requires demonstrable technical controls and evidence that risks are managed and followed up. A written retest report from a certified 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. You receive a new retest once the revised fix has been implemented.

    Yes. We need the original pentest report to understand the scope and findings. Based on that we jointly define the retest scope and timeline.

    Certain your fix works?

    Request a retest and get written confirmation per finding.

    Request a RetestContact Us