Utilities and Grid Technology IP Toolkit: Metering Data, Vendors, Standards, and Critical Infrastructure

By Casey Scott McKay · 2024-08-03

A meter reporting every fifteen minutes produces a record of how a household lives, and the rules governing it come from a state utility commission rather than from privacy law. This toolkit assembles the working material for practitioners advising utilities, grid technology vendors, and distributed energy businesses. It covers the customer data access framework and the state-by-state matrix a national product needs, together with aggregation thresholds and the re-identification risk they do not remove. It sets out the firmware escrow and patching terms that have to outlive the vendor on a thirty-year asset, and the interconnection listing that gates market access more effectively than any patent. It works through the critical infrastructure obligations that reach vendors through contract, vendor remote access controls, and the regulated procurement environment that makes commercially sensible structures financially irrational for the buyer. It closes with the patent and trade secret strategy that suits the sector, clause language, and the failures that recur.

IP and Technology > Information Technology | Toolkit | Published 3 August 2024 - Updated 19 May 2026 | Casey Scott McKay - marksy.us

Summary. A meter reporting every fifteen minutes records how a household lives, and the rules come from a state commission rather than from privacy law. This toolkit covers customer data access and the state matrix, aggregation thresholds and re-identification, firmware escrow with verification, patching obligations across a thirty-year asset life, interconnection listing as a market access gate, critical infrastructure flow-down and vendor remote access, regulated procurement, and the patent and trade secret strategy that suits the sector.

Keywords: utility IP · smart meter data · usage data access · commission rules · aggregation thresholds · firmware escrow · escrow verification · security patching · software bill of materials · interconnection listing · reliability standards · vendor remote access · infrastructure information · regulated procurement · standard-essential patents

Start Here

Three facts distinguish this sector from ordinary technology practice, and every item below follows from one of them.

The asset outlives the vendor. A meter, a relay, or a substation controller runs for decades. Contract terms drafted for a three-year enterprise software cycle fail in year twelve, which is why escrow, patching, portability, and documentation obligations are the operative provisions rather than boilerplate.

Regulatory obligations reach vendors through contract. Mandatory reliability standards approved under the authority in 16 U.S.C. § 824o bind the utility, and the utility discharges its supply chain obligations by requiring commitments from its vendors. A vendor that will not accept them is disqualified rather than negotiating.

And the customer data question is answered by a state utility commission. There is no sector-specific federal energy privacy statute. Access, format, fees, secondary use, and aggregation thresholds are set state by state, and a national product needs a matrix rather than a policy.

Four questions organise the work.

Who may access the data, on what terms, in each state?

What happens to the firmware when the vendor is gone?

Is the product listed, and does the shipped configuration still fall within the listing?

And which obligations flow down from the reliability regime?

See Keeping the Lights On for the doctrinal treatment, Advising a Utility or Grid Technology Business for the sequence, and the Utility and Grid Technology Checklist for the working list.

Part one: customer data

Stop asking who owns it. There is no property right in data as such; a compilation attracts thin protection in its selection and arrangement following Feist Publications, Inc. v. Rural Telephone Service Co., and nothing in the underlying facts. The useful questions are who holds it, who may access it, on what terms, and who decides. See Selling Something You Cannot Own.

Be honest about sensitivity. At hourly resolution a consumption trace shows occupancy, absence, and sleep patterns. At fifteen minutes it shows meal preparation, laundry cycles, and electric vehicle charging, and the charging pattern is an arrival-home pattern. At sub-minute resolution, disaggregation techniques thirty years old in the literature identify individual appliances. Advise on what the data reveals rather than on what it is called.

Build the state matrix. For every operating jurisdiction: whether a customer usage data access rule exists; the required authorisation form, duration, and revocation mechanism; what data must be provided, in what format, on what timescale; whether a standard format is mandated; what fees may be charged; restrictions on secondary use and onward transfer; aggregation thresholds for non-consented disclosure; deletion obligations on termination; how the state's comprehensive privacy statute treats regulated utilities; and any separate affiliate access rule.

Adopt the strictest standard as the product baseline where the client operates nationally, because building to the median and patching for outliers produces an architecture that fails in the markets that matter.

