CIP-012-2 R1 communications protection plan: requirements and evidence

What CIP-012-2 R1 asks registered entities to plan for

CIP-012-2 R1 asks a registered entity to implement documented plans that mitigate three risks to Real-time Assessment and Real-time monitoring data while it travels between applicable Control Centers: unauthorized disclosure, unauthorized modification and loss of availability. The plan has to name the methods used for each risk, say where those methods sit, and state who is responsible when the other end of the link belongs to a different Responsible Entity. Under the standard, the plan is the thing a Compliance Enforcement Authority will ask to see first, so the work starts with a written inventory of every communication path that carries this data, not with the encryption settings themselves. The first two risks are the familiar ones. Disclosure and modification are addressed by Part 1.1, which asks for identified methods such as encryption or data masking, and the evidence an entity would show is the method itself plus proof that it is applied on each path. Loss of availability is the newer element that version 2 added, and Part 1.2 expects methods to mitigate the loss of the ability to communicate, such as alternative communication paths or carrier service level agreements with high availability provisions. Part 1.3 adds the need to initiate recovery of the links, which points to documented link recovery procedures or the relevant sections of a CIP-009 recovery plan. Version 2 became enforceable on 1 July 2026, so entities should confirm that their availability methods were in place and documented by that date.

Several things make this hard in practice. A single Control Center-to-Control Center path often crosses more than one leased circuit, microwave hop, MPLS network or internet tunnel, and each segment may be run by a different carrier with its own contract. Mapping those hops, and confirming which party controls encryption keys on each one, usually takes longer than writing the plan. Part 1.4 requires the plan to say where each method is implemented, so a carrier-run encrypted service and an entity-run VPN need to be recorded differently. The second Control Center may belong to another Responsible Entity, which brings Part 1.5 into play: each side must document its own responsibilities, and both sides need to agree on who monitors the link, who initiates recovery and how key or certificate lifecycles are handled. A useful first step is a path inventory that lists each link, each segment owner, each protection method and each recovery action, then a review of those rows with the other entity and each carrier. Ask carriers for the service level terms and uptime reporting that back up the availability claims, and ask the other entity to confirm its side in writing. Where an entity outsources parts of the implementation, the contract should make clear who produces the evidence. Confirm the current scope and the evidence expectations with your Regional Entity and the version of the standard in force for your entity, because the plan is judged against the requirement as written.

Which Control Center links fall under the CIP-012-2 R1 plan

The CIP-012-2 R1 plan covers Real-time data moving between applicable Control Centers, so the first job is deciding which Control Centers and which links count. Each decision below changes who owns the methods and how much work the plan carries. Confirm every scoping call against your CIP-002 categorization before you build the plan.

Applicable Control Centers

CIP-012-2 applies to Control Centers that fall within its scope, and the list of applicable sites comes from your CIP-002 categorization of BES Cyber Systems. High impact Control Centers are the usual starting point, but the categorization decides which medium impact or other Control Centers are in scope. Ask the compliance lead for a written list of applicable sites and the BES Cyber Systems at each one, and check that the list matches your current asset inventory.

Real-time data definition

The plan protects data used in Real-time Assessment and Real-time monitoring while it is in transit, so each data flow must be classified against those two terms. Telemetry and state estimator inputs usually qualify, while historical reporting, engineering files and email typically do not. Document the classification rule and the list of data flows it covers, and confirm the boundary with operations and your Reliability Coordinator.

Links to another entity's Control Center

When a Control Center is owned or operated by a different Responsible Entity, Part 1.5 requires the plan to name each entity's responsibilities for the communication path. The two entities must agree who implements encryption, who monitors the link, and who starts recovery. Confirm these split responsibilities in writing with the other entity, since a gap in one party's controls leaves the shared data flow unprotected.

Carrier and third-party circuits

Many Control Center links run over leased circuits, MPLS services or internet transport owned by a carrier or managed provider. The plan still has to show how data in transit is protected and how loss of the path is mitigated, even though the entity does not own the medium. Ask each provider for its service level agreement, high availability provisions and uptime reporting, and confirm whether the provider or your team applies encryption end to end.

