CIP-011 BES Cyber System Information: what counts and how to protect it

Network diagrams, firewall rule sets, switch configurations, vulnerability assessment results: the documents that describe how a control system is built are also a map for anyone who wants to attack it. CIP-011 is the NERC CIP standard that asks you to treat that information as something to protect. The version in effect in the U.S. is CIP-011-3.

This post covers who CIP-011 applies to, what counts as BES Cyber System Information (BCSI), what the two requirements ask, and how CIP-004-7 controls who can get at it.

Who CIP-011 applies to

CIP-011-3 applies to high and medium impact BES Cyber Systems and their associated EACMS (Electronic Access Control or Monitoring Systems) and PACS (Physical Access Control Systems). Requirement R2 adds Protected Cyber Assets (PCA). Low impact BES Cyber Systems are not among the applicable systems, and CIP-003-9's list of low impact policy topics does not include information protection. A site whose BES Cyber Systems are all low impact has no CIP-011 obligation.

For solar, wind and battery owners that usually means:

• Individual plants are rarely in scope. Under CIP-002-5.1a criterion 2.1, a generating plant is medium impact only when its units add up to 1,500 MW or more at one plant location in one Interconnection. Almost every single site rates low impact.
• The control center is where to look. Criterion 2.11 rates a Control Center medium impact when it performs Generator Operator functions for 1,500 MW or more in a single Interconnection. If yours does, CIP-011 applies to its BES Cyber Systems, their EACMS and PACS, and the information about them.
• Category 2 inverter-based resources, registered with NERC since May 15, 2026, are not BES facilities and are not subject to the CIP standards at all.

None of this makes a low impact plant's network diagram harmless. It is just as useful to an attacker. Protecting it is good practice; it is simply not a CIP-011 requirement.

What counts as BCSI

In short, BCSI is information about a BES Cyber System that could be used to gain unauthorized access to it or to pose a security threat to it. Typical examples:

• network diagrams of BES Cyber Systems and Electronic Security Perimeters;
• firewall rules and access control lists that protect them;
• configuration files of BES Cyber Systems and Electronic Access Points;
• vulnerability assessment and penetration test results;
• physical security plans that show where BES Cyber Systems are;
• software design specifications for BES Cyber Systems.

Operational data such as sensor readings and SCADA values, public information, and general policies that reveal nothing specific about the systems are generally not BCSI. The test is whether the information could help someone get in or do harm.

Two things are easy to miss. BCSI produced by a third party is still BCSI: a network diagram drawn by an integrator or consultant counts the same as one drawn in-house. And copies multiply: the firewall export attached to an email, the diagram inside a commissioning report, the configuration backup on an engineer's laptop.

R1: an information protection program

Requirement R1 asks each Responsible Entity to implement one or more documented information protection programs for BCSI pertaining to the applicable systems. The program has two parts:

• Part 1.1: method(s) to identify BCSI.
• Part 1.2: method(s) to protect and securely handle BCSI to mitigate risks of compromising confidentiality.

The standard's examples of evidence for Part 1.1 are documented methods to identify BCSI, labels or classification on the information itself, training materials that give personnel enough knowledge to identify BCSI, or storage locations identified for housing BCSI.

For Part 1.2 the standard separates on-premise and off-premise BCSI. On-premise examples are procedures covering storage, security during transit and use, or records showing BCSI is handled as those procedures say. Off-premise examples, which fit BCSI held in a cloud service or by a vendor, are electronic methods (data masking, encryption, hashing, tokenization, cipher, electronic key management), physical methods (lock and key management, badge management, biometrics, alarm systems), and administrative methods such as vendor service risk assessments and business agreements.

Part 1.2 is about confidentiality. The question an auditor works through is whether BCSI can end up in front of someone who should not see it, wherever it is stored or sent.

R2: reuse and disposal

Requirement R2 covers the Cyber Assets that hold BCSI when they leave service:

• Part 2.1: before releasing an applicable Cyber Asset that contains BCSI for reuse (except reuse within other applicable systems), take action to prevent the unauthorized retrieval of BCSI from its data storage media.
• Part 2.2: before disposing of an applicable Cyber Asset that contains BCSI, take action to prevent the unauthorized retrieval of BCSI from it, or destroy the data storage media.

Evidence examples include records of sanitization (clearing, purging or destroying) and records of other actions such as encryption or keeping the asset inside the Physical Security Perimeter. A replaced HMI, a retired firewall or a failed historian disk all need that record. Be careful with solid-state drives: overwriting may not reach every cell, so cryptographic erase or physical destruction is the safer method. If a vendor destroys the media, keep its certificate of destruction.

CIP-004-7 R6: who can get at BCSI

Access to BCSI is managed under CIP-004-7 Requirement R6, not CIP-011. To count as access, an individual has both the ability to obtain and use BCSI. Provisioned access is the result of specific actions taken to give someone the means to access BCSI, such as physical keys or access cards, user accounts with their rights and privileges, or encryption keys. The parts:

• Part 6.1: before provisioning, authorize access based on need (unless already authorized under Part 4.1), except during CIP Exceptional Circumstances, for both electronic access to electronic BCSI and physical access to physical BCSI.
• Part 6.2: at least once every 15 calendar months, verify that everyone with provisioned access to BCSI has an authorization record and still needs the access for their current work.
• Part 6.3: for termination actions, remove the individual's ability to use provisioned access to BCSI by the end of the next calendar day after the termination takes effect (unless already revoked under Part 5.1).

R6 applies to high impact BES Cyber Systems and to medium impact BES Cyber Systems with External Routable Connectivity, with their EACMS and PACS. That is narrower than CIP-011's medium impact scope, so check which applies to each system.

Software counts too. FERC staff's 2026 CIP audit lessons learned suggested limiting what BCSI AI tools can reach, under CIP-011, and treating access they facilitate like any other access under CIP-004-7.

A practical starting list

• Write down your identification method: which kinds of information are BCSI, and how they are labeled or where they are stored.
• List every BCSI repository: file shares, document systems, cloud folders, engineering laptops, locked cabinets, and copies held by vendors and integrators.
• Set handling rules for transit: how BCSI goes to a vendor, and what is not allowed, such as sending it to someone who is not authorized.
• Tie each repository to CIP-004-7 R6: authorization before access, a 15-month verification, and removal by the end of the next calendar day after a termination.
• Keep a reuse and disposal record for every drive and device that held BCSI.

Where automated evidence collection fits

Tools that collect device configurations automatically produce useful evidence for other standards, but what they collect is often BCSI itself: firewall rule sets, switch configurations, network addresses in context. So the collection system is a BCSI repository too, and belongs in your R1 program and your R6 access list. When you evaluate one, ask where the data is stored, who can reach it, and whether it leaves your network. GridShield's Command Center runs on-premises or air-gapped and does not require a connection to the internet or to GridSafe, and sign-in supports multi-factor authentication, account lockout and role-based personas. You still decide who is provisioned to it, and record that under CIP-004.

CIP-011-3 is the version audited today. CIP-011-4.1, part of the virtualization revisions, takes effect in the U.S. on July 1, 2028.