Treat aggregation thresholds as compliance minima, not de-identification. A household consumption pattern is close to unique and re-identifies readily against auxiliary information; a small-cell query against a large aggregate defeats a threshold applied to the dataset as a whole. Apply the threshold to the query and run an independent re-identification assessment.

Settle the affiliate question before designing a competitive offering, because commissions treat cross-subsidy seriously and the answer is usually no or not without conditions.

Document the consent architecture so it can be shown to a commission: what the customer saw, when, what they authorised, for how long, how they revoke, and what happens on revocation.

And build a law enforcement response process, since utility records have traditionally been third-party business records under Smith v. Maryland while the argument that granular interval data is closer to the information in Carpenter v. United States has gained traction. A documented process beats a counter-level decision.

Part two: firmware, escrow, and patching

Understand both positions. The utility is buying an asset with a thirty-year life across a million endpoints in a regulated environment where it must demonstrate control. The vendor's firmware is the product; the metal is commodity.

Work the ladder: support commitments; escrow; escrow with verification; a contingent maintenance licence; a full source licence. Most deals land at verified escrow plus a contingent maintenance licence, and the negotiation is about triggers and scope.

Draft release triggers around abandonment, not just insolvency. End-of-life notice; acquisition followed by discontinuation; failure to remedy a critical security defect within a stated period; failure to correct a severity-one defect after escalation; material breach of support. Each with an objective test and a cure period.

Insist on verification. An escrow deposit nobody has compiled is a comfort document. Periodic independent verification that the deposit builds into the shipping binary, with the build environment and dependencies, is what makes the arrangement real — and it is the most commonly omitted term.

Deposit more than source: build scripts, toolchain versions, dependency manifests, configuration, test suites, documentation, and the signing keys or a mechanism to produce signed images, because firmware that cannot be signed cannot be installed on a device that verifies signatures.

Grant the maintenance licence now, conditioned on the trigger, rather than promising to grant it later — a promise from an insolvent vendor is an unsecured claim. Scope it to maintenance, defect correction, and security modification only; no distribution; use by the utility or a nominated third party under equivalent confidentiality; term running for the life of the deployed assets.

Allocate recertification. A permitted modification that voids the metrology approval or the interconnection listing is a right the utility cannot exercise. Identify which classes of change trigger recertification and who bears the cost.

Express patching by severity and time, not by reference to an amendable support policy, with severity tied to an external scale and an escalation route on disagreement. Set a maximum window for critical vulnerabilities in days, require interim mitigations, and extend the obligation across the full deployed life or specify what happens beyond the support horizon.

Require vulnerability disclosure, including for third-party and open source components, and a machine-readable software bill of materials at delivery and on every release — which is what lets a utility answer "are we affected" in hours rather than weeks.

Specify the update mechanism: authentication, signing, staged rollout, rollback, and failure handling.

And test the obligation once, end to end, with a simulated critical vulnerability, because a clause never exercised is a clause nobody knows works.

Part three: the rest of the vendor agreement

Interoperability. Documented, stable interfaces and conformance to any applicable standard. Proprietary protocol control is how a thirty-year dependency is created, and the utility's resistance to it is rational.

Data portability. A defined export format, timescale, and completeness obligation. General cooperation language is worth little at migration.

Documentation and training, which are what survive the departure of everybody who negotiated the deal.

Spares availability and licence transferability on sale or acquisition of service territory.

Change-of-standard allocation, since interconnection and metering standards are revised and somebody must pay to bring installed equipment into compliance. Secure a committed upgrade path.

Liability with a general cap and 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, which utility procurement typically prescribes.

Records and audit rights, which are the mechanism by which the utility demonstrates prudence to its commission rather than administrative overhead.

Transition assistance on exit, with a defined period and rate, not conditioned on settlement of any disputed amount.

And confirm nothing conflicts with the approved tariff, which governs the utility's relationship with its customers and renders an inconsistent contractual term unenforceable.

Part four: interconnection, certification, and standards

Certification is the market access gate, and it matters more than any patent. Equipment tested against the interconnection standard by an accredited laboratory and listed moves through a streamlined process; unlisted equipment faces supplemental review that is slower, costlier, and frequently commercially fatal.