Dual paths and backup links

Part 1.2 expects methods to mitigate loss of the ability to communicate, and alternative communication paths are a common answer. Identify whether each in-scope data flow has a second route, whether that route is physically diverse, and whether it carries the same protections as the primary link. A backup path that bypasses encryption or was never tested will not satisfy the requirement on its own.

Link recovery ownership

Part 1.3 requires methods to initiate recovery of the communication links, which can point to a documented procedure or to the relevant section of a CIP-009 recovery plan. Decide who detects a link failure, who calls the carrier, and who verifies that Real-time data is flowing again. Record those roles in the plan so a dropped circuit does not turn into an undocumented outage.

What version 2 added and why plans written for version 1 fall short

CIP-012-2 added availability to the risks a Control Center communications plan must address. Version 1 focused on unauthorized disclosure and modification of Real-time data in transit. Version 2 adds the risk of loss of the ability to communicate that data, and it became enforceable on 1 July 2026 (NERC CIP standards page). A plan written only for encryption and integrity answers Part 1.1 but leaves Part 1.2, which asks for methods to mitigate loss of communication, and Part 1.3, which asks for methods to initiate recovery of the communication links, with no documented answer. An assessor will look for those two parts specifically, so a plan that stops at encryption is incomplete on its face.

Mapping an existing plan starts with a line-by-line read of the standard against the document. Mark which sentences describe Part 1.1 methods such as the encryption or masking applied to Real-time data, then ask whether any sentence names an alternative communication path, a carrier service level agreement with high availability provisions or uptime reports for Part 1.2, and a link recovery procedure or a cross-reference to the relevant CIP-009 recovery plan section for Part 1.3. Gaps are usually the Part 1.2 and 1.3 content. Confirm the mapping with your own compliance lead or independent advisor, because the supplied facts do not include a mapping of NERC's text to any specific product or architecture.

Treat the gap analysis as a decision list, not a drafting exercise. For each missing element, decide who owns it, what it costs in staff time and vendor terms, and what evidence will prove it works. Carrier agreements and uptime reports sit with procurement and the communications provider, so ask them early. For a self-hosted design, an illustrative example would be a team that already encrypts links with TLS but has no documented fallback path; its work is to define that path, record where it sits, and test the link recovery step before an assessor asks.

How an assessor tests the CIP-012-2 R1 plan

This table walks through how a Compliance Enforcement Authority typically tests each part of CIP-012-2 R1, the evidence it usually asks for, and where entities most often receive findings. Read it as a preparation checklist: the auditor decides whether evidence is sufficient, so use the examples as starting points and confirm scope with your Regional Entity.

Requirement part	What the assessor checks	Evidence typically requested	Common findings
Implementation (R1 lead-in)	The documented plan exists, is implemented for applicable Control Center communications, and covers Real-time Assessment and Real-time monitoring data in transit	Written plan, scope of applicable Control Center pairs, records showing methods are operating, any CIP Exceptional Circumstances records	Plan covers only some data flows, or the plan exists on paper but a link carries Real-time data outside its described methods
Part 1.1 (confidentiality and integrity in transit)	Named methods protect data against unauthorized disclosure and modification between Control Centers	Encryption or data masking configuration, protocol settings, certificate or key inventory, network diagrams showing where protection applies	Methods named generically, no evidence that protection is active on every link, keys or certificates not managed or rotated
Part 1.2 (loss of communication)	Methods exist to mitigate loss of the ability to communicate Real-time data, such as alternative paths	Alternative communication path diagrams, carrier service level agreements with high availability provisions, uptime reports	Single path with no documented alternative, carrier SLA not reviewed, uptime reports missing or not tied to the plan
Part 1.3 (link recovery)	Methods initiate recovery of the communication links after a loss	Link recovery procedures, or the relevant sections of the CIP-009 recovery plan, and records of tests or real events	Recovery steps undocumented, owner unclear, procedures never exercised or not linked to CIP-009
Part 1.4 (where methods are implemented)	The plan identifies where the Part 1.1 and 1.2 methods sit, such as at endpoints, in transit devices or at a provider	Architecture or data flow diagrams, device lists, configuration extracts that match the stated locations	Diagrams out of date after a network change, or locations named at a level too vague to verify
Part 1.5 (responsibilities across entities)	When Control Centers belong to different Responsible Entities, each party's responsibilities are identified	Agreements or documented responsibility matrices with each counterparty, contact and escalation records	Responsibilities assumed rather than written, or one side's duties missing from the plan
Plan maintenance and review	The plan reflects current systems and is kept up to date with the environment	Revision history, change records tied to network or key changes, review sign-off dates	Plan revised only after an audit request, or changes to carriers, keys or paths not reflected
Sufficiency decision	Whether the evidence shows the methods work as described is a judgment made by the auditor	Ask the Regional Entity or auditor which evidence formats they accept before the audit period	Entities assume a screenshot or policy statement satisfies a test that the auditor expects to see operating

