Most data governance is sold as insurance. Reduce regulatory risk. Avoid the audit finding. Control who can access what.

All true. And all the reason it gets funded like a cost center, if it gets funded at all.

The projects the same leaders approved last quarter tell a different story. The AI initiative needs customer data that is complete and deduplicated. The reporting upgrade needs one definition of revenue that finance and sales both accept. The client platform needs to know, reliably, who the client is. Each of them is quietly waiting on the thing nobody wanted to pay for.

Offensive data governance starts from that observation. It is not a different discipline. It is the same work, justified by what it enables rather than what it prevents.

Where the defensive framing comes from

In their 2017 Harvard Business Review article What’s Your Data Strategy?, Leandro DalleMule and Thomas Davenport drew a line that most organizations still use. Data defense minimizes downside risk: compliance, security, integrity, a single source of truth. Data offense creates upside: analytics, prediction, new products, faster decisions. Governance, in their model, sits on the defense side.

The model is useful. The filing is the problem.

Once governance is labeled defense, it competes for budget against everything else that reduces risk, and it loses, because risk reduction is hard to see until the day it fails. Meanwhile the offense side, the AI program and the analytics platform, gets funded on promise, then stalls on the data.

DalleMule and Davenport are clear that defense is the foundation offense runs on. The mistake is not their framework. It is the way organizations read it: as two budgets rather than one dependency.

Governance is the foundation under the projects you already approved

You cannot build the upper floors before the foundation. Every organization knows this about buildings. Few apply it to their data roadmap.

The pattern looks like this. An AI use case is approved on a compelling business case. Six months in, the model is fine but the training data is not: customers duplicated across systems, key attributes missing because they were never mandatory at capture, definitions that differ between the CRM and the ERP. The team spends the next two quarters on what is, in every practical sense, governance work. It is just not called that, and it is not funded as that, so it is done badly and once.

This is the same failure described in data quality management work: the data team cannot fix data that was never collected. The AI team cannot either. They discover it later, at higher cost.

Offensive data governance reverses the order. Name the approved projects. Trace each one to the data it depends on. Fund the governance of that data as a prerequisite to those projects, with their sponsors, on their timeline.

What changes in practice

Tie governance to the roadmap, not to a maturity goal. A target maturity level persuades nobody. “The client platform launches in Q2 and requires a single client identifier across three systems” persuades the platform sponsor, who now has a reason to care about master data.

Show which approved initiatives stall without it. Make the dependency visible. A one-page map from each funded project to the data domains it needs, with the current state of each, is more effective than any governance charter. Sponsors read it and recognize their own risk.

Fund it inside those projects, not beside them. A separate governance line is the first thing cut. A governance workstream inside the AI program, owned by the AI sponsor, survives because cutting it means cutting the program.

Start with one business problem. This is the same discipline that makes data governance work at all: pick a costed problem the business already feels, fix it end to end, and let the structure form around the fix. Offensive governance simply picks the problem from the roadmap rather than from the complaint list.

The defensive work still gets done

None of this abandons defense. The compliance obligations, the access controls, the audit trail all remain. But they get done as a consequence of building the foundation the offense needs, not as a standalone program asking for money to prevent a future nobody can see.

DAMA-DMBOK describes governance as the enabler of value, not the policing of it. That is the offensive reading. The organizations that get it right do not have a better governance framework. They have stopped presenting governance as a tax on the data strategy and started presenting it as the thing that makes the strategy work.

The question to ask

Take your approved data and AI projects for the year. For each one, ask what data it depends on and whether that data is owned, defined and trusted today.

If the answer is no for most of them, you do not have a governance problem. You have a delivery problem, and governance is how you solve it.