How to Re-Present Pen Test Findings That Engineering Dismissed Six Months Ago

Understanding why a finding was dismissed is the necessary first step before re-escalating it. There are four common dismissal reasons, and each requires a different re-presentation approach:

Competing sprint priorities. The engineering team agreed the finding was real but could not fit remediation into their current sprint or quarterly roadmap. This is the most common dismissal reason. The fix is timing the re-escalation to align with sprint planning or roadmap cycles, and making the remediation scope concrete enough to fit into a sprint estimation.

Insufficient business impact framing. The original finding was presented in technical terms that did not translate to business risk. "SQL injection on the reporting endpoint" does not carry the same weight as "an authenticated user can extract all customer records from the reporting database." Re-escalation requires translating the finding into the business impact the original report may have left implicit.

Disagreement on exploitability. Engineering assessed the attack path as too complex or too unlikely to warrant immediate remediation. If exploit code has been released or the finding class has appeared in CISA KEV since the original report, this objection is no longer valid and that is the new evidence for re-escalation.

No clear owner. The finding fell between teams: it affected both the backend API and the infrastructure layer, and neither team felt full ownership. Re-escalation requires identifying a single named owner before the re-presentation meeting, not during it.

Before re-escalating a dismissed finding, verify three things:

Is the vulnerability still present? Systems change. The affected component may have been updated, replaced, or removed since the original assessment. A quick targeted retest of the specific attack path (not a full re-assessment) confirms whether the finding is still exploitable in the current environment. A finding that has been accidentally remediated through unrelated infrastructure changes should be marked closed, not re-escalated.

Has the exploitability changed? Check the EPSS score for the underlying CVE (if the finding maps to a known CVE). Check CISA KEV for active exploitation confirmation. Search for public proof-of-concept code released since the original report. A finding with an EPSS score that has increased from 0.02 to 0.4 since the original report has materially changed risk profile -- that change is the central argument for re-escalation.

Is the remediation still technically feasible as described? Code changes, architecture changes, or dependency updates since the original report may have changed what remediation requires. If the original recommendation was "upgrade this library to version 3.2" and the library has since been deprecated, the remediation path needs to be updated before re-presenting.

Findings that fail the first check should be closed. Findings that fail the second check with no change in exploitability and no new threat intelligence may not justify re-escalation if they were genuinely low risk. Findings that pass all three checks with updated exploitability data are strong re-escalation candidates.

The single biggest mistake in re-escalating dismissed findings is repeating the original urgency argument more loudly. If "this is a critical severity finding" did not produce a remediation commitment six months ago, repeating it will not produce one now. Engineering heard it. They made a prioritization decision. Repeating the same argument with more emphasis signals that you have no new information.

Effective re-escalation always leads with what has changed since the original dismissal. That change can be:

New exploit availability. "When we presented this finding in December, there was no public proof-of-concept code. Since then, two PoC implementations have been published on GitHub and the EPSS score has increased from 0.03 to 0.38."

A real-world incident in the same vulnerability class. "The MOVEit breach in 2023 exploited an SQL injection vulnerability in a file transfer interface. The finding on our reporting API uses an identical attack pattern and we process the same category of data that MOVEit customers lost."

A compliance or audit obligation. "This finding is now scheduled to appear in our next SOC 2 audit cycle. An open finding of this severity without a documented remediation plan or formal risk acceptance will appear as an observation in the audit report."

A changed system role. "The affected endpoint was internal-only when this finding was originally presented. It has since been exposed to third-party API clients as part of the partner integration project, which changes the effective attack surface."

Any one of these represents genuinely new information that justifies reopening the conversation. None of them require re-arguing the original risk assessment.

The most effective re-escalation argument is a real-world incident that demonstrates the exact attack path the finding describes. When an organization in the same industry suffers a breach from the vulnerability class your finding covers, the re-escalation conversation changes from a theoretical argument to a concrete risk demonstration.

Maintain a running reference set of public breach incidents organized by vulnerability class. When a finding re-escalation is coming up, check whether any recent public incident maps to the attack pattern. For SQL injection findings, the reference set might include major incidents from the past 24 months involving SQL injection exploitation. For authentication bypass findings, the reference set includes incidents involving session hijacking or credential-based lateral movement.

If a direct industry match exists, structure the re-escalation around it: "Here is a breach incident from six weeks ago involving a company with a similar system profile to ours. Here is how our open finding creates the same attack path. Here is what remediation looks like in our environment and how long it takes."

If no direct industry match exists, use CISA KEV listings as the threat context proxy. A finding that maps to a CVE on the KEV list has confirmed, active exploitation by real threat actors -- that is a factual statement about current threat activity that does not require a specific breach incident to be compelling.

Do not re-escalate to the same engineer who originally dismissed the finding. Re-escalation is a leadership conversation, not a technical debate. Bring it to the engineering manager or VP of Engineering with three prepared elements:

A one-page summary with updated evidence. The finding ID and original date, current status (still open, still exploitable -- confirmed via retest), what has changed since dismissal (new exploit data, relevant incident, changed system role), and the business impact in non-technical language.

A concrete remediation scope. Re-escalation fails when engineering cannot estimate the remediation work. Before the meeting, do the scoping work yourself or with a friendly engineering contact: which files change, roughly how many hours, what regression testing is required. "This requires modifying the query construction in two functions in the reporting service. Our estimate is 4 to 6 hours of engineering time plus standard regression testing." Engineering leaders can schedule 4 to 6 hours. They cannot schedule "address the SQL injection findings."

A formal decision request. The purpose of the re-escalation is to obtain one of two outcomes: a dated remediation commitment that goes into the sprint plan, or a formal documented risk acceptance signed by someone with the authority to accept it. If neither outcome is produced, schedule a follow-up within 30 days. Open findings without either a remediation plan or a risk acceptance are not managed risk -- they are ignored risk.

Not every open finding needs to be remediated. Some findings represent risks that the organization has genuinely evaluated and accepted -- perhaps because the attack path requires authenticated access that is tightly controlled, or because the affected system is scheduled for decommission, or because compensating controls adequately reduce the practical risk.

A formal documented risk acceptance is a legitimate and appropriate outcome for a finding that cannot be immediately remediated. It is not a failure of the re-escalation process. What is a failure is an informal verbal dismissal with no documentation: "we will get to it eventually" is not a risk acceptance, it is deferred decision-making.

A valid formal risk acceptance includes: the specific finding ID and description, the justification for accepting the risk rather than remediating, the compensating controls in place, the name and title of the person accepting the risk on behalf of the organization, the date of acceptance, and a review date (typically 6 to 12 months) at which the risk acceptance is re-evaluated.

With a formal risk acceptance documented, the finding is managed. Without it, the finding remains open and unmanaged. The re-escalation conversation should frame the choice explicitly: "We need a dated sprint commitment for remediation by [date], or a formal risk acceptance document. Which makes more sense given current engineering priorities?"