Utility and Grid Technology Checklist: Metering and Usage Data Rights, Vendor and Firmware Terms, Interconnection and Standards Exposure, Critical Infrastructure Obligations, and Customer Data Handling

By Casey Scott McKay · 2023-09-15

A ten-phase working checklist for utility and grid technology matters, usable by a utility, a technology vendor, or a distributed energy business. Phases one to three cover the data inventory, the state-by-state access matrix, and the contracts governing each flow. Phases four to six cover the firmware position, the patching obligation, and the remaining vendor terms that have to survive a thirty-year asset life. Phase seven covers interconnection, certification, and market participation. Phase eight covers critical infrastructure obligations and the vendor flow-down that carries them. Phases nine and ten cover regulated procurement and the intellectual property strategy that suits the sector. Each phase ends with a gate.

IP and Technology > Information Technology | Checklist | Published 15 September 2023 - Updated 10 September 2024 | Casey Scott McKay - marksy.us

How to use this checklist

Three things make this sector different from ordinary technology practice, and every item below follows from one of them.

The asset outlives the vendor. The regulatory obligations reach vendors through contract rather than directly. And the customer data question is answered by a state utility commission rather than by privacy law.

Ten phases, each ending with a gate. Establish first which client is in the chair — a regulated utility, a technology vendor, or a distributed energy or data business — because the emphasis differs sharply, and whether any utility counterparty is investor-owned, municipal, or cooperative.

Use alongside Advising a Utility or Grid Technology Business and Keeping the Lights On. Templates sit in the Utilities and Grid Technology IP Toolkit.

Phase 1 — Data inventory

Streams

[ ] Interval consumption at the meter, with resolution and retention recorded.
[ ] Voltage, current, and power quality measurements.
[ ] Outage, restoration, and tamper events.
[ ] Device status, diagnostics, and health telemetry.
[ ] Distributed resource output, state of charge, and dispatch records.
[ ] Electric vehicle charging sessions, including location and duration.
[ ] Demand response enrolment, dispatch, and performance records.
[ ] Customer account, premises, and billing information.
[ ] Vendor-collected telemetry from installed equipment.
[ ] Field workforce data, including location and work order records.

Flows

[ ] Map each stream from device to collector to head-end to meter data management to billing.
[ ] Identify every copy: analytics platform, data warehouse, business intelligence tool, vendor cloud environment, and any research or pilot extract.
[ ] Identify every party with access, including vendor support personnel with remote access.
[ ] Identify cross-border transfers and the destinations.
[ ] Identify retention settings per system and confirm they match policy.
[ ] Identify the legal basis for each flow, and flag every flow with none.
[ ] Flag vendor telemetry configured by default and never reviewed, which is the most common finding.

Sensitivity

[ ] Record what each stream reveals at its actual resolution — occupancy, absence, behaviour, appliance-level activity — rather than what it is called.
[ ] Identify any stream capable of appliance disaggregation.
[ ] Identify any stream that reveals location or movement.
[ ] Assess re-identification risk on any dataset described as anonymised, independently of any regulatory aggregation threshold.
[ ] Confirm aggregation thresholds are applied to the specific query, not to the dataset as a whole, so a small-cell query cannot defeat them.

Gate 1. Every stream is mapped end to end with resolution, retention, access list, and legal basis recorded; flows with no basis are flagged; and sensitivity is assessed on what the data reveals rather than on its label.

Phase 2 — State access matrix

[ ] List every jurisdiction in which the client operates or intends to.
[ ] For each, record whether a customer energy usage data access rule exists.
[ ] Record the required authorisation form, duration, and revocation mechanism.
[ ] Record what data must be provided, in what format, and on what timescale.
[ ] Record whether a standard format such as Green Button is mandated or merely available.
[ ] Record what fees the utility may charge a third party for access.
[ ] Record restrictions on secondary use and onward transfer.
[ ] Record the aggregation thresholds applicable to non-consented disclosure.
[ ] Record deletion obligations on termination of the authorisation.
[ ] Record how the state's comprehensive privacy statute treats regulated utilities, including any exemption.
[ ] Record any separate rule governing utility affiliate access.
[ ] Record the commission's complaint or dispute mechanism for access disputes.
[ ] Identify the strictest standard in the matrix and adopt it as the product baseline where the client operates nationally.
[ ] Diary the pending dockets that will change any of the above.
[ ] Confirm no product decision assumes a single national compliance model.

