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.

So who owns it

The honest answer is that it has to be one named person, and the question is only which chair they sit in. Four candidates come up, and three of them fail for structural reasons rather than for lack of effort.

The engineering lead. The most common default, and it works right up until it competes with the roadmap. A finding is not a feature, it has no customer asking for it, and it loses every prioritization conversation it enters unless somebody outside engineering is counting. The deeper problem is that the person is being asked to assess the security of their own team's work, which is the same independence problem the testing firm had, moved one layer in.

The managed provider. Covered already: their contract is uptime and support, and application-layer findings sit outside it. Asking them to own closure also asks them to report on gaps in infrastructure they configured.

Compliance, quality or regulatory affairs. Often the only function that actually tracks the findings to closure, and genuinely good at the paper trail. They cannot evaluate whether a proposed fix is correct, which means they end up tracking assertions rather than outcomes. A finding marked closed because a ticket was closed is the failure mode this produces, and it survives right up until the retest.

A named security owner. The one that works, and the one most companies at this size do not have. It does not need to be full-time. It needs to be somebody with enough application and infrastructure knowledge to judge whether a fix is real, and enough standing to say the date is not going to hold.

The shape that fails in every case is the same: responsibility spread across three functions with adjacent duties and no one holding the specific sentence "every finding in this report has a disposition and evidence." That is the same join that leaves an MSP and an MSSP both reporting green while the estate is half covered.

Who gets to accept a risk

Worth separating out, because it is where ownership gets tested.

Accepting a risk is a business decision, not an engineering one. The person accepting it is saying the company will carry the consequence if the finding is exploited, and that is not a judgment an engineer can make on a Thursday afternoon to clear a backlog. In a regulated company it is also a decision somebody will eventually read back to you with the benefit of hindsight.

So the rule worth adopting is simple. Whoever accepts a risk has to be senior enough to carry it, the rationale goes in writing at the moment of the decision, and it gets a review date rather than standing forever. A risk accepted in writing by a named person is a decision. The same risk accepted silently by nobody in particular is an oversight, and the difference is entirely visible to a regulator, an acquirer or an enterprise customer reading the file afterwards.

The practical test for whether ownership exists: ask who accepted the open findings from your last test, and see whether a name comes back.

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.