CIP-011-3 R1 Information protection program: requirements and evidence

What CIP-011-3 R1 information protection program requires

CIP-011-3 Requirement R1 asks a registered entity to maintain a documented information protection program for BES Cyber System Information (BCSI), with methods to identify BCSI under Part 1.1 and methods to protect and securely handle it under Part 1.2. If your organization keeps BCSI in engineering documents, shared drives, ticketing tools, vendor portals or cloud services, R1 is the requirement that makes you account for every place that information lives and show how each copy is kept confidential. The risk R1 addresses is straightforward: BCSI describes how an attacker could target BES Cyber Systems, such as network diagrams, configurations, security settings and vulnerability details, and its exposure can be as damaging as direct access to the systems themselves. R1 applies to BCSI associated with high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). Low impact scope is handled elsewhere in the CIP set, so the first decision is confirming which categorized systems generate BCSI in your environment.

The requirement carries a Medium Violation Risk Factor, and in practice identification is the hard part. Protection methods are easy to name once you know where the information sits, but many organizations discover BCSI in copies they did not expect: exported configuration files, screenshots attached to tickets, drawings emailed to contractors, or backups held by a hosting provider. Build the identification method first. Define what counts as BCSI for your organization, assign owners for each repository, and run a search across file shares, collaboration platforms and cloud storage to find existing copies. Then document the protection method for each location. Confirm with your Regional Entity or internal compliance lead how they expect the identification method to be recorded, since the measures for R1 depend on what your procedures say and whether your records match them.

Protection methods differ by where the information is kept, and the evidence an auditor expects follows that split. For on-premise storage, evidence centers on documented procedures for storage, transit and use, plus records showing staff followed them. For off-premise storage, such as a cloud service, the standard's evidence examples point to electronic methods (encryption, data masking, hashing, tokenization and electronic key management), physical methods such as lock and badge management, and administrative methods such as vendor risk assessments and business agreements. Self-hosted open-source tools can support several of these controls inside your own infrastructure. For example, Nextcloud's server-side encryption protects file contents at rest, but it does not encrypt file names or folder structure, so the procedure must address that gap. The NERC CIP-011-3 standard is the authoritative source for the exact evidence wording, and you should confirm any tool capability against vendor documentation before relying on it.

Which BCSI and systems fall under the R1 program

The R1 program covers BCSI tied to high and medium impact BES Cyber Systems and their associated EACMS and PACS. The cards below cover the scoping decisions that determine how much work the program creates, from the systems in scope to the copies of information that travel with them.

High and medium impact BES Cyber Systems

These are the core systems in scope. Their impact rating comes from the bright-line criteria in CIP-002-5.1a, so the categorization record is the starting point for the R1 program. Check that every system rated high or medium is listed, and that the rating is current after any change to Control Center roles, generation or Transmission Facilities. Low impact systems are handled under CIP-003 and are not part of this card's scope.

Associated EACMS and PACS

Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with in-scope BES Cyber Systems hold BCSI about access paths, credentials and badge data. Entities often scope these late because they sit outside the control room. Confirm that each access control server, jump host, log collector and badge system tied to an in-scope system is inventoried and flagged for R1.

Network diagrams, configurations and vulnerability data

Much of what makes a system exploitable is documentation: network diagrams, firewall rule sets, baseline configurations and vulnerability assessment results. Each of these is BCSI when it describes in-scope systems. Ask who creates these records, where they are saved, and whether ticketing, engineering and wiki tools hold copies that the program must cover.

Security procedures and response plans

Documents that describe how to defend, recover or respond to incidents for in-scope systems are also BCSI. Examples include cyber security incident response plans, recovery procedures, and step-by-step guides for patching or access changes. A reader who knows the procedure can plan an attack, so these documents should be classified with the same care as technical diagrams.

Copies held by engineers and workstations

BCSI spreads quickly. Engineers export diagrams to laptops, attach configurations to email, and keep local notes. Each copy falls within the program even when the original sits in a controlled repository. Confirm how your organization finds these copies, what the procedure requires for transit and local use, and how staff return or delete copies when their role changes.

Vendor-held and backup copies

