Turn data strategy into owned decisions, maintained evidence, and usable data products.

1. Start with the decisions and services the data must support

A data strategy should name the outcomes it supports before selecting architecture or governance tooling. For each important data domain, record:

• the operational, analytical, regulatory, research, or public-service decisions the data supports;
• the users and systems that depend on it;
• the timeliness and quality required for those uses;
• the consequences of inaccurate, unavailable, stale, or unauthorized data;
• the accountable owner who can accept tradeoffs.

This keeps quality and governance proportional. A dataset used for an executive dashboard, a statutory filing, a clinical decision, and an exploratory analysis should not automatically have the same assurance requirements.

2. Define decision rights, not just role names

Titles such as owner, steward, custodian, product manager, and architect are useful only when they map to decisions. Define who can:

• approve a data definition or authoritative-source designation;
• accept a known quality limitation;
• approve access or a new use;
• change retention or disposition rules;
• approve external sharing;
• change a schema or interface with downstream impact;
• declare a dataset or data product deprecated;
• accept an exception to the normal governance standard.

Escalation should follow consequence. The central governance body should not approve every column-level change, and a local team should not unilaterally accept a risk that affects enterprise reporting or another agency/business unit.

3. Maintain an inventory that helps people discover and trust data

The Federal Data Strategy's practices call for maintaining an inventory with enough completeness, quality, and metadata to support discovery, collaboration, documentation, provenance, and intended use within the federal context.^{Federal Data Strategy — Practices 16 and 19} The same operating principle is broadly useful.

Minimum useful inventory fields

• stable dataset/data-product identifier and human-readable name;
• business/domain owner and technical custodian;
• description and key definitions;
• authoritative/source-system status;
• classification and major access restrictions;
• update/freshness expectation;
• known quality limitations;
• lineage/source and major downstream consumers;
• schema/interface/documentation location;
• retention/disposition owner;
• support/contact and change-notification path.

Where interoperable web catalogs are useful, DCAT 3 can describe datasets, data services, distributions, versioning, and series using a standardized vocabulary that supports aggregation and federated discovery.^{W3C DCAT 3}

4. Separate classification, access, and permitted use

A data classification label does not answer every access question. Maintain at least three distinct decisions:

• Sensitivity/classification: what harm could follow disclosure, alteration, or loss?
• Access: which people, systems, roles, or partners can receive the data?
• Use: what purposes are permitted, prohibited, or require additional review?

Access controls should reflect real business roles and data use, not simply organization membership. For personal data, use a privacy-risk process appropriate to the organization. NIST's current Privacy Framework remains a voluntary risk-management tool; NIST's 1.1 update is still under development, so do not represent its initial public draft as a final standard.^{NIST Privacy Framework}

5. Define quality against intended use

Quality is not a single score. Define the dimensions that matter for each use case and the threshold at which the owner must decide whether to continue, correct, qualify, or stop the use.

For deeper operating controls, use Data Quality Assurance.

6. Govern the entire lifecycle, including retirement

Every material dataset or data product should have an explicit lifecycle:

1. purpose and collection/acquisition;
2. classification and initial quality checks;
3. storage and access;
4. transformation/integration;
5. publication or internal use;
6. change/version management;
7. retention, archival, deletion, or transfer;
8. deprecation/retirement of products and interfaces.

Do not keep data indefinitely because nobody owns deletion. Record the authority for retention/disposition, legal holds where applicable, operational need, and downstream dependencies that must be resolved before retirement.

7. Make lineage and change impact operational

Lineage should answer enough of the path to investigate a decision or change: source, transformation, major intermediate product, destination, and version. Avoid spending years building perfect field-level lineage if the organization cannot yet answer which dashboard or system consumes a changed dataset.

Change triggers that require downstream review

• schema or semantic definition changes;
• source-system replacement;
• material transformation/business-rule change;
• new external sharing or geography;
• classification or retention change;
• new machine-learning/automated-decision use;
• quality threshold breach;
• supplier/platform migration.

Keep a version/change record with the owner, reason, effective date, affected consumers, test/reconciliation evidence, and rollback/transition plan where appropriate.

8. Treat interoperability as a maintained contract

Interoperability depends on shared meaning and change discipline, not just APIs. Define stable identifiers, schemas, units, code sets, error behavior, versioning, compatibility policy, and ownership.

Use standards when they fit the domain. DCAT 3 is useful for interoperable catalogs; other domains may need healthcare, geospatial, financial, scientific, or sector-specific standards. The governance question is whether the organization can explain why a standard/profile was selected and how conformance/change is tested.

For implementation patterns, use Data Interoperability Engineering.

9. Put data sharing through a repeatable decision path

Before data is shared internally, externally, or across jurisdictions, document:

• purpose and recipient;
• data scope and classification;
• legal/contractual authority or permission where required;
• security and privacy controls;
• permitted/prohibited downstream use;
• retention/deletion expectations;
• quality/fitness limitations communicated to the recipient;
• revocation/change/incident process.

For cross-border personal-data transfers, use the dedicated Cross-Border Transfer Governance guide instead of treating ordinary data governance as a transfer-law checklist.

10. Maintain an applicability register instead of globalizing one jurisdiction's rules

Legal obligations should be attached to the organization, role, dataset, service, geography, and activity that actually triggers them. Examples:

• EU Data Act: assess whether the organization is acting in a covered role such as connected-product manufacturer, related-service provider, data holder/recipient, or data-processing service provider before applying specific obligations.^{Regulation (EU) 2023/2854}
• EU Data Governance Act: assess whether data-intermediation, protected public-sector data reuse, or recognized data-altruism provisions are actually in scope.^{Regulation (EU) 2022/868}
• Federal Data Strategy: treat its requirements/practices as federal-government guidance unless adopted voluntarily elsewhere.

For every applicable rule, record the source, owner, scoped obligation, implementation evidence, exceptions, review date, and trigger that forces reassessment.

Measure operating effectiveness, not catalog size

• important data domains with named accountable owners;
• critical datasets with current documentation and classification;
• material data products with defined quality expectations and issue owners;
• downstream consumers covered by change notification/testing;
• access/sharing decisions past review date;
• quality incidents repeated after corrective action;
• datasets with uncertain retention/disposition authority;
• time to identify source, owner, consumers, and limitations during an incident or audit.

30-day data operating-model reset

1. Week 1: select the highest-consequence data domains and define owners, decisions, and intended uses.
2. Week 2: build or clean the inventory, classification, documentation, and quality expectations.
3. Week 3: test one schema/change event and one access/sharing decision end to end.
4. Week 4: establish review cadence, applicability register, metrics, and remediation backlog.

Current sources

• Federal Data Strategy — Principles (federal scope)
• Federal Data Strategy — Practices (federal scope)
• W3C Recommendation — Data Catalog Vocabulary (DCAT) Version 3
• NIST Privacy Framework (voluntary; current page notes PF 1.1 development status)
• EU Data Act — Regulation (EU) 2023/2854
• EU Data Governance Act — Regulation (EU) 2022/868