Complete a quick assessment and discover your Data Governance Maturity Score.

Most AEC firms have people who care about data quality. Document controllers who catch naming errors, BIM coordinators who flag model inconsistencies, project managers who question the numbers in a report. What these firms don’t have is a structure that gives those people authority, accountability, and escalation paths.

The result is governance by heroics: individuals taking ownership informally, without mandate or recognition, while systemic data quality problems persist because no one has the formal responsibility to resolve them. When that person leaves, the institutional knowledge leaves with them.

This pattern is more acute in AEC than in most other sectors for three reasons. First, the project-based operating model creates natural silos: each project team develops its own data practices, and there is no enterprise function to standardize across them. Second, the supply chain is complex: subcontractors, consultants, and specialist contractors contribute data to your systems with no accountability for quality. Third, the data estate spans both project operations and long-lived physical assets, creating governance obligations that extend decades beyond project completion.

The Six Core Data Governance Roles

Every mature data governance program, across every industry, is built on six roles. The titles vary. The functions do not. Understanding these roles is the foundation for building a governance operating model that works in your specific organizational context.

Role 1: Chief Data Officer (CDO) or Head of Data Governance

The CDO is accountable for the organization’s overall data strategy and governance program. In smaller AEC organizations, this role is often held by the CTO, CIO, or Head of Information Management rather than a dedicated CDO. The title matters less than the mandate: someone at the executive table must own the data agenda, have budget authority, and be accountable for governance outcomes.

The CDO chairs the data governance council, sponsors the governance program, sets the strategic direction for data investment, and is the escalation point for governance disputes that cannot be resolved at the domain level.

Role 2: Data Governance Council

The governance council is the decision-making body for cross-functional data issues: conflicting definitions, competing priorities for data quality investment, policy changes, and disputes about data ownership. It typically meets monthly or quarterly and is chaired by the CDO.

In AEC, council membership should include representatives from engineering, project delivery, commercial, finance, IT, and HR. This cross-functional composition ensures governance decisions reflect operational reality across the business, not just the preferences of the IT function.

Role 3: Data Domain Owner

Domain Owners hold business accountability for a defined data domain: project data, asset data, financial data, workforce data, or supply chain data. They are typically senior business managers with P&L or operational accountability in that domain.

The Domain Owner is responsible for defining quality standards for their domain, approving changes to governance policies that affect their data, resolving escalated data quality issues, and ensuring their domain’s data stewards have the resources and authority to operate. This role must sit in the business, not IT. When IT owns data domains, governance becomes a technology project. When the business owns them, it becomes an operational discipline.

Role 4: Data Steward

The Data Steward is the operational heart of the governance program. Stewards execute governance policy in day-to-day operations: enforcing naming conventions, resolving data quality issues, managing metadata, monitoring data quality metrics, and maintaining the data catalogue for their domain.

In AEC, the natural stewardship population is the people already closest to the data: BIM Coordinators, Document Controllers, Project Information Managers (PIMs), and Commercial Analysts. These individuals have the domain knowledge to identify quality issues and operational access to resolve them. What they typically lack is the formal mandate, defined authority, and escalation path that governance provides.

Role 5: Data Custodian

Data Custodians are responsible for the technical implementation of governance controls: platform access management, metadata tagging in CDE and ERP systems, data backup and recovery, and the technical pipelines that move data between systems. This is typically the IT function.

The custodian role is often confused with the role of stewardship. The distinction matters: Stewards own the data from a business accountability perspective. Custodians manage the platforms and pipelines that store and move it. Governance fails when the IT team is asked to own quality standards for data they do not understand in business terms.

Role 6: Data Consumer

Data Consumers are the project teams, analysts, finance managers, and executives who use governed data to make decisions and deliver work. Consumers are not passive recipients. In a mature governance program, they have obligations: reporting data quality issues, using approved data sources rather than shadow systems, and following access request procedures.

