Stewardship

Stewardship assigns a group as the owner of a data asset. The group is then responsible for the asset’s quality, maintenance, and managing who else can access it.

For instructions on how to assign, transfer, or override stewardship, see Assign Stewardship.

What stewardship is for

Stewardship answers a fundamental question in data governance: who is responsible for this asset?

Clear ownership enables:

Accountability: Someone is responsible for the asset’s quality, accuracy, and compliance. When issues arise, there’s no ambiguity about who should address them.
Decision authority: The owner group can make decisions about the asset: who gets access, what changes are appropriate, how long it’s retained.
Point of contact: Users know exactly who to ask about data meaning, quality concerns, or access requests.
Lifecycle management: Someone is responsible for keeping the asset accurate, updating it as requirements change, and retiring it when it’s no longer needed.

Without stewardship, assets become unmanaged. No one knows who to contact, access requests stall, quality degrades, and compliance becomes difficult to demonstrate.

How stewardship works

You assign stewardship to a group, not to individual users. When you assign stewardship:

The group becomes the owner of the asset, visible in the Stewardship widget.
The group receives full access to the asset (locked while stewardship is assigned).
Each member’s effective access depends on their governance role within the group.
Child assets can inherit stewardship from their parent. For example, catalog items inherit stewardship from their source.

This keeps ownership tied to teams rather than individuals, so responsibility doesn’t disappear when someone changes roles or leaves.

Asset owner vs. author

The person who creates an asset (the author) automatically receives access to it. But this doesn’t assign stewardship: the asset author isn’t automatically the asset owner.

Stewardship must be set separately. It’s possible (though not recommended) to have assets with no stewardship assigned, where only the author and explicitly shared users have access.

Stewardship inheritance

Stewardship flows down through asset hierarchies, reducing the need for manual assignment. When you assign stewardship to a parent asset, child assets inherit that ownership.

For example:

Assign stewardship of a source to the "Data Engineering" group.
All catalog items within that source automatically inherit the same stewardship.

Overriding inherited stewardship

You can override inherited stewardship on any child asset by assigning a different group. From that point down, the new stewardship applies.

Changes to parent stewardship don’t affect child assets that have been manually overridden.

For example:

A source is owned by "Data Engineering".
You assign a specific catalog item to "Finance Analytics".
That catalog item (and any of its child assets) is now owned by Finance Analytics.
Other catalog items in the source remain with Data Engineering.

Stewardship overrides

A stewardship override tailors who acts as steward on a single asset, without changing the stewardship group assigned to it. The asset keeps its stewardship group and the override only changes which people act in each governance role on that specific asset.

This is different from overriding inherited stewardship, where you assign a different group to a child asset. Stewardship overrides instead create a narrower or augmented set of stewards, who might or might not belong to the stewardship group.

Once you override stewardship, the original stewardship group stays assigned, and the Stewardship widget lists additional users and roles as the asset’s Data Owner and Data Consumer. Overridden roles are labeled in the Stewardship widget:

Modified: The role’s assignment differs from the group default. Future updates to the group no longer apply to this role.
Local: The role isn’t part of the group default and applies to this item only.

Roles whose assignment matches the group default aren’t labeled.

Use an override when:

Only some members of the steward group should govern a specific asset. For example, only certain data owners in the group should govern a sensitive table.
An asset needs additional people acting in a governance role, beyond what the group provides.
The stewardship group should keep ownership of the asset for visibility and reporting, while day-to-day stewardship is delegated to a smaller, named set of users.

If the same people should govern many assets in the same way, place a single override on the closest common ancestor and let inheritance propagate to assets downstream. Alternatively, consider creating a dedicated stewardship group whose membership you don’t need to alter for these assets.

Overriding a governance role replaces the group’s definition of that role on the asset: members who held the role through the group no longer act in it there. When you create the override, you choose the access level these members keep, the same way as when transferring stewardship. Members who remain part of the asset’s stewardship in another way — through a role that isn’t overridden, or because the override names them — aren’t affected.

If a user has access to the asset through multiple paths, they keep the highest level available. See Sharing Access to Assets.

Overrides and inheritance

Overrides follow the same rules as stewardship inheritance: child assets inherit the override together with the stewardship, and an override defined closer to the asset takes precedence.

One behavior is specific to overrides: if the stewardship an override depends on is removed or transferred to another group, the override is removed with it. After reorganizing stewardship, check the child assets for overrides you meant to keep.

Stewardship for custom entities

By default, stewardship is available for standard asset types. If you’ve created custom entities in the metadata model, you can enable stewardship for them by adding the core:hasStewardship trait in the metadata model.

Best practices for stewardship

Assign stewardship to all assets. Every asset should have a clear owner. This is foundational to data governance.
Set stewardship at the highest practical level. Use inheritance to reduce manual work. Assign ownership to sources or locations, and override at lower levels only when needed.
Use groups, not workarounds. If you need specific people to own an asset, create a group for them rather than relying on direct sharing. For the same reason, prefer creating appropriate groups over stewardship overrides.
Document why a stewardship override exists. Overrides apply at a single asset and are easy to overlook during audits.
Review assets without stewardship regularly. Assets without stewardship assigned lack clear ownership. Periodically check for and assign stewardship to these assets.

For guidance on how stewardship fits into different organizational models, see Access Management Models.

Was this page useful?