What happens after a penetration test? The retest and remediation process

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

Step 1: The report walkthrough

Before your team starts writing patches, schedule a walkthrough call with the testing firm. At Simpa Labs, we walk through every finding with your engineering and security teams, explaining the attack chain, demonstrating the proof-of-concept, and answering technical questions. This session prevents a common failure mode: developers misunderstanding a finding and implementing a fix that addresses the symptom but not the vulnerability.

For example, a finding about broken object-level authorisation on a transfer endpoint might get "fixed" by adding a check on one endpoint when the actual issue is a missing authorisation middleware across the entire API layer. The walkthrough ensures your team understands the root cause, not just the reported instance.

Step 2: Reading findings by severity

Every finding carries a CVSS severity score. But severity alone does not determine remediation order. You need to factor in business context. Here is how to prioritise:

Critical (CVSS 9.0–10.0)

These findings represent active exploitability with high business impact. In fintech, this typically means: unauthorised fund transfers, authentication bypass allowing account takeover, or data exfiltration of customer financial records. Target remediation within 48 to 72 hours. If the vulnerability is in production and exploitable now, consider an emergency patch before the walkthrough is even complete. Your testing vendor should have escalated these during the engagement, so this should not be a surprise.

High (CVSS 7.0–8.9)

Significant vulnerabilities that require specific conditions to exploit but would cause serious damage if triggered. Examples: privilege escalation between user roles, rate limiting failures on sensitive endpoints, or insecure direct object references that expose transaction data. Target remediation within one to two weeks.

Medium (CVSS 4.0–6.9)

Vulnerabilities that contribute to risk but are not independently exploitable for high-impact outcomes. Examples: verbose error messages that leak stack traces, missing security headers, or session configuration weaknesses. Target remediation within one sprint cycle (two to three weeks).

Low and informational (CVSS 0.1–3.9)

Best-practice deviations and hardening recommendations. These rarely warrant emergency patches but should be tracked as technical debt and addressed systematically. Examples: cookie attributes, minor information disclosure, deprecated TLS cipher suites still enabled.

Step 3: Assigning findings to engineering

Each finding needs an owner. Assign findings to the engineer or team responsible for the affected component. Do not dump the entire report on one developer. Findings on the payment API go to the payments team. Findings on the mobile app go to the mobile team. Infrastructure findings go to DevOps.

Create tickets in your project tracker (Jira, Linear, GitHub Issues) with the finding title, severity, reproduction steps from the report, and the target remediation date. Link the ticket to the relevant section of the pentest report. This creates an auditable trail that compliance teams and CBN auditors can follow from finding to fix.

Avoid the "fix and forget" pattern

A common anti-pattern: the developer reads the finding, patches the specific endpoint mentioned, and closes the ticket. The same vulnerability pattern exists on four other endpoints that were not in the report because they were not tested or because the tester demonstrated the issue on one representative endpoint. Train your team to ask: "Does this same pattern exist elsewhere in our codebase?" Fix the class of vulnerability, not just the instance.

Step 4: Implementing fixes

Each fix should follow your standard development workflow: branch, implement, code review, test, merge. Do not skip code review on security fixes. A rushed patch that introduces a regression in your payment flow is worse than the vulnerability it was meant to fix. Write unit tests that validate the security control. If the finding was an authorisation bypass, your test should verify that an unauthorised user receives a 403, not that an authorised user receives a 200.

For structural findings that require architectural changes (centralising authorisation middleware, restructuring data access patterns), create a separate implementation plan. These fixes take longer and affect more code paths. Scope them realistically rather than rushing them into a hotfix cycle. For guidance on architectural improvements, see our article on architecture reviews.

Step 5: Requesting retest

Once remediation is complete, notify your testing vendor and request a retest. At Simpa Labs, retesting is included in the engagement. We re-execute the specific attack scenarios that originally produced findings and verify whether the fixes hold. This is not a full re-engagement. It is a targeted verification pass focused on the remediated findings.

Before requesting retest, confirm: all findings have been addressed or documented with an accepted-risk justification, fixes have been deployed to the test environment, and the test environment is accessible with the same credentials. The retest typically takes two to five days depending on the number of findings.

Step 6: Getting the clean certificate

After retest, each finding is marked with an updated status: Remediated (fix verified), Partially Remediated (some risk reduced but not fully resolved), or Open (not fixed or fix did not hold). The updated report and retest certificate become your evidence package.

The final deliverables include: the updated technical report with retest results, the retest certificate confirming verified fixes, and the letter of attestation for external stakeholders. These three documents together form the evidence chain that regulators, auditors, enterprise clients, and investors expect to see. For the complete deliverable list, see our article on documents to demand after a pentest.

Timeline expectations

The full post-pentest cycle from report delivery to clean certificate typically takes four to eight weeks:

• Report delivery: 3–5 business days after testing concludes
• Walkthrough call: Within 1 week of report delivery
• Remediation: 2–4 weeks depending on finding volume and severity
• Retest: 2–5 business days after remediation is complete
• Final deliverables: 2–3 business days after retest

Plan for this timeline when scheduling your engagement. If you have a CBN audit in three months, start the pentest now, not eight weeks before the audit date. For a detailed timeline breakdown by scope, see our article on realistic pentest timelines.

Related reading

Blog: How a Simpa Labs pentest works · What to expect from an engagement · What to look for in a pentest report

Guides: After a breach · Pentest report explained · How to book a pentest

Services: Penetration testing · Vulnerability assessment · API security