A pentest finds a vulnerability. A developer patches it. The ticket closes. For most organizations, that is where the story ends, and that is exactly the point where the risk quietly reopens.

A patch is a claim, not a guarantee. It says the reported flaw was addressed. It does not say the fix was tested against the same conditions that exposed the flaw, or that the fix did not create a new one, or that the same class of bug is not still sitting one endpoint over. Closing a finding and closing the risk are two different events, and the gap between them is where the most expensive vulnerabilities in cybersecurity history have lived.

Here is what the numbers show about how often that gap opens, one case where it stayed open for eighteen years, and how independent verification is meant to shut it.

The Gap Between "Fixed" and "Verified"

The scale of the remediation gap is larger than most security leaders assume. Larger enterprises leave 45.4% of discovered vulnerabilities unresolved within a 12-month period, concentrated heavily in the network and device layer.

Even among the vulnerabilities organizations do address, high and critical severity application and API findings take an average of 54.81 days to remediate, and 32% remain unpatched for more than 180 days.

Verification adds another layer of difficulty on top of that. 79% of organizations say patch validation is a major challenge, and 66% miss their own patching deadlines before validation even begins. This is not a discipline problem. It is a design problem: most remediation workflows have a hard deadline for writing the fix and no equivalent deadline for confirming it.

Why Fixes Fail More Often Than Teams Expect

The assumption behind most remediation workflows is that a fix, once shipped, is done. The data does not support that assumption.

Partial fixes are the most common failure mode. A patch blocks the specific exploitation technique described in a report rather than addressing the underlying flaw, which is why the reported test case stops reproducing while the real vulnerability class survives underneath it. A large-scale analysis of 8,100 security patches found that 84.6% of unreliable patches are never publicly disclosed as incomplete, which means most organizations relying on a patch announcement as proof of resolution are relying on information that was wrong from the start and never corrected.

Patch regressions are the second failure mode, and they are not rare edge cases. An exploratory study of regression vulnerabilities at Mozilla examined 78 cases where a bug fix itself introduced a new vulnerability that had not existed before. The fix worked. It also opened a different door.

Environment drift is the third. A fix validated in staging, where configuration, feature flags, and dependency versions rarely match production exactly, can pass every internal test and still leave the underlying flaw reachable once it ships. None of these three patterns point to a careless engineer. They point to a system that changes faster than any single internal review cycle can keep pace with, which is precisely why the fix itself was never going to be the last word on whether the risk was gone.

When the Fix Is the Vulnerability

The clearest illustration of what happens when verification does not outlive the fix is CVE-2024-6387, known as regreSSHion, a textbook case of the patch regression pattern described above, playing out at global scale.

In 2006, researchers identified and patched a race condition vulnerability in OpenSSH, tracked as CVE-2006-5051. The fix held for fourteen years. Then, in October 2020, an unrelated update to OpenSSH's logging infrastructure in version 8.5p1 quietly reintroduced the exact same race condition. Nobody caught it, because nobody was testing a fourteen-year-old finding against a change that had nothing to do with security on its surface. The regression sat undetected until 2024, when researchers at the Qualys Threat Research Unit rediscovered it and found that more than 14 million potentially vulnerable OpenSSH instances were exposed to the internet worldwide.

The original fix in 2006 was correct. The problem was that nobody was still checking eighteen years later, when an unrelated change quietly undid it. That is the entire argument for verification outliving the fix in one case study: the vulnerability was not new, it was not clever, and it was not caused by a bad developer. It was caused by a fix that nobody went back to confirm was still holding.

How Independent Verification Fits Into the Process

A finding reaches your team one of two ways. Secuna Pentest goes looking for it on a schedule, through scheduled vulnerability assessment and penetration testing. Secuna Response, the vulnerability disclosure program, receives it whenever an outside researcher finds it first. Secuna treats verification as a required stage after either one, not an optional favor tacked on at the end.

Once a Pentest finding is marked fixed, a hunter retests it against the exact attack path in the original report: same input, same route, same environment where possible. The retest returns one of two outcomes, confirmed or not confirmed, with the same level of detail the original finding had. There is no third category where a fix is assumed to have worked because nobody heard otherwise.

