NERC’s Project 2026-02 Computational Loads which proposes an introduction of the Computational Load Entity (CLE), marks a notable shift in how the Bulk Power System accounts for large, rapidly scaling sources of demand. For those working within the NERC CIP compliance world, this is less about a brand-new concept and more about the expansion of familiar regulatory patterns into a new class of industry participants.
The April 2026 proposed updates to the Rules of Procedure and NERC Glossary signal that NERC is moving deliberately to bring high-density computational loads into clearer regulatory scope, particularly where those loads introduce planning and operational uncertainty.
From Passive Demand to Reliability Participant
Historically, large loads on the grid have been treated as planning considerations rather than registered entities with defined reliability responsibilities. The emergence of hyperscale data centers, AI infrastructure, and colocation environments has started to blur that boundary.
The CLE construct reflects a recognition that certain loads are no longer passive. Their size, ramp characteristics, and operational behavior can influence system conditions in ways that resemble generation or transmission impacts. NERC’s proposed definition of Computational Load and the associated CLE classification formalize that shift by identifying the end-user or hosting entity as a participant in reliability, not just a consumer of power.
What stands out is not just the definition itself, but the intent behind it. NERC is creating a pathway to visibility and accountability in an area where, until recently, there has been limited standardized regulatory oversight.
NERC Registration as the Inflection Point
The proposed registration thresholds introduce a practical filter, targeting facilities with sufficient scale and system connectivity to affect the BPS. Once an organization crosses into registered entity status, the conversation changes immediately.
Summary of Revisions
To add a new Computational Load Entity functional entity, NERC must revise Rules of Procedure Appendix 2 (Definitions Used in the Rules of Procedure); Appendix 5A (Organization Registration and Certification Manual); and Appendix 5B (Statement of Compliance Registry Criteria). The following provides a summary of the proposed revisions to each of these appendices:
Appendix 2 (Definitions Used in the Rules of Procedure)
Appendix 2 to the NERC Rules of Procedure includes defined terms used throughout the Rules of Procedure. The proposed revisions add the following two terms and definitions:
• “Computational Load means Load comprised of electric power demand from information technology equipment, such as servers, storage, and networking hardware.”
• “Computational Load Entity means the end-user or the entity that hosts end-users that receives electric power for Computational Load.”
Appendix 5A (Organization Registration and Certification Manual)
Appendix 5A contains the process used by NERC and the Regional Entities to register certain functional entity types to which mandatory and enforceable Reliability Standards apply. The proposed revisions to Appendix 5A add “Computational Load Entity (CLE)” as a type of entity that is required to register on the NERC Compliance Registry. In addition, proposed revisions to Appendix 5A include minor administrative corrections.
Appendix 5B (Statement of Compliance Registry Criteria)
Appendix 5B contains the specific criteria NERC and the Regional Entities use to identify which organizations may be candidates for registration for functional entity types. In accordance with the Federal Power Act, NERC must identify the owners, operators, and users of the BPS who have a material impact on the BPS. To that end, the proposed revisions in Appendix 5B add threshold criteria to identify those organizations that should be registered as Computational Load Entities, summarized below:
1. A Computational Load Entity must be the end-user or the entity that hosts end-users that receives electric power for Computational Load; and
2. A Computational Load Entity that 1) contributes to an aggregate connected Load capability greater than or equal to 20 MW; 2) at a single point of interconnection to the Bulk Power System at a voltage greater than or equal to 60 kV; and 3) hosts 1 MW or greater of Computational Load.
Candidates must meet all the criteria in the proposed revisions in Appendix 5B in order to be registered as a Computational Load Entity.
For many potential CLEs, this would represent their first exposure to NERC compliance expectations. That transition is rarely trivial. The compliance requirements most likely coming around documentation, evidence retention, internal controls, and audit readiness that are often unfamiliar to organizations outside the traditional utility or generation space.
This is where the real impact of the CLE designation begins to take shape. Registration is not just a label. It is the entry point into a structured NERC compliance ecosystem that expects repeatability, traceability, and demonstrable control over reliability activities.
Will Computational Load Entities Follow the Low Impact Model?
Although no specific Reliability Standards have been finalized for CLEs, the direction of travel feels familiar to anyone who has worked through the evolution of the CIP standards.
NERC has indicated a phased or “bridge standard” approach, which strongly suggests that initial requirements will focus on establishing baseline practices rather than imposing fully developed, high-burden obligations. This pattern closely mirrors how Low Impact BES Cyber Systems were introduced, where the emphasis was placed on foundational controls, documented processes, and demonstrable awareness of cyber risk.
For CLEs, this could reasonably translate into early expectations around coordination, visibility into load behavior, and internal governance over operational changes that may affect the system. Over time, those expectations would likely mature, particularly as NERC gains more insight into how computational loads behave during disturbances and system events.
Governance, Risk, and Compliance for Computational Load Entities
What makes CLEs particularly interesting is that many of the organizations that may fall into scope are not built around compliance frameworks in the way utilities are. Their operational culture is often driven by uptime, performance, and rapid scaling, not regulatory traceability.
Introducing NERC oversight into this environment creates a gap that cannot be closed with documentation alone. It requires a structured approach to governance, risk, and compliance that aligns operational behavior with reliability expectations.
In practice, this means moving beyond reactive compliance and toward integrated control environments. Processes need to be defined in a way that ties system behavior to reliability outcomes. Evidence needs to be generated as a byproduct of operations, not reconstructed after the fact. Risk needs to be continuously understood, not periodically assessed in isolation.
For organizations already operating under CIP, this will feel like an extension of existing disciplines. For new entrants, it will feel like an entirely new operating model.
Preparing for What Comes Next
The CLE proposal is still in development, industry stakeholder input will shape its final form. That said, the underlying direction is clear. NERC is expanding its scope to address reliability risks introduced by large, dynamic loads, and it is doing so using mechanisms that have been proven in other parts of the framework.
For those who may be affected, the window between awareness and enforcement is a big gap. Understanding how registration could apply, how internal processes align with reliability expectations, and how evidence of control can be produced consistently will matter far more than reacting once standards are finalized.
From a broader perspective, CLEs represent a continuation of a long-standing trend. As the grid evolves, so does the definition of who is responsible for its reliability. This is simply the next category of NERC entity being brought into that shared responsibility.
NovaSync will be keeping our eyes and ears open for further developments on the Computational Load Entity and how it will affect our industry.