This article was published in 2026 and references a historical event from 2007, included here for context and accuracy.
- Tension: Organizations treat data governance as either rigid internal control or radical external crowdsourcing when neither extreme addresses why governance fails.
- Noise: The debate over centralized versus distributed governance obscures the fact that most organizations can’t execute either approach effectively.
- Direct Message: Governance succeeds not by choosing between internal control and external input, but by building organizational capacity to sustain any governance model.
To learn more about our editorial approach, explore The Direct Message methodology.
In 2007, data governance experts outlined seven critical questions organizations needed to answer before implementing master data governance programs.
Answer these questions properly, establish clear councils and stewardship, and governance would succeed.
Nearly two decades later, organizations debate whether to expand governance beyond these internal questions to include external perspectives or even crowdsource governance decisions entirely.
But 80% of governance initiatives are predicted to fail by 2027, whether they embrace traditional boards and stewards or experimental distributed models.
The problem isn’t whether governance should be inward-focused or externally informed.
The problem is that most organizations lack capacity to execute any governance approach consistently.
The seven questions that should have guaranteed success
The 2007 framework identified specific questions organizations needed to answer upfront to avoid political logjams and costly delays:
1. What data should constitute master data? Organizations needed to define which data qualified as master data based on industry and fundamental business processes. A manufacturer managing supply chains would define products, units of measure, and kit components as master data. A pharmaceutical company complying with marketing regulations would define healthcare providers, hospitals, state licenses, and sales territories. A financial services firm managing risk would define counterparties, securities, geography, and currency.
2. Who will own the various aspects of master data? Before governance could be effective, master data definitions needed to be unique across the organization. But various elements comprising these definitions came from different lines of business. Product master design elements came from engineering. Packaging and part information came from manufacturing. Category and product family elements came from distribution. Organizations needed to determine whether a single owner would work collaboratively with other departments or whether ownership of different elements should be assigned to different departmental owners.
3. How many and what data sources exist for each type of master data? Application systems were widely distributed across business functions, storing multiple instances of the same master data entity and requiring consolidation. Product master data existed in engineering’s product lifecycle management systems, manufacturing’s enterprise resource planning systems, and distribution’s supply chain management systems. Organizations also sourced master data from external providers like Dun & Bradstreet or Acxiom. Determining which systems would supply data initially and ongoing, and whether new systems were planned or existing systems would be retired, became essential.
4. What level of validation or verification of consistency, correctness, and completeness is sufficient? Master data needed to be consistent, correct, and complete. But quality standards varied depending on data type, source, usage, and overall cost of maintaining quality. If postal codes were critical for marketing campaign effectiveness but missing from most customer records, data augmentation from external providers might be required to ensure reliability.
5. What, if any, industry or regulatory standards must be supported? Regulatory standards differed greatly by industry sector. Pharmaceutical companies needed to comply with marketing regulations and prescribing drug restrictions. Financial institutions needed to comply with Basel II, privacy, and MiFID regulations. Compliance to evolving industry standards often dictated that additional master data entities be tracked along with data history and lineage information to support necessary reporting and audit functions.
6. Who is allowed access rights to which data type and what actions can they perform? System and master data security access rights and policies needed to be established and enforced to ensure compliance and data quality requirements were met. Organizations needed to determine what elements or fields of master data individuals could access, what access each individual had (read, edit, or full privileges), and whether restrictions applied. For instance, should a sales representative be restricted from or given rights to view a customer’s social security number or other sensitive information?
7. What controls need to be put in place for master data and what level of change needs to be recorded over what timeframe? Controls would monitor and audit system usage in real-time to alert data stewards of possible issues and exceptions. All changes to master data would need to be tracked to document lineage while providing a foundation for historical reporting. The extent of change tracking and auditing required would depend on specific business requirements.
The framework promised that answering these questions in advance would allow organizations to better plan and implement successful master data governance throughout their enterprises.
Why technically sound questions produce organizationally impossible answers
These seven questions remain technically valid. Organizations do need to define which data qualifies as master data.
A pharmaceutical company tracking healthcare provider licenses requires different entities than a manufacturer managing supply chain components. Engineering contributes design specifications while manufacturing provides packaging details. Multiple systems store duplicate records requiring consolidation.
But consider what happens when organizations actually attempt to answer these questions.
42% of firms cite lack of clear data ownership as their primary governance challenge. Not uncertainty about which data qualifies as master data, but fundamental inability to establish who owns anything.
Finance believes they own customer profitability data. Sales insists customer relationships belong to them. Marketing claims ownership of customer engagement metrics. IT argues that as system custodians, they’re the true data owners.
The technical questions assume organizational coherence that doesn’t exist. They presume that once you identify that product master data exists in engineering’s PLM system, manufacturing’s ERP, and distribution’s supply chain management platform, you can simply “determine which will supply data initially and on an ongoing basis.”
But those systems represent territories, budgets, and political power. Distribution’s supply chain platform runs on a different vendor’s technology than manufacturing’s ERP because the distribution VP negotiated that purchase five years ago and any attempt to consolidate threatens their departmental autonomy.
Organizations manage an average of 897 applications with only 29% integrated. These aren’t just technical integration challenges. They’re manifestations of organizational fragmentation where each business unit maintains separate systems precisely to preserve independence from central governance.
The systematic avoidance of why governance actually fails
While the industry debates whether to track social security numbers at the field level or whether sales representatives need read versus edit privileges, 88% of data scientists report spending most of their time cleaning and organizing data rather than analyzing it.
That’s not a data validation problem. That’s what happens when organizations would rather waste hundreds of analyst hours than confront the territorial disputes preventing system consolidation.
Recognizing traditional governance’s limitations, some advocates propose expanding governance to include external perspectives. Instead of boards and councils asking inward-looking questions about what we’re allowed to do with our data, governance should consider how external stakeholders view data-related issues.
Others push further, suggesting organizations crowdsource governance decisions where “the crowd” collectively determines critical policies around user, customer, product, and employee data.
But both approaches, while opposite in their premises, make the same fundamental error. They assume organizational dysfunction stems from asking the wrong questions or excluding the right voices.
Add external perspectives or open governance to crowds, and suddenly the organization can execute what it previously couldn’t. Reality suggests otherwise.
The technical questions from 2007 weren’t insufficient because they lacked external input. They were insufficient because they treated governance as a design problem rather than an organizational capacity problem.
What determines whether any governance model succeeds
Governance fails not from choosing the wrong structural model but from organizations lacking the capacity to sustain any model against opposing organizational forces.
Whether governance relies on traditional boards asking seven critical questions or expanded councils incorporating external perspectives or crowdsourced collective decision-making, success depends on organizational capacity to enforce decisions once made.
That capacity doesn’t emerge from better questions or more inclusive processes. It emerges from power structures that can overcome territorial resistance.
Gartner’s prediction specifies exactly what’s required: a real or manufactured crisis. Not more sophisticated technical frameworks. Not expanded stakeholder inclusion. Not crowdsourced collective intelligence.
Organizational pain severe enough that resistance to governance becomes more costly than submission to it.
This explains why organizations with mature governance don’t just have better questions or more inclusive processes. They have fundamentally different power structures where strong integration enables 10.3x ROI from AI initiatives versus 3.7x for those with poor connectivity.
That performance difference doesn’t come from asking better governance questions or including more stakeholders in decision-making. It comes from organizational capacity to enforce integration that makes governance possible.
The 2007 questions remain essential. But answering these questions reveals organizational capacity rather than creating it.
When ownership remains contested after extended discussions, that signals power structures incompatible with centralized governance. When multiple source systems exist but determining which supplies data proves politically impossible, that exposes fragmentation that will reject any governance framework.
Building governance that survives organizational reality
The choice between traditional internal governance and expanded external perspectives represents a false dilemma.
Both can succeed in organizations with capacity to enforce decisions. Both will fail in organizations lacking that capacity.
The critical question isn’t whether to expand governance’s scope but whether your organization can sustain governance at all.
Organizations discovering they lack this capacity face a choice. They can build capacity by creating the crisis that makes governance resistance more painful than submission.
Quantify the cost of data inconsistency. Document the competitive disadvantage from fragmented customer views. Calculate the regulatory risk from ungoverned sensitive data. Make organizational pain from poor governance exceed the discomfort of territorial compromise.
Or they can acknowledge that distributed governance aligned with existing territories represents the only viable approach. Not as failure but as accurate assessment preventing wasted investment in frameworks organizational structure will reject.
Some organizations genuinely cannot sustain enterprise governance. Better to implement federated models respecting departmental autonomy than to mandate central control that political reality will dismantle.
For organizations possessing capacity for enterprise governance, implementation uses the seven questions not as checklists but as forcing functions.
Defining master data becomes the mechanism for aligning business processes. Establishing ownership creates the authority needed to resolve disputes. Documenting source systems exposes fragmentation demanding consolidation.
Each question becomes a lever for organizational change rather than a technical specification.
The debate over whether to maintain traditional governance or expand to external perspectives or even crowdsource decisions misses the point.
The industry spent two decades arguing about governance’s proper scope while carefully avoiding examination of why organizations systematically reject governance regardless of its design.
Organizations that acknowledge this can either build the capacity governance requires or implement approaches aligned with political reality.
Both paths succeed better than debating whether internal control or external crowdsourcing represents governance’s future while 80% of initiatives fail from organizational dysfunction neither approach addresses.
