NERC CIP — the Critical Infrastructure Protection standards issued by the North American Electric Reliability Corporation — is not guidance. It is mandatory and enforceable for owners and operators of the bulk electric system, backed by financial penalties for violations. The standards span a family: CIP-002 through CIP-014 and beyond, covering asset categorization, security management controls, personnel and training, electronic security perimeters, physical security, system security management, incident response, recovery planning, configuration and vulnerability management, information protection, and physical security of critical facilities. Each standard contains numbered requirements, and each requirement is something a registered entity must demonstrably do.
The foundational move is CIP-002: bright-line criteria that categorize BES Cyber Systems as High, Medium, or Low impact. This categorization is the rail equivalent of a safety integrity level or an automotive ASIL — it is the dial that sets how much of the rest of the standard applies. A High-impact control center inherits the full weight of the requirements. A Low-impact substation carries a much lighter, but still non-zero, set. Getting the categorization right is the highest-leverage decision in a CIP program, because everything downstream — the perimeters you must define, the access controls you must enforce, the monitoring you must perform — scales from it. Miscategorize an asset low and you have an under-protected system and an audit finding waiting to happen.
The mistake many entities make is treating CIP as a documentation exercise owned by a compliance team, separate from the engineers who run the systems. The requirements read like engineering requirements because they are: CIP-005 demands a defined Electronic Security Perimeter with controlled access points; CIP-007 demands ports and services be restricted to those needed, security patches be evaluated on a defined cadence, and malicious code prevention be in place; CIP-010 demands baseline configurations be established and changes be authorized and tested. Each of these is verifiable. Each has a natural verification method — inspection of a firewall ruleset, review of a patch evaluation record, comparison of a running configuration against its authorized baseline. When you model them as requirements with assigned verification methods and evidence, an audit becomes "produce the evidence you already maintain" instead of "reconstruct a year of activity under deadline."
Traceability is where CIP programs live or die during an audit. An auditor does not simply ask whether you have a policy. They select a sample — this asset, this account, this change, this patch cycle — and ask you to walk the full chain: the requirement, the control that implements it, the evidence that the control operated over the audit period, and the trail showing exceptions were handled per your documented process. If your requirements, your assets, your controls, and your evidence live in separate spreadsheets and shared drives, assembling that chain for a sampled asset is a scramble. If they are linked as first-class relationships, the chain is a query.
The evidence-over-time problem is what makes CIP distinct from a one-time design review. Many requirements are not "prove it once" — they are "prove it continuously across the audit period." Access reviews on a defined interval. Patch evaluations within a defined window of release. Configuration change records. Log retention and review. The requirement is satisfied not by a single artifact but by an unbroken series of artifacts on a cadence. A CIP requirements model has to capture not just the requirement and its verification method, but the recurrence and the record of each occurrence, so a gap in the cadence is visible before an auditor finds it.
Change is the other constant. The BES Cyber System inventory is not static — assets are added, retired, reclassified, and reconfigured. When an asset's impact rating changes, the set of requirements that apply to it changes with it, and every linked control and piece of evidence must be reassessed against the new obligation. When a standard is revised — and CIP standards are revised regularly through the NERC standards development process — the requirements themselves shift, and existing controls must be re-mapped. Without a system that flags what a change touches, entities discover the delta during the next audit rather than during the change.
A common failure mode is the "compliance snapshot": a beautifully assembled binder that reflects the state of the program on the day it was compiled and drifts out of date immediately. Auditors are not fooled by a snapshot; they sample across the audit period and probe for the gaps between the binder and reality. The durable approach is to make the compliance posture a byproduct of the live data — the actual asset inventory, the actual access records, the actual change and patch history — so the evidence you present is the evidence the systems produced, not a curated retelling.
Hitt Hosting SE's Energy pack treats NERC CIP requirements as engineering requirements. BES Cyber Systems carry their impact categorization, and the applicable requirements flow from that categorization rather than being tracked by hand. Each requirement links to the control that implements it and to the recurring evidence that demonstrates it over the audit period, with the cadence made explicit so a missed interval surfaces early. When an asset is reclassified or a standard is revised, the requirements, controls, and evidence the change touches are flagged for reassessment. The audit package — the asset inventory, the requirement-to-control-to-evidence trace, and the record of recurring activities — generates from the live data, so what you hand an auditor is what your systems actually did across the period, not a snapshot assembled the week before.