CIP-015-1 R2 INSM data retention: requirements and evidence

CIP-015-1 R2 asks you to keep the right monitoring data, for long enough

R2 asks you to keep the network monitoring data tied to anomalous activity, and to keep it at least until the evaluation and response action is complete. It does not ask you to keep every packet your monitoring captures. If your entity is preparing for CIP-015-1, which is subject to future enforcement from 1 October 2028, the practical question is which records survive once your INSM tool flags something, how long they survive, and whether you can prove both to an auditor. CIP-015-1 R2 carries a Lower Violation Risk Factor, but a gap here still leaves you unable to reconstruct an intrusion inside the Electronic Security Perimeter, which is the risk the requirement exists to address. The requirement is tied to R1. Under Part 1.2 you detect anomalous network activity, and under Part 1.3 you evaluate it and decide on further action. R2 requires documented processes, with an exception for CIP Exceptional Circumstances, that retain the data associated with that anomalous activity at least until Part 1.3 is complete. Data that is not relevant to a detected anomaly does not have to be retained under R2. Two judgment calls usually make this hard. The first is what your organization counts as anomalous, since that definition determines which records enter retention at all. The second is aligning retention periods with the actual duration of your evaluation and response, including investigations that run longer than a routine alert.

Start by writing down your anomaly criteria and mapping each detection type to the records it produces, such as Suricata EVE alerts and related flow or protocol transactions where your tooling supports them. Confirm with your vendor which components keep those records, where they are stored, and how retention is set, rather than assuming defaults. Then set retention timelines that cover your longest realistic Part 1.3 evaluation, and keep system configurations or system-generated reports that show those timelines are in force. Assessors look for evidence that the process runs as documented, so a written retention procedure with matching configuration exports is stronger than a policy statement alone. Ask your implementation partner to test a sample anomaly end to end, from detection through evaluation to the point where data is released, so the documented process matches what the systems actually do.

Which systems and data does CIP-015-1 R2 apply to?

CIP-015-1 R2 sits downstream of the monitoring scope set under R1, and that scope starts with CIP-002-5.1a categorization. The choices below decide which networks generate retained data, which records must be kept, who owns the process, and how the scope changes when CIP-015-2 takes effect.

Confirm high and medium impact scope

CIP-015-1 applies to internal network security monitoring inside Electronic Security Perimeters of high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. Start from your CIP-002-5.1a categorization records, not from a network diagram. A medium impact system without External Routable Connectivity falls outside this retention scope, so document that determination and its basis before you build any retention process.

Map monitoring feeds to each ESP

Retention can only cover data that a monitoring feed actually collects. For each Electronic Security Perimeter in scope, list the network segments, switch span points, firewall logs and intrusion detection outputs that feed the monitoring system. Note any segment with no feed. A gap in feeds is a scoping decision you must justify under R1, and it changes what R2 has to retain.

Define what counts as anomalous

R2 applies to data tied to network activity determined to be anomalous under R1 Part 1.2, and the standard does not require keeping traffic that is not relevant to those detections. Write down the detection logic, the alert triage criteria and the point at which an alert is closed as benign. Those records set the boundary of retained data and are the first thing an assessor will ask to see.

Assign ownership across teams

Retention spans the security operations team that evaluates alerts, the network team that owns the sensors, and the compliance group that holds the evidence. Name one accountable owner for the retention process and document who can extend or release holds on data. Unclear ownership is a common reason that retained records are deleted before an evaluation is closed.

Plan for CIP-015-2 extension

NERC lists CIP-015-2 as extending monitoring to the associated EACMS and PACS, with an effective date of 1 October 2029. Inventory your EACMS and PACS now, including their network paths and log sources, so that your retention design can absorb them later. Treat that inventory as a planning input, and confirm the final scope against the approved standard text when it applies.

Confirm scope with your Regional Entity

