Are Vibe-Coded Apps Leaking Your Data?
Anyone can build an app by lunch. Almost nobody can say where its customer data goes. That's a governance problem, not a people problem.
Decision governance is the practice of capturing consequential decisions as they are made — who owned each one, on what basis, with what authority, and how it turned out — so the record exists when someone asks, rather than being reconstructed later.
It applies to the decisions that carry consequence — an architecture call, a credit exception, a grant award, a model override, a board-level decision — the ones an auditor, a board, a regulator, or a new leader may later ask you to justify. The discipline is producing that justification as a byproduct of the work, not as a reconstruction weeks after. The same principles hold across IT, financial institutions, and government.
Data governance is about the data — its quality, lineage, access, and definitions. Decision governance is about the choices made from that data. You can have clean, well-governed data and still have no record of who decided what, on what basis, or whether it worked. One governs the inputs; the other governs the calls.
Governance, risk, and compliance (GRC) tracks controls, policies, and findings — whether a control exists and who owns it. Decision governance captures the decision the control was meant to produce: who decided, on what basis, with what authority, and how it turned out. GRC tells you the framework is in place; decision governance shows it was actually followed, one decision at a time.
Decision intelligence helps you make a better decision — models, analytics, and recommendations at the point of choice. Decision governance is about accountability after the choice: an owned, reconstructable record of what was decided and why. One improves the decision; the other proves it. A recommendation engine with no record still can’t answer “who approved this, and on what authority?”
Every governed decision resolves into the same five stages — one record, captured in the flow of the work.
Signal
What prompted the decision
Owner
Who is accountable, named
Decision · rationale
The call, and why it was made
Action · evidence
What was done, with proof
Outcome
The result, tracked back
Five stages. One record. Exportable on demand.
Maturity in decision governance is measured across six facets — the questions anyone opening a decision file later asks. Together they form the Decision Governance Maturity Model, an open framework adapted from CMMI.
The practice of capturing consequential decisions — who owned each one, on what basis, with what authority, and how it turned out — at the moment they’re made, so the record exists when an auditor, a board, or a new leader later asks, instead of being reconstructed.
Data governance governs the data — quality, lineage, access. Decision governance governs the choices made from it: who decided, why, and how it turned out. Well-governed data still won’t tell you who approved the exception.
No. GRC tracks whether controls and policies exist; decision governance captures the decisions those controls were meant to produce — evidence the framework was actually followed, decision by decision.
Every consequential decision has a single named owner on the record, at the authority level policy requires — one of the six facets of the Decision Governance Maturity Model.
Across six facets — Ownership, Timeliness, Reconstructability, Override Discipline, Authority, and Apex Linkage — on a five-level scale. The open framework is the Decision Governance Maturity Model; the self-assessment places your organization against it.
Organizations are routinely asked to justify past decisions — a technology bet, a credit exception, a grant award, a model override. Decision governance produces that justification as a byproduct of the work, so answering “who decided this, and why?” is an export, not a reconstruction.
DataVisuals builds decision governance products for IT, for banks and credit unions, and for government — see the products.
Anyone can build an app by lunch. Almost nobody can say where its customer data goes. That's a governance problem, not a people problem.
Most of your tech stack is SaaS or COTS. Why IT Architecture should govern meaning, not code, and why a Decision Board beats an ARB in a SaaS-centric enterprise.
MCP tools that orchestrate, sequence, or apply rules create a second place business logic lives. The two copies drift, because nothing forces them to agree.