Customer Data Governance for energy technology companies: Operating Cadence Playbook

Define the data system before defining the meeting

Energy technology companies often describe customer data as if it were one dataset. In practice, a customer account may be connected to sites, assets, meters, telemetry, service tickets, contracts, usage observations, forecasts, invoices and marketing interactions. Each domain has a different owner, update rhythm, quality risk and permission boundary.

Governance is therefore an operating system for decisions, not a quarterly meeting that approves a spreadsheet. The NIST data-governance glossary describes governance as processes that formally manage data assets and establish authority, management and decision-making parameters. It is a useful definition, not an energy-sector certification or a substitute for applicable law and engineering controls.

Start with a domain register. For each domain, record the business decision it supports, the authoritative source, the accountable owner, the steward, consumers, update frequency, quality checks, sensitivity, retention rule, known gaps and escalation route.

Separate the customer and operational domains

Use boundaries that reflect how the business works:

• Account and contact: organization, relationship, permission, role and communication history.
• Site and asset: location, equipment identity, configuration, service relationship and lifecycle.
• Meter and telemetry: readings, timestamps, units, quality flags, gaps and transformations.
• Commercial: contract, tariff or pricing context, invoice, forecast commitment and opportunity state.
• Service and incident: issue, severity, owner, response, resolution and post-incident correction.
• Marketing and research: source, campaign, consent, problem statement, evidence and next action.

Do not make the marketing system the authority for a site, an asset or a meter merely because it has a convenient field. Link domains with stable identifiers, record the source and preserve a clear “unknown” state when the match is not verified.

Assign authority and decision rights

Every domain needs one accountable owner, one or more stewards and a route for decisions that cross domains. The owner decides definitions, access, quality thresholds and acceptable use. The steward manages day-to-day checks and correction queues. Consumers document the decision they need and the evidence they require.

Write decision rights for common cases:

• who can create or merge an account;
• who can correct a site or asset identity;
• who approves a new telemetry transformation;
• who can change a customer segment or consent state;
• who decides whether a data gap blocks a commercial or operational action;
• who can authorize a temporary exception and when it expires.

Avoid “everyone owns data.” Shared responsibility without a final decision owner leaves defects in a queue until a forecast, renewal or incident exposes them.

Run a daily exception review

The daily review is for exceptions that could change today’s work. It should be short and operational:

• telemetry or meter records outside expected time or unit bounds;
• customer-to-site or site-to-asset links that fail validation;
• duplicate accounts or conflicting identifiers;
• missing consent or an access request nearing its deadline;
• service or incident records with no owner;
• a commercial action relying on a stale or unverified value.

Classify each exception as safe to correct, needs domain-owner decision, blocks the current action, or requires incident handling. Preserve the original value and the correction reason. A daily queue should not become a hidden place where analysts overwrite source data to make a dashboard green.

Run a weekly quality and lineage review

The weekly forum examines trends rather than individual tickets. Review completeness, timeliness, validity, uniqueness, consistency, lineage coverage, unresolved exceptions, correction age and downstream decisions affected. Show denominators and time windows; a quality percentage without population and rule version cannot be compared.

For a telemetry-derived metric, trace at least one value from source capture through transformation, storage, reporting and action. Record the source timestamp, unit, quality flag, transformation version, owner and consumer. If a value is estimated, label it as estimated and show the rule and period rather than silently presenting it as measured.

The NIST Information Quality Standards provide a useful prompt to discuss provenance, utility, objectivity and integrity; they do not certify telemetry accuracy.

For customer and contact privacy questions, use the NIST Privacy Framework as a vocabulary for identifying, governing, controlling, communicating and protecting risk. Apply it with the responsible privacy or legal owner; it does not decide the retention period or lawful use for a particular jurisdiction.

Run a monthly governance decision forum

The monthly forum makes changes that cross teams or systems. Typical decisions include a new domain definition, identifier rule, source-of-truth change, retention exception, enrichment source, model input, access role or customer-facing disclosure.

For each proposal, require:

1. the business decision and users affected;
2. current and proposed definition;
3. source and lineage impact;
4. data classification and access impact;
5. quality and operational risk;
6. implementation owner and test evidence;
7. effective date, version and communication plan;
8. rollback or restoration of the prior rule.

An approved change is not complete until the catalog, interfaces, dashboards, training and correction procedures use the same version. If only one report changes, the organization has a fork, not governance.

Keep OT, IT and commercial boundaries visible

Energy technology products may connect commercial applications to operational or device environments. Keep those boundaries explicit in the data register and access review. Marketing and analytics users should receive the least sensitive, least detailed data needed for their decision. An operational signal may be useful as an aggregated service indicator without exposing a control detail or live device identity.

The NIST Cybersecurity Framework is a context for organizing cybersecurity risk discussions; it is not a certification and does not replace an engineering or regulatory review. Use it to ask who identifies, protects, detects, responds and recovers when a data flow or access path changes. Escalate a suspected security or safety issue to the designated incident process rather than resolving it in a marketing-data meeting.

Run a quarterly model and retention review

Quarterly, review definitions that drift as products, sites, contracts or telemetry change. Retire unused fields, document breaking changes, recheck joins, inspect access logs and confirm that retention and deletion rules still match the purpose. Review whether a derived customer score is being used for a decision that its evidence cannot support.

Keep a decision and exception log with version, owner, evidence, affected domains, effective date, expiry and rollback. A temporary data exception should have an end date. If no owner can explain why it remains, close it or return it to the governance forum.

Use a controlled change and incident path

Not every bad record is a data-governance issue. A typo can use the normal correction queue. A broad identity mismatch, unexplained telemetry shift, unauthorized access or customer-impacting disclosure may require an incident path. Define the threshold, notification owner, evidence preservation and communication boundary in advance.

When a change causes a quality regression, freeze the new feed or transformation, preserve the affected version, notify consumers, restore the prior rule where safe, and publish the next recheck. Rollback should restore a known state; it should not erase the fact that the change occurred.

Use the Energy Customer Data Governance Cadence

Maintain one page with these fields:

• Domain: account, site, asset, meter, telemetry, commercial, service or marketing.
• Decision supported: what action depends on the data?
• Authority: accountable owner and steward.
• Source and lineage: where it originates and how it changes.
• Quality contract: checks, denominator, thresholds and unknown states.
• Access and purpose: who needs it, why and for how long.
• Rhythm: daily exception, weekly quality, monthly decision or quarterly review.
• Open risk: defect, privacy, security, operational or commercial impact.
• Release gate: test evidence, approval, communication and effective date.
• Rollback: prior definition, feed, transformation or access state.

The cadence is working when a customer, asset or telemetry question has an owner, a source and a correction path; when a new use is reviewed before it spreads; and when a dashboard can explain its lineage and uncertainty. Keep indexable: false until editorial, overlap, privacy, security, specialist and canonical reviews are complete. Governance earns trust through repeatable decisions, not the number of policies in the catalog.