Data Governance — behaviour with evidence, not policy on paper

Working draft — pre-publication review. This pillar carries the governance operating-model half of Cordata's Fabric + Mesh argument. The Fabric substrate half — catalog, lineage, policy-as-code enforcement — is in the Data Engineering pillar and the Fabric + Mesh on AWS reference.

Governance is decisions plus evidence — not paper

Data governance is one of the most muddied terms in enterprise data conversations. Getting the definition wrong on day one costs a programme years and millions.

Three common confusions cloud every conversation Cordata walks into. Naming them first — with the concrete failure each one produces — saves an hour later:

Data governance is not data management. Data management is the pipeline / storage / catalog layer — the technical substrate. That is the Fabric half of the argument, treated in the Data Engineering pillar. The confusion Cordata sees most often: a bank hires a Chief Data Officer to "fix governance" and gets a data-lake modernisation programme instead. Eighteen months in, the platform is much improved; who can see what, under which documented conditions, and with what evidence, is the same undecided mess it was before.
Data governance is not master-data management. MDM is the shape of shared reference data — customer master, product master, chart of accounts. In a Mesh, MDM is a domain like any other, not the governance layer above the Mesh. The confusion: a customer-360 project pitched as a "governance initiative" because it deals with reference data. Six months in, a golden-record engine exists; no decision has been made about who can access the golden record, under what conditions, for what purpose — those decisions still get made by ad-hoc email approval.
Data governance is not IT-security policy. Access-control primitives (roles, permissions, encryption keys) are what governance uses to enforce decisions. But the decisions themselves — who owns this data, who can see it under what conditions, how a change is authorised — are governance, not security. The confusion: the IT-security team is asked to own governance because "they already handle access control". Result: Role-Based Access Control (RBAC) gets granted against job titles rather than data purposes. A marketing analyst can query fraud-transaction logs because both fall under the same broad analytics role — not because anyone in the fraud domain made a purposive decision about that sharing.

The positive definition Cordata works from is deliberately small:

Data governance is the set of decisions about data — who owns it, who can see it under what conditions, how change is authorised — plus the evidence those decisions are being lived, not just documented.

It sits above the Fabric substrate and inside the Mesh operating model. It is behaviour with evidence, not paper. Every substantive claim in the rest of this pillar is downstream of that definition.

Three years after "we have a data governance council"

A DACH mid-market company kicks off a data governance programme in early 2023. A steering committee is formed with senior sponsors from IT, Legal, Risk, and two business lines. A governance framework is selected — a recognised industry framework like DAMA-DMBOK is name-checked in the kickoff deck. A council meets monthly. Policies are written for access management, data classification, retention, third-party sharing. A RACI is signed. Records of Processing Activities (RoPAs, the register required by DSGVO Art. 30) are populated for every processing operation across the DACH footprint. Compliance signs off on the artefacts by end of Q3. There is champagne.

Fifteen months later, the council meets quarterly, then only before audits. Policies dated 2023 sit in the wiki; a comparison against the platform's actual grant log shows the two have not matched in nine months. Domain teams say — off the record — that when they need cross-domain access, they Slack their counterpart, not the governance council. The RoPA is known to be roughly 40% wrong. The compliance team knows. Nobody has the mandate to fix it because "the domains own it" — and the domains say "compliance owns it".

We at Cordata have watched this pattern repeat — in variations — across banking, insurance, and telco over years of engagements as engineers on these projects. Two specific ways the definition above fails to be met keep showing up:

The central bottleneck. Governance decisions route through a central team or council; scale exceeds capacity; approval times stretch; domain teams route around it. Shadow-IT reappears under a different name — a shared Confluence page of "temporary exceptions" that never expire. Decisions get made — just not by anyone accountable.
The artefact drift. Policies, RACI, RoPAs, Data Protection Impact Assessments (DPIAs, per DSGVO Art. 35) exist and audit-pass — but they do not reflect or drive what actually happens with data. The artefacts and reality diverge quietly, and everyone knows. The evidence is documentation, not behaviour.

Both are the same underlying failure of the definition — decisions and evidence are decoupled — surfacing in two directions. The sentence Cordata leaves prospects with when the governance conversation reaches this point:

A policy no one follows is empty theatre. A ticket queue no one can clear is a manual bottleneck. Neither is governance.

The DORA shift — governance is now a management-body responsibility

The story above played out in 2023-2024, before DORA came into force. Since January 2025 the personal stakes have changed.

