Framework - September 2026

The Blended Cyber Governance Model

One framework tells you what a governance program has to produce. Another tells you who is accountable for producing it. Neither tells you how the capability gets built. This is how I put three of them together into a single governing structure.

The problem this solves

Cybersecurity governance is usually organized as a subset of something else. A workstream inside risk. A committee inside compliance. A category inside a framework built mainly to describe controls. Organized that way it has no outcomes of its own, so it gets measured by activity, and activity is the one thing a governance function can always produce.

The failure that follows is structural rather than careless. A central function is made accountable for security programs it does not operate, and over time it starts performing pieces of them. A capability exists centrally before it exists locally. Some work needs access only the central team holds. Urgent things land where there is capacity. None of those is a bad decision on the day it is made.

What they add up to is a function that cannot say where its oversight ends and its own operations begin. It cannot be held to an outcome, because it is too entangled in the work to judge it, and the people it oversees experience the entanglement as interference rather than support.

The question worth asking is not whether an organization is compliant. It is whether it is governed, or merely busy.

I have built these functions and I have worked under them, and the pattern looks the same from both sides. Governance deserves the rigor any other enterprise capability gets: named outcomes, named accountability, and a capability underneath that sustains both. No single framework delivers all three.

Why no single framework answers that

I went looking for one framework to anchor a program on and did not find it. Not because the frameworks are weak - each is very good at the job it was built for - but because a governance program answers three different questions at once, and each framework answers one of them well and is close to silent on the other two.

Coverage of three governance questions by three frameworks

Framework	What outcomes must be produced	Who is accountable for each one	How the capability is built and sustained
NIST Cybersecurity FrameworkCSF 2.0, February 2024	Defines it	Silent	Silent
The IIA's Three Lines ModelJuly 2020	Silent	Defines it	Silent
People, process and technologyorganized around data	Silent	Silent	Defines it

NIST CSF is an outcomes framework. It states what a program must achieve in language a board and a regulator both recognize, with informative references into COBIT, ISO 27001 and NIST SP 800-53 so a control set can be traced rather than argued about. I contributed to the original framework as an energy and operational technology subject matter expert, and its strength has always been that it describes outcomes without prescribing an organization chart. That is also its limit here: it does not say who owns an outcome. Wherever a function governs work it does not perform, who owns it is the whole question.

The IIA's Three Lines Model answers that one. It separates the governing body's accountability to stakeholders from management's ownership of risk in the first and second line, and from internal audit's independent assurance in the third, then names what flows between them: delegation and direction down, accountability and reporting up, alignment and communication across. What it does not say is what has to be governed in cybersecurity, or how any of it gets built.

People, process and technology, organized around data, answers the third question - and it is the one governance programs skip. A program can name the right outcomes and the right owners and still fail, because the capability underneath was never resourced, the process was never written down, or the data it all depends on was never classified. Data sits at the center rather than beside the other three, because every governance decision turns on knowing what data exists, where it lives, and what it is worth.

The blended model

Stacking them is what makes them work. Each framework becomes a layer, and each layer answers its own question without pretending to answer the others.

Scroll the diagram sideways to see all three layers. Every dimension is listed in full below.

The eight dimensions

These are the eight I use, and the mapping I would apply today. Each is stated as a condition to sustain rather than a project to finish, because a governance dimension is never done.

What the model changes in practice

A model earns its place by making decisions easier. These are the ones it makes, and the order they have to happen in.

1. Adopt an outcomes framework formally, and say so in writing. Informal use of a framework gives you its vocabulary without its discipline. A governance policy and standard, formally issued, converts a framework into guardrails the business can be held to and can plan against.
2. Split the what from the how, then move the how. The governing function owns what must be true. Whoever runs the program owns how. Anything the governing function performs rather than oversees transfers, with oversight staying behind. The test is blunt and it works: if the governance team would be the one paged at two in the morning, that activity is not governance.
3. Publish roles and responsibilities. Not a chart. A statement of which function owns which outcome, which challenges it, and which assures it, in the terms of the accountability layer. Ambiguity here is what turns oversight into friction.
4. Fix what reaches the board before fixing what reaches the dashboard. Board information assembled from sources that do not share definitions is worse than less information: it looks authoritative and cannot be reconciled in the room. Settle definitions with the technology and security leaders who produce the numbers, at the source, not in the deck.
5. Measure the governance program itself, with automation. A governing function that only measures the programs beneath it has no evidence about its own effectiveness, and will be evaluated on volume instead.
6. Give the relationship work the same standing as the structural work. Every item above can be executed correctly and still fail if the people being governed experience the result as control rather than support. That is a leadership obligation, not a change-management workstream.

A note on framework versions

I was making the argument on this page before the framework made it for me, and for a while the framework was an obstacle to it. Until early 2024, the version of CSF in general use held governance as a single category, ID.GV, inside the Identify function, which made it structurally awkward to argue that governance warranted outcomes and accountabilities of its own.

In February 2024, NIST published CSF 2.0 and made Govern a full function. ID.GV was withdrawn into it, and business environment, risk management strategy and supply chain risk management moved under it as well. The mapping on this page is to 2.0, because that is the version a reader will be working in, and because the restructure makes the case considerably easier to make than it used to be.

Where this applies

The model fits anywhere a function is accountable for security programs it does not operate. Federated global businesses. Groups whose divisions run their own technology. Post-merger organizations holding two stacks together while they converge. Any organization where a second-line function has been quietly absorbing first-line work because it had the skills and the access. The structures differ; the condition is the same one.

It is deliberately framework level, and it is a starting structure rather than an answer. Applying it means reconciling it against plans and initiatives already in flight, which in every case I have seen is most of the work and none of the diagram.

Back to How I Work