Case Study Governance Architecture Program Management SecOps

Your Tools Work. Your Governance Doesn't. That's Why Compliance Still Fails.

As Program Manager and Technical Product Owner, I found TD Bank with CrowdStrike, Qualys, Akamai, ServiceNow, and every security tool a compliance programme could need. Compliance rates sat at 38%. The problem was not the tools. It was the total absence of a governance model connecting them. I built the operating model that turned seven disconnected tools into a defensible, auditable compliance programme.

Stakeholder groups aligned under one governance operating model

99.2%

SLA adherence after consequence models activated

85%

Compliance rate achieved from a 38% starting point

Problem Statement

Six best-in-class security tools. Zero governance. 38% compliance six months after a $3.2B fine.

Following the regulatory fine, leadership invested in every available security tool. CrowdStrike, Qualys, Akamai, ServiceNow CMDB, SCCM, Dynatrace. Each worked exactly as designed. Six months later, compliance rates sat at 38%. The tools detected thousands of vulnerabilities. Detection without ownership is just a longer list of unresolved problems. Nobody could answer the four questions that matter in a regulated environment: who owns remediation? Who approves exceptions? Who escalates when SLAs breach? What evidence do regulators see when they ask about control effectiveness? This is the governance story, not the platform story. The discipline underneath the technology.

Signals With No Owners

Security tools detected thousands of vulnerabilities monthly. Assignment logic did not exist. Issues sat unaddressed because nobody owned them. Security detected. Operations patched. No defined accountability connected the two.

Asset Inventory in a Separate Universe

CMDB tracked 50,000 assets. Security tools scanned a different population. 40% of vulnerabilities could not be mapped to owners because asset data was siloed. Automation cannot assign to owners that do not exist in the system of record.

Remediation Without Structure

Compliance tracking relied on email chains and manual follow-up. SLA enforcement did not exist. Exception approval was informal. Audit evidence took weeks because the trail was scattered across tools with no unified workflow layer connecting them.

Seven Stakeholder Groups, Seven Realities

Security defined risk one way. Operations prioritised differently. Risk wanted exception governance that did not exist. Audit needed evidence requiring manual aggregation. Regulators asked questions that took 6 to 8 weeks to answer. No shared operating model existed.

Governance Model

Four layers. One operating model. Ownership defined at every step.

The governance model was built on a simple principle: ownership must be defined at every step, workflow must be automated where possible, SLAs must be enforced where automation is not possible, and every stakeholder must have exactly the visibility they need without requiring someone to produce it for them.

🏛️

Splunk: Single Source of Truth

All seven security systems fed into one Splunk data lake. CrowdStrike, Qualys, Akamai, CMDB, SCCM, Dynatrace: one place where compliance ratios, risk scoring, trending, and audit trails lived. For the first time, every stakeholder group worked from the same data, at the same time, with the same definitions. That alone resolved a significant share of the governance disagreements.

🔗

ServiceNow CCM: Workflow and Ownership Engine

Automated assignment logic routed every detected vulnerability to the correct asset owner based on CMDB relationships. Multi-tier escalation at 30, 60, and 90 days activated without human intervention. Exception approval workflows created a formal, documented, auditable process replacing the informal email chains that had made governance indefensible to regulators.

⚡

Consequence Models: Enforcement Mechanism

Governance without enforcement is policy theatre. Consequence models activated professional accountability for chronic non-compliance at 90-day SLA breaches. SLA adherence moved from 68% to 99.2% after consequence models went live. Dashboards inform. Consequence models convert visibility into behaviour change. Both are required. Neither alone is sufficient.

👁️

Seven Role-Based Stakeholder Views

Regulators accessed real-time compliance posture without requesting evidence packages. Audit teams had pre-built quarterly evidence with drill-down. SecOps had live operational views. Asset owners saw their individual accountability dashboards. Executives saw enterprise trending. One data source. Seven purpose-built views serving different governance functions.

Implementation

Governance before technology. Ownership before automation.

The sequencing was deliberate. The governance operating model was defined on paper before any technology was deployed. No automation went live until ownership was clear. No dashboard was built until the data layer was accurate. Phased delivery shipped governance value continuously rather than waiting 18 months for a complete system.

Pre-Build

Define the Governance Model on Paper First

Mapped every vulnerability type to an owner. Defined SLA expectations for critical, high, medium, and low findings. Established exception approval criteria and escalation paths. Documented the governance operating model before deploying any technology. Technology enforces what the governance model defines.

Months 1 to 6

Data Accuracy and Assignment Logic

CMDB accuracy brought to 95%+ before any workflow automation was deployed. Splunk data lake stood up with all seven system feeds. Assignment logic deployed in ServiceNow CCM. The governance model only works when the underlying asset data is accurate enough to trust.

Months 7 to 12

Enforcement: Escalation and Consequence Models

Multi-tier escalation framework activated. Consequence models deployed for chronic non-compliance. Exception approval workflows formalised. The governance model transitioned from advisory to enforcement, and SLA adherence jumped from 68% to 99.2% within two quarters.

Months 13 to 18

Scale: Seven Stakeholders, Seven Views

Role-based dashboards deployed for all seven stakeholder groups. Regulatory portal launched with direct access for OCC and FDIC reviewers. Audit evidence packages automated. Governance architecture reached full operating capability, and quarterly regulatory reviews began returning zero repeat findings.

Final Outcomes

What a governance model produces that tools alone cannot.

Measured at 18 months. Validated through OCC consent order reviews, third-party audits, and internal compliance reporting across all seven integrated systems.

85%

Compliance rate from a 38% starting point. Governance model drove what the tools alone could not deliver.

99.2%

SLA adherence after consequence models activated. Up from 68% with dashboards and visibility alone.

Real-time

Audit evidence delivery, replaced a 6 to 8 week quarterly manual collection process for every audit cycle.

7 groups

Stakeholder groups aligned on one operating model, one data source, and seven purpose-built visibility layers.

Zero

Repeat findings in OCC consent order reviews since governance architecture reached full operating capability.

60%

Fewer third-party audit findings through continuous, auditable compliance evidence across all systems.

Lessons Learned

What governance actually requires to function in a regulated environment.

Governance Precedes Technology

Define ownership, SLAs, exception criteria, and escalation paths before deploying any automation. Technology enforces the governance model. It cannot substitute for one. Deploying ServiceNow CCM without first defining who owns which vulnerabilities would have automated the confusion rather than resolved it.

Accountability Requires Consequences

Dashboards showing compliance status are necessary. They are not sufficient. SLA adherence at 68% with dashboards alone moved to 99.2% after consequence models activated. Governance without enforcement is a reporting exercise. The enforcement mechanism is what makes the governance model real.

One Data Source, Many Stakeholder Relationships

Regulators, audit teams, SecOps, asset owners, and executives need compliance data in fundamentally different formats for different governance functions. One report served no audience well. Seven role-based views built on one data source served every audience exactly what they needed. The governance model enables differentiation. The data model enables consistency.

CMDB Is Governance Infrastructure

Three months on CMDB accuracy before deploying governance automation felt like delay. Every vulnerability assigned to the wrong owner, every ticket that could not be routed correctly, every dashboard showing inaccurate coverage: all of it traces to asset inventory accuracy. CMDB is not a configuration setting. It is the foundation the governance model runs on.