Defining consumer obligations is one of the most overlooked elements of AEC governance programs. When project teams are allowed to maintain their own spreadsheets alongside governed systems, the governance program and the shadow system compete for legitimacy. Governance wins when consumers trust governed data more than their own workarounds.

Role Mapping for AEC: Who Does What

The table below maps standard governance roles to the people and functions that typically hold them in AEC organizations. This is a starting point, not a prescription. Your governance operating model should reflect your organizational structure, not a generic template.

How Other Industries Assign Governance Roles

AEC organizations do not need to build governance role structures from scratch. Healthcare, financial services, and manufacturing have decades of practice in this area. The principles translate directly, even if the domain-specific detail does not.

Healthcare: Clinician-Led Stewardship

In healthcare, patient data governance requires clinicians — nurses, physicians, and department heads — to serve as data stewards for clinical data domains. This is the most important lesson for AEC: the steward must understand the data they govern in operational context, not just technically.

UK NHS trusts and US hospital systems have found that placing IT staff in stewardship roles for clinical data produces governance that is technically correct but operationally unusable. The same failure mode occurs in AEC when IT teams are asked to govern BIM or project data. The steward must be the domain expert first, the data manager second.

Financial Services: Regulator-Driven Role Clarity

Banks and asset managers in the US, UK, and EU operate under regulatory frameworks — Basel III, BCBS 239, MiFID II — that mandate explicit data lineage, ownership, and accountability. This regulatory pressure has produced some of the most mature governance operating models in any industry.

The financial services lesson for AEC is structural: governance roles need written mandates, not informal agreements. When BCBS 239 required banks to demonstrate data lineage for risk data, informal stewardship arrangements collapsed under audit scrutiny. AEC firms pursuing public-sector contracts or ISO 19650 compliance face comparable scrutiny. The governance structure must be documented to be defensible.

Manufacturing: Bridging OT and IT Data Governance

Advanced manufacturers operating Industry 4.0 environments have had to extend governance roles into operational technology (OT) domains: sensor data, equipment telemetry, quality control systems. The challenge of bridging IT and OT governance is directly analogous to the AEC challenge of bridging project information management and enterprise data governance.

Manufacturers like Siemens and ABB have addressed this by creating hybrid stewardship roles that understand both operational processes and data management principles. AEC firms building smart building and digital twin capabilities face identical challenges. The BIM Coordinator of 2026 is increasingly a hybrid role: part project information manager, part data governance steward.

Building Your Governance Operating Model

A governance operating model defines not just who holds each role, but how they interact: the decision of rights, escalation paths, meeting cadences, and accountability mechanisms that turn governance roles into a functioning system. Most AEC organizations that struggle with governance have roles assigned but no operating model connects them.

Decision Rights: Who Decides What

Decision rights define which governance decisions are made at which level. Quality standards for a data domain are set by the Domain Owner. Changes to platform access permissions are made by the Data Custodian, with Domain Owner approval. Policy changes affecting multiple domains go to the Governance Council. Disputes between Domain Owners escalate to the CDO.

Without documented decision rights, governance bodies become discussion forums rather than decision-making structures. Every cross-domain issue becomes a political negotiation because there is no agreed mechanism for resolving it.

Escalation Paths: Resolving Governance Conflicts

Governance conflicts are inevitable in AEC organizations. A subcontractor delivers data that fails to quality standards. Two projects use conflicting naming conventions for the same asset type. A project team’s urgency conflicts with the Domain Owner’s quality requirements. The governance operating model must define a clear escalation path for each conflict type.

A three-level escalation model works well for most AEC organizations: first to the relevant Data Steward, then to the Domain Owner, then to the Governance Council or CDO if unresolved. Establishing this explicitly removes the organizational friction that stalls governance decisions.

Cadence: Making Governance Sustainable