Integrators, managed service providers and equipment vendors often store configurations, diagrams or support tickets that describe your systems. Backup sets and archives also contain BCSI, sometimes in locations the team has forgotten. Ask each vendor where it keeps your information, and confirm that backup retention and offsite copies are included in the R1 inventory and handling methods.

How an assessor tests the BCSI program

This table walks through how a Regional Entity auditor typically tests CIP-011-3 R1, step by step, and what each step asks the entity to produce. Read it as a preparation checklist: each row names an audit focus, the evidence the auditor usually requests, and the gaps that most often appear in findings. The auditor issues findings and determinations; DeployOpen prepares systems and evidence but does not assess compliance.

Audit focus	What the auditor reviews	Common finding
Documented program	The written BCSI information protection program covering high and medium impact BES Cyber Systems and their associated EACMS and PACS, including its owner and review cycle	Program exists but does not name the systems in scope or lacks evidence of periodic review
BCSI identification method	The method used to recognize BCSI, such as classification labels, repository rules or document templates, and how staff apply it	Method is described in policy but staff cannot show how it is applied to actual documents
BCSI inventory	The list of repositories, file shares, ticketing systems, wikis and cloud locations where BCSI is held, with owners	Inventory is incomplete and omits engineering wikis, vendor portals or cloud copies
On-premise protection	Procedures for storage, transit and use of BCSI, plus access records showing the procedures were followed	Procedures exist but sampled repositories show access beyond authorized personnel
Off-premise protection	Technical controls such as encryption, key management and access logs, and administrative evidence such as vendor risk assessments and business agreements	Cloud or SaaS copies exist outside the program, or the vendor assessment does not cover the storage used
Handling records sample	A sample of tickets, transfers, shared links and access grants selected by the auditor and traced back to the program	Sampled records show BCSI emailed or shared outside approved methods
Access and key management	Who can decrypt or retrieve BCSI, how keys are rotated and revoked, and how departing staff are removed	Former staff or contractors retain access to off-premise repositories
Change over the audit period	Evidence that new repositories or tools were added to the inventory and assessed when they were adopted	New collaboration tools adopted during the period were never brought into the program

How to build the BCSI information protection program step by step

This sequence turns the CIP-011-3 R1 requirement into a working program: it defines what counts as BES Cyber System Information, finds every place it lives, sets protections for on-premise and off-premise storage, and keeps the program current with a review cycle that produces evidence an auditor can test.

Define the BCSI categories
Start by agreeing, in writing, which information your organization treats as BES Cyber System Information. Work from the scope of your high and medium impact BES Cyber Systems and their associated EACMS and PACS, then list the information types that could help someone compromise those systems, such as network diagrams, configuration files, security procedures and vulnerability reports. The compliance lead and system owners sign off on the list. The step is done when each category has a short definition, an owner and a documented reason it is or is not BCSI.
Build the identification method and inventory
Write the method you use to recognize BCSI in practice, such as document labeling rules, repository tags or a review checkpoint when new engineering material is created. Then build an inventory of where BCSI currently exists, covering file shares, engineering tools, ticketing systems, wikis, email and vendor portals. Ask the operations and engineering teams to confirm the list, because the inventory usually misses informal copies. The output is a dated inventory with an identification method that a reviewer can follow without asking the author.
Classify and map storage locations
For each location in the inventory, record whether the BCSI is stored on premises or off premises, including cloud and SaaS services, and whether a third party operates the storage. Note who can access it and how that access is granted. This mapping separates the two evidence paths in CIP-011-3, so each location must be placed in one path. The step closes with a storage map that a Regional Entity auditor could read to see every place BCSI is kept and which controls apply there.
Select protection methods for each storage type
Choose the methods for each location. For on-premise storage, the program typically relies on access restrictions, secure storage areas and handling rules. For off-premise storage, the standard's evidence examples name electronic technical methods such as encryption, data masking, hashing, tokenization and electronic key management, physical technical methods such as lock and key or badge management, and administrative methods such as vendor service risk assessments and business agreements. Document why each selected method fits its location. Confirm with the vendor, in writing, what its service does and does not protect before you rely on it.
Write handling procedures for transit, storage and use
Write the procedures that govern how staff store, transmit and use BCSI. Cover approved storage locations, secure methods for sending BCSI between people or sites, rules for viewing it on shared screens or in meetings, and what happens when a person no longer needs access. Assign an owner to each procedure and tie it to the storage map from the previous step. The procedures are complete when a new engineer could follow them and an assessor could match each one to a record showing the procedure was followed.
Configure and record the technical controls
Implement the chosen controls in the systems themselves. Examples include enabling server-side encryption on file storage, setting up key management with rotation and versioned keys, restricting roles and permissions by shelf, book or page in documentation platforms, and enabling version history so changes are attributable. Keep configuration exports, screenshots and change tickets as evidence. Confirm each setting against the vendor documentation for your version, since capabilities differ between editions and releases. The step closes when each control has a configuration record and a test that shows it works.
Set a review cycle and keep the evidence current
Define how often the inventory, storage map, procedures and control settings are reviewed, and who approves changes to each. Trigger an extra review when a new repository is added, a vendor changes or a system moves to a new environment. Retain the dated review records, updated inventory versions and change tickets so the program can show it was maintained over time. The output is a review calendar, a review log and a version history that together show the program is operating, not just written down.

