Setting up a data governance program in a public agency

Reference article · 5 min read

Most data governance programs in public agencies start under pressure. An audit finding says the agency cannot show who authorized access to a system of record. A spreadsheet of resident information goes to the wrong recipient. An analytics project stalls because two departments report different counts for the same population and nobody has standing to say which is correct. In each case, decisions about data are being made, but not by anyone in particular, and not in writing.

Governance is the practice of writing those decisions down and attaching them to named people. It is not a software purchase, and in an agency of modest size it does not require new positions. What follows is a sequence an IT director or program manager can run with existing staff.

What the program actually consists of

• An executive sponsor. A department head, CIO, or assistant administrator with authority to settle disputes between departments. Without one, stewards get overruled by whoever objects loudest.
• A short charter. Two or three pages: scope, who decides what, meeting cadence, and how a disagreement escalates.
• Named data stewards. One accountable person, plus an alternate, for each data domain.
• A classification scheme. A few levels, each with concrete handling rules.
• A documented access request path. How someone asks for data, who approves, and what gets recorded.
• An inventory. A running list of the systems and datasets the agency holds, useful even while incomplete.

None of these are technical deliverables. A catalog populated without owners is a list, not governance.

Write the charter first, and keep it short

A charter that runs long gets read once. It should answer a few questions plainly: what is in scope (start with systems of record, not every shared drive), who sits on the governance group, what the group decides as opposed to recommends, and how an unresolved question reaches the sponsor. Adopt it by administrative memo or directive rather than waiting for board action, unless local policy requires one. Version it and revisit it annually.

Name stewards by domain, not by job title

A common failure is assigning stewardship to "IT" or to a title such as systems administrator. Domains cross systems and survive reorganizations; titles do not. Define domains by subject matter, then name the person who knows the subject best: personnel and payroll, finance and procurement, client and case records, permitting and land records, public safety records, assets and infrastructure, geographic base data.

Stewards usually come from the program side rather than IT, because the steward is the person who knows what a field means, what it may lawfully be used for, and who should not see it. The duty is a share of an existing job and belongs in the position description so it survives turnover. A steward approves or denies access in the domain, designates the authoritative source when systems disagree, maintains key definitions, and raises quality and retention problems.

Classify data with as few levels as you can defend

Three or four levels is usually enough: public, internal, confidential, restricted. For each, write down examples, who may approve access, where the data may be stored, how it may be shared, and how it is destroyed. Anchor the levels to obligations the agency already carries: state public records law, privacy and breach notification statutes, criminal justice information, protected health information, student records, federal tax information. Agencies often hold several at once, and the strictest applicable rule governs. Requirements change, so confirm current text with the official source or counsel.

Classify systems before records. Assigning a level to every system of record is achievable in a few working sessions. Assigning one to every field may never pay for itself.

Make the access path boring and written down

Pick one path, a form or a ticket type, and require the same elements every time: requester, dataset, purpose, legal basis where one applies, duration, and the steward's approval. Log approvals where an auditor can find them, and review access on a schedule so it ends when a role changes. Define a standing path for routine repeated access so the process does not become a bottleneck staff route around. A process people avoid is worse than none, because it produces a record suggesting control that does not exist.

What to ask vendors and require in the contract

Vendors shape governance whether or not they sell governance software. Ask during evaluation:

• Which classification levels can the system enforce, and how are roles and permissions documented?
• Can it produce an access report showing who holds which permission, and an audit log of access to sensitive records?
• Can the agency extract all of its data, in a documented format, on demand and at termination?
• Where is data stored and processed, and which subcontractors handle it?
• Can retention and deletion be configured to match the agency's records schedule?

In the contract, require agency ownership of agency data, confidentiality and handling terms, breach notification within a defined period, limits on vendor use of agency data including for product improvement or model training, flow-down to subcontractors, and certified deletion at termination.

A starting sequence

1. Secure the sponsor. One conversation and one memo.
2. Draft the charter and circulate it to department heads for comment.
3. List systems of record: name, purpose, department, vendor, one line each.
4. Name a steward and an alternate for each domain, in writing.
5. Adopt classification levels and assign one to each system.
6. Publish the access request path and begin logging approvals.
7. Meet on a set cadence, record decisions, and reopen the inventory each time.

The first cycle is uncomfortable because it surfaces disagreements that were previously avoided. That is the point. HQT works with state and local agencies on data management and analytics, including the inventory and classification work a governance program depends on.

Frequently asked questions