Case-Based Insights

When the Symptom Isn't the Problem: A Cybersecurity Governance Diagnosis

By Abdul KunatehLeadership & Enterprise Transformation StrategistSeptember 8, 20264 min read
Abstract editorial illustration of several small gold warning markers across the upper area, each traced by thin gray lines converging into a single navy root node below, visualizing surface symptoms tracing back to one underlying governance issue.

A multi-year cybersecurity program across a distributed retail and fuel estate of 800+ locations had three visible symptoms when the diagnosis started. The multi-factor authentication rollout had stalled in the field. Patch cadence was drifting quarter to quarter. Endpoint hardening standards existed on paper but weren't being enforced consistently across sites. Read individually, each symptom suggested its own fix: push harder on MFA adoption, tighten the patching schedule, audit endpoint compliance more often. None of those fixes would have worked, because none of them addressed what was actually producing all three symptoms at once.

Three symptoms, one root cause

The instinct when a rollout stalls is to treat it as a rollout problem — better change management, more communication, a firmer deadline. The instinct when patching drifts is to treat it as a patching problem — more automation, a stricter SLA. The instinct when a standard isn't enforced is to treat it as an enforcement problem — an audit, a scorecard, a consequence for non-compliance. Each of these instincts produces a plausible-sounding fix. None of them was the actual constraint here.

The underlying issue was governance, not execution. There was no shared framework defining who owned security decisions across an 800-plus-location footprint, what standards applied uniformly, when something became an escalation, or on what cadence leadership actually saw the real picture. Without that framework, each symptom was a local optimization problem being solved by whoever was closest to it — and every local fix was solving a different version of the same underlying gap. MFA adoption stalled because there was no consistent ownership model driving it site by site. Patch cadence drifted because there was no accountability structure tying patching to a measurable standard. Hardening wasn't enforced because there was no mechanism connecting the written standard to what actually happened at the site level.

Three symptoms. One governance gap. Fixing any one symptom in isolation would have improved that metric temporarily and left the other two — plus whatever the next symptom turned out to be — completely untouched.

What the diagnosis changed about the approach

Recognizing the governance gap as the actual constraint changed the shape of the program. Instead of three separate initiatives — an MFA push, a patching initiative, a hardening audit — the work became a single governance and risk framework that the other three workstreams ran inside of: a written risk register scoring vulnerabilities by business impact, remediation SLAs tied to severity bands rather than uniform deadlines, and a reporting cadence that gave leadership a real view of exposure rather than a status update.

Once that framework existed, MFA, patching, and endpoint hardening stopped being three separate problems competing for attention and became three coordinated workstreams reinforcing a single standard. Sequencing mattered here — the framework had to exist before the technical workstreams could compound rather than duplicate each other's effort. Cross- functional coordination between security, infrastructure, and operations — including things as specific as weekend cutover windows and regional variations across the footprint — only worked because there was now a shared structure to coordinate against.

The lesson that generalizes

The specific fix here was a security governance framework. The generalizable lesson isn't about cybersecurity — it's about what multiple simultaneous symptoms across a large, distributed operating environment usually mean. When several things are going wrong in different parts of the same system at the same time, treating each one as its own isolated problem is the most expensive way to respond, because it produces multiple fixes that each address a fraction of the actual constraint. The more useful question isn't "how do we fix this symptom" — it's "what would have to be true about the underlying system for all of these symptoms to show up together."

In this case, the answer was a missing governance layer, and the program that resulted delivered a 40% reduction in threat exposure sustained across the estate — not because any single technical control was stronger, but because the framework underneath the controls made the improvement durable rather than a one-time gain.

This is a selected example from Abdul Kunateh's professional career. Certain organizational details, technologies, and operational information have been generalized to protect confidential and proprietary information. Results reflect collaborative organizational efforts; this account describes Abdul's leadership responsibilities, contributions, and strategic thinking within this initiative. For the complete case study, see Enterprise Cybersecurity Program on the Impact page.

More from Case-Based Insights
Share
AK
Abdul Kunateh

Leadership & Enterprise Transformation Strategist · Founder, Kunateh Impact

Ideas worth applying.

Practical thinking on leadership, enterprise transformation, and building organizations that perform. Sent occasionally. No noise.