Gate 2. A state matrix exists covering every operating jurisdiction, the strictest standard is the product baseline, and pending regulatory changes are diarised.

Phase 3 — Data contracts and consent architecture

Customer-facing

[ ] Confirm the authorisation language matches the strictest applicable state requirement.
[ ] Confirm the customer is told what data, to whom, for what purpose, for how long.
[ ] Confirm revocation is available, simple, and effective within a stated period.
[ ] Confirm what happens to data already transferred on revocation.
[ ] Confirm the consent record captures what the customer saw, when, and what they agreed.
[ ] Confirm the record can be produced to a commission.
[ ] Confirm nothing in the customer terms conflicts with the approved tariff, which governs.

Vendor terms

[ ] Purpose limitation, stated narrowly.
[ ] Prohibition on secondary use, including product improvement, absent express grant.
[ ] Security requirements, expressed as controls rather than as a general standard.
[ ] Subcontractor approval and flow-down.
[ ] Breach notification with a defined clock measured in hours.
[ ] Audit rights, exercisable and used.
[ ] Return or deletion on termination, with certification.
[ ] Express allocation of ownership in models and derived outputs.
[ ] Express treatment of aggregated and de-identified derivatives.

Third parties and aggregators

[ ] Terms mirroring the commission's conditions on the authorised third party.
[ ] Indemnity for breach of those conditions.
[ ] Mechanism to terminate access immediately on revocation.
[ ] For aggregators, terms addressing device control authority, market obligations, and customer churn.
[ ] For research access, a written agreement rather than informal provision.
[ ] Cross-refer to the Data Licensing Checklist for derived data and exit terms.

Law enforcement and legal process

[ ] Establish a documented response process for subpoenas and warrants.
[ ] Record the position on whether granular interval data warrants a higher standard, noting Carpenter v. United States against the third-party analysis of Smith v. Maryland.
[ ] Establish who decides, and confirm it is not the person at the counter.
[ ] Establish customer notification practice where lawful.

Gate 3. Consent architecture satisfies the strictest applicable rule and is provable; vendor and third-party terms carry purpose limits, security controls, and exit obligations; and legal process has a documented route.

Phase 4 — Firmware position

Establish the baseline

[ ] Record the expected service life of the deployed asset.
[ ] Record the vendor's standard support horizon and compare the two.
[ ] Record whether the device verifies firmware signatures, since it determines what an escrow must contain.
[ ] Record whether firmware changes require recertification, and against which standard.

Escrow

[ ] Confirm an escrow exists and that the deposit is current.
[ ] Confirm the deposit includes source, build scripts, toolchain versions, dependency manifests, configuration, test suites, and documentation.
[ ] Confirm the deposit includes signing keys or a mechanism to produce signed images.
[ ] Confirm independent verification that the deposit builds into the shipping binary, on a stated frequency.
[ ] Confirm who pays for verification and what happens on failure.
[ ] Confirm release triggers cover abandonment, not only insolvency: end-of-life notice, failure to remedy a critical vulnerability within a stated period, failure to correct a severity-one defect after escalation, and material support breach.
[ ] Confirm each trigger has an objective test and a cure period.
[ ] Confirm the release mechanism is executable without the vendor's cooperation.

Maintenance licence

[ ] Confirm the licence is granted now, conditioned on the trigger, rather than promised for later.
[ ] Confirm the scope: maintenance, defect correction, and security modification only.
[ ] Confirm no right to distribute and no right to build a competing product.
[ ] Confirm use by the utility or a nominated third party under equivalent confidentiality.
[ ] Confirm the term runs for the life of the deployed assets.
[ ] Confirm recertification responsibility and cost are allocated for any permitted modification.
[ ] Confirm which classes of change trigger recertification.

Gate 4. The escrow is complete, verified, and releasable on realistic triggers; the maintenance licence is granted rather than promised; and recertification is allocated so the licence is usable.

Phase 5 — Patching and vulnerability management