Track the standard and the revision in force in each state of operation, because adoption differs in timing and detail and a product compliant in one state may face a different requirement next door.

Treat the listing as an asset with a scope, and enforce it with a change control process that tests every product change against what the listing covers. A shipped configuration that has outrun its listing is a problem discovered by an inspector rather than by the company.

Record metrology approvals separately where the device measures for billing.

Read the interconnection agreement as a regulated instrument, generally on a commission-approved form, with the provisions on curtailment, liability, metering, and access mattering most.

Track queue position and study milestones, since missing one usually means losing position, and monitor the interconnection reform dockets that change project economics.

Analyse aggregation separately. A virtual power plant sits across interconnection rules designed for single facilities, wholesale market participation rules, and retail tariffs. Federal authority over wholesale demand response was upheld in Federal Energy Commission v. Electric Power Supply Ass'n, and the limits on state programmes affecting wholesale rates were addressed in Hughes v. Talen Energy Marketing, LLC. The jurisdictional line decides the forum and the rules. State standards consideration sits at 16 U.S.C. § 2621 and wholesale interconnection procedure at 18 C.F.R. § 35.

Manage standards exposure deliberately. A patent essential to a grid communications or interconnection standard carries a licensing commitment on fair, reasonable, and non-discriminatory terms where declared, with the rate analysis of Microsoft Corp. v. Motorola, Inc. and Ericsson, Inc. v. D-Link Systems, Inc. and the injunction constraint of eBay Inc. v. MercExchange, L.L.C.. Link standards participation to portfolio management so the commitment is a decision rather than an accident. See Licensing or Litigating a Standard-Essential Patent and the Standard-Essential Patent Checklist.

And screen the equipment supply chain, since component origin scrutiny now reaches grid equipment. See the Trade Compliance Checklist.

Part five: critical infrastructure obligations

Establish applicability. The reliability standards apply to registered entities by function, and the registration determines which apply. A vendor should know its customer's registration because it drives the flow-down.

Understand the enforcement. Standards approved under 16 U.S.C. § 824o are mandatory, and violations attract civil penalties per violation per day. This is not advisory guidance.

Work the domains: asset identification and impact rating; security management controls; personnel and training including background screening reaching vendor staff; electronic security perimeters; physical security; system security management; incident reporting and response planning; recovery planning; configuration change management and vulnerability assessment; information protection; and supply chain risk management.

Supply chain risk management reaches vendors directly, requiring notification of vendor-identified incidents, notification when vendor remote access should be terminated, disclosure of known vulnerabilities, verification of software integrity and authenticity, and coordination of controls for vendor-initiated remote access.

Build these into the vendor's standard terms rather than negotiating each, and verify performance rather than accepting the clause as compliance.

Control remote access, which is both operationally necessary and the largest single third-party risk: multi-factor authentication, named individuals, approval workflow, time-limited sessions, session recording, immediate termination capability, and periodic review of who retains access.

Build the incident reporting matrix across the reliability regulator, state breach notification authorities, federal critical infrastructure reporting, insurers, and contractual obligations, each with its own threshold and clock, and rehearse it. See Running a Data Breach Response.

Protect the information itself. Detailed information about critical energy infrastructure is subject to disclosure restrictions reaching patent applications, marketing materials, academic papers, and litigation productions. Somebody who understands those restrictions should read applications before filing.

And align the security programme with the trade secret programme, since the access controls, marking, and personnel measures serve both. See Building a Trade Secret Program That Survives Litigation.

Part six: procurement and portfolio strategy

Cost recovery drives behaviour. A regulated utility recovers prudently incurred costs through rates and must demonstrate prudence, which pushes procurement toward competitive processes, documented evaluation, and defensible pricing.

Capital versus operating expenditure is not an accounting detail. A utility earns a return on capital investment and passes operating expense through without return, so a subscription model converting a capital purchase into an operating expense is financially worse for the utility regardless of total cost. Vendors misread the resulting resistance as conservatism; structuring around it is a commercial conversation with a legal component.

Cycles are long, tied to rate case timing and regulatory approval, and vendors routinely underestimate the pilot phase.

Public records exposure is a genuine trap for vendors selling to municipal utilities and public power authorities: proposals, pricing, and technical documentation may be disclosable. Trade secret exemptions exist, must be claimed properly and at the right time, and material submitted without marking is usually lost.

