By NHI Mgmt Group Editorial TeamBased on Nozomi Networks: “NERC CIP-015 in Practice #9: Writing Your INSM Program” (October 19, 2026)

TL;DR: NERC CIP-015 compliance depends less on tooling than on documented policy, process and evidence, because auditors will judge what an entity can prove about feed selection, anomaly definition, evaluation and retention, according to Nozomi Networks research. The practical failure mode is sensor-first, paper-last implementation that leaves no defensible chain from detection to action.


At a glance

What this is: This is a practical explanation of how NERC CIP-015 internal network security monitoring becomes defensible only when policy, process and evidence are documented together.

Why it matters: It matters to IAM and security practitioners because the article shows how governance gaps, not just telemetry gaps, create audit and operational risk in regulated environments.


Context

NERC CIP-015 is not just a monitoring requirement, it is a documentation and evidence requirement wrapped around monitoring. The control problem is that a tool can be deployed without creating a defensible record of why feeds were chosen, how anomalies are defined, and what happens after detection, leaving an audit gap even when visibility exists.

This post is about the governance layer that sits above internal network security monitoring. For regulated operators, the missing piece is often not sensor coverage but the documented link between decision criteria, operating procedures and retained evidence, which is the difference between a functioning programme and an audit artefact.


Key questions

Q: What breaks when INSM documentation is missing in a regulated utility environment?

A: The monitoring programme can still generate alerts, but it cannot reliably prove why a feed was selected, how anomalies are defined, who evaluated the event or what evidence was retained. In a CIP-015 context, that means the control may exist technically while remaining weak or indefensible in audit and incident review.

Q: When should utilities prioritise evidence quality over additional telemetry in CIP-015 programmes?

A: When the telemetry already exists but the programme cannot show a clear chain from feed selection to anomaly evaluation and retained records. More data does not close a governance gap if the entity still cannot explain the decision logic behind what it monitors or how it proves action was taken.

Q: What do security teams get wrong about anomaly detection in internal network security monitoring?

A: They often treat anomaly detection as the whole control, when it is only one step in a larger governed process. The mistake is failing to define the anomaly boundary, the evaluation outcome and the record that must exist after the decision, which leaves the programme technically active but procedurally incomplete.

Q: Which NERC CIP documents need to stay aligned when writing an INSM programme?

A: The INSM policy, procedures, retention records and incident response handoff need to align so the same event is classified consistently from detection through closure. If the anomaly definition in CIP-015 and the escalation logic in related response processes diverge, the programme can create a compliance gap instead of closing one.


Technical breakdown

How policy, process and evidence work together in CIP-015

CIP-015 works as a chain, not as three separate documents. Policy sets the commitment and scope, process turns that commitment into repeatable operational steps, and evidence proves the steps happened. If any link is missing, the programme becomes hard to defend because the standard expects not only implementation but documented proof that implementation occurred. In practice, this means the policy defines the rules of the game, the process defines the workflow, and the records show the workflow was followed. That structure also prevents auditors from filling in interpretive gaps on the entity’s behalf. See the NERC CIP Guide.

Practical implication: Define each monitoring activity so it produces a record that can be retained and reviewed.

Why risk-based rationale determines what gets monitored

The risk-based rationale is the programmatic explanation for why particular network segments, feeds and collection methods are in scope. It should be tied to consequence, attack-path relevance, observability and feasibility, not to budget convenience. In CIP-015 terms, that rationale is part of the control, because it demonstrates why the chosen data sources are fit for the purpose of improving detection. A weak rationale makes it easier for an auditor to challenge both what was excluded and why a phased deployment still meets the requirement.

Practical implication: Document segment-by-segment rationale so every monitoring decision can be traced back to defined criteria.

How anomaly definition and evaluation become audit evidence

CIP-015 requires more than detecting unusual activity. The entity must define what counts as anomalous, connect that definition to the feeds in use, and then evaluate detections into a concrete outcome. That makes the anomaly definition a load-bearing control statement, not a glossary term. Evaluation is also distinct from detection. A queue of alerts with no recorded outcome suggests the requirement has not been fully implemented, because the standard expects a determination of further action and a record of that decision. Retention then preserves both the data and the decision trail.

Practical implication: Write the anomaly threshold, triage outcome and retention trigger together so the control can be evidenced end to end.


Threat narrative

Attacker objective: The practical objective is to exploit governance ambiguity so that a monitoring programme looks deployed while remaining unable to prove detection, evaluation or retention obligations.

  1. Entry occurs when a utility deploys monitoring technology without a documented rationale that ties feeds to the specific risk it is meant to detect.
  2. Credential or access abuse is not the central issue here; the failure begins earlier, when the programme cannot prove why a feed exists or what it is meant to catch.
  3. Impact follows during audit or incident review, when the entity cannot demonstrate that detections were evaluated, retained and escalated through a defensible process.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Documentation is the control in CIP-015, not an afterthought. This standard is built around what an entity can prove, not just what it can observe. In regulated environments, tooling without policy, process and evidence creates a compliance illusion that collapses under audit scrutiny. The practitioner takeaway is simple: monitoring must be governable before it is operationalised.

