CIP-008 incident response plans for generation sites: writing one and testing it

An incident response plan is required at every NERC CIP impact level. High and medium impact BES Cyber Systems get the requirement from CIP-008-6. Low impact sites, where most solar, wind and battery plants under CIP land, get a shorter version from CIP-003-9 Attachment 1, Section 4. The two are close relatives, which is why they get mixed up: the test intervals, update deadlines and reporting obligations all differ.

This post separates the two, then covers how to write a plan a small site team can run, and how to test it.

First: which version applies to your site

Two questions come before the plan.

• Is the plant under CIP at all? Generating plants that are BES facilities, which for solar, wind and storage usually means more than 75 MVA in aggregate connected at 100 kV or higher, are under the CIP standards. Category 2 inverter-based resources, registered with NERC since May 15, 2026, are not BES facilities and are not subject to CIP. Registration alone does not bring CIP with it.
• If it is under CIP, how does CIP-002 rate it? Under CIP-002-5.1a criterion 2.1, a generating plant is medium impact only at 1,500 MW or more at one plant location in one Interconnection, so most sites rate low impact. A Control Center that performs Generator Operator functions for 1,500 MW or more in a single Interconnection is medium impact under criterion 2.11, even when every plant it runs is low impact.

Low impact sites follow CIP-003-9 Section 4; high or medium impact systems, such as a fleet control center's, follow CIP-008-6. One plan can serve both if it meets CIP-008-6 for the high and medium impact systems.

Low impact: what CIP-003-9 Section 4 asks for

CIP-003-9 R2 requires a documented cyber security plan for low impact BES Cyber Systems that includes the sections in Attachment 1. Section 4 covers incident response. The plan can be written by asset or for a group of assets, and it has to include:

• 4.1 Identification, classification and response to Cyber Security Incidents.
• 4.2 Determining whether an identified Cyber Security Incident is a Reportable Cyber Security Incident, and notifying the E-ISAC, unless prohibited by law.
• 4.3 Roles and responsibilities of the incident response groups or individuals.
• 4.4 Incident handling procedures.
• 4.5 Testing the plan at least once every 36 calendar months, by responding to an actual Reportable Cyber Security Incident, with a paper drill or tabletop exercise, or with an operational exercise.
• 4.6 Updating the plan, if needed, within 180 calendar days after a test or an actual Reportable Cyber Security Incident.

Not there: a separate lessons-learned deadline, reporting of attempts to compromise, and a list of reporting attributes. Those belong to CIP-008-6. Incident response is also a low impact policy topic under CIP-003-9 R1, reviewed and approved by the CIP Senior Manager at least once every 15 calendar months.

High and medium impact: what CIP-008-6 adds

CIP-008-6 applies to high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS). It has four requirements.

• R1, the plan: processes to identify, classify and respond to Cyber Security Incidents (Part 1.1); criteria to evaluate and define attempts to compromise, and a process to decide whether an incident is reportable or an attempt to compromise and to notify (Part 1.2); roles and responsibilities (Part 1.3); and incident handling procedures (Part 1.4).
• R2, implementation and testing: test each plan at least once every 15 calendar months, by responding to an actual Reportable Cyber Security Incident, with a paper drill or tabletop exercise, or with an operational exercise (Part 2.1). Use the plan when responding to a real incident or performing an exercise, and document any deviations from it (Part 2.2). Retain records of Reportable Cyber Security Incidents and of incidents that attempted to compromise an applicable system (Part 2.3).
• R3, review and update: no later than 90 calendar days after a test or an actual Reportable Cyber Security Incident response, document lessons learned, update the plan and notify the people with a defined role (Part 3.1). No later than 60 calendar days after a change to roles, response groups or individuals, or technology that would affect your ability to run the plan, update it and notify those people (Part 3.2).
• R4, notification: notify the E-ISAC and, in the United States, the National Cybersecurity and Communications Integration Center (NCCIC) or its successor, unless prohibited by law. Initial notification is due within one hour of determining that an incident is a Reportable Cyber Security Incident, and by the end of the next calendar day after determining that an incident was an attempt to compromise an applicable system (Part 4.2). Notifications include, to the extent known, the functional impact, the attack vector used, and the level of intrusion achieved or attempted (Part 4.1). Updates are due within 7 calendar days of determining new or changed information (Part 4.3).

The one-hour clock runs from your determination under your R1 process, not from when the activity started, so the classification step in Part 1.2 deserves the most care.

The two side by side

• Test: every 36 calendar months at low impact; every 15 under CIP-008-6.
• After a test or real reportable incident: update if needed within 180 calendar days at low impact; lessons learned, update and notification within 90 under CIP-008-6.
• Attempts to compromise: outside the low impact plan; criteria, records and notification under CIP-008-6.

Writing a plan a small site team can run

Most generation sites are unstaffed, and the responders are spread across an operations center, an O&M contractor and equipment vendors. The plan has to work for that.

• Name roles as well as people, with a backup for each, including outside parties: the O&M contractor, the inverter or battery vendor, the integrator.
• Write down how an incident gets noticed at a site nobody is at: who watches the alarms and logs, and what they do with something unusual.
• Give the person on call a short decision path for classification and reportability, with the criteria written out. A plan that says "assess the situation" leaves the hardest decision to the worst moment.
• Keep the E-ISAC contact details in the plan, and for high and medium impact systems the NCCIC route too, so nobody has to search for them.
• Say how you would cut the site's remote connections, including vendor remote access, and who may do it. At low impact, Section 6 already asks for a method to disable vendor electronic remote access.

Testing it

Both standards accept the same three kinds of test: a real reportable incident, a paper drill or tabletop exercise, or an operational exercise. For most generation sites a tabletop is the practical choice.

• Pick a scenario that fits the site, for example a vendor remote session into the plant controller outside any maintenance window, or inverters changing setpoints with no dispatch instruction behind it.
• Run it with the people named in the plan, outside parties included if you can, and time the reportability decision against the deadlines that apply.
• Record the date, attendees, scenario, decisions and what did not work. The record has to show the exercise was carried out, not only planned.

Records to keep

• The current plan and earlier versions, with approval dates.
• Each test, and the plan updates that followed it, dated so the 180-day or 90-day window can be checked.
• Incidents you classified as not reportable, with the reasoning. Auditors may ask why an event was not reported.
• Under CIP-008-6, records of Reportable Cyber Security Incidents and attempts to compromise (Part 2.3), and copies of the notifications and updates you sent.

CIP-003-9 asks you to keep evidence for three calendar years unless your Compliance Enforcement Authority asks for longer.

Where automated evidence collection helps

Classification and the reportability decision are human work, and so is the tabletop. Automation helps with the record underneath: device configurations and logs collected read-only on a schedule, compared with each device's baseline so a change shows up for review, and stored so you can show they were not altered afterwards. That gives the team a dated view of what changed and when, and gives the lessons-learned review something firmer than memory.

What changes next

CIP-008-6 is the version in force in the U.S. today. CIP-008-7.1, part of NERC's virtualization revisions, takes effect on July 1, 2028. For low impact sites, CIP-003-9 applies until CIP-003-10 takes effect on July 1, 2028, followed by CIP-003-11 on July 1, 2029.