Closing a finding and reducing the underlying risk are not the same thing. Most organizations have spent years confusing the two.

Somewhere in your organization right now, a finding is being marked closed. The remediation plan was approved, the control owner uploaded evidence, Internal Audit validated the response, and the issue disappeared from the dashboard.

That sequence may satisfy the mechanics of issue management. What it may not do is reduce the risk.

This distinction matters for anyone carrying a CISO, CRO, technology risk, or security leadership title. Remediation is the act of resolving a defined exception. Risk reduction is the act of changing the conditions that allowed the exception to exist in the first place.

One is procedural. The other is structural.

In regulated environments, this difference gets collapsed all the time. Audit findings, SOX control gaps, access exceptions, cloud misconfigurations, vendor issues, and incident remediation items all create pressure to show closure. Closure matters. No serious risk leader would argue otherwise. But closure becomes dangerous when the organization starts optimizing for aged-issue reduction instead of control durability.

A finding can be closed while the control environment remains fragile. A policy can be updated while the operating process stays manual, inconsistent, or unenforced. A vulnerability can be patched while the organization still lacks reliable asset inventory, configuration governance, and escalation discipline.

The dashboard looks better.

The exposure has not changed.

The better question is never, “Was the issue closed?”

It is, “Did we reduce the likelihood, severity, or recurrence of the risk?”

The case record on what happens when organizations get this wrong is not ambiguous.

Equifax: Narrow Remediation Against a Systemic Failure

The 2017 Equifax breach is typically summarized as a failure to patch a known Apache Struts vulnerability. That summary is accurate as far as it goes, but it misses the larger control failure.

A 2015 internal audit had already identified more than 8,500 medium, high, or critical vulnerabilities, with many outstanding beyond 90 days. The same audit flagged the absence of a comprehensive IT asset inventory and a patch management process that was regional, fragmented, and disconnected from global vulnerability scanning.

Equifax committed to remediate and agreed to have automated tooling in place by the end of 2016. It was not.

When the Apache Struts vulnerability was disclosed in March 2017, Equifax issued the patch notification internally, ran a scan that failed to detect the vulnerable system, and closed the loop on paper. The Senate investigation later concluded the breach was entirely preventable, and the House Oversight report identified deeper failures in patch management, asset inventory, accountability, detection, and certificate management that stretched well beyond any single missed update.

Patching a server addresses an instance of risk. Strengthening asset management, vulnerability governance, detection coverage, and control accountability reduces the probability that the same failure reappears in a different system under a different name.

Equifax had done the former and called it the latter.

Capital One: Fixing One Configuration Without Fixing the Environment

The 2019 Capital One breach exposed data on more than 106 million people. When the OCC examined what happened, it found that Internal Audit had failed to identify numerous control weaknesses in the cloud environment and that, when concerns were raised, the board failed to hold management accountable for timely remediation.

The OCC assessed an $80 million civil money penalty and found that Capital One had failed to establish effective risk assessment processes before migrating significant technology operations to the cloud.

A narrow remediation response would have corrected the specific misconfiguration and closed the ticket. That would have been necessary, but it would not have answered the more important questions.

Were cloud architecture reviews mature enough to catch these issues before deployment? Were identity permissions scoped appropriately across the environment? Was configuration drift being continuously monitored rather than periodically checked? Did senior leadership actually understand the cloud risk decisions being made before major migrations were approved?

Cloud environments do not tolerate static control thinking. Closing a misconfiguration finding does not accomplish much if the organization has not also improved the process that allowed the misconfiguration to reach production and remain exploitable.

SolarWinds: When Vendor Assurance Becomes a Compliance Ritual

The SEC alleged that for years, SolarWinds and its CISO ignored repeated internal red flags about cybersecurity risks that were well known throughout the company. The complaint cited internal risk scores, SOX audit materials, and employee communications as evidence.

The company’s own people had concluded internally that the organization was not security-minded. The controls described in public disclosures did not reflect what was actually operating.

The SUNBURST supply chain compromise that followed was not a zero-day surprise against a hardened environment. It was the foreseeable consequence of known, unresolved structural weakness that had been documented, discussed, and not fixed.

A genuine risk reduction response would have identified which vendors could push code into the environment, which tools operated with elevated privileges, which third parties created concentration risk, and how quickly the organization could isolate a trusted technology if it became suspect.

Annual questionnaires and contract files do not provide that level of protection. Third-party risk must operate as part of technology resilience, not as a separate documentation exercise that produces evidence of review without evidence of control.

Uber: The Same Attack Vector, Twice

In 2014, attackers accessed an unencrypted Amazon S3 bucket using an access key that an engineer had posted to a public GitHub repository. The FTC opened an investigation, and Uber eventually settled in 2017, agreeing to a 20-year third-party audit requirement and a comprehensive privacy program.

