Which framework should a utility or generator pursue first
If your organization is a registered entity that owns or operates BES Cyber Systems, the NERC CIP standards come first, and the CSF is the enterprise layer built around them. Neither produces a certificate: CIP compliance is checked by the Compliance Enforcement Authority, a Regional Entity or NERC, through audits, spot checks, self-certifications and self-reports, and the CSF is a voluntary outcome framework that NIST says it does not certify. The first CIP step is the CIP-002-5.1a categorization of your BES Cyber Systems as high, medium or low impact, because every other CIP requirement is scoped to the systems that categorization produces. Confirm your registered functions in the NERC Compliance Registry before you do anything else, since they determine which Reliability Standards apply to you.
Once the CIP scope is fixed, use the CSF to cover what CIP does not reach: corporate IT, cloud services, supplier management, and the governance and recovery outcomes that sit outside the CIP boundary. The Govern Function is the most useful addition for this work, because it gives a single place to record risk strategy and supplier oversight for both the CIP program and the enterprise. Doing both makes sense when the same people run the CIP program and enterprise security, so that CIP evidence can be mapped into CSF outcomes once rather than rebuilt for each reporting request. Plan the CIP audit notice period, which the CEA must give at least 270 days before a planned Compliance Audit, as the trigger for your evidence work.
If your organization is not a registered entity, CIP does not apply and the CSF is the only practical starting point for a utility-style program. Use it to set a Current Profile, define a Target Profile and track progress by Function, and consider whether a published Community Profile for the energy sector fits your needs. Be clear with customers, regulators and boards that the CSF is self-assessed, so any claim of CSF alignment should be described as a self-assessment. If a counterparty asks for CIP-style proof, confirm whether the request is contractual, since no CIP certificate exists to offer in its place.
How NERC CIP and NIST CSF differ on scope, status and proof
This table compares who must comply, whether obligations are mandatory, the unit each framework scopes, how each is structured, how enforcement works and what proof each produces. Read it as a boundary question first: CIP applies to specific registered entities and assets, while the CSF is a voluntary enterprise framework with no certification.
| Dimension | NERC CIP Reliability Standards | NIST CSF 2.0 |
|---|---|---|
| Who must comply | Registered entities with BES Cyber Systems in the United States, as recorded in the NERC Compliance Registry | No one by default. Voluntary for most organizations, though some customers or suppliers may require it, and U.S. federal agencies are required to use it |
| Mandatory or voluntary | Mandatory once FERC approves each standard under section 215 of the Federal Power Act | Voluntary. NIST is not a regulatory agency |
| Scope unit | BES Cyber Systems, sorted as high, medium or low impact under CIP-002-5.1a, plus associated EACMS, PACS and PCA | The whole organization, its missions, assets and risk, expressed through Organizational Profiles |
| Structure | Reliability Standards with requirement tables scoped by Applicable Systems, such as CIP-007-6 | Six Functions (Govern, Identify, Protect, Detect, Respond, Recover), 22 Categories and 106 Subcategories |
| Enforcement and penalties | Regional Entities or NERC audit and enforce, with penalties and mitigation; minimal-risk issues may resolve as Compliance Exceptions or FFT | No enforcement body. Results are internal, and customer or contractual terms are the only consequence |
| Proof produced | Audit findings, evidence submitted to the Compliance Enforcement Authority and settled noncompliance records. There is no CIP certificate | Internal assessments and Current and Target Profiles. NIST does not offer certifications or a conformity assessment program |
| Version notes | CIP-002-5.1a categorization is reviewed at least every 15 calendar months. CIP-003-9 became enforceable 1 April 2026. CIP-015-1 is enforceable from 1 October 2028 (NERC CIP standards page) | CSF 2.0 was published 26 February 2024 (NIST CSWP 29), succeeding Version 1.1 of 16 April 2018. No revision of the Core has been issued since |
| FERC Order No. 919 changes | Eleven revised standards for virtualization, listed by NERC as effective 1 July 2028. Confirm the status of each version with NERC before planning changes | Not applicable. The CSF has no regulator-driven revision cycle |
How CIP-002 categorization sets the CIP boundary
This sequence turns an entity's asset list into a documented impact rating for each BES Cyber System, and that rating decides which CIP requirements apply to which systems. Because every later CIP obligation depends on it, the categorization is the first step to settle.
Build the inventory of BES assets and facilities
Start by listing the facilities, generation units, transmission assets and control centers the entity owns or operates that could fall within the Bulk Electric System. Operations, planning and asset management staff usually own this input, with compliance staff confirming that the list matches the entity's registered functions. The step is done when each facility is traced to a registered function and to a named owner who can confirm its status.
Identify candidate BES Cyber Systems
Within those facilities, identify the Cyber Assets that, if they were compromised or made unavailable, could affect the reliable operation of the BES. Group them into candidate BES Cyber Systems by the operational function they serve, such as a control center system or a substation protection system. Engineering and operations staff should lead this work, since they know how the systems are used. The output is a working list of candidate systems, each with the Cyber Assets it contains and the operational function it supports.
Apply the Attachment 1 bright-line criteria
Test each candidate system against the bright-line criteria in Attachment 1 of CIP-002-5.1a. Those criteria sort systems into high impact, medium impact or low impact, and examples in the standard include Control Centers of Reliability Coordinators and generation or transmission thresholds at listed assets. Read the attachment itself rather than relying on summaries, because the thresholds and asset types determine the result. The check is complete when each candidate has one documented impact rating and the criterion that produced it.
Document the rationale for each categorization
Record the impact rating, the criterion applied, the supporting asset data and the reasons for any judgment call. Auditors will ask how the entity reached each rating, so the rationale should be traceable to source data rather than to memory. Compliance staff typically prepare this record and engineering staff verify the technical facts. The output is a categorization record that a reviewer can follow from the asset list to the final rating.
Obtain CIP Senior Manager approval
Submit the categorization record to the CIP Senior Manager or a documented delegate for review and approval. The approval confirms that the entity's accountable executive has accepted the impact ratings and that the scope of the CIP program is set. Keep the signed approval with the categorization record. The step closes when the approval is on file and dated, and the list of BES Cyber Systems is fixed as the scope baseline for the other CIP standards.
Set the review cycle and track changes
CIP-002-5.1a requires the categorization to be reviewed and approved at least every 15 calendar months. Schedule that review in the compliance calendar and define triggers for an earlier review, such as commissioning a new asset or retiring one. Assign an owner for monitoring those changes. The check is that the review date is recorded, the trigger list is documented and the owner confirms it is active.
Map applicable systems to each CIP requirement
Use the Applicable Systems column in each CIP standard's requirement tables to determine which requirements apply to each impact category. For example, CIP-007-6 scopes some controls to high impact systems, others to medium impact systems with External Routable Connectivity, and others to associated EACMS, PACS and PCA. Build a matrix that links each system to the requirements it must meet. The matrix is complete when every BES Cyber System has a documented set of applicable requirements and every requirement has a named control owner.
Start CSF outcome work in parallel
The CSF can be used before the CIP boundary is settled, for example to assess enterprise governance, asset management and supplier risk across all business units, including those outside the BES. Confirm with the CIP Senior Manager which CSF outcomes will feed the CIP program and which will remain enterprise-only, so the two efforts do not duplicate or contradict each other. The check is a written mapping that shows which CSF outcomes cover CIP-scoped systems and which cover the wider enterprise.
How CIP audits are noticed, scheduled and resolved
The first thing to know about a CIP audit is that the Compliance Enforcement Authority must give notice well before it starts. Under Appendix 4C, section 4.1.1 of the NERC Rules of Procedure, the CEA notifies the entity at least 270 days before a planned Compliance Audit. At least 90 days before the audit, it must send the list of standards in scope, the audit team members with their recent employment history, and its request for documents, data and information. That window is the practical planning period for a utility. Compliance leads should confirm with their Regional Entity which CIP versions and effective dates will apply, because the standards in force at the audit date govern what is tested, and several CIP versions have effective dates in 2026 and later.
Audits are not the only way the CEA learns about an entity. Appendix 4C also provides for Spot Checks, Self-Certifications, Self-Reports, self-logging, periodic data submittals, investigations and complaints. Self-Reports and self-logging depend on the entity's own discipline: a noncompliance found internally should be recorded and reported promptly, because the handling of that finding is what drives the outcome. When a noncompliance is found, two alternatives to a full enforcement action exist. A Compliance Exception can resolve minimal-risk noncompliance, and Find, Fix, Track and Report (FFT) can resolve minimal or moderate risk noncompliance. Both require mitigation, so an entity cannot close a finding by documenting it alone. Teams should ask their CEA how it applies these tools and what mitigation evidence it expects.
The contrast with the CSF is direct. No regulator audits an organization against NIST CSF 2.0, NIST does not offer certifications or conformity assessments, and NIST does not set an audit cycle for the framework. Any review cadence an organization uses for the CSF is one it chooses, and its outcomes are not enforced by a Regional Entity. For a utility, this means the CSF can guide an internal review schedule that runs alongside the CIP audit calendar, but it cannot replace the notice, scope and mitigation discipline that CIP requires. Plan the CIP evidence calendar first, then use CSF reviews to find gaps the CIP audit will not reach.
Where the CSF adds value outside the CIP boundary
CIP applies to systems that are part of the BES Cyber System perimeter and their associated access control, monitoring and protected assets. Corporate IT networks such as email, identity services for staff, office file shares and general endpoints sit mostly outside that perimeter unless they connect to in-scope assets. The CSF helps here because its Govern and Identify outcomes ask the organization to set risk strategy, roles and asset inventories across the whole enterprise, not only the systems named in CIP tables. Use the CSF to organize how corporate IT risks are owned, measured and reported, and treat any shared identity or network path into the CIP boundary as a question for the CIP scope analysis.
- Enterprise risk strategy: Govern outcomes cover how risk tolerance and priorities are set for the whole organization, which CIP does not address.
- Asset inventory beyond BES Cyber Systems: Identify outcomes push you to inventory corporate assets and their dependencies, including paths that may reach CIP-scoped systems.
- Shared services: Directory, email and remote access services used by both corporate and operations staff need an owner and a documented risk position.
- Ownership and reporting: Board and executive reporting on corporate cyber risk can be structured on CSF functions while CIP evidence stays in its own program.
Before relying on the CSF for corporate IT, confirm with your compliance team and Regional Entity contact which shared services and network paths fall inside the CIP boundary, since that determines which controls are CIP obligations and which are voluntary.
Business systems such as finance, billing, customer information, human resources and ERP platforms usually fall outside the BES Cyber System categorization. They still carry operational and regulatory risk, and a utility or generator is accountable for them under its own governance. The CSF gives a structure for these systems through Identify outcomes for asset management and risk assessment, and through Govern outcomes for policy, roles and oversight. CIP does not prescribe how these systems are governed, so the CSF is the natural outcome language for them, with any state or financial reporting obligations tracked separately.
- Data and asset classification: Identify outcomes ask for data and system categories that CIP does not define for business systems.
- Policy and roles: Govern outcomes cover policy ownership, accountability and review cycles across business units.
- Integration points: Business systems that feed or receive data from operations need their interfaces documented, since those interfaces can change CIP scope.
- Third-party platforms: Hosted billing or HR services are governed through the same outcome language as other enterprise risks.
When mapping business systems, check with your legal and finance teams which obligations apply directly to each system, because CSF outcomes do not satisfy those obligations by themselves.
CIP-013 requires a supply chain cyber security risk management plan for BES Cyber Systems, covering vendor risk during procurement, installation and transitions. That obligation overlaps with enterprise third-party risk work but does not replace it. The CSF Govern function includes outcomes for supply chain risk management across the organization, which apply to every vendor, including those whose products never touch a BES Cyber System. A utility can use CSF Govern outcomes to set vendor tiering, contract terms and monitoring, then map the CIP-013 plan into that structure for in-scope vendors.
- Enterprise vendor program: Govern outcomes cover how supplier risk is assessed and monitored across all vendors, beyond CIP-013 procurement scope.
- Vendor inventory: Identify outcomes support a list of suppliers and the services they provide, which feeds both CIP-013 and general risk work.
- Contract requirements: Security terms in contracts can be set once for the enterprise and then extended to CIP-relevant suppliers.
- Monitoring and reassessment: Periodic reassessment cycles defined under CSF governance can be aligned with CIP-013 review requirements where they fit.
- Ownership split: Procurement, security and operations roles need to be defined so that CIP-013 evidence is produced by the people who run the vendor relationship.
Confirm the current text of CIP-013-2 with NERC and your Regional Entity before designing supplier evidence, and ask whether your CIP-013 plan can reference the enterprise vendor process directly.
Some operational technology sits outside the BES Cyber System categories, for example systems at facilities that are not in scope, monitoring tools that are not classified as in-scope, or engineering and maintenance environments that are not directly tied to CIP assets. These systems can still affect reliability and safety, and the organization has an interest in managing them consistently with CIP. The CSF helps by providing outcome language for asset visibility, protective controls, detection and recovery for OT that is not in scope. Using CSF outcomes for these systems should not be described as CIP compliance, and any shared controls should be documented in a way that auditors can trace.
- OT asset visibility: Identify outcomes encourage an inventory of non-BES OT, which helps confirm where the CIP boundary ends.
- Protective and detective outcomes: Protect and Detect functions give a way to plan monitoring and access controls for non-BES OT.
- Boundary decisions: Documented reasons for placing a system outside the categorization protect the organization in audits.
- Recovery planning: Recover outcomes can cover restoration of non-BES OT that supports in-scope operations.
- Shared technology: Products used in both scoped and unscoped environments should have one configuration baseline with clear evidence for each boundary.
Before treating any OT system as out of scope, confirm the categorization with your CIP Senior Manager and document the basis, because the CSF cannot decide that boundary for you.
Where CIP and CSF work overlaps, from supplied mappings
CIS and NIST publish informative mappings between their controls or outcomes and NERC CIP, so the overlap areas below are a starting point for your own crosswalk. A mapping shows where two sets of requirements address the same topic. It does not establish equivalence, and NIST does not check the correctness of non-NIST mappings.
Asset inventory and categorization
CIP begins with classifying BES Cyber Systems as high, medium or low impact category under CIP-002-5.1a, and that classification determines which requirements apply. The CSF asset management outcomes cover the wider enterprise inventory of hardware, software, data and services, including systems outside the CIP boundary. Check whether your enterprise inventory carries each CIP impact category, so the two lists do not drift apart. Confirm how the CIS mapping to NERC CIP treats asset inventory before relying on it for scope decisions.
Access control and personnel
CIP-004, CIP-005 and CIP-006 set requirements for personnel access, electronic security perimeters and physical access to applicable systems. The CSF access control outcomes in the Protect Function describe the same concerns as enterprise outcomes, covering identities, authentication and least privilege for every system. A common pitfall is applying the CSF access model to the whole enterprise while the CIP scoped tables still govern the control centers and plants. Ask the assessor which evidence can serve both programs.
Security monitoring and event logs
CIP-007 covers security event monitoring for applicable Cyber Assets, and CIP-015-1 adds internal network security monitoring, approved by FERC on 26 June 2025 and subject to enforcement from 1 October 2028. The CSF Detect Function describes monitoring outcomes that a general SOC can support across IT and operational networks. Confirm whether your monitoring design keeps CIP-scoped logs separable from enterprise logs, since retention and access requirements can differ between them.
Incident response and reporting
CIP-008-6 requires incident response plans and reporting for applicable systems, and the CSF Respond Function covers analysis, containment, mitigation and communication outcomes for the enterprise. An incident that touches a BES Cyber System may trigger CIP reporting steps on a timeline that is separate from your general playbook. Map the CIP response steps into the enterprise runbook and confirm reporting obligations with your Regional Entity before an incident occurs.
Recovery planning and availability
CIP-009-6 sets recovery plan requirements for BES Cyber Systems, and CIP-012-2 adds protection of the availability of Real-time data between Control Centers, enforceable from 1 July 2026. The CSF Recover Function covers recovery planning, improvements and communication for the enterprise, which often includes backups, restoration testing and continuity of business functions. Check that restoration tests for CIP systems are documented separately from enterprise exercises, so the CIP evidence is complete on its own.
Supply chain and vendor remote access
CIP-013-2 sets supply chain cybersecurity risk management requirements, and CIP-003-9 adds vendor electronic remote access controls for low impact BES Cyber Systems, enforceable from 1 April 2026. The CSF Govern Function covers supplier and third-party risk as an enterprise outcome, so vendor reviews often serve both programs. Confirm which vendors are in CIP scope, since remote access by a vendor to a low impact asset can create CIP obligations even when the vendor's enterprise contract looks routine.
Who assesses each framework and what it produces
This table compares who checks compliance under NERC CIP and the NIST CSF, what each produces, and how often the cycle runs. Read it to see which obligation carries an external audit and penalty exposure and which is an internal, voluntary outcome record.
| Dimension | NERC CIP | NIST CSF 2.0 |
|---|---|---|
| Who assesses | The Compliance Enforcement Authority, either a Regional Entity or NERC, audits registered entities against the standards that apply to their registered functions | The organization assesses itself. NIST offers no certification or conformity assessment program for CSF-based implementations |
| Certificate or report | No CIP certificate exists. Outcomes are audit findings, possible penalties, Compliance Exceptions or Find, Fix, Track and Report (FFT) resolutions | No certificate or external attestation. Outputs are internal Current and Target Organizational Profiles and tier assessments that you define |
| Who is bound | Registered entities with BES Cyber Systems, enforced in the United States once FERC approves each standard | Voluntary for most organizations. Some customers or suppliers may require it contractually, and it is mandatory for U.S. federal agencies |
| Scope of review | Only systems categorized under CIP-002-5.1a as high, medium or low impact, scoped by Applicable Systems in each standard | The whole enterprise or any chosen part, defined by the organization's own profile and risk decisions |
| Audit notice | At least 270 days before a planned Compliance Audit, with the standards in scope and document request at least 90 days before the audit | None. Timing is set internally, so the reader should confirm any external reporting obligation in its contracts |
| Review cycle | Impact categorization reviewed and approved at least every 15 calendar months, plus audit cycles set by the Regional Entity | Set by the organization. NIST publishes updates to references and guides on its own schedule, and no revision of the Core has been issued |
| Where DeployOpen fits | Prepares evidence, system inventories and categorization records for the entity's own review. Does not issue audit results or enforcement outcomes | Helps build profiles, tier assessments and evidence files. Does not issue certifications, attestations or CSF ratings |
Doing both: order of work and shared evidence
Running CIP and the CSF in a fixed order lets the CIP obligations, which carry audits and penalties, set the boundary first, while the enterprise CSF profiles reuse the same inventories, access records and incident evidence instead of building them twice. The sequence ends with a Current Profile and Target Profile that cover the whole organization.
Confirm registration and registered functions
Compliance or regulatory affairs leads confirm which NERC registered functions the organization holds, such as Transmission Owner, Generator Owner or Balancing Authority, and which Reliability Standards apply to each. The Compliance Enforcement Authority audits against the standards tied to those functions, so this list defines the CIP scope for everything that follows. The output is a written registration record and a list of applicable standards that the CIP senior manager signs off on. Confirm the list with your Regional Entity if a function is unclear.
Complete CIP-002 impact categorization
Operations, engineering and the CIP Senior Manager or delegate apply the bright-line criteria in CIP-002-5.1a Attachment 1 to every asset and BES Cyber System, sorting each into high, medium or low impact. Document the reasoning for each decision, not only the result, because auditors test the basis for the categorization. The output is an approved categorization list, which must be reviewed and approved at least every 15 calendar months. Confirm the current CIP-002 version applicable to your entity, since revised versions carry later effective dates.
Close CIP obligations for in-scope systems
Compliance and system owners map each requirement to the Applicable Systems in its table, such as high impact BES Cyber Systems or associated EACMS, PACS and PCA, then implement or evidence the controls for those assets. Controls covering access, configuration, monitoring and incident response are the most reused later, so record them in a form that others can read. The output is per-requirement evidence packages that the Compliance Enforcement Authority can review in an audit. Check the NERC CIP standards page for the effective dates of any new or revised versions before you set your deadlines.
Build the enterprise asset and access inventory
IT, OT and security teams merge the CIP asset lists with corporate asset inventories, identity directories and access review records, so one inventory covers both the CIP boundary and the rest of the enterprise. Tag each asset with its CIP categorization and business owner rather than keeping separate spreadsheets. The output is a single inventory that supports CSF asset identification and CIP evidence requests. Confirm that CIP-specific fields and record retention still meet the CIP evidence expectations after you merge sources.
Reuse incident and monitoring records across both
Security operations maps incident response, monitoring and reporting records to both the CIP incident and recovery requirements and the CSF Detect, Respond and Recover outcomes. One incident file, with the CIP-specific reportable details flagged, avoids two versions of the same story. The output is a shared incident evidence template and a short map from each CIP field to the CSF subcategory it supports. Confirm reporting timelines and recipients directly with the Regional Entity and your legal team, since this guide does not state them.
Start from the sector Community Profile
Governance and risk leads download the relevant sector Community Profile and use it as a baseline for the Target Profile, because CSWP 29 describes Community Profiles as shared baselines that can serve as the basis of an organization's Target Profile. Adjust the Target Profile for the enterprise, such as corporate IT and business units that sit outside the CIP boundary. The output is a draft Target Profile with notes on where the enterprise departs from the sector baseline and why. Confirm which Community Profiles NIST currently publishes for electric utilities before assuming one exists.
Build the Current Profile and close gaps
Security and IT leads record the organization's current CSF outcomes across Govern, Identify, Protect, Detect, Respond and Recover, pulling evidence from the shared inventory, access records and incident files already built. Compare the Current Profile with the Target Profile to produce a prioritized gap list. The output is a signed Current Profile, a Target Profile and a gap plan that names owners for each gap. Note that the CSF is voluntary, so the plan records your own decisions, while CIP gaps remain binding obligations to close first.
Review profiles against each CIP cycle
Compliance and security leads set a recurring review that refreshes the CIP-002 categorization, the CIP evidence packages and the CSF profiles together, so changes to assets or standards update both records at once. Track new CIP versions and their effective dates on the NERC standards page. The output is a dated review log showing which shared records changed and why. Confirm the review frequency that fits your audit calendar with your Regional Entity contact.
How much effort, time and input does each framework need from us
What drives the cost of a NERC CIP compliance program?
The main drivers are how many assets fall into scope, which impact categories they land in, and how much evidence each Applicable System has to produce. CIP-002-5.1a sorts BES Cyber Systems into high, medium and low impact using bright-line criteria, and most requirements are scoped by those categories, so a larger high or medium population means more controls to implement, document and sample at audit. Evidence volume grows with the number of Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets tied to each system. Costs are both one-time (categorization, gap analysis, tooling, procedures, and the first full evidence cycle) and recurring (periodic reviews, access reviews, patch and vulnerability work, and audit preparation). Ask any provider to price these components separately, and confirm the asset count and categorization basis with your own CIP Senior Manager before requesting a quote.
How much does virtualization change under FERC Order No. 919 affect planning?
Order No. 919, issued 19 March 2026 and effective 26 May 2026, approved 11 revised CIP standards that accommodate virtualization, including CIP-002-7, CIP-005-8, CIP-007-7.1 and CIP-010-5. NERC lists these as effective 1 July 2028. If your environment runs virtualized BES Cyber Systems, plan a design and evidence review against the revised text well before that date, because hypervisor, management plane and shared-infrastructure decisions affect how Applicable Systems are scoped and how baselines are documented. Effort depends on how much of your estate is virtualized and whether your current configuration baselines and change records can show the virtual layer. Confirm the transition details and your Regional Entity's expectations directly, since the enforceable obligations and any transition handling are set in the orders and NERC's standards page.
How much effort does a CSF 2.0 profile take to build?
Effort depends on the scope of the profile and how much existing material you can reuse. A CSF profile is a set of outcomes chosen from the Core's six Functions, 22 Categories and 106 Subcategories, recorded as a Current Profile and a Target Profile. The work has three parts: deciding the scope (enterprise, a business unit or the OT environment), recording the current state against the relevant Subcategories, and agreeing the target and the gap plan. NIST's Community Profiles can give a starting baseline for a sector or technology, and the CSF 2.0 Reference Tool's Implementation Examples and informative references help map existing controls. NIST does not publish a time or cost for building a profile, so confirm the expected effort with the workshop owners and your own control inventory. Ask for the scope, number of workshops and evidence review in the quote.
Can our internal staff run a CSF-based program without outside help?
Often yes for a voluntary CSF program, because NIST does not certify anyone and no external assessment is required. The framework is intentionally outcome-based and flexible, so a team with security, operations and governance representation can build a profile, track progress and report to leadership. Outside help is more useful for specific gaps: independent testing, an OT-literate review, or drafting evidence that an auditor will later rely on. The CIP side is different. Registered entities must meet the mandatory CIP standards, and a Compliance Audit will test that the program works in practice. Internal staff can run it, but they need documented roles (including the CIP Senior Manager or delegate), enough people to operate every required control, and time for audit preparation. Assess your capacity against the Applicable Systems list before deciding.
How long does a CIP-002 categorization review take?
CIP-002-5.1a requires the categorization of BES Cyber Systems as high, medium or low impact to be reviewed and approved by the CIP Senior Manager or delegate at least every 15 calendar months. That interval is the only fixed timing fact for the review. The effort to complete it depends on how many BES Cyber Systems and assets you hold, how well your asset inventory is maintained, and whether the bright-line criteria in Attachment 1 need engineering analysis for borderline assets. Reviews also need to be re-run after significant changes to the environment. Plan the review as a recurring activity with named reviewers, a current asset list and an approval record. Confirm your internal review duration with your own compliance and operations teams, since no supplied figure sets it.
Which 2026 standard changes should we plan for first?
Two standards are already enforceable and should be in your current baseline. CIP-003-9 adds vendor electronic remote access controls for low impact BES Cyber Systems and became enforceable on 1 April 2026. CIP-012-2 adds protection of the availability of Real-time data between Control Centers and became enforceable on 1 July 2026. Later changes have longer runways:
- CIP-015-1 (Internal Network Security Monitoring) is subject to enforcement from 1 October 2028, and CIP-015-2 extends monitoring to associated EACMS and PACS with an effective date of 1 October 2029.
- The Order No. 919 virtualization revisions are listed as effective 1 July 2028.
- CIP-003-11, from Order No. 918, is listed as effective 1 July 2029.
Plan the enforceable changes first, then budget for the network monitoring and virtualization work. Confirm each effective date against the NERC CIP standards page before you commit budget.
What should we ask for in a fixed-scope quote?
A fixed-scope quote should state the scope, deliverables and timeline in writing before work starts, as DeployOpen's engagements do. For a CIP program, ask for the list of Applicable Systems covered, the assumed impact categorization and how it will be reviewed, the number of asset types and sites, the evidence set per requirement, and the audit-support tasks included. For a CSF profile, ask for the profile scope, the workshops planned, the informative references used, and the output format. Also ask what is excluded (for example, testing, tooling licenses or ongoing support), what changes the scope, and how the retainer for upgrades and continuous review would work. DeployOpen does not publish a price list, so the quote follows from the written scope. Confirm with your Regional Entity any expectations that affect the evidence set.
What to confirm with NERC, your Regional Entity and your own environment
Start by confirming your registered functions in the NERC Compliance Registry, because those functions decide which Reliability Standards apply to you at all. A generator owner, transmission owner or balancing authority will see different obligations than a registered entity with no BES Cyber Systems, and the registry entry is the record your Regional Entity will work from. Ask your compliance lead to pull the current registration and confirm it matches what your operations and engineering teams believe the company owns and operates. If you hold the registration through a parent or shared function, confirm which entity is named.
Next, check the effective dates for each standard against your own asset list. CIP-015-1 (internal network security monitoring) carries a future enforcement date, while CIP-002-8 and CIP-003-11 are approved versions with later effective dates. Use NERC's CIP standards page as the reference for status and United States effective dates, and confirm with your Regional Entity how transition periods apply to your systems. Record which version of each standard you are planning against, because a plan built on the wrong version will be measured against the wrong requirements.
Then confirm the Regional Entity audit schedule and whether any CIP-013 supply chain obligation applies to your vendors and remote access arrangements. Ask the Regional Entity for its notice practice and the audit window it expects, since the Compliance Enforcement Authority must give advance notice under its procedures. Confirm with your vendor management and procurement teams which suppliers touch in-scope systems, so you know whether CIP-013 supply chain risk management applies to them. Keep the answers in writing, because they set the timeline for any CSF-based program you build around the CIP boundary.
How DeployOpen scopes and delivers readiness for both frameworks
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For NIST CSF vs NERC CIP, we help you prepare systems, controls and evidence for compliance assessments, while independent auditors and the Compliance Enforcement Authority make the determinations.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which BES Cyber Systems, enterprise assets and CSF functions are in and out of the work.
- Ask us to confirm how the impact categorization from CIP-002 feeds the CSF scope before any build begins.
How we build
- We plan and configure the controls, logging and access records that the written scope requires in your environment.
- Testing covers applications, infrastructure and cloud configurations, with results tied back to the agreed deliverables.
- Where an open-source platform is part of the design, we document customizations and hardening decisions as we go.
How we hand over
- You receive documentation of the controls, procedures and evidence sources built under the written scope.
- Handover records map each deliverable to the framework item it supports, so your auditors can trace the evidence.
- We do not issue audit reports, attestations or certifications, so you should confirm with your regulator or auditor what they will accept.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover standards updates, such as the 2026 CIP revisions, once they are scoped in writing.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