Secuna Response runs the same check on the other side of the pipeline. Before a disclosed vulnerability is marked resolved, a hunter, not the original reporter and not the team that wrote the fix, confirms the flaw is gone, since the researcher who found it typically has no further stake once they have reported it. Every confirmation, from either program, lands in the same record as the original finding, so the full history from discovery to fix stays in one place rather than split across a ticketing system and a thread of emails.

That record feeds the assessment trail behind a digital certificate of cybersecurity assessment, the kind of security verification an auditor can actually check.

Why This Matters More in the Philippines Right Now

The technical risk of an unverified fix is significant on its own. The business and regulatory consequences are becoming just as important, and in the Philippines, those consequences are sharpening fast.

Under the Data Privacy Act of 2012, the National Privacy Commission can impose administrative fines of 0.5% to 3% of annual gross income for grave violations, and organizations must notify the NPC and affected data subjects within 72 hours of discovering a breach involving sensitive personal information. Enforcement in 2026 has shifted from reactive to proactive, with the NPC expecting organizations to demonstrate compliance rather than waiting for an incident to prove it.

For organizations processing payment data, PCI DSS Requirement 11.3.3 is explicit: every exploitable vulnerability found during penetration testing must be corrected, and the correction must be confirmed through retesting, with no risk-acceptance exception inside the cardholder data environment. That requirement exists because auditors keep finding the same gap. Historically, just 33% of companies passed all the controls and testing procedures under PCI DSS Requirement 11, and findings from previous tests not being correctly remediated or retested is one of the most common causes of audit failure. A documented, independently verified retest is not paperwork. It is the specific piece of evidence auditors are already trained to look for and frequently do not find.

The same expectation shows up outside payment data too. ISO 27001 Clause 10.2 requires organizations to verify that corrective actions actually eliminate the cause of a nonconformity, not just document that one was attempted. SOC 2 Type II examinations go further, testing whether a control operated effectively across an entire observation period rather than checking it at a single point in time, which means a fix that held for one audit cycle and failed quietly in the next is exactly the kind of gap an auditor is trained to surface. Whether the framework is local or international, the pattern repeats: compliance is no longer satisfied by a remediation log. It requires proof that the risk actually stayed closed.

Two Changes Worth Making

Two changes are worth making regardless of which framework you report against. First, give verification its own deadline inside the remediation SLA, separate from the deadline for shipping the fix. A remediation timeline that ends the moment code merges is measuring the wrong finish line.

Second, start tracking a recurrence rate: the share of previously closed findings that reappear in a later test cycle. Most organizations track how many findings get opened and closed. Almost none track how many closed findings come back, which is exactly how a pattern like regreSSHion, a fix that held for years before quietly failing, goes unnoticed until something outside the organization catches it first.

Verification also should not stop at a single successful retest. Critical applications warrant revalidation after major code changes, infrastructure updates, significant dependency upgrades, or whenever a related vulnerability turns up elsewhere in the system. A fix confirmed once is only guaranteed to hold for the version of the system it was tested against.

Conclusion

A vulnerability management program is judged on how many findings get opened and closed. It should also be judged on how many of those closures actually held, which is a number almost nobody tracks until a regression forces the question. RegreSSHion took eighteen years to answer it. Most organizations do not have eighteen years to spare before the same pattern shows up in their own environment.

Secuna Pentest and Secuna Response build that answer into the process itself. Every finding a hunter marks as remediated goes through an independent retest before the record closes, and that retest becomes part of the same evidence trail behind Secuna's digital certificate of cybersecurity assessment. As a DICT-recognized provider under the D-TAP framework, Secuna's process is already built around the kind of proof Philippine and regional auditors ask for.

A closed ticket is an opinion. A confirmed retest is a fact.

Reach our team at [email protected] or see how Pentest and Response connect at secuna.io.

Sources: What the 2026 Vulnerability Statistics Report Tells Us, Edgescan · 46 Vulnerability Statistics 2026, Indusface · Patch Management Statistics, WifiTalents · When Patches Fail: An Analysis of Patch Bypass and Incomplete Security, Netlas · An Exploratory Study on Regression Vulnerabilities, arXiv · RegreSSHion Vulnerability CVE-2024-6387, Datadog Security Labs · OpenSSH regreSSHion CVE-2024-6387 Vulnerability, Picus Security · Philippines Data Privacy Laws, RecordingLaw · PCI Penetration Testing Guide, Blaze Information Security · ISO 27001:2022 Clause 10.2, ISMS.online · SOC 2 Type 1 vs. Type 2, Drata