Scope decisions that depend on categorization, connectivity or EACMS and PACS boundaries should be confirmed with your Regional Entity before an audit notice arrives. Ask for their interpretation in writing where your environment is unusual, such as shared networks between ESPs or cloud-hosted monitoring. Keep the categorization record, the scope memo and the correspondence together so the decisions can be shown later.

Why retention follows the anomaly, not the traffic

CIP-015-1 R2 does not ask an entity to keep everything its network monitoring captures. The retention duty attaches to internal network security monitoring data associated with network activity determined to be anomalous under R1 Part 1.2, and it lasts at least until the action taken under R1 Part 1.3 is complete. A note in the requirement confirms that monitoring data not relevant to anomalous activity does not have to be retained. That scoping decision shapes the storage design: the entity needs a way to tag or link each anomaly to the flows, alerts and captured records that support its evaluation, so those records survive while routine traffic can roll off on the entity's own schedule.

The entity must define the rules itself. The facts supplied do not set a retention period, and the standard does not define when an action is "complete." Your documented process should state the trigger (for example, closure of a ticket, a decision not to act, or a completed containment), who signs off on that closure, and the minimum time the associated data is held afterward. Confirm with your Regional Entity how it reads "complete" before you finalize the definition. Evidence examples in the standard include retention processes, system configurations and system-generated reports that show retention timelines sufficient to support Part 1.3, so the configuration of the log store, not only the written policy, will be examined.

R2 also allows an exception. The documented process must address CIP Exceptional Circumstances, meaning the entity's own process should say how retention behaves during those events, such as who may suspend or extend deletion and how that decision is recorded. Keep the carve-out narrow in writing. Where a self-hosted stack is used, Suricata EVE JSON output can split alert, flow and protocol records into separate files, and OPNsense can send alerts to syslog, which lets you apply different retention to anomaly-linked records than to bulk traffic metadata. Confirm each product's current retention and rotation options in your own environment before you rely on them.

How an assessor tests the retention process

This table compares each test step an assessor is likely to take on CIP-015-1 R2 retention, the evidence requested for that step, and the findings that appear most often. Read it as a checklist for your own dry run: if you cannot produce the evidence in the right column for a step, expect that step to become a finding. The main takeaway is that assessors test whether the documented process matches what the system actually retains and deletes.

Test step	Evidence requested	Common findings
Confirm a documented retention process exists and covers anomaly-linked data	Written retention process, scope statement tying retained data to anomalous activity under R1 Part 1.2, owner and approval record	Process describes retaining all captured traffic, or says nothing about anomaly-linked scope
Sample detected anomalies and trace each to retained data	Detection records for sampled anomalies, pointers to the stored monitoring data, retrieval results	No trace record links an alert to its stored data, or the stored data has already been overwritten
Check retention lasted until the evaluation or response action was complete	Case or ticket history with completion dates, retention settings and timestamps for the same sampled items	Completion criteria are undefined, so the team cannot show when the action ended
Check CIP Exceptional Circumstances handling	Documented exception procedure, records of any invocation, approvals and the scope affected	Exception handling is not written down, or invocations are not logged for review
Check disposal of data not tied to anomalous activity	Disposal procedure, deletion logs or scheduled purge jobs, samples of unrelated data showing it was removed per process	Deletion runs on a schedule that does not match the written process, or no deletion records exist
Review configurations and reports showing retention timelines	System configuration exports, retention settings, scheduled job definitions and system-generated reports	Configured timelines differ from the documented timelines, or reports are generated manually and cannot be reproduced
Check that the process is maintained and used by staff	Revision history, training or handoff records, evidence that the process was followed in recent cases	Process documents were written for a previous architecture and were not updated after changes

Building the R2 retention process step by step

This sequence turns the R1 detection output into a documented retention process that keeps each anomaly's monitoring data until its evaluation and response are closed, and proves it works before an auditor asks.

