FERC 2025 CIP Audit Findings: DER Impact Ratings, Vendor Oversight Gaps, and Cloud Compliance Risk
By Patrick Miller
FERC’s latest CIP audit lessons for 2025 highlight three rising compliance risks. Entities are undercounting DERs in GOP control center impact ratings, outsourcing compliance work without adequate oversight, and moving EACMS or PACS functions to the cloud without a defensible evidence path. These issues now represent real audit exposure across the US bulk power system.
Overview
The latest FERC staff Lessons Learned from Commission-Led CIP Reliability Audits sends a clear message, sourced from facts on the ground. It reflects what auditors actually saw at US utilities in Fiscal Year 2025. Three patterns stand out. First, entities are undercounting distributed energy resources (DERs) when rating generator operator control centers. Second, outsourcing compliance work does not transfer compliance risk, and evidence gaps are surfacing in audits. Third, moving associated cyber asset functions into the cloud without a defensible path through CIP creates audit exposure. The report is brief, but the implications are large.
What Changed and Why It Matters
FERC staff summarize three lessons learned that map cleanly to near-term audit risk:
DER inclusion for GOP control center impact rating under CIP-002-5.1a R1. Audit teams found entities failing to include distribution-connected generation and DER aggregation when testing the 1,500 MW threshold in Attachment 1 criterion 2.11. The report underscores that both BES and non-BES generation count toward that threshold when operated from the same Control Center. Failing to include DERs can push a control center into the wrong impact level, which then drives misapplied controls across the entire CIP stack.
Third-party reliance without real oversight touching CIP-003-8, CIP-006-6, and CIP-010-4. Staff reviewed cases where firewall rule hygiene, PACS testing cycles, and vulnerability assessment activities were delegated to vendors, yet the registered entity lacked ongoing oversight, documented role clarity, or retrievable evidence. The consistent theme is simple. You can outsource tasks, not accountability.
Cloud services used for associated cyber asset functions intersecting CIP-004-7 and CIP-010-4. Staff describe entities that moved EACMS or PACS functions into SaaS models and then could not demonstrate the required baselines, software integrity verification, vulnerability assessment methods, or personnel screening controls expected by CIP. Some vendors told utilities their offerings were “CIP compliant,” but audit evidence did not support that claim across all applicable requirements.
Taken together, these lessons show an audit posture moving steadily from “show me the policy” to “show me the evidence trail that proves you applied the right controls to the right assets.” This is a healthy trend from a security perspective, and one that will demand tighter engineering, operations, and compliance coordination.
The Three Pressure Points in Detail
1) DERs now change your control center math
What auditors saw. In several cases, entities operating a mix of transmission-connected BES generation and hundreds of smaller DERs from the same physical control center did not include those DERs in the aggregate capacity calculation for Attachment 1 criterion 2.11. FERC’s language is direct. The 1,500 MW test does not limit the tally to BES resources. If you operate both BES and non-BES generation from the same control center, you count all of it when determining the impact level. The report even cites real-world cases where the DER fleet exceeded 1,700 MVA in a single interconnection. This isn’t a new position from FERC. It goes back to the 2017 report, where they stated “Consider all owned generation assets, regardless of BES-classification, when evaluating impact ratings to ensure proper classification of BES Cyber Systems” - it just reinforces the position and specifically includes DER aggregators.
Why it matters. Control Center impact rating is foundational. If you under-rate the Control Center, every downstream control that keys off that rating can be wrong by design, from PACS testing cycles to transient device controls. The report also flags cases where BES and DER operations share a single site or staff without clear segmentation, echoing 2024 findings that logically segmented control rooms at one site are still one Control Center for categorization. The message is to evaluate operations holistically and then document the engineering logic behind the rating.
What good looks like. A defensible categorization package should document the operating footprint of GOP functions across the preceding 12 months, inventory both BES and non-BES generation tied to those operations, show the aggregation method, and then demonstrate the Control Center rating decision. If the total meets or exceeds 1,500 MW in a single interconnection, categorize as Medium Impact under 2.11 and align controls accordingly.
Table 1. DER inclusion changes the categorization outcome
Area | FERC observation | Practical implication |
---|---|---|
Scope of counting | Entities missed DERs and distribution-connected generation when applying Attachment 1 2.11 threshold | Aggregation must include BES and non-BES resources operated by the GOP control center |
Shared operation | BES and DER fleets were dispatched from the same facility with shared staff and systems | Logically separated rooms at a single site still count as one control center |
Impact | Undercounting real power capability misclassified GOP centers as Low Impact | Expect uplift to Medium Impact categorization if aggregate exceeds 1,500 MW |
2) Third parties can help you work, not carry your risk
What auditors saw. In one case, a third party was chartered to maintain firewall rule hygiene for low-impact assets under CIP-003-8, Attachment 1 section 3. The vendor did not complete the required rule reviews. The registered entity had no proactive oversight control that would have detected the lapse before the audit. In another case under CIP-006-6 R3.1, a cloud-hosted PACS required 24-month testing that the vendor failed to perform on time. The entity did not have calendar control or status attestations that would have surfaced the miss. FERC also describes a CIP-010-4 R3 scenario where a third party performed vulnerability scanning and triage, while the entity did not participate in risk review or prioritization. In all three patterns, the entity lacked evidence of ongoing oversight and could not show the auditors that required activities occurred on time and to standard.
Why it matters. The report repeats a core message. NERC registration and the Federal Power Act tie compliance obligations to the registered entity, not its vendors. The entity can and should use third parties, but must retain control of role definitions, acceptance criteria, and the evidence trail. Audit risk increases when the system of control for vendor-performed tasks is based on trust rather than verifiable status, deliverables, and alerts.
What good looks like. Build a vendor oversight model that treats delegated compliance tasks as controlled processes, not tickets, general attestations, or overly vague contract language (e.g., “will adhere to all applicable NERC CIP standards”). Maintain clear and direct contract language that binds the vendor to the requirements, keep a living RACI with named roles, implement status telemetry and other evidence submittals on a defined cadence, and retain artifacts in an evidence repository the responsible entity controls. Where the vendor operates infrastructure, establish an agreed audit window and data access plan so the responsible entity can retrieve proof without delay. This is a significant shift for both the responsible entity and the supporting vendor.
Table 2. Evidence package for third-party-performed CIP tasks
Evidence element | Why auditors care | What to keep on file |
---|---|---|
Role and requirement mapping | Confirms who is performing which requirement and why | Responsibility matrix linked to specific CIP parts and assets |
Contractual bindings | Ensures vendor obligations align with NERC Rules of Procedure and applicable Reliability Standards (CIP, O&P) | Scope of work, SLAs, data access requirements, security terms |
Operational telemetry | Validates that activities occurred on time and as required | Firewall reviews, PACS test records, scan results, logs |
Oversight cadence | Proves entity oversight rather than blind delegation | Review evidence records, meetings, approvals, audit trail comments |
Evidence retention | Demonstrates audit readiness | Locally stored evidence repository controlled by responsible entity |
3) Cloud services and associated cyber assets remain a compliance trap
What auditors saw. Staff highlight two scenarios. First, an entity used a SaaS model for PACS, but lacked a documented agreement that spelled out roles, responsibilities, security controls, and compliance requirements. The entity could not demonstrate compliance with CIP-004-7 and CIP-010-4. Second, another entity used cloud-provided MFA for EACMS and remote access into devices inside the ESP. Again, the entity had no formal agreements or evidence linking the service to CIP control expectations and failed to demonstrate compliance.
Why it matters. Current, enforceable CIP standards do not explicitly contemplate EACMS and PACS functions hosted as cloud services. That does not make cloud impossible, but it elevates the burden of proof - even with the new accommodating language in CIP-004-7 and CIP-011-3. The report points to specific sticking points you would expect in multi-tenant or abstracted platforms. For example, CIP-010-4 R1.6 expects software source identity and integrity verification prior to baseline-deviating changes, while many cloud offerings abstract underlying software delivery. CIP-010-4 R3.1 expects an active or paper vulnerability assessment at a defined cadence, which can be hard to execute credibly against cloud-hosted control planes. CIP-004-7 creates challenges for personnel screening and awareness training when the people administering parts of your control stack are the Cloud Service Provider’s (CSP’s) employees/staff. The report also cautions that entities who placed low-impact operations in the cloud later found themselves redesignated to medium impact due to asset changes, which immediately created a compliance gap (watch for the potential that this could be linked to the first issue above where Impact Ratings may need to shift).
What good looks like. If cloud is in scope, document how every applicable CIP requirement is met for that component, not just the control function you bought. That means mapping identity proofing, training, baseline content and provenance, change control, monitoring, vulnerability assessment, time-bounded testing, data residency, and evidence retention. If any of those cannot be met with CSP attestations and evidence (proof), re-architect to keep that function off cloud for medium and high impact environments. For low impact, treat cloud use as a transitional state with a clear plan for uplift if the impact rating changes.
Table 3. Cloud red flags that lead to findings
Cloud risk | Audit concern | Safer approach |
---|---|---|
"CIP compliant" SaaS claims without evidence | Marketing replaces control evidence | Map each CIP requirement to proof and hard evidence artifacts |
No software provenance or baseline visibility | Fails CIP-010-4 R1.6 integrity verification | Use trusted repositories with verifiable delivery paths |
Inability to run or obtain vulnerability assessments | Fails CIP-010-4 R3.1 assessment requirements | Require scan access or avoid cloud for EACMS/PACS |
CSP personnel have privileged access | No PRA or training evidence for CIP-004-7 | Contract for requirement of PRA records |
Low Impact cloud design later becomes Medium Impact | Architecture becomes non-compliant | Plan redesign triggers for impact rating changes |
A Practical Readiness Roadmap That Aligns with These Findings
For categorization and DERs: Inventory generation that your GOP control center dispatches or monitors across the prior 12 months. Include transmission-connected BES generation and distribution-connected DERs. Treat shared-site control rooms as a single Control Center for categorization. Document aggregation logic and apply Attachment 1 2.11 cleanly with all of the above included. If the total equals or exceeds 1,500 MW in a single interconnection, uplift to Medium Impact and plan the necessary control set.
For third-party oversight: Write the specific requirements directly into contracts and operating playbooks. Keep a single source of truth for who performs each task against each requirement (e.g., RACI, but include any applicable third-party as a participant), with due dates and acceptance criteria. Establish telemetry that alerts the responsible entity if a time-bound activity is overdue, rather than waiting for an annual health check. Keep the audit evidence in a responsible entity-owned repository.
For cloud use: Start by assuming that associated cyber asset functions for medium and high impact environments will be difficult to prove out in cloud today. If you proceed, map every applicable requirement to an evidentiary control and prove that you can receive the proof when asked. If the vendor cannot contractually commit to data access, attestations (where applicable), software provenance, baseline visibility, and vulnerability assessment results - and all of the other requirements - then redesign. For low impact, maintain a trigger-based uplift plan with plenty of lead time that addresses the moment your footprint crosses into medium impact.
Questions to prepare for the next audit cycle
Categorization logic. Can you show the 12-month aggregation that includes DERs and distribution-connected generation for GOP Control Centers, and the Control Center rating decision that followed?
Vendor control of time-bound tasks. For every third-party-performed task with a calendar boundary, can you show the proactive mechanism that would tell you it is overdue?
Evidence residency. If a vendor holds the logs, test results, or scans, do you have a current copy in your repository and a defined retrieval window for new pulls during an audit.
Cloud baseline and provenance. For any component in cloud, can you demonstrate software source identity, integrity verification, and the baseline elements expected by CIP-010-4. If the CSP cannot provide it, do you have a compensating design.
Personnel controls across organizational boundaries. Where CSP or vendor staff have privileged roles, can you produce personnel risk assessment, background checks against your criteria, and security awareness training proof that satisfies CIP-004-7 expectations.
Why This Report Fits the Larger US Policy Arc
This lessons-learned cycle continues the steady shift from static documentation to risk-aligned operational and security control. It reinforces prior staff observations from 2017 through 2024 on categorization rigor, third-party control, and evidence management. It also fits with the broader trend of addressing modern architectures such as virtualization and cloud through rigorous standards work rather than blanket acceptance. Until new standards are in force, registered entities should expect auditors to probe whether today’s designs can meet today’s requirements. The most compliance-resilient posture is to design for verifiability as a critical function in addition to reliability and security.
Final Take
FERC’s 2025 audit lessons are concise but pointed. If you operate DERs under GOP control, the math for Control Center impact rating now needs to include the full picture. This is a significant shift and may take some organizations by surprise. If you rely on third parties, your oversight and evidence must be continuous and under your control. If you plan to move associated cyber asset functions into cloud, do so carefully and treat today’s standards as the constraints they are and design for demonstrability. None of this is about checking boxes. It is about engineering a posture where you can prove that the right controls are protecting the right assets at the right time.