Fixing Penetration Test Findings Before an Enterprise Deal: A Guide for Canadian SaaS Companies

Fixing penetration test findings is often the last thing standing between a software company and a signed enterprise contract. The buyer's security team asks for a recent penetration test, reads the findings, and puts the deal on hold until you show they are fixed. For Canadian SaaS companies selling to banks, hospitals, universities, governments and large US firms, this is now a normal part of the sales cycle. Here is how to handle it quickly and honestly, and what to ask your team or development firm.

What the buyer actually wants to see

Most security reviewers do not expect a perfect report. Every real application has findings. What they want is evidence that you take them seriously:

1. Critical and high findings fixed, and confirmed by a retest.
2. A written plan with dates for the medium findings.
3. A clear decision on the low and informational ones: fix them, or accept the risk and say why.
4. Answers in their security questionnaire that match what the report says.

Check that the test covered the product the buyer is actually buying and is less than a year old. Many reviewers will reject an old or narrow report however clean it is. Buyers will often accept a summary or a letter from the testing firm instead of the full report, which can stay under NDA. Ask what they need before you send anything.

Some buyers have their own rules behind these requests. Banks and other federally regulated financial institutions in Canada follow OSFI's Guideline B-10, which expects them to manage risk from their vendors, and Guideline B-13 on technology and cyber risk, so they will look closely at how their vendors find and fix security problems. Their contract may also set deadlines for fixing findings by severity. Read the security terms before you promise dates.

Read the report like an engineer, not a checklist

A penetration test report lists what the tester found in the time they had. Before anyone starts patching, go through it carefully:

1. Check each finding is real. Testers sometimes report false positives, or issues that a control elsewhere already blocks. If you dispute one, explain why in writing and ask the tester to confirm.
2. Look past the severity score when you plan the work. A medium finding on a page that holds customer data can matter more than a high finding on an internal admin page. Do not change the tester's ratings yourself, though. If you think one is wrong, ask the tester to review it in writing, because the buyer will go by the tester's ratings.
3. Group findings by cause. Five findings about users reaching data they should not see often come from one missing check in how the application handles permissions.
4. Assume the tester only saw a sample. If one endpoint skips a permission check, others probably do too.

Fix the cause, not just the finding

The most common mistake is fixing exactly the URL in the report and nothing else. The retest then marks that one item fixed, and the same flaw is still sitting on twenty other endpoints. A good fix goes to the root:

1. Broken access control, which sits at the top of the OWASP Top 10, is best fixed with one central authorization check that every request goes through, not a patch on each page.
2. Injection flaws are fixed by using parameterized queries and safe templating everywhere, not by filtering one input.
3. Outdated or vulnerable libraries are fixed by upgrading and then adding automated dependency checks to the build, so the problem does not come back.
4. Leaked secrets, such as keys in code or logs, mean rotating the secret and checking whether anyone used it, not just deleting the line.
5. Missing security headers, weak session settings and detailed error messages are usually quick configuration fixes. Do them early because they are cheap, but never let them delay the critical and high items.

Add an automated test for each serious fix so a future change cannot quietly undo it.

Get the retest and keep the evidence

Deploy the fixes to production, or to the environment that was tested, then ask the original testing firm to retest the fixed findings. Most firms offer this, sometimes included in the original price. The result is usually an updated report or a retest letter showing each finding as fixed, partly fixed or still open. That document, from an independent tester, is what the buyer's security team trusts. Never edit the tester's report yourself.

Keep your own record too: the finding, the cause, the fix, the code change, the test that proves it and the date. The next questionnaire, your SOC 2 auditor and future buyers will ask for the same evidence.

Answer the questionnaire honestly

When a security questionnaire comes with the pen test request, the two must agree. If the report shows a weakness in how you handle sessions, do not answer "yes, fully implemented" on the session controls question. Reviewers compare them. An honest "partly, fix scheduled for next month" with a date keeps your credibility. An optimistic answer that a retest later contradicts can lose the deal and the relationship.

Stop the next report looking the same

Many enterprise buyers expect a new penetration test every year or after major changes. The cheapest way to get a short report next time is to build security into normal work:

1. Code review that checks permissions and input handling, not just style.
2. Automated dependency and secret scanning in the build pipeline.
3. Tests that check one customer cannot reach another customer's data.
4. A simple process to fix new findings by severity, with dates.

Ten questions to ask your team or development firm

1. Which findings are critical or high, and when will each be fixed and retested?
2. Have we confirmed every finding is real, and written down why we dispute any?
3. Which findings share a root cause, and are we fixing the cause or just the URL?
4. Have we checked the rest of the application for the same flaw, not only the place the tester found it?
5. Is there an automated test for each serious fix?
6. Has the testing firm agreed to retest, and when will we get the retest letter?
7. Which low findings are we accepting, and have we written down why?
8. Do our security questionnaire answers match the report and the retest?
9. What does the customer's contract say about fix deadlines (check with your lawyer if the terms are unclear)?
10. What will stop the same findings from showing up in next year's test?

If several answers are vague, that is your list of work.

How we approach it

NorthSight Technologies is a software development company in Ontario, Canada. We are not the firm that runs your penetration test. We are the engineers who fix what it finds. Senior engineers read the report and the code, find the root causes, write and test the fixes, check the rest of the code for the same flaws, and prepare the evidence your testing firm and your customer's security team will ask for. We work alongside your testing firm and your security or compliance lead.

If your enterprise deal is waiting on penetration test findings and you want a straight answer on how long the fixes will take, we offer a free 20-minute call. You can read how we work and book the call on our secure code review and application security page.

Also published on LinkedIn →