Define anomalous data from R1 Part 1.2 output
Start from the detection output your R1 Part 1.2 process produces, such as alerts and the flow or protocol records behind them, and write down which record types count as associated with anomalous network activity. The compliance lead and the security engineers who tune the detection rules do this together, because they know which alerts are raised and which records support them. Done means a written definition that names each record type, the detection source that produces it, and the rule for linking it to an anomaly. Entities are not required to keep monitoring data that is unrelated to detected anomalies, so the definition sets the boundary of what is retained.
Define when evaluation and response are complete
Write the completion criteria for each anomaly, covering the evaluation under R1 Part 1.3, any response action taken, and the point at which the analyst records the outcome. The security operations lead owns this definition, and the CIP Senior Manager or delegate approves it. Retention under R2 runs at least until the action is complete, so a vague closure point becomes a retention gap. Done means a closure standard that an analyst can apply to a ticket and that an auditor can read without interviewing the team.
Configure retention rules per system and data type
Set retention in the INSM platform and log management tools by applicable system and record type, so the anomalous records for each ESP are held until their closure criteria are met. Suricata's EVE JSON output can write alerts, flows, and protocol transactions as JSON records, and it can be split into separate files, while OPNsense can send alerts to syslog in EVE JSON format. Those splits let you match rules to record types, though you should confirm in your own environment how each tool's retention settings and file rotation behave. Done means a configuration export and a short matrix showing each system, record type, and retention rule.
Write the CIP Exceptional Circumstances procedure
Document how R2 applies during CIP Exceptional Circumstances, which the standard excludes from the retention requirement, and define who may declare one and how the declaration is recorded. Legal and compliance review the wording, and the operations manager signs off on the activation steps. Without a written procedure, staff have no defined way to decide whether an exception applies, and any use of it becomes hard to justify. Done means a procedure with activation criteria, approvers, a log of each declaration, and the end-of-exception steps that return the system to normal retention.
Link each anomaly to its retained data and closure
For every anomaly, create a record that holds the alert identifier, the location of the retained monitoring data, the retention rule applied, and the closure record with its date and outcome. The security analyst creates the link at triage, and the reviewer checks it when the ticket closes. Keeping these identifiers together lets you show, for any single anomaly, what data was kept, for how long, and why it could be released. Done means a sample of closed anomalies where each one traces from detection to stored data to closure without manual searching.
Test a full retention cycle and record the result
Run one end-to-end test that injects or selects a known anomalous event, follows it through detection, evaluation, response and closure, and confirms the linked data remains available until the closure point and is then released according to the rule. The security engineer runs the test, and the compliance lead reviews the written result. Record the test date, the scenario, the observed retention behavior, any gaps, and the corrective actions. Done means a signed test record and a dated change entry for any rule adjusted as a result, which also serves as evidence that the process operates as documented.

Evidence that passes R2 and how to keep it current

Auditors testing CIP-015-1 R2 look for a documented process, configuration that matches it, and records tying retained data to specific anomalies and their closure. Each artifact below answers one part of that chain, and each needs a named owner and a refresh cadence between audits.

Documented retention process

The written process states which internal network monitoring data is kept for anomalous activity, how long it is kept at minimum, and when it may be discarded. It must cover the period until the evaluation and response under R1 Part 1.3 is complete, and it must describe how CIP Exceptional Circumstances are handled. Review it at least annually and after any change to the monitoring architecture, with the CIP Senior Manager or delegate approving each version. Confirm with your Regional Entity how it expects the process to be dated and versioned.

Retention configuration settings

Export the actual retention settings from each collection and storage point, such as Suricata EVE JSON output files, log management tools and archive locations on OPNsense sensors. Compare them with the documented process and record any gap as a finding. Capture the configuration after every change and at a fixed interval, and have a security engineer review the export against the process before the record is signed off.

Retained data against anomaly records

System-generated reports should show, for each anomaly that was detected under R1 Part 1.2, that the related monitoring records still exist and have not aged out. Generate these reports on a fixed schedule from the storage platform and keep them with the anomaly log. The reports show whether retention timelines were long enough to support the evaluation, so run them before any scheduled purge job. Confirm which fields your platform can report on, since not all tools expose record-level retention status.

