CIP-008-6 R4 Notifications and reporting for Cyber Security Incidents

Most R4 failures start before anyone files a report, because the team never documented how it decides an event is a Reportable Cyber Security Incident or an attempt to compromise an applicable system. Without written criteria, the one-hour and next-day clocks start at inconsistent points, and an assessor cannot tell whether the entity acted within the deadline. Close the gap by writing decision criteria into the incident response plan, recording the time and the person who made each determination, and having an on-call lead confirm the classification in the incident record. Ask your compliance lead to walk through two past events against the criteria to test whether they produce the same answer.

The clock is easy to miss when no single role owns it, because responders focus on containment and the reporting step falls between teams. Name one role, such as the incident commander or a designated reporting lead, with authority to file the initial notification and a backup for nights and weekends. Put that role in the plan, in the on-call roster and in the case record, with the determination time captured the moment the classification is made. Test the handoff in your next exercise by timing how long it takes the named role to start a notification from the moment an incident is declared.

Part 4.1 requires initial notifications and updates to include, at minimum, the functional impact, the attack vector used and the level of intrusion achieved or attempted. Reports that describe only that something happened, without these three fields, are incomplete on their face and can be found deficient in an audit. Build a short notification template with a required field for each element, and make the responder state "unknown" with a reason rather than leaving a blank. Your case management record should hold the same values, so the report can be generated from data instead of rewritten from memory.

Part 4.3 requires updates within 7 calendar days of determining new or changed attribute information, so the clock restarts each time the facts change. Teams often send one initial report and then forget that later findings, such as a newly identified attack vector or a changed intrusion level, trigger their own deadline. Track each new or changed attribute as a dated entry in the case timeline, calculate the seven-day deadline from that entry, and assign an owner to each open update. Review open updates at every incident status meeting until the investigation closes.

A notification that never reaches the E-ISAC or the federal cyber incident center does not satisfy R4, regardless of how carefully it was written. Entities sometimes rely on a stale email alias, a personal mailbox or a contact list that nobody has tested. Confirm the current submission method and contact details with the E-ISAC and the NCCIC or their successors before an incident, store them in the plan, and record proof of each submission, including the time sent and any acknowledgment. Run a periodic test of the channel as part of your exercise schedule so the first real use is not the first verification.

A case management platform does not make an entity compliant, but it can hold the timestamps, attribute changes and evidence that show when each R4 step occurred. DFIR-IRIS is licensed under LGPL-3.0-or-later and keeps each case as one record of assets, indicators, tasks and evidence with a full audit trail, which gives you a consistent source for notification times and update dates. Use it to log the determination, the notification and each attribute change as timed entries, then generate the report from that record. Confirm with your own legal and compliance team that the audit trail and report formats meet your evidence requirements, since the platform cannot decide what the standard demands.

An implementation partner such as DeployOpen can prepare the systems and evidence for R4, including case workflows, notification templates, timed records and tested reporting channels, under a written scope. The organization still owns its incident response plan, its determinations and its filings. Only the Regional Entity or NERC, acting as the Compliance Enforcement Authority, can assess whether the entity meets R4, so the independent review comes from that process rather than from the implementation work. Ask any partner to state in the scope which deliverables are prepared systems and documents and which are decisions the entity must make itself.

Most of the cost is staff time and monitoring coverage, because the open-source tools in this workflow are licensed under open-source terms and the spend shifts to labor, hosting and support. One-time costs include drafting the criteria for reportable incidents and attempts, writing notification templates, building contact lists, setting up case tooling and running a tabletop exercise. Recurring costs include staff on call for the one-hour clock, template upkeep, the 15-month testing cycle and evidence retention. The main drivers are the number of BES Cyber Systems in scope, how many approvals a notification needs and whether you already run a 24-hour security function. No supplied figure gives a price, so ask any provider for a written, fixed scope with separate line items for setup, testing and ongoing support, and ask which items recur.