Governance operating models that require daily participation from senior business leaders fail. The operating cadence must fit the organizational rhythm: stewards work daily; Domain Owners engage weekly or fortnightly on escalations; the Governance Council meets monthly or quarterly for strategic decisions.

Document the cadence explicitly. When governance meetings are left to informal scheduling, they are the first things cancelled when project pressure increases. Governance that disappears under pressure is governance that was never embedded in the operating model.

Industry Standards and Professional Frameworks on Governance Roles

Two established frameworks directly define how governance roles should be structured in data-intensive organizations. Understanding these is useful context for any AEC firm designing its own operating model.

DAMA International: DMBoK 2

DAMA International’s Data Management Body of Knowledge, Second Edition (DMBoK 2) is the authoritative professional reference for data management and governance. It defines data stewardship as ‘the most common label used to describe accountability and responsibility for data and processes that ensure effective control and use of data assets.’

DMBoK 2 treats stewardship as a formal function, not a job title. It specifies that stewardship must be resourced, mandated, and connected to an accountability structure to be effective. This distinction — between informal stewardship behavior and formalized stewardship roles — is the most important governance design principle DAMA sets out. Most AEC organizations have the behavior. Very few have the structure.

ISO 19650: Information Management Roles in AEC

ISO 19650, the international standard for information management using Building Information Modelling, defines governance roles directly relevant to AEC organizations. The standard distinguishes between the Appointing Party (the client or asset owner who sets information requirements), the Lead Appointed Party (the principal contractor or lead consultant responsible for information management), and Task Teams (design and delivery teams who produce and manage information containers).

ISO 19650-1 requires each party to appoint an Information Manager responsible for the CDE and for ensuring information deliverables meet the Exchange Information Requirements. This is a governance stewardship role written into a contractual and operational standard — not a theoretical framework. AEC organizations that have not mapped their existing roles against this structure have an accountability gap that will surface during BIM-mandated project audits.

For UK firms, the BIM mandate on centrally procured public sector projects requires ISO 19650 compliance. For US firms on federal infrastructure projects, equivalent information management requirements apply under NBIMS-US and GSA BIM guidelines. In the Netherlands, the RGD (Rijksgebouwendienst) has adopted comparable information management standards for government construction. The governance role structure is therefore not optional on public sector work in BluEnt’s primary markets.

BluEnt’s Observation from Practice

Across governance engagements with AEC organizations in the US, UK, Canada, and the Netherlands, the pattern BluEnt consistently encounters is the same: informal stewardship behavior exists, but formal role structures do not. BIM Coordinators and Document Controllers are making governance decisions every day without the title, the authority, or the escalation path to make those decisions stick.

Formalizing what already happens informally is faster and less disruptive than designing governance structures from scratch. The most effective starting point is to map current informal stewardship behavior to the role definitions in DMBoK 2 and ISO 19650, then build the accountability structure that converts informal practice into durable governance.

Five Mistakes AEC Firms Make When Assigning Governance Roles

Assigning Governance Roles to IT by Default

IT departments are natural custodians of the platforms that store data. They are rarely the right owners of data quality, business definitions, or governance policy. When IT holds data domain ownership by default, governance reflects IT priorities rather than business requirements. Business users stop trusting governance outputs because they do not reflect operational reality.

Making Governance Roles Voluntary Add-Ons

Governance roles that sit outside job descriptions, carry no formal authority, and receive no recognition in performance reviews are not real roles. They are requests for unpaid overtime. BIM Coordinators and Document Controllers who perform governance functions informally, without mandate or compensation for acknowledgment, burn out. The governance program loses institutional knowledge when they leave.

Confusing Data Ownership with Data Custody

Ownership is business accountability for data quality and fitness purposes. Custody is a technical responsibility for the platforms and pipelines. These are different roles with different skill requirements. When a CDE Administrator is asked to own data quality for engineering models, they can manage the technical environment but cannot resolve business-level quality disputes about model completeness or naming standards. You need both roles, and you need them occupied by the right people.