Anomaly-to-retention trace records

A trace record links one detected anomaly to its alert identifier, the monitoring data retained for it, the retention end date and the evaluation ticket. It proves that data was kept for the right reason and not kept indefinitely by default. Build traces at the time of detection rather than reconstructing them later, and review a sample each quarter for completeness, with the security operations lead signing off.

Evaluation and response closure records

Closure records show when each evaluation and any response action finished, which is the event that allows the related monitoring data to be released under R2. Each record should name the analyst, the decision and the date. Retention runs until closure, so a missing closure date leaves the retention period open. Review open items weekly and reconcile closures against the trace records before any purge.

CIP Exceptional Circumstances declarations

R2 is written with an exception for CIP Exceptional Circumstances, so any time retention was suspended or altered under that exception needs a dated declaration. The declaration should state the circumstance, the systems affected, the approving senior manager and the end of the exception. Keep these records with the retention process, and confirm with counsel or compliance how your organization defines and documents such circumstances before relying on them.

What meeting CIP-015-1 R2 costs in money and effort

This table compares the main cost components of retaining anomaly-linked INSM data under CIP-015-1 R2, who is paid for each, whether it recurs, and what drives it up or down. Use the last column as a checklist when you compare written scopes from a partner, since no fixed price or duration applies to every environment.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
INSM platform and licensing	Recurring for commercial tools, one-time setup for open-source	Self-hosted Suricata (GPL-2.0-only) and OPNsense (BSD-2-Clause) remove license spend, but hosting, patching and staff time remain. Sensor count per ESP drives hardware and support load.	Confirm the license terms of every component, the hardware or virtual hosts the sensors need, and who patches and upgrades them after go-live.
Engineering time to configure retention and export	One-time, with periodic review	Number of data feeds in scope, how many alert and flow outputs must be separated into files, and how much retention logic must be built into log management tools.	A written list of data sources, the retention rules to be configured, export formats, and the test that proves retained records match the anomaly workflow.
Storage capacity for retained records	Recurring, growing with use	Volume of traffic linked to anomalous activity, the retention timeline the entity sets for evaluation and response, and how long records must survive while actions are open.	Estimated record volume per day based on the entity's own traffic baseline, the chosen retention period, storage tier and backup copies, and how capacity alerts are handled.
Process documentation and training	One-time build, recurring refresh	Number of teams that touch anomaly evaluation, whether retention rules are written per system or once for the ESP, and how often staff turn over.	Draft retention procedure, role assignments for evaluation and closure, training materials, and a schedule for reviewing the procedure.
Evidence upkeep between audits	Recurring	How quickly configurations change, whether retention settings are exported automatically, and how well anomaly tickets link to the retained data they relied on.	A defined evidence set (retention configuration, system-generated reports, closed anomaly records), its storage location, and the owner who refreshes it each period.
External review or testing	Optional, one-time or periodic	Whether an independent party checks the retention design before the Compliance Audit, and whether tests simulate a delayed evaluation that could lose records.	Scope of the review, the tests performed, the report format, and a statement that the reviewer prepares evidence but does not issue audit findings.
Auditor sampling effort	Recurring at each audit or monitoring engagement	How easily the entity can pull a sample of anomalous events with their retained data and show the action was completed before deletion.	Confirm with the Regional Entity how samples are requested, and make sure the partner's scope includes a sample pull exercise before audit notice arrives.

In-house work, partner work and the auditor's line

The registered entity owns its CIP-015-1 R2 obligations. That means deciding what retention rule applies to network activity determined to be anomalous, approving it, and keeping it current as the environment changes. The retention rule must support the action taken under Part 1.3, so the people who run evaluation and response need a voice in setting the timeline, not only the people who run the tools.