The Digital Operational Resilience Act came into force in January 2025; enforcement went live end-2025. For any DACH shop touching financial services, DORA turns governance from a compliance overhead into a supervisory chain of accountability that reaches the management body:

Art. 5 — ICT risk management is a management-body responsibility, not a delegable task. The board approves the strategy, and the board signs the residual-risk acceptance.
Art. 5(2) — governance-related failures can attach personal liability to management-body members.
Art. 15–17 — ICT-related incident reporting must reach the management body within tight regulatory windows, with a chain of accountability documented from detection to escalation.
Art. 24 — the digital operational resilience testing programme (TIBER-EU) requires management-body approval and reporting.
Art. 28–30 — third-party risk management applies the same evidenced-accountability chain to processors.

The practical effect: if the RoPA is 40% wrong, that is now a management-body issue with personal liability attached — not a compliance team's paperwork problem. Governance is no longer a policy-binder question. It is a personal-liability question at the board, evidenced by behaviour and audit trail, not by wiki pages.

DORA is the accelerant. What Cordata calls behaviour with evidence is the shape a supervisor can now demand, not a nice-to-have.

Federated computational governance — the four moves

The governance model that survives contact with a real Mesh — and DORA — is federated computational governance: policies decided together, enforced automatically at platform boundaries, evidenced from behaviour rather than typed into a wiki. Four moves make it work:

Federated decisions. Policy questions (retention windows, sensitivity taxonomy, cross-domain sharing rules) are decided by a council with rotating representation from the domains plus the platform team. Not a permanent central body with veto authority. The council's job is to reach shared decisions, not to approve individual requests.
Computational enforcement. Decisions are expressed as policy-as-code — Open Policy Agent rules, LakeFormation LF-tag expressions, Databricks Unity Catalog grants, dbt model contracts. The platform executes them automatically at read, write, and query boundaries. There is no separate "compliance step" between a domain team and the policy taking effect.
Evidence from behaviour. Audit artefacts (who read what, whose data flowed where, which policy fired when) are generated from real system events — CloudTrail, the lineage graph, the catalog subscription log. They are not typed into a spreadsheet by a compliance team once a quarter. This is what makes the RoPA stay current and DORA-answerable.
Shared vocabulary, local ownership. The tag ontology (LF-tags, Purview labels, Collibra classifications — the specific tool matters less than the shape) is shared across the org, but every tag value is owned by a specific domain. Sensitivity is a shared vocabulary; this column is sensitivity=high is a domain decision.

The Fabric + Mesh on AWS reference walks the concrete AWS implementation of all four moves — LF-tag ontology, two-layer DataZone segmentation, the catalog-of-catalogs trap, and the three DACH compliance checkpoints in real Terraform. This pillar's job is the operating model; the companion's job is the machinery.

Behaviour-first governance

The four moves compose into a specific operating shape. The pillar's central architectural claim, worth pull-quoting:

Governance is what the platform enforces, what the domains do, and what the evidence shows — in that order. The artefacts (policies, RACIs, RoPAs) are byproducts of that behaviour, not deliverables in themselves.

Contrast two operating shapes:

Artefact-first governance. A policy binder is written. A RACI is signed. A quarterly compliance review happens. Artefacts are the goals; the calendar is set around them. What actually happens with data — who reads it, who joins it into what, whose subscription approval was rubber-stamped — is undocumented and often unknown. Six months in, artefacts and reality diverge. Twelve months in, everyone knows, and no one has the mandate to fix it.

Behaviour-first governance. Policies are encoded as executable rules at platform boundaries — a grant is a policy expression, a subscription approval is a signed audit event. The RACI is derived from the catalog's ownership metadata, which the domains keep current because their own subscription workflow depends on it. The quarterly compliance review is pulled from the lineage graph and the subscription log, not typed. Artefacts always match reality because they are generated from it.

Diagram read-out. Three layers, bottom to top. The Fabric substrate (bottom) provides catalog, lineage graph, policy-as-code engine, and subscription log — the raw events + metadata that everything above depends on. The federated governance layer (middle) takes those raw events and turns them into three things: federated decisions (the council reaches shared policy positions), computational enforcement (those positions are expressed as policy-as-code that fires at platform boundaries), and evidence generation (the audit records that prove enforcement happened). The artefacts (top) — RoPA, RACI, audit report — are generated from the layer below, not typed by hand. The dashed arrow back to the middle layer closes the loop — the artefacts inform the next council decision, which changes enforcement, which changes what the audit shows.

