Can the firm that tested us also fix the findings?

Most reputable firms decline, and they are right to. An assessor who remediates their own findings is marking their own homework, and a regulator or customer reviewing the retest will notice. Some firms offer remediation through a separate team, which helps but does not fully resolve the conflict.

How long should remediation take?

It depends far more on decision-making than engineering. The fixes are often small. Establishing who owns a finding, what the accepted risk is, and which changes need validation is what consumes the calendar.

Who Closes Penetration Test Findings?

You commissioned a penetration test. You got a thorough report. Every finding has a severity, a description, and a recommendation.

Now what?

The structural problem

The firm that tested you generally will not remediate. That is not obstruction - it is the correct position. An assessor who fixes their own findings and then retests them has no independence left, and anyone reviewing that retest downstream, whether a regulator, an enterprise customer, or an acquirer, can see the circularity.

So the report comes back to you. And the two groups who might act on it are usually not equipped to:

Your engineering team can read the finding, but "insufficient entropy in session token generation" is not a ticket. Someone has to translate it into a change, decide whether the recommended fix suits the architecture, and know which of the twelve findings actually matter.

Your managed service provider may run the infrastructure, but their contract is uptime and support. Application-layer findings sit outside their scope, and in my experience an MSP without a security practice will quietly deprioritize them rather than say so.

The result is a report that ages. I have seen findings from one test still open when the next year's test rediscovers them.

What closing findings actually involves

Triage first. Not every finding deserves the same response, and severity ratings are the assessor's view of generic risk, not your view of your risk. Some findings are genuinely accepted risks. Say so explicitly, in writing, with a rationale - an accepted risk that is documented is a decision, and an undocumented one is an oversight.

Then the engineering. Most fixes are small. The work is knowing which change is correct, and not introducing a regression while making it.

Then the documentation. If you are in a regulated space, closing a finding is not enough - you need a record that shows what was found, what was changed, how the change was verified, and who approved it. That record is what a reviewer reads. Getting it right afterwards, from memory, is far harder than capturing it as you go.

Then retest, against the same scope, so the closure is independently confirmed. The mechanics of getting from the report to that retest are covered separately in what to actually do with a penetration test report.

The honest version

Most organizations do not have a gap in testing. Testing is easy to buy. They have a gap in the thing that happens between the report arriving and the retest passing, and that gap is engineering work with a regulatory paper trail attached.