Implementing the CIP-012-2 R1 plan step by step

This sequence turns the R1 requirement into a documented plan that names every in-transit method, its location, and the entity responsible for it, so an auditor can trace each Real-time data flow from source to recovery.

Confirm applicable Control Centers and data flows
Start by listing which Control Centers exchange Real-time Assessment and Real-time monitoring data, using the entity's CIP-002 categorization as the scoping input. For each pair, record the data types, the direction of flow, the transport path, and the systems at each end. The output is a data flow inventory that names every link in scope. The step is done when the operations, network and compliance owners have each signed off that no Control Center or link has been left out.
Identify the in-transit protection method per link
For each link in the inventory, record the method that protects Real-time data against unauthorized disclosure and modification while it moves. Typical evidence for Part 1.1 includes encryption of the channel or data masking, and the method must be stated per link, not as a general statement about the network. Confirm the cryptographic settings with the team that operates the link, since a method that is documented but not configured will not survive testing. The output is a per-link protection register that the R1 plan can cite.
Define availability and alternate-path methods
Version 2 adds Part 1.2, which asks for methods that mitigate loss of the ability to communicate Real-time data. For each link, document the alternate path, backup communication route, or carrier arrangement that keeps data flowing when the primary path fails. Where a carrier provides the service, ask for its service level terms and high availability provisions, or its uptime reports, and keep them with the plan. The output is an availability method per link with the evidence that supports it.
Document link recovery methods
Part 1.3 requires methods to initiate recovery of the communication links. Write the steps that detect a failed link, notify the responsible staff, and restore the path, and reference the relevant recovery plan sections under CIP-009 where they apply. Assign who starts recovery and what they do first, so that the procedure works during an event rather than only on paper. The output is a link recovery procedure with named roles and a cross-reference to the recovery plan.
Record where each method is implemented
Part 1.4 asks the entity to identify where the methods for Parts 1.1 and 1.2 are implemented. For each method, record the physical or logical location, such as the endpoint, gateway, encryption device, or carrier demarcation point, along with the system owner. Keep this mapping current, because an assessor will sample a method and expect to find it at the recorded location. The output is an implementation location map that ties every method in the register to a specific device or service.
Agree responsibilities with other Responsible Entities
Where a Control Center is owned or operated by a different Responsible Entity, Part 1.5 requires each entity's responsibilities to be identified. Hold a written agreement or joint working session that states who runs each method, who monitors it, who responds to failures, and who keeps the evidence. Include any vendor or carrier that operates part of the path. The output is a responsibility matrix, signed by each entity, that the plan references for every shared link.
Approve the plan and set evidence retention
Bring the inventory, method register, location map, recovery procedure and responsibility matrix together into one R1 plan document, then obtain approval from the entity's CIP Senior Manager or delegate under the entity's governance process. Set where the plan and its evidence are stored, who maintains them, and how changes trigger an update. The output is an approved, version-controlled plan that the entity can produce on request during a monitoring engagement.

Which open-source tools can support CIP-012-2 R1 evidence

The Part 1.1 and Part 1.2 methods in a CIP-012-2 R1 plan are often built from encryption, key management and certificates. The open-source tools below can produce evidence for some of those methods, but each covers only part of the picture. Confirm each one against your own Control Center links before you cite it in the plan.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It fits only where a Control Center team stores Real-time related files in Nextcloud and needs evidence of encryption for that stored data. It does not encrypt file names or folder structure, so metadata remains visible. It does not protect data while it moves between Control Centers. Confirm with your own architecture whether any Real-time data passes through this service at all.