Interoperability mandates limit lock-in strategies, pushing vendor value into implementation, integration, and services rather than into protocol control. Build a business model that survives interoperability rather than one that depends on its absence.

Then the portfolio. Claim the system, not the insight: a method of forecasting load is a calculation and will meet 35 U.S.C. § 101 resistance under Alice Corp. v. CLS Bank International and Mayo Collaborative Services v. Prometheus Laboratories, Inc., while a control system that measures defined physical quantities, computes a dispatch instruction, and actuates specific equipment is an apparatus doing something. The difference is drafting.

Claim at the point of detectable use. An algorithm executed inside a control room is invisible from outside and practically unenforceable; the behaviour of an inverter on the grid, or the content of a message a device sends, is observable. In a sector with few, large, sophisticated customers, detectability determines whether a patent has leverage.

Satisfy 35 U.S.C. § 112 with a generic system rather than a real network, to avoid disclosing protected infrastructure detail.

Protect operations expertise as trade secret under 18 U.S.C. § 1836 with reasonable measures per Rockwell Graphic Systems, Inc. v. DEV Industries, Inc.. Model calibrations, tuning parameters, historical performance, and network behaviour knowledge are valuable, unpatentable, and routinely unidentified until somebody retires.

Manage open source in firmware, with attention to the tension between copyleft obligations and a certified device that cannot lawfully be modified in the field. See Copyleft and Consequences.

And handle machine learning components deliberately: model provenance, training data rights, explainability in a regulated setting, and liability for automated dispatch. See Buying a Model and the AI Procurement Checklist.

Clause bank

Escrow with verification. Supplier shall deposit with the Escrow Agent, within [30] days of the Effective Date and on each release thereafter, the complete Source Materials for the Firmware, comprising: source code; build scripts and instructions; toolchain identification with versions; a dependency manifest; configuration files; test suites; technical documentation; and a mechanism sufficient to produce a validly signed image. The deposit shall be verified annually by an independent verifier appointed by Customer, at Supplier's cost, who shall confirm that the deposit builds into the then-current shipping binary and shall report to both parties. Failure of verification is a material breach if not remedied within [30] days.

Release and maintenance licence. Supplier grants Customer, with effect from the Effective Date and exercisable on a Release Event, a non-exclusive, worldwide, irrevocable licence to use, modify, and compile the Source Materials solely to maintain, correct defects in, and apply security updates to the Equipment deployed by Customer, for the operational life of that Equipment. Customer may exercise this licence through a nominated third party bound by equivalent confidentiality. Customer may not distribute the Source Materials or use them to develop a competing product. A Release Event occurs on: Supplier's insolvency; Supplier's issue of an end-of-life notice; Supplier's failure to remedy a Critical Vulnerability within [45] days of notification; or Supplier's failure to correct a Severity 1 Defect within [30] days after two successive escalations.

Patching and bill of materials. Supplier shall remedy Vulnerabilities within: [30] days for Critical; [90] days for High; and the next scheduled release for Medium and Low, severity being assessed by [external scale] with disputes escalated under clause [X]. Where a remedy is not available within the period, Supplier shall provide a documented interim mitigation. Supplier shall disclose to Customer every Vulnerability of which it becomes aware affecting the Equipment, including in third-party and open source components, within [5] business days. Supplier shall deliver a machine-readable Software Bill of Materials at delivery and with every release, identifying each component and version. These obligations apply for the Operational Life stated in Schedule [A], and Supplier shall give not less than [24] months' notice of end of support.

Reliability flow-down. Supplier shall: notify Customer of any Supplier-identified security incident affecting or potentially affecting the Equipment or Supplier's systems used to support it, within [24] hours; notify Customer when Supplier remote access should be terminated, including on the departure of any individual with access, within [24] hours; disclose known vulnerabilities in accordance with clause [Y]; provide a method for Customer to verify the integrity and authenticity of all software and patches; and coordinate with Customer on controls for Supplier-initiated remote access. Supplier shall procure equivalent obligations from each subcontractor with access. Customer may audit compliance on [30] days' notice, annually.

