This post is part of a blog series recapping highlights from our NERC CIP-015 webinar series, where industry experts share their knowledge and field lessons from utilities building internal network security monitoring (INSM) programs.
In the ninth episode, I focused on writing the policies, processes and supporting documentation that turn an INSM implementation into a defensible NERC CIP-015 program. I come from an asset owner background and have written, built and developed NERC CIP programs a couple of times. I’m also a bit of a NERC CIP nerd, so this is a topic I enjoy.
If you’ve been attending the webinars or reading the blog posts, this information should almost be a refresher; it’s just time to document how you will put into practice everything you’ve learned.
For NERC CIP-015, the Documentation Is the Requirement
When it comes to NERC CIP-015, and really any NERC CIP program, documentation is everything.
The CIP-015-1 and CIP-015-2 standards are your legal guiding principle. As much as this webinar series and other resources can help shape your program, the only thing you really have to stand on during an audit is the requirement language and your program documentation.
CIP-015 repeatedly requires entities to implement one or more documented processes. The measures also call for both the documented processes and evidence demonstrating that they were implemented. The documentation isn’t something you add after deploying the technology; it’s a core part of the requirement. The relationship is that simple.
The industry conversation around CIP-015 has focused heavily on tooling: sensors, taps, platforms and data feeds. I get it. The technology feels like the long pole in the tent. But many entities are sensor-first and paper-last, and that creates risk. You can have flawless deployment of the technology but unless you setup the program, you won’t be successful.
Policy, Process and Evidence: The Three Layers of an INSM Program
I think about the CIP-15 program in three layers: policy, process and evidence.
Policy: What Did You Commit To?
Your policy establishes your entity’s commitment and therefore should generally be approved by your CIP senior manager or appropriate leadership. It defines the program’s intent, scope, requirements mapping, roles and responsibilities, and important definitions.
CIP-015 was intentionally written to accommodate many different environments. That flexibility leaves some voids for each Responsible Entity to fill. Your policy must fill those voids, or an auditor’s interpretation will. This includes your risk-based rationale, what anomalous means and evaluation outcomes, which I’ll cover below in detail.
The policy should be relatively stable. Although I traditionally like to review it annually and obtain reapproval, it shouldn’t need to change every time a workflow or technology changes.
Process: How Do You Do It?
Processes and procedures describe how the policy is executed. This is where you document activities such as selecting network data feeds, applying the risk-based rationale, detecting anomalous activity, evaluating an anomaly and determining further action.
These documents are more tactical, so they’ll change more frequently than the policy. They should define triggers, responsibilities, workflows and the records produced by each step.
A practical drafting rule is to finish every process step with the thought, “This step produces record X, retained according to clock Y.” If you can’t identify the record that a step produces, either that step doesn’t need to exist or you have found an evidence gap.
Annual review and approval of this documentation is recommended, with version control to ensure the auditor can track the evolution of your processes.
Evidence: Did You Actually Do It?
Evidence proves that you followed the process. It may include tickets, logs, approvals, meeting notes, timestamped screenshots, exports, updated network diagrams and data flow diagrams.
A beautifully written process with no operational records underneath it will fail just as surely as having no documented process. Ideally, evidence should be generated naturally out of day-to-day operations, not be assembled retroactively before an audit.
Let’s walk through each CIP-15 requirement to make sure your documentation fully addresses it.
R1 Part 1.1: Documenting the Risk-based Rationale
When writing your INSM program, it helps to separate what the standard prescribes from the decisions left to the Responsible Entity.
For R1 Part 1.1, the hard obligations include implementing network data feeds to monitor connections, devices and network communications. You also need a documented risk-based rationale explaining how those feeds were selected.
The discretionary side left to the Responsible Entity includes:
- Which network segments you monitor
- Whether implementation occurs in phases
- Which collection methods you use
- Whether visibility extends into virtual environments
- Whether analysis stays at the network level or goes deeper into protocols and OT variables
The structure of the risk-based rationale isn’t defined. That doesn’t make the rationale optional or allow it to become a budget justification for minimal coverage. Your policy should define how your entity conducts a risk-based rationale.
Per network segment, the rationale might consider consequence, attack-path relevance, communication density, observability gaps and feasibility constraints. It should then define a clear decision: instrument now, instrument in a later phase or do not instrument. Most importantly, the reason for that decision should tie back to the documented criteria and the purpose of the standard.
Note that a rationale based on budget rather than risk won’t fly. The rationale is auditable evidence, and it will be read against the standard's stated purpose: improving the probability of detection. A do-not-instrument conclusion needs to survive that reading.
R1 Part 1.2: Define “Anomalous” in Writing
R1 Part 1.2 requires one or more methods for detecting anomalous network activity using the network data feeds implemented under Part 1.1.
That linkage should be explicit in your documents. A feed collected under Part 1.1 should connect to a documented detection method. An orphaned feed that no detection method uses, or a detection method relying on data outside the documented feed plan, breaks the chain.
The standard doesn’t prescribe how you detect anomalous activity. You might use baselining, signatures, protocol-aware analysis, statistical techniques or a combination thereof. While the measures reference a network communications baseline as a possible form of evidence, baselining is anticipated, not expressly mandated.
What matters most in the program documentation is your definition of “anomalous.” The term is not defined for you, so you need to define it.
That definition is load bearing twice. It bounds what your methods must detect under R1 Part 1.2 and it also becomes the trigger for R2, because R2 applies to network activity determined to be anomalous by the Responsible Entity. Your definition establishes both the detection boundary and the retention trigger.
R1 Part 1.3: Evaluation Must Produce an Outcome
Detection and evaluation are not the same step.
R1 Part 1.3 requires a distinct evaluation process and a determination of further action. An alert queue with thousands of unreviewed detections isn’t just a tuning problem. From an audit perspective, it can indicate that the evaluation requirement hasn’t been implemented.
Your procedure should define evaluation outcomes and the records associated with them. For example:
- Benign or expected activity may feed into baseline or rule tuning.
- Unauthorized but non-malicious activity may generate a tracked corrective action.
- Suspected malicious activity may trigger immediate retention and escalation into the CIP-008 Cyber Security Incident response plan.
- Indeterminate activity should remain a waypoint with an owner and due date, not become a terminal state.
How you structure triage tiers, divide work between automation and people, and design the escalation path is discretionary. But the action must be defined and the execution must be evidenced.
The CIP-008 handoff is a significant drafting consideration. The definitions, thresholds and escalation criteria in the two programs need to align. If CIP-015 classifies activity in a way that should activate CIP-008 but the incident response process does not, you may have created a compliance gap.
R2 and R3: Document the Three Retention Clocks
R2 and R3 address retention and protection. At a minimum, data associated with activity determined to be anomalous must be retained and protected until the action is complete.
I find it useful to think about three clocks:
- Evaluation data: Retain the data needed to evaluate the anomaly and determine further action.
- Compliance evidence: Retain evidence according to the applicable NERC CIP evidence-retention period and audit cycle.
- Operational data: Retain additional data for as long as it remains useful for investigations, baselining or cybersecurity operations.
Your documents should distinguish compliance requirements from operational choices. If you choose to retain data longer because it has operational value, clearly state that this is a preference, not a program requirement. Otherwise, a useful cybersecurity practice can accidentally become an enforceable compliance commitment.
R3 specifically addresses unauthorized deletion or modification. I would align protection of this information with your CIP-011 BES Cyber System Information (BCSI) program as much as practical, while still documenting the specific CIP-015 obligations. Simply pointing to the CIP-011 policy isn’t enough.
Also note that CIP Exceptional Circumstances language exists in R2 and R3, but not R1. Don’t write an INSM policy that applies that exception across the entire standard.
Common INSM Documentation Anti-patterns
Most of us have seen program documents that look complete but create more problems than they solve. A few anti-patterns are especially important for CIP-015:
- Restating the requirement as policy. Saying “we shall implement documented processes” doesn’t explain what your entity has committed to do.
- Using ambiguous language. Avoid “should,” “typically” and “generally” when setting an obligation. Use clear terms such as “must” and “shall.”
- Naming products instead of capabilities. Tools change. Your policy shouldn’t need senior management approval every time the organization changes platforms.
- Writing process steps that produce no records. A process with no evidence output is unevidenced by construction.
- Scoping around a vendor deployment. Scope comes from CIP-002 categorization, applicable systems and the Electronic Security Perimeter, not from what a particular platform does.
- Mixing CIP-015-1 and CIP-015-2. Define the version currently governing the program and prepare separately for the program’s future evolution.
Walk One Event Through the Entire Document Chain
Once the policy and processes are drafted, stress-test them before your mock audit.
Pull a handful of detection events and walk each one from beginning to end:
- Which source feed produced the detection, and is that feed documented with a risk-based rationale?
- Is there a timestamped detection record showing the alert and its source?
- Who evaluated it, and what did they decide?
- If the activity was determined to be anomalous, was the required data retained and protected?
- Was further action tracked through closure?
Every broken link is a drafting or record-discipline gap waiting for an auditor’s sample number.
Field Test Your INSM Program Documentation
I’m a big fan of writing documentation early, having people follow it and letting them find problems. The documented process and its evidence chain are living things. Maintain them continuously, and they can serve in an audit. Wait until an audit, and evidence collection becomes archaeology.
As always, this post only scratches the surface of what was covered in the webinar. If you haven’t already, register for the complete series and watch the Episode 9 replay for the complete discussion. If you’d like to talk through how any of this applies to your own program, contact us. We’re here to support you.