The companion post Behaviour-first governance in practice walks the concrete machinery — how to generate the RoPA from lineage, the RACI from catalog ownership, and the audit report from the subscription log — with real Terraform, SQL, and YAML.

Mesh provides the shape. Fabric provides the enforcement + evidence layer. Together they make behaviour-first governance possible. Without both, governance decays back into artefact-first within a year — the story from earlier in this pillar reruns.

A three-way contract — platform, domain, council

Federated computational governance is stable only under a three-way contract. Platform, domain, and governance council each owe the others something specific and non-negotiable.

Platform owes governance:

Policy-as-code primitives that governance can author against, not just consume from — a policy language a domain engineer can write directly beats one that requires a central-team translation
An evidence-generation surface (audit log + lineage + subscription records) that survives a supervisor asking "prove it"
A change-authorisation workflow that is itself audit-evidenced — every policy change carries its own record

Domain owes governance:

Metadata correctness for the tags governance policies grant against — a wrong sensitivity=confidential on a sensitivity=high column is a real governance failure, not a paperwork error
Timely subscription-review turnaround — the platform can route the request, but only the domain can approve it
Honest declaration of derived-data usage inside the domain — so the RoPA is not fiction

Governance owes platform and domain:

Decisions inside SLA-defined windows — a federated council that ships slower than a central bottleneck is worse than either
Policies that are smaller than the last version 80% of the time — governance drifts toward complexity by default; the discipline is subtraction
No policy that cannot be enforced at a platform boundary — if it can only be enforced through vigilance and blame, it is not policy

Diagram read-out. Governance sits between platform and domain, not above them — a hub with two-way obligations to each side. The three bullet lists above are the exact contents of each exchange: platform and domain owe governance different things (evidence machinery on one side, metadata quality and honest self-declaration on the other), and governance owes both the same three things back — decisions inside SLAs, policies that shrink over time, and no policy it cannot enforce at a platform boundary. Any side that stops meeting its obligations collapses the composition.

Where any side stops meeting its side of the contract, the composition collapses back into the central-bottleneck or artefact-drift failure from earlier. Cordata engagements start by testing which obligations are already met, which are aspirational, and which have quietly collapsed.

Guardrails, not gates — applied to governance

Cordata's position on where governance sits in a Fabric + Mesh Hybrid — carried through from the Data Engineering pillar's stance — is that automation makes governance faster and safer than manual review, and never forces domains through a central bottleneck.

The distinction is concrete. A gate is a central-team ticket queue for policy exceptions — every request queues, human capacity caps throughput, decisions take days. A guardrail is a policy expression that either denies access (with an audit-evidenced record) or grants it (with an audit-evidenced record) at the platform boundary — no queue, no bottleneck, always evidenced. Gates protect through veto and become the bottleneck they were meant to prevent. Guardrails protect through information — the platform executes the decision automatically, the audit shows what fired and why.

Almost all governance-through-veto systems Cordata has witnessed eventually devolve into shadow-IT workarounds, because the veto queue outgrows its human capacity within a year. Guardrails scale with the platform because they are generated from the same active metadata the Fabric already maintains.

The DACH pressures beyond DORA

DORA gets its own section above because it changed the personal stakes. The rest of the DACH regulatory + organisational landscape makes behaviour-first governance especially apt, and Cordata's engagements plan around all of it:

BaFin § 25b KWG and FINMA cloud-outsourcing — supervisory scrutiny of outsourcing arrangements requires evidenced control chains. A signed policy is not enough — the evidence that the control actually ran must be producible from the platform.
DSGVO Art. 28-30 organisational side — processor obligations require documented processes AND demonstrable enforcement. Behaviour-with-evidence, again, applied to processor boundaries.
Works-council (Betriebsrat / Personalrat) rhythm — the policy-change cadence is slower than the platform-change cadence; governance design must reconcile the two, not pretend the mismatch does not exist. Sprint velocity is a real cost of doing this right; the alternative — a rollback after downstream consumers have built against a change — costs more.
Multi-jurisdiction org governance — DE / CH / AT plus HU / SK / PL back-office is a common shape. Where does DE governance stop and CH governance begin? Federated ownership is the only structure that scales this cleanly.

The technical enforcement side of these pressures is covered in the Fabric + Mesh on AWS reference. The behaviour-first machinery — how the artefacts these pressures demand are actually generated — is covered in the companion post Behaviour-first governance in practice. DSGVO Art. 17 (right to erasure) across a distributed mesh gets its own dedicated follow-up post.

AI in governance — drafting, not deciding