Vendor remote access. All Supplier access to Customer systems shall be: by named individuals listed at Schedule [B] and no others; authenticated by multi-factor authentication; approved in advance for each session by Customer's named approver; limited in duration to the approved session; recorded in full; and terminable by Customer immediately without notice. Supplier shall notify Customer within [24] hours of any change to the list at Schedule [B]. Customer shall review the list quarterly and may remove any individual at its discretion.

Customer data. Supplier shall use Customer Data solely to provide the Services. Supplier shall not use Customer Data to develop, train, or improve any product or model, or for benchmarking, analytics, or any other purpose, without Customer's separate written consent. Supplier shall not disclose Customer Data to any third party other than an approved subprocessor listed at Schedule [C]. On termination Supplier shall export Customer Data in [format] within [30] days and shall delete all copies within [60] days, certifying deletion, and shall retire or retrain within [period] any model trained wholly or partly on Customer Data.

Worked scenarios

The escrow that was never tested. A utility deploys two million meters under a contract with source code escrow. The vendor is acquired and the product line discontinued. The escrow releases. The deposit contains source code and nothing else: no build scripts, no toolchain version, no dependency manifest, and no signing mechanism. The meters verify firmware signatures and will not accept an unsigned image. The escrow is worthless. Annual verification, at the vendor's cost, would have found this in year one.

The national product on one compliance model. A distributed energy aggregator builds a consent architecture for its home state and expands. Data access rules differ, some comprehensive privacy statutes exempt regulated utilities and some do not, interconnection requirements differ in timing and detail, and market participation rules for aggregated resources vary by wholesale market. The rebuild costs six months. Adopting the strictest standard as the baseline before writing code would have cost nothing.

The retirement. A transmission operator's most experienced engineer retires into a consultancy advising competitors. Thirty years of knowledge about how the network behaves under stress: unpatented, largely unwritten, never marked confidential. General expertise leaves lawfully, and only material reduced to a specific form and treated as confidential is protectable. The remediation is prospective — an inventory of operational know-how, access restrictions, marking, and a documented programme — so that the next departure is a different conversation.

The subscription that lost the deal. A software vendor prices its platform as an annual subscription, which is standard in its industry. The utility's evaluation treats it as operating expense, on which it earns no return, against a competitor's capitalisable licence. The vendor loses and attributes it to price. Restructuring as a capitalisable licence with a separate support agreement, or as a prepaid term arrangement, would have made the same economics acceptable.

Failures that recur

Vendor telemetry configured by default and never reviewed, sending operational and customer data with no contractual basis.

Escrow without verification, missing the toolchain, dependencies, and signing mechanism.

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.

Aggregation thresholds treated as de-identification.

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 change-of-standard cost allocation nobody drafted, arriving with the next revision.

And a commercial structure that ignores capital treatment, producing lost deals the vendor misdiagnoses.

Part seven: the other utilities

Almost everything above is written about electricity, where the technology and the regulation are most developed. The same questions arise elsewhere with different weightings.

Water. Metering is following the electricity trajectory a decade behind: mechanical devices replaced by transmitting ones, interval data, leak detection analytics, and the same occupancy disclosure problem in an arguably more intimate form. The regulatory framework is thinner, many systems are municipal, and public records exposure is correspondingly greater. Advise that the absence of a detailed access framework is uncertainty rather than permission.

Gas. Remote shut-off capability changes the consequence profile entirely. Firmware integrity, authentication, and failure modes carry weight no electricity meter contract needs, and the security provisions should be drafted against the safety consequence rather than against the data consequence.

District heating and cooling. Frequently neither a regulated utility nor an ordinary service, sitting in a regulatory gap that produces genuine uncertainty about which customer data framework applies. Contract as if the strictest does.

Municipal and cooperative utilities. Different governance, procurement law, public records exposure, and cost recovery mechanics, with no shareholder return to drive the capital-versus-operating analysis. Advice built for an investor-owned client will be wrong in several particulars.

Behind-the-meter systems. Where the customer, the installer, the equipment vendor, and the utility all have a claim to the data and to control of the device, and the position is rarely documented.

And the multi-utility premises, where electricity, water, gas, charging, storage, and building management systems report to different parties under different rules. The frameworks were built for one meter and one utility, and the gap is where the next several years of practice will be spent.

