NERC CIP-011: information protection for BES cyber systems, explained

CIP-011 applies to High and Medium Impact BES Cyber Systems, categorized under the separate CIP-002 process, and — depending on the requirement — their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCA).

Both requirements in the standard are built around a single defined term: BES Cyber System Information (BCSI). Per NERC's own Glossary, BCSI is "information about the BES Cyber System that could be used to gain unauthorized access or pose a security threat to the BES Cyber System." The definition is deliberately narrower than "anything related to a BES Cyber System" — it excludes "individual pieces of information that by themselves do not pose a threat or could not be used to allow unauthorized access to BES Cyber Systems, such as, but not limited to, device names, individual IP addresses without context, ESP names, or policy statements." What the definition does include: "security procedures or security information about BES Cyber Systems, Physical Access Control Systems, and Electronic Access Control or Monitoring Systems that is not publicly available and could be used to allow unauthorized access or unauthorized distribution; collections of network addresses; and network topology of the BES Cyber System." Getting this scoping right matters in practice — a CIP-011 program that over-classifies BCSI (treating every IP address or device name as protected) creates unnecessary handling overhead, while under-classifying it (missing network topology diagrams or access procedures) leaves genuine gaps.

Requirement R1 (Medium VRF, Operations Planning time horizon) requires "one or more documented information protection program(s)" covering two parts:

Part 1.1's scope and Part 1.2's scope both cover High and Medium Impact BES Cyber Systems and their associated EACMS and PACS. Notably, CIP-011-3 does not mandate a single specific protection technology — the standard's own Measures language lists encryption, hashing, tokenization, physical controls and administrative controls as equally acceptable examples, leaving the entity to select methods appropriate to how and where it stores BCSI.

Requirement R2 (Lower VRF, Operations Planning time horizon) requires documented processes for two distinct triggers, and additionally scopes in Protected Cyber Assets (PCA) alongside BES Cyber Systems, EACMS and PACS:

• Part 2.1 (Reuse) — "Prior to the release for reuse of applicable Cyber Assets that contain BCSI" (except reuse within other in-scope systems), the entity must "take action to prevent the unauthorized retrieval of BCSI from the Cyber Asset data storage media." Acceptable evidence includes records of sanitization actions (clearing, purging, destroying) or records of alternative controls such as encryption or retention within a Physical Security Perimeter.
• Part 2.2 (Disposal) — "Prior to the disposal of applicable Cyber Assets that contain BCSI," the entity must either prevent unauthorized retrieval of BCSI or destroy the data storage media outright.

Neither Part specifies a numeric sanitization timeline (no "within X days" window) — the requirement is purely sequential: the protective action must happen before reuse or disposal, with the specific method left to the entity's documented process. Entities building a decommissioning checklist should not invent a compliance deadline here; the standard's own text only requires the ordering, not a countdown.

Per CIP-011-3's Compliance section, "the applicable entity shall retain evidence of each requirement in this standard for three calendar years" — the same retention period used across the CIP suite (see CIP-004 and CIP-013). Where non-compliance is found, evidence related to it must be kept "until mitigation is complete and approved or for the time specified above, whichever is longer."

CIP-011-3 is the standard enforced today, but a successor is already locked in. On 19 March 2026 the Federal Energy Regulatory Commission issued Order No. 919 (Docket No. RM24-8-000), approving 11 modified CIP Reliability Standards together as part of NERC's Project 2016-02 virtualization package — published in the Federal Register on 24 March 2026 at 91 FR 13957, naming "CIP-011-4.1 (Cyber Security—Information Protection)" alongside CIP-002-7, CIP-003-10, CIP-004-8, CIP-005-8, CIP-006-7.1, CIP-007-7.1, CIP-008-7.1, CIP-009-7.1, CIP-010-5 and CIP-013-3. The order itself states "this final action is effective May 26, 2026." One naming note worth flagging: NERC's May 2025 supplemental petition referred to an interim errata draft as "CIP-011-4," but the version FERC actually approved — and the one to cite going forward — is CIP-011-4.1.

Per NERC's implementation plan, the revised standards take effect on the later of 1 April 2026 or "the first day of the first calendar quarter that is 24 months after" the order's effective date. NERC's own July 2026 Standards, Compliance, and Enforcement Bulletin confirms the resulting literal date, listing "CIP-011-4.1 – Cyber Security — Information Protection" among standards for which "the revised standards will become effective July 1, 2028." The package's substantive driver is the same across all 11 standards: four new NERC Glossary terms (Cyber System, Management Interface, Shared Cyber Infrastructure, Virtual Cyber Asset) and revisions to 18 existing defined terms, needed so the CIP suite applies cleanly to virtualized infrastructure. For CIP-011 specifically, NERC's proposed definition change extends BCSI to also cover information about "Shared Cyber Infrastructure" — otherwise, this guide found no indication that R1 or R2's substantive obligations change in the 4.1 revision beyond that scoping update; confirm exact redlined wording against NERC's and FERC's own published CIP-011-4.1 text before compliance planning.