Ownership must become a working capability
An institution can launch a modern platform and still struggle to resolve an ordinary data problem. Engineering sees a failed rule. Operations sees a wrong customer status. Finance sees an unexplained report difference. Each team can describe the issue, but no one has authority to decide which interpretation governs the correction.
Henna83 recommends designing the data operating model alongside the platform. The model needs more than a list of stewards. It must define who decides business meaning, who implements changes, who controls access, who resolves incidents and who funds the service after the program closes.
Three executive choices come first: which decisions belong to domains, which require enterprise standards, and which need independent challenge. Those choices should reflect the institution's structure and risk profile. A centralized model can set consistent standards while business domains remain accountable for meaning.
The practical test is a rehearsal. Take a realistic quality failure and follow it from detection to correction, consumer notification and retained evidence. If teams cannot resolve it with named decision rights, the platform is not ready for a clean operating handoff.
Go-live requires an organization that can make and retain the decisions needed to operate the data.
Governance remains a persistent challenge
The Basel Committee's November 2023 review covered 31 G-SIBs and reported differing levels of alignment with BCBS 239 [1]. The finding illustrates a durable challenge among major institutions. It is not evidence that every regional bank or mortgage servicer has the same regulatory obligation.
Its 2026 implementation discussion continues to address bank data and risk-management practices [2]. Henna83's implication is that governance should be tested in operations, where definition changes and quality failures occur. A policy that does not establish authority leaves teams improvising.
AWS readiness guidance spans business, people, governance, platform, security and operations [3]. These perspectives connect through staffing, funding, incident response and standards. A data service cannot be sustained if its operating obligations are funded only as temporary project work.
Establish the institution's own responsibilities: which committees approve material changes, which service owners can act within approved boundaries, and which control functions independently review outcomes. The model should be specific enough to use during an incident.
Governance becomes credible when it resolves a consequential operating decision.
Four decisions to make before launch
Business meaning: a domain owner approves definitions and material rule changes. Consumers participate where a change affects their output. Engineering should not decide a financial or regulatory classification because it is easier to implement.
Service ownership: a platform owner is accountable for availability, deployment, monitoring and recovery. A product owner is accountable for the product contract. State how those responsibilities interact rather than giving both the same vague label.
Exception resolution: triage distinguishes source errors, pipeline failures and definition disputes. Each category needs a response owner and escalation time. Emergency technical recovery can restore service while a separate business decision resolves uncertain meaning.
Funding and demand: identify who pays for shared infrastructure, maintenance and new consumption. Establish a transparent request and prioritization process. Otherwise, every product competes for unplanned engineering capacity.
Preserve challenge. Risk, compliance and audit responsibilities should not be absorbed into delivery approval. Explain who builds, who accepts and who independently assesses where assessment is required. Independence follows the institution's governance and the applicable mandate.
Operating context: enterprise standards can define naming, lineage, access and deployment controls while domain owners decide business meaning within those standards. A federated model needs explicit escalation where domains disagree. Service operations also need authority to restore a failed flow without silently changing its business rule. Separate technical recovery from semantic correction, and document how the two decisions reconnect before consumer acceptance.
Exhibit: decision rights at the point of work
This original Henna83 matrix separates accountable authority from delivery contribution. Tailor titles to the organization and name one accountable owner per decision. Record an escalation route if the owner is unavailable.
| Decision | Accountable authority | Contributors |
|---|---|---|
| Business definition | Domain business owner | Consumers, steward, compliance as applicable |
| Pipeline deployment | Platform service owner | Engineering, operations, change control |
| Quality correction | Product/domain owner | Source owner and affected consumers |
| Access approval | Approved data/access owner | Security and privacy |
| Service recovery | Platform incident authority | Operations and business escalation |
| Funding priority | Executive portfolio owner | Finance, domain and platform leaders |
Using the matrix: take actual recurring requests and identify who can decide them. Include the backup authority, expected response time and evidence retained. Rehearse an incident outside ordinary working hours. Confirm whether the domain owner, platform responder and consumer can be reached. Revise the matrix if an operating event requires a decision that no role is authorized to make.
Authority, response time and retained evidence make the matrix usable during an incident.
Worked example: a disputed account status
Illustrative scenario, not a client outcome. A quality rule flags conflicting statuses in two feeds. The platform is available and both pipelines ran. The issue is a business interpretation dispute rather than a service outage.
The steward identifies the affected population and source timing. The domain owner brings servicing and finance together to approve treatment for each consumer purpose. Compliance participates if the classification affects a covered output. Engineering implements the versioned rule after approval.
The product owner informs consumers of the correction and any historical restatement. The platform team retains the transformation version and test results. The issue is closed only when affected outputs are addressed and a preventive control has an owner.
Without these responsibilities, the issue may circulate or produce an undocumented workaround. With them, the institution can distinguish restoration of service from correction of business meaning. Rehearse the scenario before launch and measure the time needed to identify authority, approve the rule and notify consumers.
Questions for the sponsor: Who owns meaning versus availability? What authority exists during an incident? Who funds maintenance? Which decisions need independent challenge? How does a business consumer escalate an unresolved data issue?
Make the handoff measurable
Before launch, appoint owners, approve contracts, establish support coverage and define incident and change routes. Confirm the operating budget and specialist dependencies.
Run representative quality, access and schema-change rehearsals. Retain the decisions and identify unresolved responsibilities. Launch approval should state who accepts any gaps and how they will be closed.
After launch, review exception age, unassigned decisions, response-target breaches, capacity and adoption. Use the review to adjust staffing or authority. Adding a committee is useful only if it resolves a decision that the current model cannot handle.
The CDO Operating Model Starter provides decision-rights, product-canvas and escalation templates. Henna83 aligns executive governance with the teams responsible for building and operating the platform. Let's talk about the decisions your current model leaves unresolved.
Measurement detail: measure time to accountable assignment as well as time to resolution. Classify incidents by source, pipeline and interpretation. An issue should not disappear because it moved between queues. Preserve its ID and affected consumers throughout the handoff.
References
[1] Basel Committee on Banking Supervision. Progress in adopting the Principles for effective risk data aggregation and risk reporting. November 28, 2023. https://www.bis.org/bcbs/publ/d559.htm
[2] Basel Committee on Banking Supervision. Implementation of the Principles for effective risk data aggregation and risk reporting (BCBS 239 Principles). January 6, 2026. https://www.bis.org/publications/implementation-principles-effective-risk-data-aggregation-and-risk-reporting-bcbs-239-principles
[3] Amazon Web Services. Evaluating migration readiness. Living technical documentation; accessed October 10, 2026. https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluating-migration-readiness/introduction.html