That same year, Uber disclosed a second breach from 2016 involving the same basic pattern: stolen GitHub credentials, an exposed AWS key, and an unencrypted datastore.

The attack vector that produced the first breach was not structurally remediated before the second one arrived. The settlement existed. The regulatory commitment existed. The root cause fix did not.

That is the uncomfortable pattern across all four cases. Organizations could demonstrate compliance artifacts, but they could not demonstrate operational control maturity. Findings were acknowledged, remediation plans were written, dashboards showed closure, and the structural conditions that produced the findings stayed intact underneath all of it.

Why Findings Keep Recurring

Repeated findings are rarely evidence that people forgot to complete tasks. They are usually evidence that the organization has not corrected the management system beneath the task.

When access reviews repeatedly surface excessive entitlements, the root cause is often not the review process itself. It may be poor role design, weak joiner-mover-leaver discipline, unclear application ownership, or inadequate privileged access governance.

When vulnerability findings stay open cycle after cycle, the issue is often not a lack of effort. It may be incomplete asset inventory, poor risk prioritization, unresolved technical debt, or the absence of executive escalation paths for unsupported technology.

When SOX ITGC exceptions recur, the problem is often not the control description. It may be manual evidence collection, inconsistent control performance, unclear accountability, or a process that was never designed to operate at enterprise scale.

The technology risk function needs to help the organization distinguish between a control that failed once and a control that is structurally unreliable. That distinction is the foundation of everything else.

What a Better Remediation Model Looks Like

A stronger model begins by separating evidence of completion from evidence of risk reduction.

Evidence of completion answers the audit question: was the agreed action performed?

Evidence of risk reduction answers the management question: is the organization less exposed than it was before?

Each significant issue should identify the failed control, the root cause, the accountable owner, the expected control outcome, and the mechanism that prevents recurrence. For high-risk issues, remediation should include independent validation and post-closure monitoring. If the same weakness reappears within the next review cycle, the prior closure should be treated as ineffective rather than unlucky.

This changes the tone of issue management in ways that matter. It moves the conversation away from deadline defense and toward control performance. It also gives senior leadership a more accurate picture of actual risk posture.

Instead of reporting how many findings were closed, the risk function can report which systemic weaknesses have been removed, which controls remain fragile, which risks are still outside tolerance, and which remediation commitments are producing measurable reduction in exposure.

That is the kind of reporting executives need to make real decisions. It is a fundamentally different product than a closure rate.

Where the Industry Needs to Go

The regulatory and governance frameworks that shape how most organizations manage technology risk were largely built for a different era, one defined by on-premise infrastructure, annual audit cycles, and relatively stable control environments.

That architecture was imperfect even then. In a world of continuous cloud deployment, AI-driven operations, complex software supply chains, and regulatory scrutiny that now extends to board-level cyber oversight, it is no longer adequate.

The industry needs to move from periodic assurance to continuous control validation. The annual audit cycle as the primary mechanism for identifying control weakness is too slow for the environments organizations are actually running. The tooling exists to monitor control performance in near-real time across identity, access, configuration, and vulnerability domains. Organizations investing in that capability are developing a more honest picture of their risk posture than those still relying on point-in-time reviews.

Regulators are already signaling this direction. The SEC’s cybersecurity disclosure rules, the OCC’s heightened expectations for cloud risk governance, and the FCA’s operational resilience framework all reflect a shared expectation that risk management should be continuous, evidence-based, and connected to actual operating conditions rather than documented policies.

Organizations still managing risk primarily through issue tracking and audit response are going to find that gap increasingly difficult to defend.

There also needs to be a meaningful shift in how boards and senior executives engage with technology risk. The Capital One and SolarWinds cases both show what happens when audit findings and internal red flags do not reach decision-makers in a form that produces accountability.

Risk functions need the mandate, access, and communication capability to surface control fragility before it becomes a regulatory action or a breach. Boards need enough fluency to ask the right questions when they do.

Governance structures that treat cybersecurity as a technical matter handled below the executive level are not compatible with the risk environment that exists today.

Finally, the profession itself needs to retire closure rate as a primary measure of program health. Issue volume and closure speed tell you something about activity. They tell you very little about whether the organization is becoming more resilient.

The metrics that matter are recurrence rates, control maturity trends, time-to-remediation for critical findings, the ratio of systemic fixes to point-in-time patches, and the degree to which remediation activity is actually shifting risk appetite alignment.

Building and communicating those measures is harder than reporting a percentage. It is also the only version of this work that produces lasting improvement.

The best measure of a risk program is not whether the dashboard is clean. It is whether the enterprise became harder to compromise, harder to destabilize, and harder to catch off guard than it was the year before.

That is the standard the industry needs to hold itself to.

Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement.

Connect on LinkedIn or www.kimlyhong.com to continue the conversation