Why Remediation Support Should Be Included in Your Pentest Package

You receive a 60-page penetration test report with 14 findings. Three are critical, five are high severity. Your development team opens the report, reads the first finding, and immediately has questions. What is the best way to fix this in our specific framework? Will this fix break existing functionality? Is the proposed remediation the only option, or are there alternatives? Should we fix the individual instance or redesign the underlying pattern?

And the pentest firm? Their engagement ended when they delivered the report. They are already on their next client. Your team is on their own. This is the remediation gap, and it is the reason that less than half of pentest findings ever get fixed. A pentest without remediation support is like a diagnosis without treatment. You know what is wrong, but you are left to figure out the cure by yourself.

The remediation problem by the numbers

The data on pentest remediation rates is concerning. Industry research consistently shows that less than 48% of pentest findings are remediated within the expected timeline. For medium and low severity findings, the rate drops below 30%. This means the majority of vulnerabilities that companies pay to discover remain in production.

The reasons are consistent across organizations of every size:

• Unclear remediation guidance. The report says "implement proper authorization checks" but does not explain what "proper" looks like in the context of the specific application and technology stack.
• No access to the testing team. Developers have questions about findings, but the pentest engagement has ended. There is no one to ask.
• Competing priorities. Without a clear understanding of why a finding matters and how to fix it efficiently, security work gets deprioritized against feature development.
• No verification. Without retesting, there is no confirmation that the fix actually works. Teams move on to the next task without closing the loop.

Remediation support directly addresses the first two problems. When your pentest provider remains available to answer questions, review fixes, and provide implementation guidance, remediation rates increase significantly. The investment in the pentest actually produces the security improvement it was supposed to deliver.

What good remediation support looks like

Remediation support is not just a phone number you can call. It is a structured service that bridges the gap between finding vulnerabilities and fixing them. Here is what you should expect.

Direct access to the tester

The person who found the vulnerability is the best person to help you fix it. They understand the context, the attack path, and the nuances of the finding. Good remediation support means your developers can communicate directly with the consultant who performed the test, not a support desk that has to read the report to understand what you are asking about.

Fix review before implementation

Your developers should be able to describe their proposed fix and get feedback from the testing team before writing the code. This prevents wasted effort on fixes that do not actually address the root cause. It is far more efficient to validate the approach upfront than to implement a fix, deploy it, and discover during retesting that it was incomplete.

Technology-specific guidance

Generic remediation advice is not useful. "Implement input validation" means different things in Django, Express, Rails, and Spring Boot. Good remediation support provides guidance specific to your technology stack, including references to framework-specific security features, libraries, and patterns that address the vulnerability correctly.

Retesting to verify fixes

Retesting is the final step that closes the loop. The same tester who found the vulnerability confirms that the fix works as intended and that no new issues were introduced. A verified retest produces the clean finding status that your customers and auditors want to see.

What to ask your pentest provider about remediation

Before signing with any pentest provider, ask these specific questions about their remediation support:

• Is remediation support included in the engagement price? If it is an add-on, ask for the cost and what is included.
• Can my developers talk directly to the tester? Or do they go through a project manager who relays messages?
• Is retesting included? How many findings are covered? What is the retest window?
• How long is the support window? 30 days? 60 days? Until the next annual engagement?
• What communication channels are available? Email? Scheduled calls? Real-time messaging?
• Will the same consultant be available for remediation questions? Or could it be a different person?

The answers to these questions will tell you whether the provider views their job as delivering a report or as helping you actually improve your security. The best providers see the report as the starting point, not the finish line.

The hidden cost of no remediation support

When your pentest provider does not offer remediation support, your team absorbs the cost in other ways.

Developer time spent researching fixes. Your developers are not security specialists. When the report says "implement CSRF protection" or "fix the JWT algorithm confusion vulnerability," they need to research what that means, how to implement it in their stack, and how to test that the fix works. This research time adds hours or days to every finding.

Incomplete fixes that pass internal review but fail retesting. Without expert guidance, developers sometimes implement fixes that address the symptoms but not the root cause. A BOLA fix that adds authorization checks to the reported endpoint but not to similar endpoints throughout the application is incomplete. This only becomes apparent during retesting, adding another fix-and-test cycle.

Findings that never get fixed. When remediation is difficult and there is no one to ask for help, findings get deprioritized and eventually forgotten. They remain in production, accumulating risk.

Hiring external consultants. Some companies end up hiring separate security consultants to help them understand and remediate findings from their pentest. This is an additional cost that would not exist if the original provider included remediation support.

How Lorikeet Security handles remediation

At Lorikeet Security, remediation support is not an add-on. It is included in every engagement because we believe a pentest that does not lead to actual security improvement is a pentest that failed to deliver value.

• Real-time findings delivery. Critical and high findings are reported as they are discovered, so remediation begins during the engagement, not after.
• Direct access to your tester. The same consultant who found the vulnerability is available to answer questions and review fixes.
• Technology-specific remediation guidance. Our reports include remediation recommendations specific to your framework and technology stack.
• Retesting included. Every engagement includes retesting of critical and high findings to verify that fixes are effective.
• 60-day support window. Your team has 60 days of access to the testing team for remediation questions after the report is delivered.

Our goal is not to deliver a report. Our goal is to help you fix the vulnerabilities we find so that your application is actually more secure when the engagement ends than when it began.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.