The duration depends on what already exists, so ask for it in a written scope before work starts. An organization with a tested incident response plan, current E-ISAC contact details and an established case process needs less time than one starting from scratch. Typical work covers mapping the point where an incident is determined, writing notification templates with the required fields, configuring the case workflow and alert sources, rehearsing both clocks in a tabletop exercise and collecting evidence. Because the one-hour clock starts at determination, the workflow must exist before the first real incident occurs. Confirm with the E-ISAC, your Regional Entity or your own procedures which submission channel and contacts apply to your organization.

Your staff own the decisions, and the workflow needs people from security operations, OT operations, compliance and communications. Security operations staff classify alerts and decide whether an event is a reportable incident or an attempt to compromise an applicable system. OT or control room operators describe functional impact in plain terms. Compliance staff keep the record of determination times, notification content and updates. Legal or executive approvers sign off on submissions where your procedures require it. Because the clocks run around the clock, name a backup for each role, and train every backup on the template fields and the submission channel.

Yes, a team can build and run R4 in-house if it can meet both clocks and keep complete records. The organization owns the obligation in every case. An implementation partner can prepare systems, case tooling and evidence templates, but it cannot file reports on your behalf or certify your compliance. Regional Entities and NERC monitor compliance through audits and other monitoring, and no third party issues a CIP certificate. Build in-house if you already run a 24-hour security function and can staff the roles described above. Bring in outside help for build work, tabletop testing or tooling if internal capacity is thin, and ask for a written scope that names who does each task.

An auditor checks whether your records show each reportable incident and each attempt was reported on time and with the required content. Expect to produce:

• Records of the determination time, so the one-hour and next-day clocks can be measured.
• Initial notifications showing functional impact, attack vector and the level of intrusion achieved or attempted.
• Evidence of notification to the E-ISAC and, where applicable, the NCCIC.
• Update records dated within 7 calendar days of new or changed attribute information.

The auditor selects the sample, so keep a complete record for every incident, including incidents that later proved to be attempts. Audit timing depends on your registration: Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years, and other registered entities are audited on a risk-based schedule set by the Regional Entity.

R4 is the external reporting step, and it depends on R1 for its criteria and on R2 and R3 for keeping the plan current. R1 defines what counts as a Reportable Cyber Security Incident and an attempt to compromise, so the classification you make there starts the R4 clocks. R2 requires testing each plan at least every 15 calendar months, and the test should confirm the notification steps work in practice. R3 requires plan updates within 90 days after a test or real incident, and within 60 days after changes to roles, teams or technology. A notification path that fails in a test should feed back into the plan. An assessor may read these parts together, so a notification sent on time from a template with outdated contacts can point to a gap under R3.

Open-source tools can hold the case record, timeline and alert trail that R4 evidence depends on, but none of them submits the report for you. Relevant options include:

• DFIR-IRIS documentation describes how cases hold assets, indicators, tasks and evidence in one record with an audit trail, builds a consolidated timeline, logs evidence with SHA-256 verification and generates reports from case data.
• Wazuh writes matching alerts to log files and maps them to MITRE ATT&CK, which supports detection timestamps.
• OpenSearch Security Analytics records detector matches as findings with rule, log type and severity.
• MISP records sightings and exports indicators to STIX, which supports sharing with other organizations.

Before relying on any tool output, confirm that your E-ISAC submission route and NCCIC contact match your environment and your written procedure.

The most common failure is a clock that starts without a recorded determination time, so the team cannot show when it began. NERC's Sanction Guidelines reference a maximum civil penalty of $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 (January 2025) and shown in the eCFR in October 2026, which makes each documentation gap a financial risk. An illustrative case: an analyst flags suspicious logins at 17:00, the on-call lead cannot be reached, and the notification template has no fields for attack vector. Each delay becomes a documentation problem before it becomes a reporting problem. Check after-hours coverage, confirm that templates include every required field, and require a timestamped determination log for every event.