[ ] Express remediation obligations by severity and time, not by reference to an amendable support policy.
[ ] Tie severity to an external scale with an escalation route on disagreement.
[ ] Set a maximum window for critical vulnerabilities, measured in days.
[ ] Require interim mitigations where a fix is not immediately available.
[ ] Extend the obligation across the full deployed life, or specify what happens beyond the support horizon.
[ ] Require disclosure of vendor-identified vulnerabilities.
[ ] Require disclosure of vulnerabilities in third-party and open source components.
[ ] Require a software bill of materials at delivery and on every release, machine-readable, with component versions.
[ ] Confirm the bill of materials permits the question "are we affected" to be answered in hours.
[ ] Specify the update delivery mechanism: authentication, signing, staged rollout, rollback, and failure handling.
[ ] Specify end-of-life notice period, final security update commitment, and migration path.
[ ] Specify spare parts and licence availability post end-of-life.
[ ] Test the obligation end to end at least once, with a simulated critical vulnerability.
[ ] Record the test and the remediation of anything it exposed.

Gate 5. Patching is expressed by severity and time across the whole asset life, a current software bill of materials exists, and the obligation has been tested rather than assumed.

Phase 6 — Remaining vendor terms

[ ] Interoperability: documented, stable interfaces and conformance to any applicable standard.
[ ] Data portability: defined export format, timescale, and completeness obligation.
[ ] Documentation and training obligations that survive personnel turnover.
[ ] Spare parts availability commitment.
[ ] Licence transferability on sale or acquisition of service territory.
[ ] Change-of-law and change-of-standard provisions allocating upgrade cost.
[ ] Committed upgrade path to later standard revisions.
[ ] Liability: general cap with carve-outs for security breach, confidentiality, intellectual property indemnity, and gross negligence.
[ ] Intellectual property indemnity covering third-party and open source components, with defence control and a duty to procure or replace.
[ ] Insurance minimums including cyber cover.
[ ] Records and audit rights supporting the utility's prudence demonstration.
[ ] Service level commitments with meaningful remedies.
[ ] Transition assistance on exit, with a defined period and rate.
[ ] Confirm no term conflicts with the approved tariff.
[ ] Confirm the agreement contemplates assignment on corporate reorganisation of either party.

Gate 6. The agreement is drafted for a thirty-year asset and a vendor that may not survive it, with portability, documentation, standards change, and exit all addressed.

Phase 7 — Interconnection, certification, and market participation

Certification

[ ] Identify the applicable interconnection standard and the revision in force in each state of operation.
[ ] Confirm listing by an accredited laboratory for every product that connects.
[ ] Record the scope of the listing and the configurations it covers.
[ ] Establish a change control process that tests every product change against the listing scope.
[ ] Confirm no shipped configuration has outrun its listing.
[ ] Record metrology approvals separately where the device measures for billing.
[ ] Diary standard revisions and assess the upgrade path for installed equipment.

Interconnection

[ ] Obtain the commission-approved interconnection agreement form for each jurisdiction.
[ ] Review curtailment, liability, metering, and access provisions.
[ ] Record queue position, study milestones, and network upgrade cost allocation.
[ ] Diary study deadlines, since missing one usually means losing position.
[ ] Monitor interconnection process reform dockets, which change project economics.
[ ] Record the state's treatment of the standards it must consider under 16 U.S.C. § 2621.
[ ] For wholesale interconnection, work the procedures at 18 C.F.R. § 35.

Aggregation and market participation

[ ] Identify the wholesale market and its rules for aggregated distributed resources.
[ ] Identify the retail tariff interaction and any dual participation restriction.
[ ] Confirm the jurisdictional analysis, noting Federal Energy Commission v. Electric Power Supply Ass'n on wholesale demand response and Hughes v. Talen Energy Marketing, LLC on state programmes affecting wholesale rates.
[ ] Confirm registration and qualification requirements for the aggregator.
[ ] Confirm telemetry and measurement obligations for market participation.
[ ] Confirm customer contracts grant the device control authority the market requires.

Standards exposure

[ ] Identify every standard the product implements.
[ ] Identify patents the client holds that may be essential to any of them.
[ ] Confirm whether a declaration has been made and what commitment it carries.
[ ] Link standards participation to portfolio management so no commitment is made by accident.
[ ] Assess third-party essential patent exposure and licensing availability.
[ ] Work the analysis in the Standard-Essential Patent Checklist.

Gate 7. Every connecting product is listed and its listing scope is enforced by change control; interconnection agreements and queue positions are tracked; market participation requirements are met; and standards commitments are deliberate.

Phase 8 — Critical infrastructure obligations

Applicability

