Requirements at a glance
Cyber Security Incident response plan
Document processes to identify, classify and respond to Cyber Security Incidents; determine whether an incident is a Reportable Cyber Security Incident or an attempt to compromise an applicable system; define roles and responsibilities; and set incident handling procedures.
Implement and test the plan
Test the plan at least once every 15 calendar months (through an actual reportable incident, a paper drill or tabletop, or an operational exercise), use the plan when an incident occurs, and retain records.
Review, update and communicate
Within 90 calendar days of a test or actual reportable incident, document lessons learned, update the plan and notify each person with a defined role. Within 60 days of changes to roles, groups or technology, update the plan and notify the people affected.
Notifications and reporting
Notify the E-ISAC and CISA of a Reportable Cyber Security Incident within 1 hour of determining it is reportable, and of an attempt to compromise by the end of the next calendar day. Send updates within 7 calendar days of learning new information.
Plain-English summaries, not the official text. Always work from the official standard on nerc.com and your Regional Entity’s guidance.
Recurring deadlines
| Obligation | Interval | Requirement | In CIP Sentry |
|---|---|---|---|
| Notify E-ISAC and CISA of a Reportable Cyber Security Incident | 1 hour after determination | CIP-008-6 R4.2 | Auto-tracked |
| Notify of an attempt to compromise | End of next calendar day | CIP-008-6 R4.2 | |
| Provide updated attribute information | 7 calendar days | CIP-008-6 R4.3 | |
| Test the incident response plan | 15 calendar months | CIP-008-6 R2.1 | Auto-tracked |
| Lessons learned, plan update and notification after a test or incident | 90 calendar days | CIP-008-6 R3.1 | Auto-tracked |
| Update plan after role or technology changes | 60 calendar days | CIP-008-6 R3.2 |
Rows marked Auto-tracked are calculated by CIP Sentry from your own records and shown as compliance clocks. Build a free calendar of your deadlines
Decide fast, report faster
The hardest part of CIP-008 is not writing the plan. It is making the “is this reportable?” decision quickly and consistently at 3 a.m. Write clear criteria, name who is allowed to make the call, and keep the notification contacts and the reporting form where on-call staff can reach them. The 1-hour clock starts at the determination, not at detection, so record both times.
Tabletops that produce evidence
A good tabletop uses a realistic scenario (for example ransomware on an HMI, or a vendor remote session gone wrong), walks through classification, notification and recovery, and ends with written lessons learned. Those lessons feed the 90-day update clock in R3. Treat the tabletop report as the first piece of evidence, not an afterthought.
Low impact incidents
Low impact incident response lives in CIP-003 Attachment 1 Section 4, with a 36-month test cycle and a 180-day update window. The reporting obligation to the E-ISAC applies there too.
Evidence auditors typically ask for
- The incident response plan, including the criteria used to decide what is reportable and what is an attempt to compromise
- Records of plan tests (tabletop reports, exercise records) no more than 15 months apart
- Incident records with timestamps for detection, determination and notification
- Copies of E-ISAC and CISA notifications and updates
- Lessons-learned documents, plan revisions and notifications to plan participants
How CIP Sentry helps with CIP-008
The reporting clock
Each incident carries its notification deadline from the moment it is determined reportable, counted in hours.
Plan tests on schedule
The 15-month test clock and the 90-day lessons-learned clock are tracked for every plan.
One incident record
Determination, notifications, updates and lessons learned sit together, ready for an auditor.
Linked to recovery
Incident records connect to CIP-009 recovery plans and to any mitigation plans they trigger.
CIP-008 FAQ
What is the difference between a reportable incident and an attempt to compromise?
A Reportable Cyber Security Incident compromises or disrupts an applicable system or its perimeter. An attempt to compromise is an event your process classifies as a try that did not succeed. Your plan must define the criteria, and the reporting deadlines differ: 1 hour versus the end of the next calendar day.
Does a tabletop count as a test?
Yes. A paper drill or tabletop exercise satisfies R2.1, as does responding to an actual reportable incident or an operational exercise.
Last reviewed . Standard versions and effective dates are checked against nerc.com each quarter.