Part eight: transactions and diligence

Contracts first. Obtain every material customer or vendor agreement, ranked by deployed asset count rather than by contract value. Test escrow — does a deposit exist, when was it updated, has it ever been verified, does it include the signing mechanism. Test patching — is the obligation expressed by severity and time across the deployed life. Test portability, standards change allocation, and reliability flow-down with evidence of an audit.

Certification. List every connecting product and its listing status, compare shipped configurations against listing scope, and identify any pending standard revision that will obsolete a listing.

Data. Test the legal basis for every flow, expecting to find vendor telemetry with none. Test whether the consent record can be produced. Test whether a state matrix exists covering every operating jurisdiction. Test any anonymisation claim independently of the regulatory threshold.

Compliance. Obtain the reliability audit history, findings, and mitigation plans; any penalty notices or settlements; the incident history tested against the reporting matrix; and remote access controls tested 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. The cost of remediating escrow and patching gaps across the installed base; recertification where configurations have outrun listings; building the state matrix and rebuilding consent where the basis is absent; exposure from any unmitigated reliability finding; and exposure from any accidental standards commitment.

And check what does not transfer. Software licences granted to the entity rather than to the asset, retrofit permissions granted to a named owner, and reliability registrations, each of which can leave a buyer operating without something it assumed it had acquired.

Part nine: what the meter actually reveals

Being concrete about the disclosure problem helps, because the abstraction hides how much is at stake and because the legal category of a data stream depends on what it discloses rather than on its label.

At hourly resolution, a consumption trace shows occupancy patterns, sleep and waking times, and absence. A fortnight's holiday is unmistakable; so is a shift worker's rota.

At fifteen-minute resolution, the trace shows meal preparation, laundry cycles, and the operation of any load above a kilowatt. Electric vehicle charging is unmistakable and its timing is a proxy for arrival home.

At sub-minute resolution, non-intrusive load monitoring can disaggregate individual appliances by their switching signatures. The literature is thirty years old and the techniques are not exotic.

Aggregate across a street and the analyst has a demographic profile; aggregate across a city and the utility has a dataset of enormous commercial value, which is why third parties want access and why the access rules are contested.

Re-identification is the recurring failure of anonymisation here. A household consumption pattern is close to unique, and a de-identified trace can frequently be matched given any auxiliary information — a known absence, a known appliance purchase, an address-level total.

Which has consequences for the advice. A client building a product on aggregated energy data should not assume regulatory compliance answers the re-identification question and should run its own assessment. A utility asked to provide aggregated data should confirm the threshold is applied to the specific query rather than to the dataset as a whole, since a small-cell query against a large aggregate defeats the protection.

And law enforcement access is a live question, with a documented response process better than a decision taken at the counter.

Part ten: contracting for the thirty-year asset

A utility technology procurement is an infrastructure decision dressed as a technology purchase, and the drafting should reflect the timescale.

Assume the vendor will not exist for the life of the asset. Some will; planning otherwise is prudent. That drives escrow, maintenance licences, interoperability requirements, and documented interfaces.

Assume the standard will change, and allocate the cost of bringing installed equipment into compliance with a later revision.

Assume the security landscape will change, and express the patching obligation by severity and time rather than by reference to an amendable policy.

Assume personnel will turn over on both sides, which makes the documentation and training obligations the ones that survive.

Assume the data model will need to be exported, and specify the format.

Assume the regulator will ask, and secure audit rights and records retention, which in this sector are the mechanism by which the utility recovers its costs rather than administrative overhead.

And assume somebody will read the contract in fifteen years with no memory of the negotiation. Define the terms. Do not incorporate documents by reference to a website. Attach the specifications.

One paragraph 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. Verify the escrow rather than merely taking it, and make sure the deposit includes the toolchain and the signing mechanism. Express patching by severity and time across the whole deployed life, and require a machine-readable bill of materials. Enforce listing scope with change control so a shipped configuration never outruns its certificate. Build the reliability flow-down into standard terms and audit it rather than assuming it. Settle the customer data question with a state matrix rather than a policy, treat aggregation thresholds as compliance minima rather than de-identification, and remember that the patents matter less here than the escrow, the certification, and the flow-down — which is the opposite of what most technology clients expect to hear.