[ ] Confirm the client's or counterparty's registration and functions.
[ ] Identify which reliability standards apply as a consequence.
[ ] Record asset impact ratings and the controls each triggers.
[ ] Confirm awareness that violations under 16 U.S.C. § 824o carry per-violation, per-day civil penalties.

Vendor flow-down

[ ] Notification of vendor-identified security incidents.
[ ] Notification when vendor remote access should be terminated.
[ ] Disclosure of known vulnerabilities.
[ ] Verification of software integrity and authenticity for delivered code and patches.
[ ] Coordination of controls for vendor-initiated remote access.
[ ] Confirm these appear in the vendor's standard terms rather than being negotiated case by case.
[ ] Verify vendor performance rather than accepting the clause as compliance.
[ ] Audit at least one vendor per year against the terms.

Remote access

[ ] Multi-factor authentication for all vendor access.
[ ] Named individuals rather than shared accounts.
[ ] Approval workflow per session.
[ ] Time-limited sessions with automatic expiry.
[ ] Session recording and review.
[ ] Immediate termination capability, tested.
[ ] Periodic review of who retains access and why.

Incident reporting

[ ] Build the matrix: reliability regulator, state breach notification authorities, federal critical infrastructure reporting, insurers, and contractual notification obligations.
[ ] Record each recipient's threshold and clock.
[ ] Identify who decides that a threshold is met.
[ ] Rehearse once, per Running a Data Breach Response.

Information protection

[ ] Identify material subject to critical energy infrastructure information restrictions.
[ ] Review patent applications before filing for protected system detail.
[ ] Review marketing materials, conference papers, and academic submissions.
[ ] Review litigation productions and expert reports.
[ ] Confirm personnel screening requirements reach vendor staff with system access.
[ ] Align the security programme with the trade secret programme, since the controls serve both.

Gate 8. Applicability is established, flow-down terms are standard and verified, remote access is controlled and tested, the reporting matrix exists before an incident, and protected system information is screened out of every outbound document.

Phase 9 — Regulated procurement

For the utility

[ ] Confirm the procurement process supports a prudence demonstration: competitive solicitation, documented evaluation criteria, and a defensible award record.
[ ] Confirm the accounting treatment is settled before commercial terms are agreed.
[ ] Confirm the rate case timetable supports the intended approval date.
[ ] Confirm standard terms — indemnity, insurance, audit, records retention — are applied consistently.
[ ] Confirm any local content, prevailing wage, or supplier diversity requirement is reflected.
[ ] Confirm interoperability requirements are specified rather than assumed.
[ ] Confirm the evaluation weights escrow, patching, and portability rather than treating them as boilerplate.

For the vendor

[ ] Identify whether the counterparty is investor-owned, municipal, or cooperative, since it changes procurement law and disclosure exposure.
[ ] Identify public records exposure for the proposal, pricing, and technical documentation.
[ ] Mark trade secret material at submission, in the form and at the time the state's exemption requires.
[ ] Confirm somebody has read the applicable public records statute rather than assuming confidentiality.
[ ] Identify protest rights and deadlines for a competitive process.
[ ] Model the capital versus operating expenditure impact of the proposed commercial structure on the customer.
[ ] Consider capitalisable structures where a subscription model would be financially penalised.
[ ] Budget a sales cycle measured in years and a pilot phase longer than proposed.
[ ] Confirm the compliance flow-down terms are accepted in the standard agreement, since refusal is disqualification.

Gate 9. The process supports cost recovery for the utility and disclosure exposure is controlled for the vendor, with commercial structure matched to the customer's accounting reality.

Phase 10 — Intellectual property strategy

Patents

[ ] Draft claims as control systems — measure, compute, actuate — rather than as methods of analysis, to withstand 35 U.S.C. § 101 scrutiny under Alice Corp. v. CLS Bank International and Mayo Collaborative Services v. Prometheus Laboratories, Inc..
[ ] Claim at the point of detectable use — device behaviour, message content, grid-observable effect — rather than at an unobservable internal computation.
[ ] Satisfy 35 U.S.C. § 112 using a generic system rather than a real network.
[ ] Screen every application for protected infrastructure detail before filing.
[ ] Assess foreign filing value against the geography of the market.

Trade secrets

[ ] Inventory operational know-how: model calibrations, tuning parameters, historical performance data, and network behaviour knowledge.
[ ] Mark it, restrict access, and record the reasonable measures under 18 U.S.C. § 1836 and the analysis of Rockwell Graphic Systems, Inc. v. DEV Industries, Inc..
[ ] Address departure risk before the retirement, per Building a Trade Secret Program That Survives Litigation.

