Data Quality and Governance Role SOP and Operating Playbook

How to use this playbook

Use this model to run a bounded data quality and governance cycle for one important data asset. Start with a business use, name the people who can decide, test what the data must do, record defects, coordinate a fix, and close only after an independent retest. The model is based on a structured sample of 100 current United States vacancies and a separate review of product changes published from July to September 2026. It is an example to adapt to your employer's approved systems and policies, not a universal employer procedure or legal rule.

The day-to-day role here is an operational data quality and governance practitioner. A practitioner can prepare definitions, checks, findings, recommendations and follow-up records. An accountable business owner or a delegated forum makes decisions about acceptable use, priorities and exceptions. Privacy, security, legal and other specialist decisions belong to the people formally assigned those responsibilities in the organization. A junior practitioner should make the work visible and ask for the right decision, rather than assume approval authority.

Purpose, scope and successful result

The purpose is to keep a named dataset fit for one authorized use. The procedure begins when a new asset is requested, a quality monitor alerts, a user reports a defect, a source or rule changes, or a regular review becomes due. It ends when the owner accepts a documented result, affected users know what changed, monitoring is in place, and records are complete. A genuinely unresolved risk may be closed only as an explicitly approved exception with a review date and named owner.

Define the scope before touching records:

• Asset and use: the dataset, critical fields, consumers and decision or process it supports.
• Boundary: source systems, transformations, downstream products and known gaps. A catalog or lineage graph is a starting view; confirm coverage against a real pipeline or change.
• Population: which records the rule applies to, including filters and effective date. A result for active records is not a result for all historical records.
• Local controls: approved access, classification, retention, severity levels, thresholds, review frequency, notification channel and system of record. Complete these from the employer's policy owner.
• Success: a testable rule or accepted issue outcome, a responsible owner, reproducible evidence and a consumer-facing status that does not overstate reliability.

Do not copy identifiable customer, employee or patient records into a general issue ticket or an external AI service. Use permitted samples, masked values or aggregate counts according to local policy. If the work involves regulated data, route interpretation and approval to the relevant specialist rather than turning this model into jurisdiction-specific advice.

People, inputs and decision rights

The business data owner is accountable for the meaning and acceptable use of the asset, its priority, the risk of an exception and the final business decision. The working data steward maintains definitions, coordinates checks and issues, and brings choices to the owner. A data engineer or system custodian explains physical flows, implements approved technical changes and supplies logs or test results. A data consumer explains how a defect affects a decision and confirms whether a repaired output works for that use. A privacy, security, legal or risk specialist decides matters within that specialist's delegated remit. The governance forum resolves cross-domain ownership, definition or priority disputes when local rules assign those decisions to it.

Before work begins, request the minimum authorized inputs:

• Business question, expected output and critical data elements.
• Current owner and steward register, with an escalation route if a name is missing or contested.
• Business glossary or definition, catalog record and available source-to-consumer map.
• Existing quality rules, thresholds, observed results, exceptions and open issue history.
• A permitted query, sample or summary that can reproduce the concern without unnecessary sensitive data.
• Change request, incident report, monitoring alert or review schedule that triggered the work.
• Relevant local policies and the approved tool or record locations.

Mark a missing input as unknown. Do not fill a gap by guessing which system is authoritative, who owns the data, or what threshold is acceptable. An analyst may propose options and test them, but the named owner or delegated decision maker approves business definitions, thresholds and exceptions. Technical implementation follows the organization's change-control route. Access decisions and permissions require their separate specialist or owner approval and a readback that the permission actually took effect.

From trigger to verified closure

Use one issue or work item for each bounded change. Keep the steps in this order; a routine review may end after documentation and rule confirmation if no defect is found.

1. Register the trigger. Record the asset, requester, time, affected use, observed symptom and where the original evidence can be found. Assign a steward or triage lead. State whether this is a new asset, recurring review, quality alert, user report or source change. Avoid putting sensitive row values in the general ticket.
2. Confirm the business use and boundary. Ask the consumer what decision or process is affected and which fields matter. Identify the relevant source, transformations, downstream reports and any unobserved segments. Record the population, filter, time window and current lineage gaps before interpreting a metric.
3. Confirm ownership and permitted work. Read the owner/steward register and local severity rules. If the owner is missing or disputed, record the conflict and send it to the authorized decision route. Check that the proposed sample, query and collaboration tools are approved for the data classification.
4. Measure the problem. Run or request a reproducible profile, reconciliation or validation test. Record rule name, version, population, threshold, frequency, result, query or method, run time and evidence location. Distinguish a true defect from a rule that was applied to the wrong population, a stale extract or a temporary source delay.
5. Document meaning and movement. Check the business definition, catalog entry and source-to-consumer lineage against the actual path. Add missing definitions or lineage steps as proposed changes. If automated metadata or tags were imported, inspect coverage, unsupported assets and false classifications before accepting them as accurate.
6. Assess impact and route the decision. Describe affected users, records or outputs in aggregate, the decision that could be wrong, the likely cause, the confidence of that cause and the next action. The steward recommends severity and options; the owner or delegated forum accepts the business priority and any temporary exception. Route privacy, security, legal or regulated-data questions to specialists.
7. Coordinate an approved fix. Assign the engineer or custodian to correct the source, transformation, rule or mapping through the local change process. Record who approved the change, what is being changed, expected downstream effects, rollback or recovery approach, and communication needed. Do not silently alter a rule threshold to make an alert disappear.
8. Retest and check downstream use. Repeat the original test on the same defined population and a sensible control sample. Compare before and after counts, examine unintended effects, verify affected reports or data products, and update lineage or catalog records. A platform-generated root-cause suggestion can inform investigation but is not closure evidence until confirmed against source facts.
9. Close or carry an approved exception. Record the actual cause, fix or temporary control, test result, residual risk, owner decision, consumer confirmation where needed, and follow-up date. Notify affected teams in plain language. If the fix is incomplete, leave the issue open or record an approved exception with a named owner and review date. Update the scorecard and link to the change and decision records.

