NERC Computational Load Standards: FERC Sets December 2026 Deadlines
By KEIRSTEN BRAGER
FERC did not accelerate NERC's timeline, it made the calendar a directive and moved registration onto the critical path. The order creates the computational load entity, sets the December 31 and March 1 deadlines, and leaves the AI Reliability Boundary, the line between what the grid must command and what it leaves to private contract, for Phase II to draw. What is settled, what is not, and what to do in the next ninety days.
Overview
On July 16, FERC issued the order. My July 15 analysis argued the sequencing had inverted, that FERC would set scope and schedule before NERC's drafting team finished. It did. The more useful question now is not whether the prediction held. It is what the order left open, because that is where your exposure lives.
The order is Docket No. RD26-7-000, “Reliability Standards Pertaining to Computational Load Integration,” 196 FERC ¶ 61,031, issued on the Commission's own motion under section 215(d)(5) of the Federal Power Act. It directs NERC to do three things: file new or modified Reliability Standards for computational load integration, with Glossary definitions, by December 31, 2026; file Rules of Procedure revisions establishing registry criteria for computational load entities by the same date; and submit a Phase II workplan by March 1, 2027.
The dates did not move. Their legal character did.
Set the order beside NERC's own plan and the schedule is nearly identical. Project 2026-02 already targeted an initial standard by the end of 2026 and broader work in 2027. FERC did not accelerate that timeline. It adopted it.
What changed is the status of the calendar. NERC's dates were voluntary milestones inside a process the ERO controlled. They are now directives under section 215(d)(5). A voluntary milestone that slips has no consequence. A directive that slips does.
That is the whole of the reframe. Everything below is about what that deadline now sits on top of.
Registration moved onto the critical path
The most consequential unanswered question in the order is not the standards language. It is registration.
FERC directed NERC to file registry criteria for computational load entities by December 31, 2026, the same day the initial standards are due. On July 15 the registration effort read as a parallel workstream. It is now a Commission directive sharing a deadline with the standards themselves.
This closes the question my prior piece left open. The interconnection agreement was the only durable instrument for extending CIP-equivalent practice to a computational load facility, because the facility was not a registered entity. That was the reading Patrick Miller set out in May and I carried forward. It was a workaround for a jurisdictional gap, and workarounds last only as long as the gap.
Hold the word “closes” to registration alone. Registration is what the order settles. What attaches to a registered entity is not settled, and that unresolved part is the subject of the next section.
Once a computational load entity is on the compliance registry, which standards apply to it will be governed by the applicability sections those standards ultimately carry, not by the intent of the project that created the registration. What those sections say is a NERC drafting question subject to FERC approval, and it is unsettled. The order does not decide it. It establishes the entity framework to which the eventual answer will attach.
The boundary of what we know: three scenarios
Here is the honest edge of this analysis, and it belongs near the front rather than the back. The order creates the entity and schedules the proceeding. It does not decide what the standards will require, and everything downstream depends on that unmade decision.
It sets no megawatt threshold. It describes computational load as load comprised of power demand from information technology equipment such as servers, storage, and networking hardware, and leaves the registry criteria, including any size cutoff, to NERC. The population is still to be drawn.
It does not mention CIP. The unresolved question is the AI Reliability Boundary: the line between the facilities the grid must be able to see and command and those left to private contract. Three scenarios remain live for where that line falls.
Scenario one, narrow applicability: limited to modeling, commissioning, and coordination, with CIP excluded.
Scenario two, applicability by function: reaching facilities with parallel-operated generation, RAS participation, or a direct real-time interface with a Transmission Operator.
Scenario three, convergence: in which the control systems that deliver load flexibility become reliability-relevant cyber assets.
The Phase II workplan due March 1, 2027 is where that boundary gets drawn, and section 215(d)(5) shapes what the phase may consider. Read the rest of this piece as three conditional futures, not one settled one. Which scenario wins decides how much of what follows applies to you.
Section 215(d)(5) is the tell
The authority FERC used is worth reading closely. The Commission can remand a proposed standard, or it can direct NERC to develop one addressing a specific matter. It chose the second, on its own motion, before any filing. That is not a regulator waiting to review NERC's work. It is a regulator defining the assignment.
The factual predicate moved with it. The order finds that NERC has documented multiple grid disturbances in which computational loads caused or contributed to instability of the Bulk-Power System, citing two dated incident reviews and the 2026 State of Reliability: Assessment Overview of 2025 Bulk Power System Performance, published June 24, 2026. A finding in a Commission order is a firmer object than an observation in a Reliability Guideline. It is the record the standards, and any future compliance case, will rest on.
Workload composition enters the reliability frame
For AI governance leaders, this is the development that has not reached you and should.
Be precise about what happened, because the distinction is legal, not rhetorical. FERC did not regulate workload composition on July 16. It created the pathway by which workload characteristics could become relevant to a Reliability Standard, and whether they do is a Phase II drafting question that has not been answered.
On July 15 I flagged that workload composition was becoming a modeling input, and workload change a qualified change that may trigger additional transmission study requirements. That lived in a Level 3 Alert and a Reliability Guideline, which are recommendations. The order opens a path for the same subject onto the standards track and puts a registered entity beneath it.
Read plainly: the decision to retask compute from inference to training could become an attribute of a registered entity, subject to standards whose applicability will be drafted over the next eight months. Where a model trains, on what schedule, and at what ramp rate may become relevant reliability considerations rather than purely capacity questions.
Here is what this means for your organization. No enterprise AI governance framework in current use, not NIST's AI RMF, not model risk management, contemplates a grid regulator potentially incorporating workload characteristics into reliability obligations. That exposure will not resolve on its own. What the order added is a date by which you should understand it.
The interface is a security interface, and it has another potential user
The order does not touch the security asymmetry, so it persists. The operational interface the Essential Actions describe, the real-time directive path, the bidirectional telemetry, the RAS participation, the shared protection and control data, runs between a registered entity whose side sits inside CIP scope and a facility whose side sits outside it.
A control plane that can shed a gigawatt of load in seconds carries the reliability significance of a large generator's controls. The systems that govern it, the building management layer, the UPS controllers, the workload orchestration stack, the emerging grid communication path, were designed against a threat model in which customer data and availability are the targets, not grid frequency.
State it as a security problem rather than a compliance one. The interface being built has a second potential user, an adversary who wants the load to move on command. That is the strongest case for bringing these control systems inside a CIP-equivalent regime rather than leaving them to contract. Note what that is and is not. It is the argument for scenario three, not a prediction that scenario three prevails. The order built the mechanism through which the argument could be answered. It did not pull the trigger, and it may never.
What this means for utilities, on both sides of the load
The order lands differently depending on whether you already serve computational load. Both positions carry obligations. They are not the same obligations.
If you are a computational load partner, a transmission owner or load-serving entity in a growth corridor, you are already the registered entity on the CIP side of the interface. The order schedules NERC to establish registry criteria by the end of this year, and those criteria will determine which computational load entities become registered. If your counterparty meets them, a relationship you drafted and enforced becomes one you co-inhabit under standards neither of you wrote.
The Essential Actions you have been accumulating move from guidance into the evidentiary record that will inform enforceable standards. The interconnection agreements you signed as the CIP-extension vehicle become a supplement to that baseline, not its foundation. And because the registry criteria decide which of your customers become registered entities, you have a direct stake in how the population is drawn. You are being reshaped from three directions at once, since the same load drives the Section 206 show cause dockets on interconnection and cost allocation (195 FERC ¶ 61,211, June 18, 2026).
If you do not serve computational load today, do not conclude this is someone else's proceeding. The Level 3 Alert already reaches entities with no computational load in territory if they could feasibly receive an interconnection request within two years. Absence is not an exemption. It is a two-year clock that may already be running.
The decision in front of both groups is the same. Build the modeling, commissioning, and protection posture now, ahead of the first interconnection request, or retrofit it later under a signed agreement and a live standard. The first is cheaper. The second is the default for anyone who waits.
The capital and compliance bill matures inside this planning cycle
For the people who hold the capital plan, the order changed the budgeting question, and it did so on a schedule that lands in FY2027, not FY2028.
The near-certain spend is the interface itself: dynamic fault recorders and access to them, SCADA and telemetry buildout, protection and control upgrades, and the systems to collect and share modeling data. These were investments you could defer as prudent. The driver has moved from prudent planning consideration toward regulatory expectation, which strengthens the case for proactive investment and changes how future prudence reviews may evaluate deferred action.
The contingent spend is the one to name before it is required. Scenario two would bring narrower, function-specific obligations. Scenario three, convergence, is the one that would pull computational load control systems inside a CIP-equivalent regime, and that security program is a materially larger commitment than the modeling work. Neither is the expected endpoint. Both are possibilities the Phase II workplan will weigh, and a reserve is how you plan for a possibility you cannot yet price.
Here is the decision executives should be making today. Fund the certain work in the FY2027 plan, ring-fence a reserve for the contingent work, and do not wait for a balloted standard to release either. A capital plan that lags the compliance calendar does not save the money. It pays a premium for it.
What to do in the next ninety days
The window is short and the actions are specific.
Registered entities
File the Level 3 Alert response by August 3. It is a Rule 810 obligation regardless of the Alert's non-penalty framing, and it is now the evidentiary base for a rulemaking that exists rather than one FERC might open. Say in it what you want the standards to reflect.
CIP Senior Managers
This is your file under CIP-003, not a planning department's. Before the standards land, do three things. Map the obligations already accruing at the interface, the SCADA points, the fault recorders, the RAS participation, the shared protection data, against your current CIP-002 categorization, and document where that categorization gets hard to defend. Treat your interconnection-agreement controls as compliance evidence, because once the counterparty registers an auditor will read them that way. Put your position on the scenario question on the record now, internally and in the August 3 response.
Large load operators and hyperscalers
The registry criteria are being drafted against a December 31 deadline. Engage Project 2026-02 during this drafting window, not after balloting, because the criteria define the population and the population defines your obligations. File comments that address where the size threshold and the functional triggers should sit.
Security and AI governance leadership
Open a joint file this quarter and name a single owner across both functions before March 1, 2027, when the Phase II workplan scopes whether your control systems and your workload decisions become compliance objects. Neither team owns the other's half today.
Capital allocators
Put the interface spend in the FY2027 plan now, and open a named reserve line for the CIP-equivalent contingency. Tie both to the December 31 and March 1 milestones, so the capital calendar tracks the compliance calendar rather than trailing it.
Is your organization ready?
Three questions every utility and large-load operator should answer this quarter.
Do we know where computational load intersects our existing CIP obligations, and who owns that boundary internally?
Have we identified which of our AI or large-load customers could become newly registered entities under the December 31 registry criteria?
Does our FY2027 budget already carry the operational and cybersecurity investments this order makes increasingly hard to defer?
The bottom line
The order did not decide what computational load will owe. It created the entity that will owe it, set the date the answer arrives, and left the AI Reliability Boundary, the line between what the grid must command and what it leaves to contract, for Phase II to draw.
The modeling requirements are the visible half. The registry criteria, and the security obligations that may follow registration, are the half that will define this file for the next decade.
Join the conversation on this topic with Keirsten on LinkedIn