Software and open source

[ ] Maintain the component inventory for firmware and head-end software.
[ ] Assess copyleft obligations against the reality of a certified device that cannot lawfully be modified in the field.
[ ] Confirm distribution obligations are satisfied where source must be offered.
[ ] Cross-refer to Copyleft and Consequences.

Machine learning components

[ ] Record model provenance and training data rights.
[ ] Confirm explainability is sufficient for the regulated setting.
[ ] Allocate liability for automated dispatch decisions.
[ ] Confirm vendor terms do not claim rights in the utility's operational data, per Buying a Model.

Brand and marks

[ ] Confirm marks used on regulated equipment are registered in the relevant classes.
[ ] Confirm certification and listing marks are used within their licence terms.
[ ] Confirm no marketing claim about efficiency or emissions outruns its substantiation, per the Environmental Claims and Cleantech IP Checklist.

Gate 10. Claims are drafted for eligibility and detectability, operational know-how is identified and protected, the component inventory is current, and no marketing claim outruns its evidence.

Failures that recur

[ ] Vendor telemetry never reviewed, flowing operational and customer data to a cloud environment with no contractual basis.
[ ] Escrow without verification, missing the toolchain, dependencies, and signing keys.
[ ] Patching tied to an amendable support policy on a fifteen-year asset.
[ ] A maintenance licence that voids the certification when exercised, because nobody allocated recertification.
[ ] A national product on one compliance model, discovered in the second market.
[ ] Aggregation thresholds treated as de-identification, followed by a re-identification demonstration.
[ ] Patent applications describing a real network in restricted detail.
[ ] Standards participation with no portfolio link, producing an accidental licensing commitment.
[ ] A proposal submitted to a public utility without trade secret marking, disclosed on request.
[ ] Operational know-how identified at a retirement party.
[ ] A subscription model pitched without understanding capital treatment, and a lost deal misdiagnosed as price.
[ ] A change-of-standard cost allocation nobody drafted, arriving with the next revision.

Client-type variations

The ten phases hold across the sector, but the weight shifts sharply with who is in the chair. Run the relevant column rather than the whole matrix.

A regulated utility

[ ] Weight phases four to six heaviest: escrow, patching, and the terms that survive vendor failure.
[ ] Weight phase eight next: the reliability obligations that carry penalties.
[ ] Treat phase ten as a defensive exercise; the utility is rarely building a portfolio.
[ ] Confirm every procurement decision supports a prudence demonstration.
[ ] Confirm the affiliate data question is settled before any competitive offering is designed.
[ ] Confirm operational know-how is inventoried before the next senior retirement.

A grid technology vendor

[ ] Weight phase seven heaviest: certification is the market access gate.
[ ] Weight phase four next, from the other side: what can be conceded and at what price.
[ ] Weight phase nine for public records exposure and the capital treatment problem.
[ ] Build the reliability flow-down terms into the standard agreement rather than negotiating each.
[ ] Confirm the patent strategy targets detectable use and survives eligibility scrutiny.
[ ] Confirm the open source position works for a device that cannot be modified in the field.

A distributed energy or data business

[ ] Weight phases two and three heaviest: access is the whole business.
[ ] Weight phase seven for queue position and market qualification.
[ ] Sequence market entry by regulatory readiness rather than by population.
[ ] Adopt the strictest consent standard as the baseline before writing any code.
[ ] Confirm customer contracts grant the device control authority the market rules require.
[ ] Confirm the aggregation and jurisdictional analysis before committing to a market.

A municipal or cooperative counterparty on any side

[ ] Confirm the applicable procurement statute and its protest procedure.
[ ] Confirm public records exposure and the marking requirements for exemption.
[ ] Confirm governance approvals required and their meeting calendar.
[ ] Confirm the absence of a shareholder return changes the capital analysis.
[ ] Confirm whether the entity is subject to the same reliability registration as an investor-owned utility.

The other utilities