Owning the retention rule: Write the documented process, set the minimum retention period for anomaly-linked data, and assign an accountable owner by name.
CIP Exceptional Circumstances: Decide when the standard's exceptional circumstances allow a deviation from the normal process, define what triggers that decision, and record who made it and why.
Sign-off and change control: Approve the rule and each material change through the entity's own governance, and tie changes to the CIP-010 change process where it applies.
Scope decisions: Confirm which data feeds and which Applicable Systems the rule covers, using the CIP-002 categorization as the starting point.
Ongoing evidence ownership: Keep the approval records and exception logs that an assessor will ask for.

Before relying on any internal decision, confirm the current text of the standard with the Regional Entity and your compliance program.

Where retention programs usually fall short

Most retention gaps under CIP-015-1 R2 come from missing definitions and missing links, not from missing storage. The cards below cover where documented processes break down, and each one names the check that shows whether the process holds up under assessment.

No written end point for action

CIP-015-1 R2 ties retention to the point where the action in support of R1 Part 1.3 is complete, so the process must define what complete means. Without a written definition, staff either delete data while an investigation is still open or keep it indefinitely with no basis. Check that the process names the closure criteria for each anomaly category and who signs off on closure.

Platform defaults set retention

Log platforms and SIEM tools often ship with a retention period that nobody chose for CIP purposes. If that default governs how long INSM data survives, the documented process describes one schedule while the system enforces another. Compare each system's retention settings against the written process and record any difference as a deliberate decision.

No trace from anomaly to data

An assessor will ask you to show that the data kept for a specific anomaly is the data that was evaluated and acted on. If alerts, tickets and stored records cannot be joined by a shared identifier, the retention claim cannot be tested. Confirm that every anomaly record points to the monitoring data that supports it and that the link survives log rotation.

Unrelated data kept without a rule

R2 does not require keeping monitoring data that is not relevant to anomalous activity, but the entity still has to show why it kept what it kept. Broad capture with no written relevance rule makes the scope argument hard to defend and can expand the set of records that must be protected under R3. Write a rule that states which records are retained and which are discarded after evaluation.

Exceptional Circumstances handled informally

The R2 requirement applies except during CIP Exceptional Circumstances, so any deviation from the retention process needs a defined trigger, an owner and a record. Teams that suspend deletion or extend retention in an incident without writing it down cannot show when the exception started or ended. Document the activation criteria, the approver and the log of every exceptional period.

Evidence assembled only for audits

Retention evidence such as process documents, configurations and system-generated reports is only useful if it reflects what happened over the audit period. Building it the week before a Regional Entity notification leaves gaps and invites questions about whether the process ran at all. Schedule periodic exports of retention settings and sample reports so the record builds continuously.

Questions buyers ask about CIP-015-1 R2 retention

How much does meeting CIP-015-1 R2 cost, and what drives the price?

No public figure is supplied for R2 itself, so the cost depends on the scope you agree in writing. Cost comes from four places: the storage and retention infrastructure for monitoring data, the engineering time to define retention processes and configure systems, the internal staff time to review and approve them, and the evidence work that shows retention timelines were met. Storage is usually a recurring cost, while process design and configuration are mostly one-time. Costs rise with the number of ESPs, the volume of monitored network data, and how many systems must be documented. Ask any implementation partner for a fixed-scope quote that separates one-time setup from recurring operation, and confirm with your own vendors what their storage and licensing charges are.

How long does it take to implement CIP-015-1 R2 retention?

The timeline depends on the agreed scope and your environment, and no fixed duration is supplied here. The main variables are how many ESPs and high or medium impact BES Cyber Systems are in scope, how far your monitoring feeds already reach, whether your log management tools can hold data for the required period, and how quickly your internal reviewers can approve decisions. Enforcement of CIP-015-1 begins on 1 October 2028, so plan backward from that date and build in time for an internal review cycle and at least one evidence run before any assessor asks. Confirm the schedule with your partner as part of the written scope.