OpenBao transit secrets engine

The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with key rotation. This gives an entity a way to show application-level encryption and documented rotation for data that a supported application sends. The evidence is the key version history and rotation records. The limit is that the engine protects the payload only if your applications call it. Confirm that the telemetry path itself, including links and gateways, is covered by a method the plan names.

FreeIPA integrated certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For CIP-012-2 R1, the certificate inventory and issuance records can support evidence that endpoints in a communication method use certificates from a managed authority. The limit is scope: FreeIPA manages certificates but does not, by itself, encrypt Control Center links or prove that a link uses them. Confirm which endpoints, if any, your plan assigns to certificates issued from this authority, and document where that assignment sits in your Part 1.4 listing.

cert-manager TLS renewal

cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME, a CA key pair, HashiCorp Vault, CyberArk or self-signed. It stores them in Kubernetes Secrets and renews them before they expire. Renewal logs and certificate status records can show that certificates for a containerized communication service stay current. The limit is that cert-manager applies only to workloads on those platforms. Confirm that the Control Center communication endpoints run there and that the issuer you choose meets your own trust and key management requirements.

What meeting CIP-012-2 R1 costs in money and effort

This table breaks the cost of meeting CIP-012-2 R1 into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No dollar figures or durations are given because none are supplied for this requirement, so use the request column when asking for quotes. Read it as a checklist for scoping and budgeting conversations.

Cost component	One-time or recurring	What drives it	What to request in a quote
Tooling and licenses for encryption and key management	Recurring where commercial licenses apply; one-time for setup	Number of Control Center links, key management scope and whether vendor support is bought; open-source options such as OpenBao and cert-manager carry no license fee but still need hosting and support	Itemized license terms, support tiers and any per-node or per-link fees, with the open-source components listed separately
Engineering time for method design (Parts 1.1 to 1.5)	One-time, with periodic revision	Number of applicable Control Centers, how many data flows carry Real-time Assessment and monitoring data, and whether the two Control Centers have different Responsible Entities	A written breakdown of design tasks, the named deliverables and the number of review cycles included
Carrier or circuit costs for alternate paths and high availability terms	Recurring	Need for diverse routes, the availability terms a carrier will contract for, and whether backup links are always-on or standby	Quotes for primary and alternate circuits, the service level terms offered, and the uptime reporting the carrier provides
Testing and link recovery exercises	Recurring	Frequency the entity sets for testing failover and recovery steps, and whether tests are coordinated with CIP-009 recovery plan exercises	The testing scope, who runs each test, and what evidence records are delivered after each exercise
Evidence upkeep	Recurring	Frequency of configuration changes to encryption, routing and recovery procedures, and the volume of logs and records kept for each Part	A description of the evidence set maintained, the retention period the entity applies and who updates the records after changes
External review of the plan	Recurring or per engagement	Scope of the plan, number of Control Centers and whether an independent party reviews the methods before the audit	Written scope, reviewer qualifications and deliverables, with the review kept separate from any audit fee
Auditor sampling and compliance audit effort	Recurring on the audit cycle	Compliance Enforcement Authority selection, the audit period, and how many Control Center links and data flows the auditor samples	The organization's own preparation plan. Auditors issue findings, not DeployOpen, so confirm the audit scope and sample sizes directly with the Regional Entity
Open-source platform implementation	One-time, with recurring support if retained	Platform choices, integration with existing networks and the depth of documentation and hardening required	A fixed-scope proposal listing deliverables, assumptions about the client environment and any ongoing support retainer terms

Who owns each part of the plan and what can be outsourced

The registered entity owns the plan. Its compliance and operations leadership decide which methods protect Real-time data in transit, accept the residual risk of each choice, and approve the document. CIP-012-2 R1 is an obligation on the entity, so no vendor or consultant can take it over. Part 1.5 is especially internal: when two Responsible Entities own or operate the connected Control Centers, each entity must state its own responsibilities, and those statements need agreement from both sides.