Work rhythm

The rhythm below is a useful starting pattern. Set actual times, service levels and responsible people from local policy and the criticality of the asset.

Daily or each operating day

• Review new quality alerts and user reports; check whether the monitor actually covered the expected assets and population.
• Triage items that could affect a current business decision, assign a steward and route urgent risk through the local escalation path.
• Follow up on open fixes and capture evidence of any changed source, rule, filter or permission state.

Weekly

• Review the issue queue with owners, stewards and implementers; remove duplicates, update status, aging, blockers and next actions.
• Inspect the quality scorecard for critical assets: rule coverage, failed checks, repeat defects, unresolved high-impact issues and time to verified closure.
• Check a sample of changed glossary terms, catalog records and lineage links against actual source behavior.

Monthly or the locally approved review period

• Review the owner/steward register, critical data elements, definitions, thresholds, issue trends and exceptions with the business owner.
• Ask whether an accepted exception is still needed and whether its compensating control worked.
• Record governance forum decisions, policy changes, training needs and improvements to the workflow. Report only results backed by defined populations and methods.

When an event occurs

• A new data product, migration, source change, major rule change, access request or policy update triggers an impact review before release or acceptance.
• Confirm source-to-consumer lineage, data contracts or mappings, rule scope, owner, approval route and rollback plan. Recheck after the change has reached the consuming system.

Handoffs, escalation and exceptions

An exception needs more than an accepted label. Record the affected asset and use, specific rule or control, reason, evidence, risk owner, permitted period, interim control, approval, consumer notice and retest date. A change in source, consumer, population or risk may require a new decision. Never use an exception to hide an unresolved defect from a decision maker.

Records and useful quality measures

Keep a small, linked record set in approved systems rather than copying the same facts into many files:

• Asset record: owner, steward, purpose, critical fields, classification, permitted use, source systems and known lineage gaps.
• Rule record: business question, definition, population/filter, calculation, threshold, frequency, version, effective date and approving owner.
• Issue record: trigger, severity, impact, evidence link, status, assignee, decision, fix, retest and communication.
• Decision and change record: alternatives, approver, reason, residual risk, affected assets, release and rollback references.
• Scorecard: the results and coverage of defined rules over time, with explicit denominator and any monitoring blind spots.

Measures can include the share of critical elements with an approved definition and owner; the share of critical rules actually running on the intended population; pass rate for a stated rule and time window; number and age of unresolved material issues; repeat defects after closure; and proportion of changes whose downstream impact was checked. Choose measures that lead to a decision. Report both numerator and denominator, and show when the monitored population or rule changed. A lower incident count can mean improvement, reduced coverage or suppressed alerts; check the cause before celebrating it.

Automation may help discover assets, propose lineage, apply governed tags or group quality failures in a queue. Record the product, configuration, supported asset types, edition or region limits, and whether a feature is generally available, preview or beta before promising it in an SOP. Keep a human owner for rule approval, impact, exception and closure. Use the organization's approved current tool guidance for changing product details rather than relying on an old model or dashboard behavior.

Reusable blank SOP model

Copy this model into the employer's approved document or workflow. Use the guidance below, then fill the empty cells with authorized local facts. A blank cell is not an assumed default or an approval.

• Asset and authorized business use: name the dataset, critical fields, consumer and supported decision.
• Boundaries and lineage: list sources, transformations, outputs and known coverage gaps.
• Owner, steward and forum: enter approved roles or names, decision rights and escalation contact.
• Specialist approvals: identify the local privacy, security, legal, risk or domain route; write “not required” only after checking.
• Classification and permitted evidence: state approved access, safe sample method, ticket location and handling rule.
• Trigger and intake channel: name alerts, user reports, change events and review schedule.
• Quality rule: record purpose, population/filter, calculation, threshold, frequency, version, effective date and owner approval.
• Severity and response: enter local severity definitions, response times, notification route and interim controls.
• Implementation and change control: enter implementer, approval route, test environment and recovery method.
• Closure: define retest, downstream check, consumer confirmation and owner sign-off.
• Records and measures: link catalog, rule, issue, decision, change and scorecard records with denominators.
• Review cycle: enter the employer-approved daily, weekly, monthly or event-driven cadence and SOP owner.

Use this compact work-item form with the model:

1. Trigger and impact: record what happened, when, to which asset, and which decision could be affected.
2. Evidence and scope: record the rule result, population, time window, safe evidence location and lineage coverage.
3. Decision route: name the owner, specialist if needed, proposed options and approval recorded.
4. Fix and retest: link the approved change, before/after result, downstream check and consumer response.
5. Closure or exception: record status, residual risk, approver, communication and next review date.

Quick check before use

• Is the asset, business use, population and owner explicit?
• Can another authorized colleague rerun the check from the recorded method and safe evidence?
• Are metadata and lineage statements tested against the actual path, with gaps visible?
• Does the issue record show who may decide, who implements, who retests and who receives the result?
• Are approvals and exceptions tied to local policy rather than assumed from this example?
• Does the closure prove both the rule result and the effect on the consuming decision?

This model draws its role tasks and boundaries from MTF Institute's 2026 U.S. vacancy study and uses the separate current-changes review to frame automation and coverage checks. The vacancy study is a purposive point-in-time sample; neither source establishes a universal employer policy or a national adoption rate.