Sensor-first, paper-last programmes create a governance debt that audits will expose. The article correctly identifies a common failure pattern in operational security programmes, where visibility is treated as success even though the written programme cannot explain the scope, thresholds or outcomes. That is a control design flaw, not a documentation nuisance. Practitioners should treat the documented process as part of the control surface, not the paperwork around it.

INSM programmes need a named decision model for what counts as anomalous. The standard leaves room for local judgement, which means the absence of a formal definition becomes an interpretive risk. That is especially important in utilities where different environments, protocols and observability constraints can produce very different monitoring outcomes. The practitioner implication is to make the threshold explicit so the control can be repeated, challenged and audited.

Evidence discipline is what separates a monitoring event from a compliance record. Tickets, logs, approvals and screenshots only matter when they are generated naturally and mapped to a defined process step. If the programme cannot produce those records in normal operations, it has not yet crossed from implementation into defensible governance. The field lesson is that evidence design belongs in the programme architecture from the start.

What this signals

Defensible monitoring now depends on governance design, not just telemetry coverage. Utilities that treat detection engineering as separate from policy design will struggle to show why a feed exists, how an anomaly is judged and what outcome follows. The programme-level signal is that monitoring controls are moving toward documented decision systems, not just sensor deployments.

Evidence generation must be engineered into the workflow. When a process step does not naturally create a ticket, log, approval or retained artefact, it is not yet a mature operational control. That is the key lesson for regulated operators building INSM around CIP-015: the record is part of the control, not a by-product.

Auditability is becoming the differentiator in utility monitoring programmes. The operational question is no longer whether a utility has tools, but whether it can reconstruct the full control chain under scrutiny. For programmes that also touch identity-adjacent access paths and privileged administration, that mindset helps prevent undocumented exceptions from becoming silent governance debt.


For practitioners

  • Document the policy, process and evidence chain Write each INSM step so it states the decision, the owner, the trigger and the record it produces. Treat the record requirement as part of the step, not as a later audit clean-up task.
  • Define a risk-based rationale for every monitored segment Record why each network segment is monitored now, later or not at all, using criteria such as consequence, attack-path relevance, observability gaps and implementation feasibility.
  • Tie anomaly definitions to detection and retention State exactly what anomalous means, which feed or method detects it, and what retention trigger follows when activity crosses that threshold.
  • Walk one event through the full control chain Trace a single alert from source feed through evaluation, disposition, retention and escalation to verify that the documented workflow actually produces usable evidence.

Key takeaways

  • CIP-015 turns internal network security monitoring into a documentation problem as much as a detection problem.
  • A monitoring tool without a written rationale, defined anomaly threshold and evidence trail leaves a compliance gap even if alerts are flowing.
  • Utilities should align policy, procedures and retained records so every monitored event can be defended from feed selection through closure.

Related NHI Mgmt Group resources: NERC CIP Guide · OT Security Guide · Identity Provider and SSO Security Guide


Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while NIS2 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.RR-02 — Roles, Responsibilities, and AuthoritiesThe article centres on documented responsibilities for an INSM programme.
PR.AA-05 — Access Permissions, Entitlements and AuthorizationsINSM evidence and control records depend on governed access to systems and logs.
Recommendation — Assign documented roles for feed selection, anomaly evaluation and evidence retention. Restrict access to monitoring data and supporting evidence to authorized operators only.
CIS Controls v8CIS-5 — Account ManagementOperational monitoring and evidence collection rely on controlled, reviewed account access.
Recommendation — Review and manage accounts that can alter monitoring sources, alerts and retained evidence.
NIS2Article 21 — Cybersecurity risk-management measuresThe post discusses structured governance for a regulated operational security programme.
Recommendation — Map INSM documentation to Article 21 risk-management expectations for governance and evidence.

Key terms

  • Risk-Based Approach: A risk-based approach allocates monitoring effort according to the exposure presented by a customer, product, channel, or geography. Instead of applying one static rule set everywhere, teams adjust thresholds and scrutiny to match expected behaviour and documented risk.
  • Anomalous Activity Detection: Anomalous activity detection is the process of identifying behaviour that deviates from a user or system’s normal pattern. In security programmes, it relies on baselines, signals, and correlation to surface suspicious access, data movement, or privilege use that may indicate insider misuse or compromise.
  • Evidence Chain: An evidence chain is the connected sequence of records that proves an identity action was requested, approved, executed, and reconciled. Without that continuity, access governance becomes fragmented and auditors are left to infer intent from incomplete system data.
  • Internal network security monitoring: Internal network security monitoring is the practice of observing traffic and activity inside trusted environments to detect anomalies, evidence misuse, and support investigations. In OT settings, it is most useful when paired with access controls that reduce exposure before suspicious activity can spread.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suitable for practitioners who need to connect identity governance with broader security programmes and operational evidence.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org