The three-day test

The quickest diagnostic on a programme in this sector takes three days. Choose one deployed product and ask for six documents.

The escrow verification report from the most recent cycle. The current machine-readable software bill of materials. The listing certificate with its recorded scope. The change control record showing that the shipped configuration falls within that scope. The legal basis for every data flow the product generates, including any vendor telemetry. And the reliability flow-down terms with evidence that 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. A programme that produces one has a policy rather than a practice, and the gap will surface at an audit, at a vendor's insolvency, or in a diligence report — none of which is a good moment to discover it.

A note on working with the client's own experts

The technical dependency in this sector is heavier than in most, and the adviser's contribution is rarely to know more than the client's specialists about their own domain.

The protection engineer knows what the relay does, and where a contract term touches device behaviour they should read that clause specifically rather than receiving the whole agreement.

The compliance manager knows the registration, the applicable standards, and the audit history, and their view on whether a proposed flow-down term is sufficient is worth more than an outside assessment.

The regulatory affairs team knows the commission and the pending dockets that will change the rules the deal is drafted against — which is why a contract signed the month before a rule change needed a change-of-law provision.

The security team knows what remote access looks like in practice, as opposed to what the policy says.

And the finance team knows the rate case timetable, which determines when the deal can be approved and what accounting treatment it needs.

The value the adviser adds is being the one who asks each of them the right question and writes down an arrangement reflecting all five answers at once, which nobody inside the organisation is positioned to do.

A closing observation

There is a symmetry in this sector worth stating plainly.

The utility's central operational problem is that electricity cannot be stored at scale, so supply must match demand continuously, which means the system must know what is happening everywhere at once. That requirement produced the measurement infrastructure; the measurement infrastructure produced the data; and the data turned out to be a portrait of how people live.

Nobody set out to build a surveillance system. Somebody set out to balance a grid, and the balancing required knowing, and the knowing turned out to be the same thing.

Which is the shape of a great many technology law problems, and it is why the advice that works here is rarely about the technology. It is about being clear-eyed regarding what a system reveals as a by-product of doing its actual job, and putting the controls around the by-product before somebody else works out what it is worth.

Key Authorities at a Glance

Federal energy regulation. 16 U.S.C. § 824 on jurisdiction; 16 U.S.C. § 824d and 16 U.S.C. § 824e on rates; 16 U.S.C. § 824o on mandatory reliability standards; 16 U.S.C. § 2621 on state standards; 18 C.F.R. § 35 on wholesale interconnection. Federal Energy Commission v. Electric Power Supply Ass'n; Hughes v. Talen Energy Marketing, LLC.

Data. Feist Publications, Inc. v. Rural Telephone Service Co.; 17 U.S.C. § 103; 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 and 18 U.S.C. § 1839; 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; 35 U.S.C. § 271; Microsoft Corp. v. Motorola, Inc.; Ericsson, Inc. v. D-Link Systems, Inc.; eBay Inc. v. MercExchange, L.L.C..

Software and copyright. 17 U.S.C. § 102; 17 U.S.C. § 117; 17 U.S.C. § 1201; Google LLC v. Oracle America, Inc..

| Authority | Governs | Practical consequence | | --- | --- | --- | | 16 U.S.C. § 824o | Reliability standards | Vendor flow-down is non-negotiable | | FERC v. EPSA | Wholesale demand response | Federal authority over aggregation | | Hughes v. Talen | State programmes | Limits on intrusion into wholesale rates | | 16 U.S.C. § 2621 | State standards | Interconnection consideration mandate | | Feist | Facts | Meter data is contractual, not owned | | Carpenter | Third-party records | The argument for warrant protection | | 18 U.S.C. § 1836 | Trade secrets | Where operations expertise lives | | Rockwell | Reasonable measures | Marking and access controls | | 35 U.S.C. § 101 with Alice | Eligibility | Claim the control system | | eBay | Injunctions | Limits on essential patent remedies | | 17 U.S.C. § 1201 | Access controls | Diagnostic access in field equipment | | 17 U.S.C. § 117 | Owner adaptations | Narrow, and relevant to maintenance |