In my previous two posts (Process centric thinking for data governance and from process awareness to process driven governance), I argued that data governance only becomes meaningful when we see it through the lens of business processes, those moments where data is created, changed, handed over, and relied upon.

Process-centric thinking reveals something important. Most data problems are not abstract data problems. They are process problems with data consequences.

Yet when organisations respond, they often reach for frameworks, models, and operating structures. Steering committees are formed. Roles are named. Policies are written. Tools are implemented.

And still, very little changes.

What is missing is not another framework. What is missing are patterns.

Frameworks describe structure. Patterns describe behaviour.

It’s important to understand that patterns do not replace frameworks. They make them real. They take governance from an idea on paper and turn it into the choices people make every day.

Frameworks are useful. They give structure and clarity. They help answer questions like:

• Which roles should exist?
• What artefacts should be produced?
• How should responsibilities be divided?

But frameworks rarely answer the questions that really matter:

• What happens when data is wrong at the moment it counts?
• Who notices first, and how fast do they react?
• Where in the process does governance actually show up?

This is where patterns come in. They appear in real work, over and over. A problem repeats in a certain context, and a pattern captures a proven way to deal with it. That is how governance stops being theory and starts guiding decisions.

process is the natural home for governance patterns

Look closely at data issues, and a pattern emerges. Data does not fail randomly. It fails at very specific points in the process: when it is created, approved, enriched, moved between teams, or reused for a new purpose. Processes make these moments visible. And visibility is what governance needs.

Governance detached from process becomes something different. It becomes retrospective, bureaucratic, someone else’s problem. Governance embedded in process looks completely different. It becomes immediate, actionable, part of how work actually happens. This is why thinking in processes naturally leads to thinking in patterns.

A process-driven governance pattern is simply a way to embed governance into a recurring process situation. Each pattern has four parts:

1. A recognisable process signal a creation step, an approval, or a handover.
2. A governance concern with ownership, quality, compliance, or accountability.
3. A lightweight mechanism showing something that fits naturally into the flow of work.
4. A clear outcome when things go wrong.

Patterns do not tell you which tool to use or how your org chart should look. They describe how governance behaves when the moment occurs. That is what makes them practical.

Principles sound good on paper. Data must have an owner. Data quality must be ensured. Issues must be escalated and resolved. But principles only come alive when they attach to real moments in the process.

Who owns this material at the point it is created?
What happens before this record moves downstream?
Who gets notified if this step fails?

Patterns bridge that gap. They turn principles into repeatable, practical responses to everyday work.

Rules tend to multiply. One per dataset. One per domain. One per exception. Patterns scale differently. One pattern can work across many processes. One way of thinking applies repeatedly. One shared language connects teams.

Instead of asking “Do we have a rule for this?” teams start asking “Which pattern applies here?” That is the subtle but powerful shift. Governance moves from being a constraint to being guidance—something you can see, understand, and trust.

In the coming posts, I will explore a set of concrete, reusable patterns:

• Ownership in the process anchors responsibility for data creation or modification.
• Embedded Quality Gates applying quality checks built into the flow, not after the fact.
• Feedback Loops turning data errors into learning, not just fixes.
• Minimum Governance focusing effort where process failure hurts most.
• Anti-patterns are common ways governance fails when process is ignored.

Each post will show the problem it addresses, where it appears in the process, how the pattern works, and what outcome it creates. The goal is not to define a new framework. The goal is to make governance visible in daily work. To make it real.