How on-premise and cloud BCSI storage need different evidence

The evidence an assessor expects depends on where BES Cyber System Information (BCSI) physically and logically sits. For on-premise BCSI, CIP-011-3 R1 evidence examples center on documented procedures for storage, security during transit and use, plus records showing that staff actually handled the information the way those procedures describe. The entity controls the building, the file shares and the people, so the assessor will look for access-controlled repositories, labeled locations, handling rules for printouts and removable media, and a trail that shows the rules were followed. Pair each procedure with a sample of records, such as access reviews on the storage location or sign-out logs for hard copies, so the evidence shows operation, not just policy.

Off-premise BCSI, including BCSI held by a cloud or SaaS provider, shifts much of the protection into methods the entity must select and prove. The evidence examples group these into electronic technical methods (data masking, encryption, hashing, tokenization and electronic key management), physical technical methods (lock and key or badge management, biometrics and alarms, which apply at the provider's facility), and administrative methods such as vendor service risk assessments and business agreements. Key custody is the question most worth settling early. If the entity holds the encryption keys, the provider stores ciphertext it cannot read. If the provider holds or can reach the keys, the provider's staff and access processes become part of the entity's protection. Ask who generates, stores, rotates and revokes keys, and which provider personnel can request access to decrypted data. Confirm these answers in the contract and the provider's own documentation before relying on them, because a cloud deployment with provider-held keys needs stronger administrative evidence than one with customer-held keys.

Evidence that passes an R1 audit

An auditor testing CIP-011-3 R1 looks for a written program, a current picture of where BCSI lives, and records proving the program runs as written. The cards below cover the artifacts that connect those three things, and the upkeep each one needs between audits.

Written information protection program

This is the documented program that R1 requires, covering how BCSI is identified, protected and handled. It should name the owner, the systems in scope (high and medium impact BES Cyber Systems and their associated EACMS and PACS) and the methods used for each Part. Check that the document matches what staff actually do, because a program that reads well but is not followed is the first gap an auditor finds. Review it on a set schedule and record each approved revision.

BCSI inventory and identification method

The inventory shows every repository, file share, wiki, ticketing record and cloud bucket that holds BCSI, along with the method used to find it, such as a classification label, a data owner review or a search. Auditors compare this list against what they find during testing, so an inventory that omits one location undermines the rest of the evidence. Assign an owner for each repository and recheck the list whenever a new tool or project starts.

Storage and handling procedures

For on-premise BCSI, procedures should cover where it may be stored, how it is protected in transit and who may use it. Records such as access reviews, transfer logs and sign-off on handling steps show that the procedure was followed. Keep the procedure next to the records it governs, so an auditor can trace a rule to the activity behind it. Update the procedure when storage locations or transfer methods change.

Encryption and key management records

Where encryption protects BCSI, the evidence should show which data is covered, which algorithms and key sizes are used, where keys are held, and who can manage them. Key rotation logs, key custody assignments and records of decommissioned keys are the items auditors ask for first. Server-side encryption can protect file contents at rest, but it does not hide file names or folder structure, so document what the encryption does not cover. Check that keys are held apart from the data they protect.

Access and role configurations

Exported role assignments, group memberships and permission settings show who can read, edit or share BCSI in each repository. Auditors check that access follows job need, that role definitions match the program, and that changes to them were approved. Compare these exports with the access revocation records kept under CIP-004 to confirm that departed staff no longer hold access. Export and file these configurations on a regular cycle so the record of access is never older than the most recent review.

Change history of BCSI repositories

Version history shows what changed in a BCSI repository, when, and by whom, which lets an assessor trace an unauthorized edit or confirm an approved update. Wiki and document platforms that keep page revisions can supply this record directly, but the team must retain it and be able to restore earlier versions. Confirm that history cannot be erased by ordinary users and that retention meets the period your program sets. Review a sample of changes during the year rather than waiting for an audit.

Vendor risk assessments and agreements

When BCSI is stored or processed off premise, including with a cloud provider, the evidence includes the risk assessment performed before use and the business agreement that sets handling duties. Assessors look for the assessment date, the risks considered and the decision reached. Record which administrative and technical methods the vendor supplies and which the registered entity keeps. Reassess when the service, its location or its terms change, and keep the agreements that are in force.

What meeting CIP-011-3 R1 costs in money and effort

An in-house build keeps all cost inside the registered entity. The organization pays staff time to identify where BCSI lives, write the information protection procedures, configure storage and handling controls, and collect evidence for each review cycle. Few of these costs appear as a single line item, so they are easy to underestimate. Most of the effort is recurring: procedures need upkeep as systems change, and access and handling records must be kept current for every audit period.

Engineering time: Staff to map BCSI repositories, configure encryption, access restrictions and logging, and test them.
Procedure writing: Storage, transit and use procedures, plus the review and approval workflow behind them.
Tooling and licenses: Any commercial or open-source platform, its support contract and the hosting it needs inside your own network.
Evidence upkeep: Recurring collection of handling records, access reviews and change history for the audit period.
External review: Optional outside assessment of the program before the Regional Entity audit.

Ask internal teams to list which costs are one-time (initial mapping, first procedures, tool setup) and which recur (reviews, evidence collection, tool maintenance). Confirm how often your own information protection procedures will be reviewed and who signs off on each revision.

Where R1 programs usually fall short and how to close the gap

Most CIP-011-3 R1 programs fail in the places BCSI travels without anyone tracking it: tickets, inboxes, shared folders, vendor systems and cloud keys. The cards below name each gap and give a closing action the registered entity can check against its own environment. Confirm each finding with your Compliance Enforcement Authority's expectations and your own evidence trail.

BCSI in ticketing systems

Engineers paste network diagrams, IP addresses, firewall rules and configuration exports into service tickets to get help from another team. The ticketing tool is often not in the information protection program at all, so its access list, retention settings and attachment storage are never reviewed. Close the gap by inventorying every ticket queue and attachment store that can hold BCSI, then either restricting attachments or applying the same identification and handling rules you apply to file shares. Confirm who can read closed tickets, since that is where old BCSI tends to survive.

BCSI in email and chat

Email threads and chat channels carry BCSI in forwarded drawings, screenshots and quick questions about settings. These copies sit outside the systems that hold the designated repository, and they are rarely covered by the procedure on storage and transit. Close the gap by writing a rule for when BCSI may be sent by email or chat, and by testing a sample of mailboxes and channels against that rule. Ask whether your mail archive and chat retention settings would preserve these copies after the staff member who sent them has left.

Shared drives and unmanaged copies

Shared drives collect exported spreadsheets, local copies of network diagrams and personal downloads that nobody registered as BCSI. Permissions are often inherited from a parent folder and never reviewed, so people outside the authorized group can read files that should be restricted. Close the gap by tagging known BCSI repositories, removing inherited access to them, and running a periodic search for files that match your BCSI identification method. Record the search results as evidence, because they show the method works in practice.

Vendor-held copies of BCSI

Integrators, managed service providers and equipment vendors often keep copies of configurations, drawings and vulnerability reports to support their work. These copies sit under the vendor's controls, which the entity may never have assessed. Under the off-premise evidence examples in CIP-011-3, the entity should be able to show vendor service risk assessments and business agreements that cover them. Close the gap by listing every vendor that holds BCSI, confirming the contract terms that govern it, and asking each vendor to state where its copies live and how they are deleted. Confirm this list matches what your contracts actually say.

Undocumented cloud key custody

Teams that store BCSI in cloud object storage or SaaS tools often rely on provider-managed encryption without recording who holds the keys, how they rotate and who can revoke access. When a cloud account owner leaves, the key arrangement can become unclear. Close the gap by documenting key ownership, rotation and revocation for every cloud location that holds BCSI, and by checking that the documentation matches the actual key policies. Assess whether any key or account can be used without a logged approval.

Procedures that do not match practice

A procedure may require BCSI to be stored only in an approved repository, yet the team's daily habits say otherwise. An auditor who samples records and finds handling that contradicts the written procedure will question the whole program. Close the gap by walking through two or three real BCSI handling tasks with the people who do them, then updating the procedure to describe what they actually do or changing the practice to match the procedure. Keep dated records of both the walkthrough and the change.

Missing review cycles

Information protection programs are often written once and never reviewed, so new tools, new vendors and reorganized teams fall outside them. Without a scheduled review, no one records whether the BCSI identification method still finds the information it should. Close the gap by setting a review date for the program, assigning an owner, and recording each review with its findings and the changes it produced. Confirm the review cycle with your internal compliance policy, since the review interval is set by the entity rather than fixed by the requirement text.

Questions buyers ask about CIP-011-3 R1

How much effort does CIP-011-3 R1 take to implement?

No public price applies to R1, and effort depends mainly on how much BCSI your organization holds and where it sits. The biggest drivers are the number of high and medium impact BES Cyber Systems and their associated EACMS and PACS, the number of documents, drawings, configuration exports and vendor records that count as BCSI, and how many repositories, file shares, ticketing tools and cloud accounts hold them. Costs fall into two groups: internal staff time to write the program, classify information and collect records, and external fees for any partner or tooling. Recurring effort includes reviewing identification methods, checking access and collecting evidence before each audit. Ask any quote to itemize the systems in scope, the repositories covered and the evidence each deliverable produces.

How long does it take to set up a CIP-011-3 R1 program?

The timeline depends on your starting point, not on a fixed duration in the standard. An organization with an existing information classification policy, access controls and records retention practices has less to build than one that has never written down how BCSI is marked or shared. Timing is driven by the BCSI inventory, the number of storage locations, the vendors that host BCSI and how quickly data owners approve procedures. Technical work such as encryption, key management and access restrictions adds time wherever systems must be configured and tested. Ask a partner to express the schedule as milestones tied to the written scope, and to name which dependencies sit with your staff. Confirm with your Regional Entity what evidence it expects for the audit period under review.

What must our team provide to demonstrate R1 compliance?

Your team must own a documented information protection program and be able to show that it operates as written. An assessor will look for three groups of material:

Methods to identify BCSI, such as classification criteria, labeling rules and a list of the repositories where BCSI is found (Part 1.1).
Methods to protect and securely handle BCSI to mitigate the risk of compromising its confidentiality (Part 1.2).
Evidence of use. For on-premise BCSI, that means procedures covering storage, transit and use, plus records showing handling matched them. For off-premise BCSI, it means technical methods such as encryption, masking or key management, physical controls, and administrative records such as vendor service risk assessments and business agreements.

Keep records current, because they must reflect how BCSI was actually handled.

Can our own staff implement CIP-011-3 R1 without outside help?

Yes. The obligation sits with the registered entity, so an organization with qualified staff can write and run the program internally. Whether that is practical depends on staff time, familiarity with the CIP standards and whether the team can keep evidence complete across an audit period. Internal teams usually own the policy, the BCSI inventory, access reviews and records. Outside help is most often used for technical work, such as configuring encryption or access controls on self-hosted platforms, testing those controls and documenting the result. Compliance decisions remain with your organization. The stakes justify careful planning: the maximum civil penalty referenced by NERC's Sanction Guidelines is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 (January 2025) and shown in the eCFR entry for 18 CFR 385.1602.

Can we store BCSI in the cloud under CIP-011-3?

Yes, the standard covers BCSI stored off premises, so cloud storage is in scope for your program and must meet the same confidentiality goal. You must protect it with methods that address confidentiality and be able to show how you did so. Evidence for off-premise storage falls into three groups: electronic technical methods such as data masking, encryption, hashing, tokenization and electronic key management; physical technical methods such as lock and key or badge management, biometrics and alarms, where they apply to the provider; and administrative methods such as vendor service risk assessments and business agreements. Before choosing a provider, confirm that the contract, key ownership, access logging and disposal terms support these methods. Self-hosted platforms keep key material under your control. For example, Nextcloud's server-side encryption protects file contents at rest, but it does not encrypt file names or folder structure, so that gap must be documented and mitigated.

How does an implementation partner differ from a CIP auditor?

An implementation partner prepares systems, procedures and evidence, while your organization owns the controls and an independent assessor reviews them. DeployOpen works in the first group: it plans, configures, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares the evidence for assessment. It does not issue audit reports, attestations or certifications, and it does not decide whether your program is compliant. An auditor or the Compliance Enforcement Authority reviews what you operate, tests samples and reports findings. There is no CIP certificate, so no outside party certifies CIP compliance. Ask any partner to state in writing which deliverables are configuration and evidence, and which decisions stay with your organization.

Which open-source tools can produce evidence for R1?

Several self-hosted tools can produce parts of the evidence an assessor reviews. Each covers only part of the picture:

Nextcloud (AGPL-3.0-only) offers server-side encryption for files at rest, with keys kept on the server, but it does not encrypt file names or folder structure.
OpenBao (MPL-2.0) has a transit secrets engine that encrypts and decrypts application data without storing it, and it supports versioned encryption keys with key rotation. Its documentation describes these functions.
XWiki (LGPL-2.1-or-later) keeps version history for every page change, recording what changed, when and by whom, and lets users compare or roll back versions.
BookStack (MIT) assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level.

Confirm feature behavior and edition limits in your own environment before you cite any tool in an audit file.

Does CIP-011-3 R1 apply to low impact BES Cyber Systems?

R1 is scoped to BCSI related to high and medium impact BES Cyber Systems and their associated EACMS and PACS. Low impact BES Cyber Systems are not listed in its scope, so an organization whose assets are only low impact should confirm its obligations under CIP-003 with its Regional Entity. Scope starts with categorization under CIP-002-5.1a, which uses the bright-line criteria in its Attachment 1 to rate systems as high, medium or low impact. That categorization decides which BCSI enters the program. Keep the categorization record with your R1 evidence, because an assessor will expect the program's scope to match it. If assets change, such as through a new Control Center or a new generation facility, recheck the categorization before you update the BCSI inventory.

Official sources for the CIP-011-3 standard and compliance monitoring

Start with the CIP-011-3 standard PDF published by NERC. It is the text an auditor works from, so read Requirement R1 and its Parts 1.1 and 1.2 directly rather than relying on summaries, including this one. The standard sets out the information protection program your documentation must satisfy, and the measures column shows the evidence examples for on-premise and off-premise BCSI. Keep a copy of the version you are assessed against, dated and filed with your compliance records, so your program is traceable to the exact text in force for each audit period.

For how compliance is actually monitored, read NERC Rules of Procedure Appendix 4C, the Compliance Monitoring and Enforcement Program. It explains the tools a Compliance Enforcement Authority can use, including Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and periodic data submittals, and it is the reference for what a Regional Entity can ask you to produce. Your compliance lead should also read Section 400 of the Rules of Procedure for the broader monitoring framework. Note that there is no CIP certificate, so any document claiming to certify CIP-011-3 compliance should be treated with skepticism.

Before you rely on any document, confirm the current status on the NERC CIP standards page. It lists which CIP standard versions are mandatory and enforceable in the United States, and it shows effective dates for revisions. Check it at the start of each audit period and again when your Regional Entity sends notification, because versions and effective dates change. Ask your Regional Entity or a qualified advisor to confirm which version applies to your registration and any upcoming revisions that touch information protection.

CIP-011-3 R1 Information protection program