Governing shared data across a multi-brand portfolio means assigning clear ownership at the brand level, defining a minimal shared schema that each brand must conform to, and reserving central control for cross-portfolio risk and compliance only. Doing less creates data chaos; doing more destroys the brand autonomy that makes a portfolio valuable.
Key takeaways
- Data governance in a multi-brand portfolio fails in two opposite directions: too little central control produces fragmentation, too much produces a monoculture that erases brand differentiation.
- The right model assigns data ownership to the brand closest to the data, with a thin central layer responsible only for shared schema, compliance, and cross-portfolio risk.
- ISO 8000 defines data quality as fitness for purpose, not absolute correctness; that framing is especially useful in portfolio contexts where each brand has different data needs.
- Decision rights for data must be documented at the role level, not the person level, so they survive staff turnover.
- voolama's portfolio spans SaaS, AI, consulting, and airport infrastructure; each venture has distinct data needs, which is why a one-size governance model would be counterproductive.
Summary
The Portfolio Data Problem Nobody Talks About
Enterprise data governance literature is written for single organizations. It assumes one set of strategic objectives, one data culture, and one definition of what good data looks like. Multi-brand portfolio companies do not fit that assumption.
voolama's portfolio makes this concrete. DAVE (hellodave.ai) orchestrates AI workflows and requires high-integrity, auditable event data. The DAM Republic is a vendor-neutral digital asset management hub whose core data is rich media metadata. Rarovera is a consulting practice whose primary data is engagement and project records. Airport Online is a SaaS microsite platform for airports whose data is operational and content-driven. Four brands, four data models, four different tolerances for central oversight, all under one parent.
The governance question is not how to standardize all of that. It is how to create enough shared structure to enable cross-portfolio insight and compliance, without destroying the operational independence that makes each brand work. Get the balance wrong in one direction and you have data chaos: four brands running on incompatible schemas with no way to aggregate anything. Get it wrong in the other direction and you have a monoculture: one data model imposed on four businesses with different needs, slowing all of them down.
The right answer sits in the middle, and it requires being explicit about exactly where the line is. The DAMA International Data Management Body of Knowledge (DMBOK) frames this as the difference between enterprise governance, which sets policy and standards, and stewardship, which applies them at the data domain level. In a portfolio company, each brand is effectively a data domain with its own steward.
What the Central Layer Should and Should Not Own
The central governance layer in a multi-brand portfolio should own exactly three things, and nothing more.
- Shared identifiers. Any entity that appears across more than one brand, such as a partner, a vendor, or a shared contact, needs a consistent identifier so that cross-portfolio reporting is possible. The central layer defines and maintains that identifier schema. It does not define how each brand stores or uses the entity beyond that identifier. In voolama's case, a consulting engagement through Rarovera that later involves DAVE's AI workflow tooling needs a shared engagement identifier; without one, cross-portfolio reporting requires manual reconciliation every time.
- Compliance obligations at the parent level. Where a regulation applies to the holding company as a whole, the central layer owns the data standards needed to meet that obligation. The EU AI Act, under Article 14(4), requires that operators of high-risk AI systems implement human oversight measures and document them. If any portfolio brand deploys a high-risk AI system as defined by the Act, the parent needs a consistent, auditable way to evidence that oversight across its portfolio. That evidence requirement is a central governance responsibility, not a brand-level one.
- Cross-portfolio analytics schema. If the parent wants to run any analysis that spans brands, it needs a minimal common schema for the fields that analysis depends on. That schema should be as small as possible and defined by what the analysis actually requires, not by what would be convenient to standardize.
Everything outside those three categories should be owned and governed by the brand that creates and uses the data. ISO 8000, the international standard for data quality, defines quality as fitness for purpose rather than absolute correctness. What counts as high-quality metadata for The DAM Republic's asset library is not the same as what counts as high-quality event data for DAVE's workflow engine. Imposing a single quality standard across both is a category error, and ISO 8000's fitness-for-purpose principle gives portfolio operators a principled basis for resisting that pressure.
Decision Rights: The Part Most Portfolios Skip
Defining what the central layer owns is necessary but not sufficient. The governance model only works if decision rights are documented at the role level, not the person level. In a portfolio company, people move between brands, take on new responsibilities, and leave. A governance model that lives in one person's head is not a governance model; it is a single point of failure.
A practical decision-rights matrix for portfolio data governance has three columns: the decision type, the role that owns it at the brand level, and the role that owns it at the central level. For most decisions, the brand-level role has full authority. For the three central-layer categories above, the central role has authority, with a defined escalation path for disputes.
The DAMA DMBOK recommends that data governance frameworks include explicit RACI (Responsible, Accountable, Consulted, Informed) assignments for each data domain and each governance decision type. In a portfolio context, the RACI table should distinguish between brand-domain decisions and parent-level decisions, and should be reviewed at least annually. A single page covering the twenty most common data decision types is more useful than a comprehensive policy document that nobody reads.
One practical signal that decision rights are unclear: when a brand-level data decision gets escalated to the parent more than twice in a quarter for the same decision type, the matrix has a gap. That gap should be closed by documenting the decision rule, not by the parent making the call each time.
What This Does Not Cover
This piece addresses the governance structure question: who owns what, and how is that documented. It does not address the technical implementation of shared data infrastructure, the selection of data platforms or warehouses, or the specifics of any sector-specific regulation beyond the examples cited. Organizations subject to GDPR, HIPAA, or sector-specific AI regulation should engage qualified legal and compliance counsel; this piece is not legal advice.
The framing here is most directly applicable to holding companies with two to six distinct brands operating in different markets. Very large conglomerates with dozens of brands face additional complexity that this framing does not fully address. It also does not address data sovereignty or cross-border transfer restrictions, which require separate legal analysis.
Disclosure: voolama is the parent company of ventures that include AI workflow orchestration (DAVE) and digital asset management (The DAM Republic). The perspective in this piece reflects the parent-brand view, informed by operating across those ventures since 2016. It is not a recommendation of any specific platform or vendor.
FAQ
- What is shared data governance in a multi-brand portfolio?
- Shared data governance in a multi-brand portfolio is the set of policies, ownership assignments, and standards that determine how data is created, maintained, accessed, and retired across brands that operate under a common parent. The goal is to enable cross-portfolio insight and compliance without forcing every brand to manage data the same way, which would undermine the operational independence that makes a portfolio structure worthwhile.
- How do you decide what data should be governed centrally versus at the brand level?
- A useful rule is that data should be governed at the level closest to where it is created and used, with central governance reserved for three things: shared identifiers that need to be consistent across brands, compliance obligations that apply at the parent-company level, and cross-portfolio analytics that require a common schema. Everything else should be owned and governed by the brand that knows it best.
- What does ISO 8000 say about data quality that is relevant here?
- ISO 8000 defines data quality as fitness for purpose rather than absolute correctness. That distinction matters in a portfolio context because what counts as high-quality data for an airport SaaS product is different from what counts as high-quality data for an AI workflow tool. Central governance that imposes a single quality standard across all brands will either be too loose for some or too restrictive for others. Fitness-for-purpose framing lets each brand set its own quality bar within a shared structural envelope.
- What is the biggest governance mistake multi-brand holding companies make with data?
- The most common mistake is centralizing too much, too fast. A newly consolidated portfolio often responds to data fragmentation by pulling all governance to the center. This solves the fragmentation problem but creates a new one: brands lose the ability to move quickly on data decisions that are entirely local to them, and the central team becomes a bottleneck. The DAMA DMBOK recommends that governance authority be distributed to the organizational unit closest to the data's point of origin, with central oversight reserved for enterprise-wide risk. The fix is to define the minimum viable central layer and leave everything else at the brand.
Sources
- ISO 8000 - Data Quality standard, ISO official page
- EU AI Act - European Commission regulatory framework overview
- DAMA International - Data Management Body of Knowledge (DMBOK)
Last reviewed