AI has one honest place in governance workflows: as a drafting and consistency assistant, sitting on top of the operating model. It has one honest exclusion: any decision path that produces the artefact of record.

Drafting layer — where AI belongs, when it is justified:

RoPA and DPIA drafting. An LLM proposes a first-draft record from the lineage graph plus the catalog plus the subscription log. The record then passes through a human-in-the-loop (HITL) review and signature. The AI has saved half a day; the accountability chain is unchanged.
Policy consistency checks. An LLM reads the entire policy corpus and flags contradictions — a common failure mode as governance drifts toward complexity. The LLM does not fix them; it surfaces them for the council.
Drift detection surfacing policy violations. Active-metadata alerts translated into human-readable governance signals — "the fraud domain has read sensitivity=high outside its declared purpose three times this week" — feed the council's next review.
Natural-language policy queries. "Under what conditions can the fraud domain share transaction data with analytics?" answered from the policy corpus, grounded in the actual rule, with citation to the specific policy that applies.

Decision layer — where AI does NOT belong, ever:

Do not let an LLM auto-approve or auto-deny an access request. The audit trail cannot survive an LLM in the loop when the artefact must carry personal accountability under DORA Art. 5.
Do not let an LLM sign a RoPA, DPIA, or third-party risk assessment. Those artefacts require named human accountability under DSGVO Art. 30 and DORA Art. 28. An AI-drafted, human-signed artefact is fine. An AI-signed artefact is not.
Do not send policy corpora, RoPAs, or audit logs to third-party LLM APIs. The governance artefacts themselves become sensitive data leaving the processor boundary — the compliance surface has grown by one vendor without the CIO noticing. If drafting-AI is legitimate, run the inference inside the compliance boundary.

Every DACH prospect Cordata speaks to about AI-in-governance asks these questions inside the first fifteen minutes. The pattern Cordata refuses is "we added AI because everyone does". Every use has to reduce a specific human hour per week or a specific class of drift — measurably. If it does not, it does not belong.

When federated governance is the wrong shape

The three "wrong-shop" exclusions from the Data Engineering pillar apply here too, in their governance-specific form — the underlying reason is the same in both pillars: the overhead of federation only earns its keep at a certain scale and complexity threshold. In short:

Single-domain shops — there is no federation to build. A well-run centralised policy set is the honest answer; imposing federated governance vocabulary on a team that fits in a Slack channel is unnecessary overkill.
Greenfield teams under six engineers — the overhead of a rotating council + policy-as-code authoring + evidence-generation surface exceeds the drift a single well-informed lead catches by paying attention.
Regulated slices with one canonical answer (regulatory reporting is the canonical case) — central ownership of that slice is often right, even inside a federated shop. This pillar does not forbid centralisation; it forbids centralising everything.

A governance pillar that never says "no" is the compliance-theatre it warned against. This one does.

How Cordata engages

Cordata refuses to sell (a) governance-strategy engagements that produce a policy binder without an executable enforcement path, or (b) compliance-audit prep that turns into artefact-generation theatre. A policy binder without executable enforcement is the paperwork that comes back at the next audit. Audit-prep engagements without a behavioural change are the same paperwork with a fresh timestamp. Both refusals come from experience.

What Cordata does sell: engagements that close both halves of the governance failure at once.

The shape is deliberately narrow. A two-week discovery: an audit of the current governance surface (policies, RoPAs, decision-making bodies, and the actual grant log in production), structured interviews with two domains and one central function, and an honest map of where the central bottleneck and artefact drift each sit today.

From there, engagements are scoped 6-12 weeks, not open-ended. Deliverables are always both:

Organisational — a federated council charter with rotation and SLAs, decision rights across the domains, a RACI derived from catalog ownership metadata, and a policy-subtraction plan for the current corpus.
Technical — policy-as-code in place, an evidence-generation surface wired up, one domain onboarded end-to-end as the reference shape.

Handover-first. Every engagement builds Cordata's replaceability into the deliverable. The measure of a successful engagement is whether the client's team can extend the governance surface without us six months later.

If you have watched a governance programme decay in the shape above — or shipped one that survived contact with a real Mesh — I would genuinely like to hear where the seams showed. The door is open at cordata.tech/contact.

Companion + follow-ups: Behaviour-first governance in practice — generating artefacts from platform events walks the concrete machinery from § 5 with real Terraform, SQL, and YAML (ships alongside this pillar as its technical companion); DSGVO Art. 17 across a mesh covers the erasure mechanics when a customer's data lives in eight accounts.