Finding Closed Is Not Finding Fixed: Who Actually Owns Remediation After a Pentest

Most pentest reports end the same way. The findings land in a PDF, someone creates Jira tickets, developers close them over the next few sprints, and the tracker eventually reads zero open issues. Leadership sees a green dashboard. The security team marks the engagement complete. Nobody retests.

The vulnerability may still be there. The tracker just stopped caring.

And that is the straightforward case. Many findings do not have a clean technical fix at all. They require a process change — updated access controls, a new approval workflow, a revised deployment practice — that cuts across multiple teams and carries its own project timeline. Developing the better practice, getting cross-functional buy-in, building it, training on it, and verifying it is not a sprint task. It can take months. A Jira ticket closed after a single pull request tells you nothing about whether that organizational change actually took hold.

This is the remediation accountability gap — the space between a finding being logged and a finding being fixed — and it is where most of the risk lives after a pentest. It is also why retesting at the end of remediation, and re-running a full pentest once significant changes are in place, is not optional diligence. It is the only honest way to know where you actually stand.

The Problem With “Closed”

Closing a ticket is an administrative act. Fixing a vulnerability is a technical one. Organizations routinely conflate the two, and the consequences are predictable: the same findings resurface in the next engagement, often more deeply embedded because the team believed they had already addressed them.

Consider what “closed” actually means in most workflows. A developer patches a parameter. A ticket moves to Done. A manager signs off. No one with security context verified the fix, no one confirmed it reached production, and no one tested whether the remediation introduced a new issue. The Jira board is clean. The attack surface is not.

This is not a failure of effort. It is a failure of process. Remediation without verification is assumption management, not risk reduction.

Who Has the Authority to Call It Fixed?

This question exposes a structural problem most organizations have not thought through. After a pentest, findings typically transfer to the development or infrastructure team. Those teams are accountable for shipping fixes, but they are not positioned to confirm that a fix is security-complete. That judgment requires someone with enough context to understand both the original vulnerability and the technical adequacy of the remediation.

In practice, remediation sign-off requires three distinct checkpoints:

1. The fix is deployed to production. Not the dev environment. Not staging. The environment the pentest tested against. This sounds obvious; it is frequently missed.

2. The fix addresses the root cause, not just the symptom. A patched endpoint does not close a finding if the underlying misconfiguration persists elsewhere. The person reviewing remediation needs to understand the finding well enough to know whether the fix is complete.

3. An independent party has verified the fix under real conditions. This is the retest—the only confirmation that carries actual weight. Self-attestation from the team that wrote the code is not verification; it is optimism.

Authority to declare a finding resolved should require all three. Most organizations stop at the first.

What Proper Remediation Documentation Looks Like

When a finding is genuinely closed, there should be a paper trail that supports that claim. At minimum:

• The specific change made, with enough technical detail to trace it back to the original finding. “Patched” is not sufficient. “Updated library X from version 2.1 to 2.8, which addresses CVE-YYYY-XXXXX” is.
• The deployment confirmation, showing the fix reached the environment that was tested.
• The retest result, documented by the security practitioner who conducted the original assessment or a qualified reviewer with full context of the finding.

This documentation exists not to create bureaucracy, but to make the accountability chain legible. When an auditor, a board, or a prospective client asks whether a critical finding from six months ago is resolved, “the ticket is closed” is not an answer. A retest result with a timestamp is.

The Retest Is the Only Real Confirmation

A retest is not a follow-on engagement you negotiate separately after the dust settles. It should be a built-in expectation—a structural part of how a pentest engagement works, rather than an optional add-on that gets cut from scope when budgets tighten.

This is exactly why EliteSec includes five free retests as a standard component of every engagement. Not as a marketing gesture. As an accountability mechanism. The retest forces the question: is this actually fixed, or does the tracker just say it is?

Five retests covers the realistic remediation cycle for most engagements. Teams rarely fix everything in one sprint. Priorities shift, fixes regress, and some findings require multiple iterations before they are genuinely resolved. Building the retest into the engagement keeps the security context intact. The same practitioner who found the issue returns to confirm it is gone, with full knowledge of how it was exploited and what a real fix should look like.

That continuity matters. A retest conducted by someone without context of the original finding is a checklist exercise. A retest conducted by the person who wrote the finding report is accountability.

A Practical Remediation Handoff Standard

If your organization does not have a defined remediation handoff process, here is a working baseline:

At report delivery: Each finding should be assigned to a named owner, a person, not a team. That owner is responsible for coordinating the fix and staging the verification, not just routing the ticket.

At fix completion: The owner documents the specific change and confirms deployment to the tested environment. This documentation goes back to the security team, not just into the ticket.

At retest: The security practitioner verifies the fix against the original finding, documents the outcome, and formally closes the finding in the engagement record. The ticket in Jira reflects the retest result. It does not drive it.

At engagement closure: The only findings that are genuinely closed are those with completed retests. Everything else is open, deferred, or accepted as residual risk. That distinction matters for audits, for client conversations, and for your own honest assessment of where you stand.

Moving Beyond the Tracker

Remediation is where security programs succeed or quietly fail. The pentest is not the end—it is the beginning of a verification cycle. How your organization closes that loop determines whether the engagement produced real risk reduction or just an expensive report with an expiration date.

If the tracker says done but no one retested, the work is not done. Build verification into your process from the start, assign clear ownership at every stage, and demand evidence before you move forward. That discipline is what separates genuine security improvement from security theater.

---

Not sure whether last year’s findings were ever truly fixed? Get in touch and we’ll help you build retesting and remediation accountability into your engagements.