Microsoft Purview Data Asset Ownership Decision Tree

Part 3 of the Data SkyLab Studio Microsoft Purview Data Asset Ownership and Onboarding Framework v1.0.

Use this decision path for a specific Data Asset. Record the evidence used at each decision point so the ownership decision is repeatable, explainable and reviewable.

Core principle: Do not begin with “Who can we put in the Purview Owner field?” Begin with “Where does accountability for this data actually sit?”

Decision 1 — Is the Data Asset sufficiently understood?

YES: Continue to Decision 2.

NO: Do not assign an owner yet. First review relevant Data Governance policy, guidance, standards and other organisational documentation. Identify an SME, technical contact or source-system expert where needed; establish business meaning, provenance and intended use; then restart the decision path.

Support note: Ownership without understanding usually creates a name in a field rather than genuine accountability.

Decision 2 — Can you identify the accountable business function?

Can you identify the business function accountable for the activity or information represented by the asset?

YES: Continue to Decision 3 using that function as the ownership area.

NO: Trace the business processes that create, maintain and depend on the information. If the accountable function remains unclear, escalate to Governance Domain leadership or the defined Data Governance authority.

Support note: The aim is to identify where accountability already exists, not invent a new owner simply for Purview.

Decision 3 — Is the proposed owner being chosen mainly because of technical custody?

Are they being selected mainly because they host, administer, build or frequently use the technology?

YES: Do not confirm ownership on that basis alone. Identify whether business accountability sits elsewhere; then continue to Decision 4.

NO: Continue to Decision 4.

Support note: Technical custody may support ownership but does not automatically establish it.

Decision 4 — Is there an existing accountable business role?

YES: Use that role as the candidate owner and continue to Decision 5.

NO: Identify the role with the closest existing accountability and sufficient authority. If no appropriate role exists, escalate the organisational accountability gap.

Support note: Prefer an accountable business role over a person-specific assignment. The named individual can then be recorded as the current role holder.

Decision 5 — Does the candidate have sufficient authority?

Test whether the candidate can approve or sponsor meaning, appropriate use, quality remediation, significant change, risk decisions and escalation.

Can they approve or challenge what the data means?
Can they make or sponsor decisions about appropriate use?
Can they require, sponsor or escalate remediation of significant Data Quality problems?
Can they influence or sponsor access, sensitivity, security and risk decisions?
Can they approve or sponsor significant change?
Can they prioritise or obtain resources for remediation?
Can they resolve or escalate disputes?
Can they say no to an inappropriate use?

YES: Continue to Decision 6.

NO: The candidate may be a Steward, SME or Custodian. Move to the role that can exercise the required authority, then retest.

Decision 6 — Are two or more roles or people claiming accountable ownership?

YES: Ask who is ultimately accountable when a decision cannot be agreed. Select that single accountable role; retain others as Stewards, SMEs or stakeholders. If there is no defensible answer, escalate.

NO: Continue to Decision 7.

Support note: The framework permits many supporting roles but aims for one clearly identifiable accountable Data Asset Owner.

Decision 7 — Is the data externally supplied?

YES: Preserve the external source, provenance and legal or intellectual-property position, but identify an internal role accountable for the organisation's use, handling, risk, quality expectations, licensing obligations and governance. Continue to Decision 8.

NO: Continue to Decision 8.

Support note: Internal governance accountability does not imply transfer of legal or intellectual-property ownership.

Decision 8 — Is the asset derived from another Data Asset?

YES: Ask whether it has become materially distinct in business meaning, purpose, lifecycle, risk or decision authority.

If materially new, restart the ownership test for the new asset. If not, the existing ownership may remain appropriate. Then continue to Decision 9.

NO: Continue to Decision 9.

Support note: Technical transformation alone is not enough to create a new ownership boundary.

Decision 9 — Has an appropriate stewardship arrangement been established?

YES: Continue to Decision 10.

NO: Identify the named steward or stewards, domain stewardship team or other recognised arrangement that will support day-to-day governance before completing the baseline.

Support note: Ownership is accountability; stewardship supports operational governance.

Decision 10 — Has the accountable owner understood and acknowledged the assignment?

YES: Continue to Decision 11.

NO: Validate and nominate the role, explain the accountability, obtain acknowledgement through the organisation's agreed process, and then record it.

Support note: The recommended lifecycle is Identify → Validate → Nominate → Accept → Record → Review.

Decision 11 — Has the required Governance Baseline been met?

YES: Mark the asset Governance Baseline Met and assess Data Product readiness.

NO: Complete the mandatory metadata and controls appropriate to this asset class, risk and intended use.

Support note: The baseline should be proportionate. It is not a requirement to populate every possible Purview field for every discovered technical object.

Decision 12 — Is the Data Asset suitable for deliberate association with a business-facing Data Product?

YES: Mark it Data Product Ready and associate it with the relevant Data Product or Data Products where it contributes to the defined purpose or use case.

NO: Keep it governed in Data Map and revisit Data Product readiness when the use case, maturity or governance state changes.

Support note: A draft or investigatory Data Product may still use candidate assets, but status and governance gaps should be clear.

End-state rule

If the Data Asset is associated with one or more Data Products, retain the established Data Asset Owner. The Data Product Owner remains accountable for the product; association does not transfer ownership of the underlying asset.

Decision record — suggested evidence

For important or disputed ownership decisions, retain enough evidence to show how the decision was reached. A simple record can include:

Data Asset name and Purview identifier / FQN
business meaning and purpose
source and provenance
accountable business function
candidate owner role and current role holder
evidence against the ownership decision test
stewardship arrangement
date ownership was accepted or confirmed
governance baseline status
Data Product associations
exceptions, disputes or escalation decisions
review date or review trigger

Quick reference — Data SkyLab Studio core principles

Discovery does not equal governance.
Ownership follows business accountability and decision authority, not technical custody.
Each Data Asset reaching the governance baseline should have one clearly accountable Data Asset Owner, even where Microsoft Purview can hold multiple owner contacts.
Appropriate stewardship must be established alongside ownership.
A Data Asset should meet the agreed governance baseline before being treated as production Data Product Ready.
A Data Asset may be associated with one or more Microsoft Purview Data Products.
Association with a Data Product does not transfer ownership of the underlying Data Asset.
A Data Product Owner is accountable for the Data Product; a Data Asset Owner is accountable for the Data Asset.
Derived Data Assets should have ownership reassessed when a materially distinct business asset is created.
Discover broadly, govern progressively and productise according to business value.