No Escalation Path for Cross-Domain Disputes

In AEC projects, data disputes frequently cross domain boundaries: schedule data owned by the project team conflicts with cost data owned by the commercial team. Without a defined escalation path, these disputes resolve through politics and seniority rather than governance principles. The Governance Council exists precisely to resolve cross-domain conflicts through a neutral, structured process.

Designing for the Org Chart, Not the Work

Governance role structures built from a clean org chart rarely survive in contact with how AEC organizations actually operate. Projects are temporary. Teams change. Supply chains are complex. The governance operating model must accommodate how decisions are actually made in your organization, not how they appear on paper. The most effective governance models are built through discovery sessions with the people who do the work, not through top-down design by consultants who have never been on a project site.

BluEnt: Trusted Data Governance Partner for the AEC Industry

BluEnt is a data governance and digital transformation consultancy with offices in the United States, United Kingdom, Canada, Netherlands, and India. We help AEC organizations build governance operating models, deploy stewardship programs, and create data foundations that support AI, analytics, and regulatory compliance. Our data governance team has designed governance role structures and operating models for AEC firms across North America, Europe, and the GCC.

Whether you’re building a governance program from the ground up or strengthening an existing framework, our experts can help you define the right operating model for your business.

Frequently Asked Questions

What is the difference between a Data Owner and a Data Steward?A Data Owner is a senior business manager who holds ultimate accountability for a data domain — they set quality standards, approve policy changes, and are responsible for the business outcomes that depend on that data. A Data Steward is the operational practitioner who executes governance on a day-to-day basis: monitoring quality, resolving issues, maintaining the data catalogue, and enforcing standards. In AEC, a VP of Engineering might be the Domain Owner for project data, while a BIM Coordinator is the Data Steward. Both roles are essential; confusing them is one of the most common governance design errors.

Does an AEC firm need a Chief Data Officer?Not necessarily by title, but yes by function. Someone at the executive level must own the data governance agenda, chair the governance council, and be accountable for governance program outcomes. In AEC firms with fewer than 500 employees, this responsibility is typically held by the CTO, CIO, or Head of Information Management. The important thing is that the role exists, is formally assigned, and carries genuine authority to make and enforce governance decisions. Governance programs that lack executive sponsorship consistently fail to resolve cross-domain data disputes because no one has the organizational authority to adjudicate them.

How many data stewards does an AEC firm typically need?The number of stewards depends on the number of distinct data domains your organization manages and the scale of governance activity within each. A mid-sized AEC firm typically operates 6 to 10 primary data domains: project data, asset data, financial data, HR data, supply chain data, BIM data, health and safety data, and commercial data. Each domain needs at least one steward, and active project-heavy domains may need more. The right approach is to identify where data quality issues and governance gaps currently exist, prioritize those domains, and deploy stewards there first rather than designing a comprehensive stewardship program before you have evidence of where it is needed most.

Can governance roles be part-time in an AEC organization?Yes, and for most AEC firms they should be, at least initially. Data Stewards are most effective when they are embedded in the business functions that generate and use the data they govern. A BIM Coordinator who spends 80% of their time on project delivery and 20% on governance stewardship activities is more effective than a dedicated governance analyst who understands data management but lacks operational context. As governance matures, dedicated stewardship resource is appropriate. Start with embedded part-time stewards and scale from there based on governance activity volume.

How do governance roles change in a federated vs centralized governance model?In a centralized model, governance roles are concentrated at the enterprise level: a central governance team sets policy and manages the data catalogue, with limited devolved authority at the business unit level. In a federated model, governance authority is distributed: Domain Owners and Stewards within each business unit have significant autonomy, with the central governance function providing standards, arbitration, and programme oversight. For multi-project, multi-geography AEC firms, the federated model is almost always more appropriate, because project delivery contexts vary too much for a single central team to govern effectively. The governance operating model design must match the organizational structure.