Can our own team implement CIP-015-1 R2 without an outside partner?

Yes, an entity can do this in-house, since the obligation sits with the registered entity and the standard does not require an outside firm. The question is capacity and skills. Your team needs people who understand your ESP architecture, your monitoring data flows, your log storage, and the NERC CIP evidence expectations. Many teams find that the hardest part is not configuration but writing retention processes that are specific enough to show the timeline required by Part 1.3 and reviewing them against real anomaly cases. An implementation partner can prepare systems, documentation and evidence, but it does not issue audit reports, and the entity remains responsible for its controls.

What does our team need to provide for an R2 engagement?

Three things matter most. First, named owners: a CIP compliance lead who approves the retention process, an operations owner for the monitoring platform, and a storage owner for retained data. Second, access to ESP monitoring feeds and the systems that hold them, including test access to sample anomalous events. Third, decisions on completion criteria, meaning when an evaluation or response action counts as complete for Part 1.3, who signs off, and how long data stays after that point. Ask for a written list of these inputs in the scope document so that gaps appear before work starts, not during an audit.

Do we have to keep all captured network traffic under R2?

No. CIP-015-1 R2 requires retention of monitoring data associated with network activity determined to be anomalous, kept at least until the evaluation and response action is complete. The standard states that entities are not required to retain monitoring data that is not relevant to anomalous activity detected under Part 1.2. Your retention process should therefore define what counts as anomalous, which data is linked to each detection, and how long that linked data is held after the action completes. Storing everything can still be a design choice, but it adds cost and protection burden, so decide it deliberately and document the rationale.

What changes when CIP-015-2 applies to EACMS and PACS from 1 October 2029?

CIP-015-2 extends internal network security monitoring to the associated Electronic Access Control or Monitoring Systems and Physical Access Control Systems, and NERC lists it as approved by FERC on 10 August 2026 with an effective date of 1 October 2029. For retention, that means the same logic you build for CIP-015-1 may need to cover EACMS and PACS activity as well. Entities should plan now by inventorying EACMS and PACS within their ESPs, confirming that monitoring can reach them, and checking whether retention processes and storage can scale. Confirm the final requirement text with NERC before design decisions are locked.

How does R2 retention relate to protecting the stored monitoring data?

R2 covers how long linked monitoring data is kept, while protecting that data from unauthorized deletion or modification is handled by a separate requirement, CIP-015-1 R3. In practice, the two should be designed together. A retention window that is correct on paper fails if an attacker or an administrator can alter the records, and a tamper-resistant store that deletes data too early fails R2. Test both during design so that retained evidence is complete, unchanged and still available until the action is finished.

How DeployOpen scopes and prepares R2 retention evidence

DeployOpen works on CIP-015-1 R2 retention as an implementation and evidence-preparation job inside your own environment. We scope which monitoring data is tied to anomalous activity, configure retention to support the evaluation and response timeline, and document it so your team and an independent auditor can review it.

How we scope

Written scope names the monitoring data sources, Electronic Security Perimeters and Applicable Systems covered by R2.
Scope defines which anomaly detections feed retention and who owns each evaluation and response step.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Retention settings are configured for the open-source sensors and log pipelines your team selects, inside your infrastructure.
Log output is set so records tied to anomalous activity are kept until the response action is complete, with timelines you approve.
Configuration is tested against sample anomaly scenarios to confirm retained data stays available through the full response cycle.

How we hand over

Documented retention process covers triggers, retention periods, storage locations and deletion steps mapped to R2.
System configuration exports and generated reports are delivered as evidence of retention timelines for your records.
Runbooks explain how staff confirm retention is working, and what to ask your independent auditor to review.

How we support

Ongoing support, upgrades and continuous testing of the retention setup are available as a retainer.
Retainer work can review retention settings after platform upgrades or changes to the Electronic Security Perimeter.
Confirm with your Compliance Enforcement Authority which evidence formats it expects before finalizing the handover.