Method selection: Decide the confidentiality, integrity, availability and link recovery methods for each communication path, and record the reasoning.
Part 1.4 location records: Identify where each method runs, such as a particular gateway, carrier circuit or key service, and keep that list current.
Part 1.5 responsibilities: Agree responsibilities with the other Responsible Entity in writing, including who maintains the link, who responds to failures and who holds keys.
Approval and review: Assign a senior owner to sign off the plan and the change record when methods change.
Carrier and vendor contracts: Own the service level terms that back the Part 1.2 availability methods.

Before accepting any partner's work, confirm that your own team can explain every method, its location and the Part 1.5 split without reading the vendor's documents.

Where CIP-012-2 R1 plans usually fall short

Most CIP-012-2 R1 plans cover the encryption step and stop there. The gaps below cluster around availability, recovery and ownership, which are the parts added or sharpened in version 2 and the parts an assessor is most likely to ask for evidence on.

Plan covers only confidentiality and integrity

Many plans name encryption for data in transit under Part 1.1 and say nothing about Part 1.2, which asks for methods to mitigate loss of the ability to communicate Real-time data. A plan that stops at disclosure and modification leaves the availability risk unaddressed. Check that the plan has a separate, documented method for each of the three risks and that each method names the link or service it protects.

No evidence of alternate paths

Part 1.2 mitigations are often described in general terms, such as redundancy, without showing a second communication path between the two Control Centers. The fix is to document the primary and alternate routes, the equipment or carrier on each, and the data that shows the alternate path is configured and usable. Illustrative example: a plan that names a backup microwave link should also point to the routing or failover configuration that activates it.

Carrier agreements without availability terms

A plan that relies on a telecommunications carrier for Part 1.2 needs more than a contract reference. Ask the carrier for service level terms that include high availability provisions, and keep uptime reports that show how the link performed. Without these, the plan has a claim the entity cannot demonstrate. Confirm the exact terms and reporting frequency with the carrier, since they vary by contract.

No responsibility split with the other Control Center

Part 1.5 asks for each entity's responsibilities when the two Control Centers are owned or operated by different Responsible Entities. Plans often name the methods but not who runs, monitors and repairs each one. Write a short responsibility matrix that assigns encryption key management, link monitoring and recovery actions to a named party on each side, and have both entities sign off on it.

Recovery steps not tied to CIP-009

Part 1.3 requires methods to initiate recovery of communication links, and the evidence examples point to link recovery procedures or relevant CIP-009 recovery plan sections. A recovery procedure written as a standalone checklist with no cross reference to the recovery plan is easy to miss during audit. Map each link recovery step to the CIP-009 section that covers it, and confirm that the CIP-009 testing schedule also exercises communication recovery.

What CIP-012-2 R1 costs, how long it takes and what it needs from us

What drives the cost of a CIP-012-2 R1 communications protection plan?

The cost depends mostly on how many Control Center links carry Real-time data, how many different carriers and vendors are involved, and how much of the existing encryption and redundancy is already documented. Organizations pay for three separate things: internal staff time to confirm the data flows, the implementation partner's fixed-scope work to write the plan and prepare evidence, and any new hardware, circuits or key management services. Ask any quote to list each link in scope, each method it names for Parts 1.1 to 1.3, the evidence to be delivered, and which costs are one-time and which recur, such as renewals and annual reviews. No DeployOpen price is published, and a quote follows from the written scope.

How long does it take to get a CIP-012-2 R1 plan ready?

Timeline depends on whether the communication paths are already known. Entities with accurate network diagrams, documented carrier contracts and existing encryption on inter-Control Center links usually spend most of the time on review and sign-off. Entities that must discover data flows, negotiate carrier service levels or add redundant paths need more time, and carrier lead times are often the longest item. CIP-012-2 became enforceable on 1 July 2026, so entities should confirm their own compliance dates with their Regional Entity and plan backward from them. A fixed-scope agreement sets the milestones in writing before work begins.

Can our in-house team write and maintain the plan without outside help?

