Dashboard governance: owners, certification tiers, and retirement

Reference article · 6 min read

Most agencies reach a point where the problem is not too few dashboards but too many that disagree. A program manager cites one caseload figure in a budget hearing, a deputy director cites a different one from a dashboard a departed staffer built, and nobody can explain the gap. The underlying data is often fine. What is missing is a way to tell, at a glance, which views the agency stands behind and which are somebody's working sketch.

Dashboard governance fixes that with labeling and accountability rather than restriction. Staff keep the freedom to build quick exploratory views. The agency reserves a separate, visibly marked tier for products it will defend in public. The scheme below is deliberately small: two tiers, a named owner, a short metadata block, a periodic review, and a retirement path. One analyst can run it with a shared spreadsheet, and it does not require buying anything.

Two tiers: certified and exploratory

Draw one bright line and resist the temptation to add more. Three and four tier schemes collapse because nobody remembers what the middle ones mean.

• Certified. The agency stands behind these numbers. Staff may cite them in briefings, budget documents, public meetings, legislative responses, and records requests. Each has a named owner, documented definitions, a stated refresh schedule, and a passed review.
• Exploratory. Everything else: prototypes, ad hoc analyses, personal views, work in progress. Useful and encouraged, but not quotable outside the team that built it.

Make the tier visible on the dashboard itself, not just in a catalog. A badge in the header travels with a screenshot; a catalog entry does not. Certification is about the published product, not the person who built it, so a dashboard by a senior analyst is exploratory until it has been through review.

What a named owner actually owes

Ownership means a person, not a division. Titles change and mailboxes go unread, so record both the individual and the role so the entry survives turnover.

The business owner is accountable for whether the numbers mean what the labels say. That person approves definition changes, answers questions from staff who cite the dashboard, confirms the refresh schedule is being met, and decides when the dashboard should be retired. A technical steward, often in IT or a central analytics unit, handles the pipeline, permissions, and outages. Both names belong in the catalog. When an owner leaves, reassignment is part of the offboarding checklist, and any certified dashboard left without an owner drops to exploratory automatically.

The metadata every certified dashboard carries

Require a short, standard block on or one click from the dashboard face:

• Last updated. A timestamp of the data, not the page load. Distinguish the data-through date from the refresh time when they differ, because a page that refreshed this morning may still be showing last month's extract.
• Refresh schedule. How often the data is expected to update, and what happens when a load fails. A visible staleness warning after a missed cycle prevents the worst failure mode, which is a dashboard that quietly stops updating while still looking current.
• Definitions. Plain language for every metric: what is counted, what is excluded, the date field used, and the population. Most disputes between two dashboards are definition disputes, not data disputes.
• Source systems. Which systems of record feed it, so readers know where corrections must be made.
• Owner and steward. Names and contact points.
• Known limitations. Lag in reporting, backfilled records, jurisdictions not yet included, suppression rules for small counts.

Where a dashboard displays information about individuals, confirm with your privacy officer and counsel how public records, health privacy, education privacy, and criminal justice information rules apply to the specific fields shown. Those requirements vary by state and program and change over time.

Certification review

Keep the review short enough that people actually request it. A reviewer independent of the builder should confirm: definitions are written and match the query logic; at least one figure reconciles to the system of record or an official published count; the refresh actually runs on schedule; access permissions match the sensitivity of the data; and the page states its limitations. Record the outcome, the date, and the reviewer.

Recertify on a set cadence, commonly annual, and immediately after any change to a definition, a source system, or a filter that affects published numbers. Treat definition changes like code changes: note what changed and when, so someone comparing an old briefing to today's screen can explain the difference.

Reviewing and retiring stale dashboards

Retirement is the step agencies skip, and it is the reason catalogs fill with contradictions. Build a scheduled sweep, quarterly or semiannual, that surfaces dashboards with no owner, no view activity over the period, a failed or missed refresh, or a passed recertification date.

For each, the owner chooses one of four outcomes: keep as certified, drop to exploratory, archive, or delete. Archiving should freeze the content and keep it readable for the retention period your schedule requires, since a dashboard used to support a public statement may itself be a record. Announce retirements before they happen, leave a landing note pointing to the replacement, and keep decommissioned links from resolving to a blank page.

How to start, and what to ask of vendors

1. Inventory what exists, including spreadsheets circulated by email.
2. Certify a handful of dashboards leadership already relies on, rather than the whole inventory.
3. Publish the tier definitions and the citation rule in writing.
4. Run the first retirement sweep, and keep it on the calendar.

When buying or renewing an analytics platform, ask how the tool stores owner, definition, and certification fields; whether a certification badge and data-through timestamp can be enforced on every page rather than added by hand; whether failed refreshes raise an alert; whether usage metrics are available per dashboard; and whether the catalog and definitions can be exported in an open format. In the contract, require export of metadata and definitions at termination, alerting on refresh failure, and cooperation with your retention schedule. Ask for these in a demonstration on your own data rather than in a written response.

HQT works with state and local agencies on data and analytics programs, including catalog, definition, and dashboard lifecycle practices.

Frequently asked questions