[ ] Water. Confirm whether any customer data access rule exists at all; treat silence as uncertainty rather than permission. Expect greater public records exposure where the system is municipal. Assess occupancy disclosure on the same basis as electricity.
[ ] Gas. Confirm the safety consequence profile where remote shut-off exists, and draft firmware integrity, authentication, and failure-mode provisions against that consequence rather than against the data consequence.
[ ] District heating and cooling. Confirm which regulatory framework applies, and contract as if the strictest does where the answer is unclear.
[ ] Multi-utility premises. Where electricity, water, gas, charging, storage, and building management systems report to different parties under different rules, construct a coherent client position rather than expecting to find one.
[ ] Behind-the-meter systems. Confirm whether the customer, the installer, the equipment vendor, or the utility holds the data and controls the device, since the answer is frequently contested and rarely documented.

Diligence on a utility technology business

Where the matter is an acquisition, a financing, or an internal audit, run this shorter sequence first and expand into the phases where it finds trouble.

Contracts

[ ] Obtain every material customer or vendor agreement and rank by deployed asset count rather than by contract value.
[ ] Test escrow: does a deposit exist, when was it last updated, has it ever been verified, and does it include the signing mechanism.
[ ] Test patching: is the obligation expressed by severity and time, and does it extend across the deployed life.
[ ] Test portability: is there a defined export format and timescale.
[ ] Test standards change: who pays when the revision lands.
[ ] Test flow-down: do the reliability supply chain terms appear, and have they ever been audited.

Certification

[ ] List every product that connects and its listing status.
[ ] Compare shipped configurations against listing scope, and expect divergence.
[ ] Identify any pending standard revision that will obsolete a listing.

Data

[ ] Test the legal basis for every flow, and expect to find vendor telemetry with none.
[ ] Test the consent record: can the company produce what a customer saw and when.
[ ] Test the state matrix: does one exist, and does it cover every operating jurisdiction.
[ ] Test any claim of anonymisation independently of the regulatory threshold.

Compliance

[ ] Obtain the reliability audit history, findings, and mitigation plans.
[ ] Obtain any penalty notices or settlements.
[ ] Obtain the incident history and test the reporting matrix against it.
[ ] Test remote access controls against the written policy.

Intellectual property

[ ] Test claim drafting against eligibility and detectability rather than counting assets.
[ ] Identify standards declarations and the commitments they carry.
[ ] Test the open source inventory and any distribution obligation.
[ ] Test whether operational know-how has been identified, marked, and access-controlled.
[ ] Screen the published portfolio for protected infrastructure detail.

Quantify

[ ] Cost of remediating escrow and patching gaps across the installed base.
[ ] Cost of recertification where configurations have outrun listings.
[ ] Cost of building the state matrix and rebuilding consent where the basis is absent.
[ ] Exposure from any reliability finding not yet mitigated.
[ ] Exposure from any accidental standards commitment.

Documents that must exist

For each item: does it exist, where does it live, who owns it, and can it be produced within three working days?

[ ] The data map, with resolution, retention, path, access list, and legal basis per stream.
[ ] The state access matrix, with the chosen product baseline recorded.
[ ] Consent records provable to a commission.
[ ] The approved tariff, current version.
[ ] Every vendor agreement, indexed by deployed asset count.
[ ] Escrow agreements, deposit inventories, and verification reports.
[ ] The software bill of materials for every deployed firmware version.
[ ] Severity definitions and the patching performance record.
[ ] Certification and listing certificates, with scope recorded.
[ ] The change control record linking product changes to listing scope.
[ ] Interconnection agreements and queue status records.
[ ] Market registration and qualification documents for any aggregation activity.
[ ] The reliability registration and applicable standards list.
[ ] Asset impact ratings.
[ ] Vendor flow-down terms and the vendor audit record.
[ ] Remote access logs, approval records, and session recordings.
[ ] The incident reporting matrix with thresholds and clocks.
[ ] The incident history and after-action records.
[ ] The protected information screening record for filings and publications.
[ ] Standards declarations made and the portfolio review that authorised them.
[ ] The open source component inventory and licence obligations register.
[ ] The operational know-how inventory with marking and access controls.
[ ] Procurement records supporting the prudence demonstration.
[ ] Trade secret markings on any submission to a public entity.

The three-day test

The quickest diagnostic on any programme in this sector takes three days. Choose one deployed product and ask for six documents: the escrow verification report, the current software bill of materials, the listing certificate with its scope, the change control record showing the shipped configuration is within that scope, the legal basis for every data flow the product generates, and the vendor flow-down terms with evidence they have been audited.

