Microsoft Purview Data Asset Ownership Policy — Data SkyLab Studio

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

This policy sets the mandatory rules for identifying and assigning accountability for Data Assets governed through Microsoft Purview Data Map and Unified Catalog. It separates technical discovery from governance onboarding and from association with Microsoft Purview Data Products.

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?”

Policy scope and status

This is a Data SkyLab Studio practitioner policy for organisations using Microsoft Purview. It can be adopted as written or tailored to an organisation's own governance model, regulatory obligations, operating structure and risk appetite.

It is informed by a range of established data-management and governance practices. Examples include Microsoft Purview guidance, DAMA principles, EDM Association / DCAM, and the UK Government Data Ownership Model. These are examples rather than an exhaustive list and no external body is represented as endorsing this framework.

Mandatory policy rules

1. Ownership is accountability

Data Asset ownership represents business accountability and decision authority for the Data Asset. It does not automatically mean technical possession, system administration, platform administration or legal ownership of the data.

2. One clearly accountable Data Asset Owner

Every Data Asset that reaches the organisation's governance baseline must have one clearly identifiable accountable Data Asset Owner. Microsoft Purview may technically support several owner contacts; this policy nevertheless maintains a single point of accountability.

3. Ownership follows business accountability

The accountable Data Asset Owner should normally be the business role with sufficient authority over the business meaning, appropriate use, fitness for purpose, governance and lifecycle of the Data Asset.

4. Technical custody does not automatically establish ownership

A database administrator, data engineer, system administrator, report developer, platform team or frequent consumer must not be made the Data Asset Owner solely because they build, host, administer or use the asset.

5. Appropriate stewardship must be established

Every Data Asset reaching the governance baseline must have an appropriate stewardship arrangement. This may consist of one named steward, several stewards, a domain stewardship team or another formally recognised operating arrangement.

6. Discovery does not equal governance onboarding

Technical discovery or registration of a Data Asset in Microsoft Purview Data Map does not mean that governance onboarding has been completed.

7. Governance baseline must be explicit

The organisation must define the minimum governance metadata and controls required for each relevant class of Data Asset. The baseline should be proportionate to the asset's business value, risk, sensitivity and intended use.

8. Data Product readiness is a governance state

A published or operational Data Product intended for trusted business consumption should normally use Data Assets that have reached the required governance baseline. Draft or investigatory products may identify candidate assets before that baseline is complete, provided the status is clear.

9. Association does not transfer ownership

Associating a Data Asset with a Microsoft Purview Data Product does not transfer accountability for that Data Asset to the Data Product Owner.

10. Data Asset ownership and Data Product ownership remain separate

The Data Product Owner is accountable for the Data Product. The Data Asset Owner remains accountable for the underlying Data Asset. The same person may hold both roles only where that is an explicit and appropriate accountability decision.

11. Data Assets may be reused

A Data Asset may be associated with one or more Microsoft Purview Data Products. Reuse across Data Products must not create duplicate accountable Data Asset Owners solely because the asset is used in several business contexts.

12. Materially distinct derived Data Assets require a fresh accountability test

Ownership must not automatically be inherited through lineage. Where processing creates a materially distinct Data Asset with a new business meaning, purpose, lifecycle, risk profile or decision authority, the new asset must undergo its own ownership assessment.

13. External provenance does not remove internal accountability

Where externally supplied data is held or consumed by the organisation, an internal accountable role must still be identified for the organisation's use, handling, governance, risk and licensing obligations. This does not imply transfer of legal or intellectual-property ownership.

14. Ownership decisions must be validated and acknowledged

The proposed owner should be validated against the ownership decision test and should understand and acknowledge the accountability before the assignment is treated as complete.

15. Ownership disputes must be escalated

Where ownership is genuinely unclear or disputed, the matter must be escalated through the organisation's defined Data Governance authority. Ownership must not be assigned merely to close a governance task.

Governance baseline

The exact governance baseline must be defined by the organisation. As a minimum, the Data SkyLab Studio framework recommends considering the following before a Data Asset is treated as Data Product Ready:

• clearly accountable Data Asset Owner
• appropriate stewardship arrangement
• meaningful business name and description
• business purpose or context
• source and location
• relevant Governance Domain
• classification and sensitivity where applicable
• lifecycle or status
• mandatory organisational metadata
• known limitations or risks where material

Lineage, Data Quality, Glossary Terms, Critical Data Element status and additional controls should be applied according to the importance, risk and intended use of the asset. The baseline should not become an unrealistic requirement to complete every possible metadata field for every discovered technical object.

Roles and accountability boundaries

Data Asset Owner

Primary accountability: the Data Asset, including its business meaning, fitness for purpose, appropriate use, governance and lifecycle.

Must not be assumed to mean: that the owner personally performs every stewardship or technical task.

Data Steward / stewardship arrangement

Primary accountability: supports day-to-day governance, metadata, definitions, quality, issue management and subject-matter activities.

Must not be assumed to mean: that the steward is automatically the accountable owner.

Data Product Owner

Primary accountability: the Data Product purpose, value, usability, governance context and lifecycle.

Must not be assumed to mean: ownership of every Data Asset associated with the product.

Technical Custodian / Platform or System Team

Primary accountability: operates, hosts, secures or administers the technology and technical controls.

Must not be assumed to mean: business ownership of the information merely because they operate the technology.

Subject Matter Expert

Primary accountability: provides deep knowledge about meaning, business process, data behaviour or interpretation.

Must not be assumed to mean: formal decision authority unless separately assigned.

Framework lifecycle

Discovered → Business Accountability Identified → Accountable Data Asset Owner Identified → Stewardship Established → Governance Baseline Met → Data Product Ready → Associated with Data Product(s) → Continuously Governed

Continue through the framework

Next, use the Data Asset Ownership Guidance to apply these policy rules in practice, then use the Data Asset Ownership Decision Tree for a repeatable ownership decision path.

Foundation definitions

• Data Asset, Information Asset, Dataset and Microsoft Purview Data Asset
• What Is a Microsoft Purview Data Product? — Data SkyLab Studio Definition