NERC CIP, evidenced asset by asset

NERC penalties scale at $1.5M per violation per day. A triennial audit shouldn't be a six-month gamble.

Every three years, your Regional Entity walks. They want CIP-007-6 R4 security event monitoring evidence and CIP-010-4 R1 baseline configuration evidence for every High and Medium impact Bulk Electric System Cyber System you own. For the past three years. With cryptographic proof that nothing has been retroactively modified.

In most utilities, this is a six-month project. Your SCADA log holds the security events. Your EMS holds operational changes. Your IT change-management tool holds infrastructure changes. Your config-management database holds baselines. Reconciling them per asset across three years takes a senior compliance team months. And NERC penalties don't wait — they scale at $1.5M per violation per day until the violation is cured.

Why this is so painful in most stacks

The two big CIP standards demand three things that almost never live in the same system:

CIP-007-6 R4: Security event monitoring. Every BES Cyber System must generate, retain, and protect security event logs. R4.1 specifically requires integrity protection of those logs. Retroactive deletion or modification is a violation.
CIP-010-4 R1: Configuration change management. Every change to a baseline must derive from an approved change ticket, be tested, and have a rollback plan.
CIP-013 R1: Supply chain risk. Every vendor on a CIP-impacted asset must have onboarding due-diligence and continuous monitoring on file.

If those three things live in three or four different tools, the auditor has to mentally stitch them together. Mistakes happen. Notices of violation follow.

The one-query CIP-007 R4 reconstruction

MATCH (a:Asset)-[:GENERATED]->(e:SecurityEvent)
WHERE a.cip_impact IN ['High', 'Medium']
  AND e.ts > datetime() - duration('P3Y')
OPTIONAL MATCH (e)-[:ALERTED]->(r:Response)
OPTIONAL MATCH (a)-[:BASELINED_BY]->(b:Baseline)
RETURN a.id, count(e), count(r), b.last_validated

Three-year window. 612 CIP-impacted assets. 18.7 million security events. Every event monitored, every alert responded to within SLA, every baseline validated quarterly. The full CIP-007 R4 evidence package, in five minutes.

The R4.1 integrity proof

The auditor's hardest CIP question — have any security events been deleted or modified since they were recorded? — is the easiest one to answer when the audit log is a chain. db.verifyAclChain rehashes every event from genesis to today. Zero modifications. Cryptographic proof of log integrity for the entire three-year window.

R4.1 used to require an annual integrity assessment plus painful operator attestations. With a chained audit log, it's a procedure call.

The CIP-010 R1 change lineage

Every configuration change to a CIP-impacted asset must connect backward to an approved change ticket, the test record, the rollback plan, and the responsible engineer. db.derivedFrom walks the lineage. The chain also shows the denied changes — unapproved attempts that were blocked at the planner level, never landing on the asset. That's evidence of effective access control, not just an audit log.

The CIP-013 supply chain twist

While CIP-007 and CIP-010 are evidenced, the auditor pivots to supply chain. This vendor's firmware is on dozens of your CIP-impacted assets — when was your last onboarding review? The graph shows every CIP-013 vendor relationship, every onboarding due-diligence record, every continuous monitoring entry. Same primitive, different audience.

The numbers

A six-month, $350,000 evidence sweep becomes a two-week assessment. Zero notices of violation. NERC penalty exposure: gone. Your CIP compliance program now runs on chain primitives, not on a triennial scramble.

Live walkthrough on the NERC CIP tab.