A programme that produces all six is genuinely in order. A programme that produces three is the ordinary case and has a year of unglamorous work ahead of it. A programme that produces one has a policy rather than a practice, and the gap will surface at an audit, at a detention of a shipment, at a vendor's insolvency, or in a diligence report — none of which is a good moment to discover it.

A ninety-day start

For a client with an unmanaged position, sequenced so each fortnight produces something durable.

Weeks 1–2. Establish the client type and the counterparty type. Obtain the tariff and the reliability registration. Begin the data map.

Weeks 3–4. Complete the data map, including the systems nobody in legal knew about. Flag every flow with no legal basis and stop the ones that cannot be justified.

Weeks 5–6. Build the state access matrix. Choose the product baseline. Identify the pending dockets that will change it.

Weeks 7–8. Review vendor agreements against escrow, patching, portability, and flow-down. Rank the gaps by deployed asset count. Open the remediation conversation with the two vendors that matter most.

Weeks 9–10. Audit certification and listing scope against shipped configurations. Establish the change control gate so the gap does not widen.

Weeks 11–12. Build the incident reporting matrix and rehearse it once. Inventory operational know-how and apply marking and access controls. Screen the pending patent filings for protected detail.

Throughout. Verify one escrow deposit, audit one vendor against the flow-down terms, and test one patching obligation end to end. Three tests are worth more than three months of drafting, because they tell the client which of its paper protections are real.

At day ninety the client knows what data it holds and on what basis, what it may do with it in each state, which vendor terms will fail when tested, whether its products are shipping within their listings, and who it must notify when something goes wrong. That is not a finished programme. It is enough to survive an audit and to answer a vendor failure, which is the point.

A closing note

Every item in this checklist is a variation on one question: when the vendor is gone, the standard has changed, the engineer has retired, and the regulator is asking, what can the client actually produce?

The answer is never the contract clause on its own. It is the verified escrow deposit, the current bill of materials, the listing certificate matched to the shipped configuration, the consent record, and the audit that proved the flow-down terms were being honoured. Those are artefacts, they take ordinary administrative effort to maintain, and they are the whole difference between a programme that works and a folder of well-drafted documents that nobody has tested.

One line to remember

In utility technology the contract is the compliance mechanism, the certification is the market access gate, and the asset outlives everybody who signs the deal — so draft for the vendor's absence, test the protections you have written, and settle the customer data question with the state commission rather than with a privacy policy.

Key Authorities at a Glance

Federal energy regulation. 16 U.S.C. § 824; 16 U.S.C. § 824d; 16 U.S.C. § 824e; 16 U.S.C. § 824o; 16 U.S.C. § 2621; 18 C.F.R. § 35. Federal Energy Commission v. Electric Power Supply Ass'n; Hughes v. Talen Energy Marketing, LLC.

Data. Feist Publications, Inc. v. Rural Telephone Service Co.; 18 U.S.C. § 1030 with Van Buren v. United States; Carpenter v. United States; Smith v. Maryland.

Trade secret. 18 U.S.C. § 1836; Rockwell Graphic Systems, Inc. v. DEV Industries, Inc..

Patent and standards. 35 U.S.C. § 101 with Alice Corp. v. CLS Bank International and Mayo Collaborative Services v. Prometheus Laboratories, Inc.; 35 U.S.C. § 112; Microsoft Corp. v. Motorola, Inc.; Ericsson, Inc. v. D-Link Systems, Inc.; eBay Inc. v. MercExchange, L.L.C..

| Phase | Authority | Record that proves it | | --- | --- | --- | | 1 Inventory | State commission rules | Data map with legal basis per flow | | 2 Access | State access rules | The state matrix with the baseline chosen | | 3 Consent | Approved tariff | Provable consent record | | 4 Firmware | Contract | Verified escrow deposit and build report | | 5 Patching | Contract | Severity matrix and current bill of materials | | 6 Vendor terms | Contract | Portability, standards change, exit provisions | | 7 Interconnection | 16 U.S.C. § 2621 | Listing scope and change control record | | 7 Aggregation | FERC v. EPSA | Registration and market qualification | | 8 Reliability | 16 U.S.C. § 824o | Flow-down terms plus vendor audit | | 9 Procurement | State procurement law | Marked submission and award record | | 10 Patents | 35 U.S.C. § 101 | Control-system claims, screened for disclosure | | 10 Know-how | 18 U.S.C. § 1836 | Inventory, marking, and access controls |