NERC CIP Compliance Evidence Software: Why Audit Prep Still Eats Four Months of Your Year

Why CIP evidence work eats a quarter of your year

It is week three of audit prep at a registered entity with 41 substations and two control centres. The compliance manager has a SharePoint tree named by standard. Inside the CIP-007 folder sits a spreadsheet of patch sources, a second spreadsheet of evaluations, and roughly 300 console screenshots captured by three different engineers over 15 months. Two have no visible timestamp. One substation energised in March, and nobody can say for certain whether its relays entered the evaluation list before or after the clock started running on them. That single uncertainty is the thing the compliance manager will lose sleep over, because a gap in the evaluation cadence is precisely the finding that becomes a self report, a mitigation plan and a conversation with the Regional Entity.

The uncomfortable part is that the entity is probably secure. The patches were evaluated. The engineers did the work. What does not exist is a dated, attributable, tamper evident record that the work happened inside the window the standard defines, for every asset in scope, without a break. CIP compliance is not a security outcome, it is a documentation product with a security process underneath it, and the two are graded separately.

Monetary penalties under the Federal Power Act are assessed per violation per day, with a statutory ceiling in the seven figures per day, and the number that actually gets settled depends heavily on your internal controls and how you found the issue. That is the economic argument for a real evidence system: a self identified gap with a documented control that caught it lands in a different place than a gap an auditor finds in a folder of screenshots.

The clocks are the product, and spreadsheets cannot hold them

Every CIP requirement that generates audit pain is a cadence. CIP-007-6 R2.2 requires evaluating security patches for applicability at least once every 35 calendar days for each source you have identified. CIP-004-6 R5.1 requires revoking unescorted physical access and interactive remote access by the end of the next calendar day following a termination. Access verifications, cyber vulnerability assessments and policy approvals run on quarterly and 15 calendar month cycles. CIP-010 requires baseline configurations and change records that show what changed, when, and who authorised it.

A spreadsheet can list those cadences. What it cannot do is hold the clock as a live object per asset, start it on the day an asset was commissioned, stop it on the day it was decommissioned, and prove after the fact which assets were in scope on any given date. That last point is where audits actually go wrong. An auditor picks a sample of assets and a sample of dates, and the entity has to reconstruct scope as it stood 14 months ago. If your asset list is a current state spreadsheet that gets overwritten, you cannot reconstruct anything, and you will spend two weeks reading commissioning emails to answer one sampling question.

Your evidence lives where IT tooling cannot reach

This is the reason enterprise GRC platforms underdeliver here. In an IT estate, evidence collection means pointing a connector at Active Directory, the endpoint agent and the ticketing system. Inside an electronic security perimeter you have relays, RTUs, protection and control gateways, HMIs and engineering workstations that will not accept an agent, are not domain joined, run vendor signed firmware you are contractually not allowed to modify, and are reachable only through an intermediate system under CIP-005 R2.

So collection has to be architected the other way around: a collector that lives inside the perimeter, runs read only queries against what the OT systems already expose, writes structured output to a controlled drop, and pushes outward through the same reviewed path your operations traffic already uses. Nothing reaches inward. Anyone who proposes an outbound agent per device has not worked inside a substation and will not survive your own cyber security review, let alone an auditor asking about CIP-005 conformance.

There is a second wrinkle people forget until late. The evidence repository itself holds network diagrams, IP addressing, access lists and asset inventories, which makes it BES Cyber System Information under CIP-011. The system you build to prove compliance is itself in scope, so its access controls, hosting decision and vendor arrangements have to be documented before go live rather than after.

What the named tools actually do, and where they stop

Certrec is strong where it is aimed: regulatory compliance services, managed reporting and keeping a registered entity's program tidy against the standards. It is oriented around the compliance program and the filings, and it is a genuinely reasonable answer for a smaller entity that wants the function outsourced. It is not a harvesting layer that reaches into your specific relay estate and produces dated artifacts on its own.

FoxGuard Solutions solves one requirement well. Their patch intelligence tells you which patches exist for industrial assets from vendors who do not publish machine readable feeds, which is the hardest input to CIP-007 R2. It answers what patches are available. It does not own your asset inventory of record, your evaluation attestations or the rest of the program.

Network Perception is excellent at firewall ruleset verification and segmentation analysis, which maps cleanly onto CIP-005 and gives you defensible evidence about your perimeter. Its scope is the network. Your access reviews, patch cycles and change records live elsewhere.