Yes, many entities do this internally, especially when the Control Center network team already owns the links and has a CIP program. The work requires knowing exactly which Real-time Assessment and Real-time monitoring data crosses each link, what protects it in transit, and how each link recovers. Teams that lack staff for the evidence work, for testing recovery, or for keeping the plan current after network changes often bring in help for specific parts. Any outside partner prepares systems, documentation and evidence; the organization keeps ownership of its controls, and only an independent auditor issues compliance findings.

What does the work need from our network and carrier teams?

It needs network teams to provide current topology, routing and encryption configurations for each inter-Control Center path, and it needs carrier teams to provide service agreements and uptime reporting. Carrier contracts should be checked for high availability provisions and for the reporting that can serve as Part 1.2 evidence. Network teams also confirm where encryption or data masking is applied, such as at a gateway or within an application, because Part 1.4 requires the plan to name where each method sits. Where Control Centers are run by different Responsible Entities, the counterparties must agree in writing on their responsibilities under Part 1.5.

How does the CIP-012-2 R1 plan relate to CIP-009 and CIP-005?

CIP-012-2 R1 Part 1.3 allows link recovery methods to reference relevant CIP-009 recovery plan sections, so the communication recovery steps should be consistent with the recovery plan and tested with it. CIP-005 governs Electronic Security Perimeters and remote access, and the encryption and access paths on Control Center links often overlap with those perimeter controls. Entities should map each link once, then show how the same method serves both requirements, which avoids two inconsistent descriptions of one path. Confirm the exact applicability of each standard to your assets with your compliance lead.

Which encryption tools could support the confidentiality and integrity methods?

Open-source platforms can support the evidence, but the choice of method belongs to the entity. For example, a self-hosted secrets engine such as OpenBao's transit secrets engine can encrypt and decrypt application data, sign and verify it, and rotate versioned keys, which can document key handling. cert-manager can issue and renew TLS certificates for workloads in Kubernetes or OpenShift, and FreeIPA includes an integrated certificate authority based on Dogtag. Confirm each tool's fit with your link architecture, its licensing and its support model before relying on it as evidence.

What will the auditor check, and what will the auditor not do?

The Regional Entity or NERC, as the Compliance Enforcement Authority, reviews whether the plan exists, names methods for Parts 1.1 to 1.5, and is implemented as written. The auditor will request evidence such as encryption configurations, carrier uptime reports, alternative path records and recovery procedures. The auditor will not write the plan, design your network or certify the organization, because CIP compliance is monitored through audits, spot checks and self-certifications rather than issued certificates. An implementation partner can prepare the evidence, but it cannot issue audit results or attest to compliance.

How DeployOpen scopes and prepares CIP-012-2 R1 evidence

DeployOpen works on CIP-012-2 R1 by agreeing the Control Center communications in scope before any work starts, then preparing the protection methods and the documented plan that the registered entity owns. DeployOpen prepares systems and evidence only; the entity's own compliance function and the Compliance Enforcement Authority decide how the plan is judged.

How we scope

Confirm which Control Center links carry Real-time Assessment and Real-time monitoring data and which Control Centers they connect.
Record which Responsible Entity owns each Control Center, so the Part 1.5 responsibilities are documented from the start.
Agree the written scope, deliverables and timeline in writing before work begins, since most engagements are fixed-scope.

How we build

Implement confidentiality and integrity methods for data in transit, such as encryption with keys managed on the entity's own infrastructure.
Configure alternative communication paths and link recovery procedures, and document how they map to the Part 1.2 and Part 1.3 methods.
Test each method in the entity's environment and record the results so the evidence reflects what the systems actually do.

How we hand over

Deliver the written plan with each method, where it is implemented, and the responsible party for each Control Center.
Provide the evidence set that matches each Part, such as configuration exports, test records and recovery procedure references.
Walk the entity's compliance and operations staff through the plan so they can maintain it and answer assessor questions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can keep the plan current as links and systems change.
Review the plan when Control Center communications change, and update the evidence to match the current configuration.
Confirm with the entity's compliance lead which items the independent auditor or Regional Entity will request before each review.

CIP-012-2 R1 Control Center communications protection plan