Give every important data decision an owner, evidence, and escalation path.

1. Define stewardship by decisions, not titles

A stewardship role is useful only if the holder can make or coordinate a defined set of decisions. For every major domain, assign decision rights for:

• authoritative definitions and reference values;
• source-of-record designation;
• quality expectations and accepted limitations;
• access and permitted-use decisions;
• classification and handling changes;
• schema/semantic changes with downstream impact;
• retention, archival, and retirement;
• issue escalation and exception acceptance.

Write those rights into a short stewardship charter. Avoid a model where the "steward" is accountable for quality but cannot change a source system, challenge a business definition, or escalate a broken control.

2. Separate accountability, stewardship, and custody

Small organizations can combine roles; they should not combine accountability so completely that nobody can independently challenge a decision.

3. Steward definitions as controlled assets

Many data conflicts are semantic, not technical. Maintain definitions for critical concepts, measures, code sets, identifiers, calculation rules, and time periods. Each important definition should have:

• a plain-language meaning;
• owner/steward;
• effective date and version;
• included/excluded cases;
• source/system implementation;
• known exceptions;
• downstream consumers or reports affected by change.

When two valid definitions exist for different purposes, preserve that distinction rather than forcing a false enterprise-wide definition. Label context explicitly.

4. Keep stewardship visible in the catalog and documentation

The Federal Data Strategy calls for inventorying data assets and maintaining current documentation within federal agencies.^{Federal Data Strategy Practices 16 and 19} A broadly useful stewardship pattern is to make owner, steward, definition, restrictions, quality status, source, and change path discoverable wherever users discover the data.

DCAT 3 can support interoperable descriptions of catalogs, datasets, data services, distributions, and versions when its RDF model is appropriate.^{W3C DCAT 3} Whether or not DCAT is used, metadata should be sufficient for a consumer to identify the responsible human and understand the data's intended context.

5. Steward access and use as separate decisions

Someone being technically able to query a dataset does not prove every use is appropriate. Maintain a repeatable path for access and new-use decisions:

1. identify requester, purpose, and recipient system;
2. confirm classification and applicable restrictions;
3. evaluate minimum data needed;
4. define duration and review date;
5. record any use limitations;
6. implement access through technical controls;
7. review materially changed use, audience, geography, or data scope.

For personal data, connect the stewardship process to the organization's privacy-risk process. NIST's Privacy Framework is a voluntary tool for managing privacy risk and can be used alongside other enterprise risk frameworks.^{NIST Privacy Framework}

6. Make quality ownership specific

Stewards should not "own data quality" as a vague aspiration. For each critical data product, record:

• quality dimensions that matter to intended use;
• threshold/expectation and measurement method;
• source control or process that prevents/detects failure;
• technical/business owner responsible for remediation;
• consumer communication when limitations are material;
• exception acceptance authority and expiry date.

The steward coordinates definitions and consequences; engineering or business process owners may perform the actual correction.

7. Operate a data-issue lifecycle

Use an issue record that distinguishes symptom, cause, consequence, affected consumers, immediate containment, corrective action, owner, due date, and validation evidence. Prioritize by consequence rather than the number of bad rows alone.

Escalate when

• a critical decision/report is materially affected;
• personal/sensitive data may be mishandled;
• the same defect repeatedly returns;
• the owner cannot remediate within the acceptable window;
• two domains cannot agree on an authoritative definition;
• a consumer needs to knowingly operate with a material limitation.

8. Govern semantic and structural change

Stewardship is especially valuable when data changes. Require impact review for changed definitions, schemas, source systems, classifications, interfaces, key transformations, retention rules, and external-sharing arrangements.

The change record should state what changed, why, effective date, affected consumers, compatibility/migration approach, testing or reconciliation evidence, and who approved the risk. Notify consumers early enough to adapt instead of discovering a breaking change after deployment.

9. Use governance forums only for decisions that need them

• Weekly/domain: material quality issues, access decisions, upcoming changes, unresolved definitions.
• Monthly/cross-domain: shared definitions, interoperability dependencies, overdue remediation, high-impact exceptions.
• Quarterly/executive: systemic risks, investment decisions, unresolved ownership, major policy changes, stewardship effectiveness.

Do not spend governance meetings reviewing dashboards with no decision. Every agenda item should have an owner, requested decision, or clear escalation purpose.

10. Keep a minimum stewardship evidence pack

A mature stewardship program should be reconstructable from evidence, not dependent on one steward remembering why a decision was made. For every critical domain, keep a compact evidence pack that links the domain charter, named owner and steward, controlled definitions, authoritative sources, access and use restrictions, quality expectations, major consumers, open exceptions, and recent material changes. The objective is not paperwork for its own sake; it is to make accountability visible when a system changes, an incident occurs, an auditor asks how a value was governed, or a new team inherits the data product.

Sample the evidence periodically. Pick one important definition and verify that its catalog entry, source implementation, downstream report, and change history agree. Pick one access decision and confirm the recorded purpose still matches the active entitlement. Pick one quality exception and confirm it has an owner, expiry, consumer impact, and closure evidence. If the organization cannot reconstruct these decisions without interviewing several people, stewardship is still too dependent on institutional memory.

Retain decision evidence in the systems teams already use where practical. A ticket, catalog record, approval workflow, repository change, or controlled register can all be valid evidence if ownership, date, rationale, scope, and outcome are preserved and searchable.

Measure stewardship effectiveness

• critical datasets with named owner/steward and current documentation;
• material definitions with controlled versions;
• quality/access exceptions past expiry;
• data issues without an accountable remediation owner;
• breaking changes communicated before implementation;
• repeat issues caused by the same uncorrected process;
• time to identify owner, source, limitation, and affected consumers during an incident.

30-day stewardship reset

1. Week 1: choose the highest-consequence domains and document decision rights.
2. Week 2: attach owners/stewards, definitions, restrictions, and quality expectations to the inventory.
3. Week 3: run one access decision, one quality issue, and one schema/definition change through the operating process.
4. Week 4: fix unclear authority, establish cadence, and publish an exception/issue aging view.

Current sources

• Federal Data Strategy — Principles (federal scope)
• Federal Data Strategy — Practices (federal scope)
• W3C Recommendation — DCAT Version 3
• NIST Privacy Framework