Dragos gives you OT asset visibility and threat detection, and the asset data it produces is genuinely useful upstream of CIP-002 classification and CIP-010 baselines. It is a security platform judged on detection, not an evidence system judged on whether an artifact carries a defensible capture time.

Archer will model anything, and that is the problem. Its control framework and data model were written for enterprise IT risk, so the CIP specific parts, meaning applicability by asset type, per requirement cadence and worksheet aligned export, are things your team builds inside their toolkit at consultant rates. You end up with a custom build wearing a licence fee.

What a custom CIP evidence build has to include

• An asset inventory of record with impact rating and effective dating, so scope on any past date is reconstructable rather than inferred, and with the classification chain from BES Cyber System down through associated EACMS, PACS and PCA carried explicitly.
• A cadence engine where each requirement clock is a first class object per asset, alerting before a window closes rather than reporting after it has.
• Evidence objects that record source system, collector identity, capture time and a content hash, written to an append only log so nobody can quietly backdate an artifact.
• Pull side collectors that operate inside the perimeter and push outward, with a manual capture path that produces the same structured object when a device genuinely cannot be queried.
• Export that assembles a requirement part, its evidence set and its sampling response in the shape the audit worksheets ask for, so audit prep is a review rather than an assembly job.
• Workflow for self reports, mitigation plans, extension requests and technical feasibility exceptions, linked to the assets and requirement parts they cover.
• An access revocation path that reconciles OT account and badge lists against HR (Human Resources) terminations inside the next calendar day, with the reconciliation itself as the evidence.

What this costs and how long it takes

Digital Heroes has delivered over 2,000 projects, and this category has a consistent shape. A first release covering the asset inventory of record, the cadence engine, patch evaluation and access revocation evidence, and worksheet aligned export, runs $70,000 to $150,000 and ships in 12 to 18 weeks. That is a system your compliance manager works in daily, not a pilot. Extending to CIP-005 ruleset evidence, CIP-010 baseline and change records, CIP-013 supply chain artifacts, mitigation plan management and internal controls monitoring takes the total to $200,000 to $500,000 across 9 to 15 months.

What pushes cost up in this specific environment: the number of distinct OT vendor platforms in the estate, because each relay family, gateway and historian is its own read path. Multiple Regional Entities, because expectations on evidence presentation differ and you will be maintaining two conventions. Any requirement to run the whole thing on premises inside the perimeter, which removes the easy hosting answers. And how honest your current asset list is, which you will not know until the first reconciliation run finds substations with equipment nobody recorded.

What holds cost down: starting with the two or three standards that generate most of your findings history, usually CIP-007, CIP-004 and CIP-010, and treating everything else as phase two.

When you should not build this

If you are registered with low impact assets only and your CIP-003 obligations are the extent of it, do not commission software. Your program fits in a well maintained document set plus a managed service, and a build will cost more to keep current than the risk it retires.

If you are a medium impact entity with a stable footprint, a single control centre and no acquisitions on the horizon, buy the point tools that map to your worst standards and accept the seams. FoxGuard for patch source intelligence plus Network Perception for perimeter evidence covers a lot of ground for a fraction of a build.

Build when the scale is against you. More than roughly 30 in scope locations, or a high impact control centre, or an estate that keeps changing through capital projects and acquisitions, means scope reconstruction becomes the dominant cost of every audit. Build also when you are under an active mitigation plan and your regional auditor has already told you your controls are not evidenced. At that point the system is not a productivity purchase, it is the mitigation.

How to choose a developer for CIP evidence work

Ask them to describe the collection path into a substation before they talk about the interface. If the answer involves installing an agent on a relay or opening an inbound connection through the perimeter, they are describing a design your own security team will reject and an auditor will question.

Ask how they will represent effective dated scope. The correct answer involves asset records that carry commissioning and decommissioning dates and a way to query the inventory as of a past date. If they describe a current state table, they have built an asset register and you will still be reading commissioning emails during sampling.

Ask whether they understand that the evidence system holds BES Cyber System Information and what that means for hosting and access. A developer who has done CIP work brings this up before you do.

Ask who owns the repository, the infrastructure accounts and the right to hire someone else to continue the work, and get it written down before kickoff. At Digital Heroes the code is yours from the first commit. The next step worth taking is to pull your last two audit findings and your last three self reports, and map each one to the clock that was missed. That list is your first release scope, and you can hand it to any developer as a starting brief.