CIP-004-7 R6 BCSI access: requirements and evidence

What CIP-004-7 R6 BCSI access management asks for

CIP-004-7 R6 requires a documented access management program that authorizes, verifies and revokes provisioned access to BES Cyber System Information (BCSI) for high impact and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). BCSI is the information that could be used to plan or execute an attack on those systems, such as network diagrams, configuration files, IP address schemes, system procedures and recovery plans. In practice that material has spread well beyond the control room: it sits on file shares, in engineering drawings, in ticketing attachments, in email, in vendor portals and increasingly in cloud storage. Each copy is a place where an unauthorized person could read it, and each copy is outside the physical and electronic controls that were built around the original system.

The difficulty is that access to BCSI is granted through many channels at once. R6 treats a person as having access only when they can both obtain and use the information, and it describes provisioned access as the result of actions that give the means to get at it, such as keys, access cards, user accounts with rights and privileges, or encryption keys. A single engineer may hold a share permission, a repository role, a cloud bucket policy and a decryption key, each granted by a different team on a different schedule. Before you design the program, confirm with your Compliance Enforcement Authority and your own legal and records teams which of your locations and providers hold BCSI, and which of those copies you can actually inventory and revoke.

Which BCSI, systems and people fall under R6

R6 applies to BES Cyber System Information tied to high and medium impact BES Cyber Systems and their associated EACMS and PACS. CIP-002 categorization decides which systems are in scope, and the BCSI you must track follows from those decisions, wherever it is stored and whoever can reach it.

Start with CIP-002 categorization

R6 does not begin with a list of accounts. It begins with the CIP-002 impact rating of each BES Cyber System. R6 covers high and medium impact systems and their associated EACMS and PACS, so a system rated low impact sits outside R6 unless its information flows into a higher rated system's scope. Confirm the current categorization list, then identify which BCSI repositories relate to those rated systems. Low impact only assets generally fall outside R6.

Tie scope to BCSI, not every account

R6 is written around BES Cyber System Information, not around every system account in the environment. A user with a login to a corporate file share does not fall under R6 for that reason alone. Scope comes from the information: diagrams, configuration files, network maps and security procedures that describe high or medium impact systems. Build an inventory of BCSI locations first, then derive the list of individuals who can obtain or use that information.

Electronic and physical BCSI

The requirement covers both electronic and physical BCSI. Electronic BCSI includes files, databases, ticketing attachments and repository content. Physical BCSI includes printed diagrams, binders and removable media kept in controlled areas. Each form needs its own authorization path: electronic access is granted through accounts and encryption keys, while unescorted physical access is granted through badges, keys and access lists. Check both paths during scoping, because teams often track only one.

BCSI held by cloud and managed providers

BCSI stored with a cloud service, managed service provider or SaaS tool stays in scope. The question is who can obtain or use it: the provider's administrators, your own cloud administrators and any integrated service accounts may all count as having provisioned access. Ask each provider how it isolates tenant data, who holds encryption keys, and how it removes access on request. Record these answers in the R6 program before data is moved.

Contractors and vendors with access

Integrators, contractors and vendor support staff who can obtain or use BCSI are inside the R6 program even though they are not employees. Their access must be authorized on the same basis, verified on the same cycle and removed on the same termination timeline. Vendor support tools that copy configuration files to their own systems deserve particular attention, because the copies can become BCSI held outside your control. Confirm contract terms and onboarding steps before granting access.

When an individual has access to BCSI under R6

Under CIP-004-7 R6, an individual has access to BES Cyber System Information (BCSI) only when they can both obtain it and use it. Obtaining means the individual can reach the information, and using means they can read, copy, change or otherwise act on it once reached. Your access management program has to treat both halves as in scope. A person who can open a file but cannot decrypt it, or who holds a decryption key but cannot reach the storage location, does not yet have access in the sense the standard uses. Before you draw your access population, confirm with your compliance lead how your organization documents each half of that test.

The standard describes provisioned access as the result of specific actions that give someone the means to reach BCSI. Those actions include issuing a physical key, programming an access card, creating a user account with rights and privileges, or releasing an encryption key. Each one creates its own provisioned access path, and each path needs an authorization record and a verification under the R6 cycle. Start by listing every means of getting to BCSI, including items that are easy to overlook, such as service accounts, administrator roles that can grant themselves read rights, and backup copies that a second team can restore.

*Illustrative example:* a utility stores a network diagram containing BCSI in three places. The first is a cloud storage bucket, where an engineer's account has a read role. The second is a shared network drive, where a project group has modify rights. The third is an encryption key in a key vault that decrypts an archive of the same diagrams. Under this model, the bucket role, the drive group membership and the vault key each count as a separate provisioned access path. Each needs an authorization record that names the individual, the BCSI location and the business need, and each must be verified within the 15-calendar-month cycle in Part 6.2. Removing the engineer from the drive group does not revoke the vault key, so the revocation check in Part 6.3 must cover every path.

How an assessor tests R6 access management

This table walks through how a Regional Entity auditor typically tests each part of CIP-004-7 R6, what evidence is requested, and where findings tend to arise. Read each row as a test question the entity should be able to answer with records, not recollection. There is no CIP certificate; the Compliance Enforcement Authority decides whether any finding is issued.

Requirement part	Test approach and evidence requested	Common findings
Part 6.1: Authorization before provisioning	Auditor selects a sample of provisioned electronic or unescorted physical BCSI access and asks for the authorization record dated before the provisioning date, showing the business need. Evidence includes the access request, approver identity, and the provisioning log for the same account, key or badge.	Access provisioned before any authorization record exists, authorization approved after the fact, or records that state no need. Gaps appear most often for shared repository accounts and cloud storage permissions granted by administrators.
Part 6.1: CIP Exceptional Circumstances	Auditor checks whether any access was granted under the CIP Exceptional Circumstances carve-out, then confirms the entity's documented definition was applied and the event was recorded. Ask for the exception log and the operational reason it was invoked.	Carve-out used for routine onboarding, or no record kept of the circumstance. Entities should confirm their own documented definition before relying on it.
Part 6.2: Verification at least every 15 calendar months	Auditor requests the most recent verification record for each individual with provisioned BCSI access, including the list of all provisioned users pulled from each system where BCSI is stored, cloud tenants included. The auditor compares that list with authorization records and asks the reviewer to confirm current work function.	Verification missed for one repository or cloud tenant, provisioned users absent from the review list, or reviewers who confirmed access without checking the need.
Part 6.2: Scope of provisioned access	Auditor expects the entity to show how it determined every location where BCSI is stored, including off-premise and third-party hosting, and the access paths to each. Evidence includes an inventory of storage locations, system exports of users with rights, and encryption key holders.	Storage locations missing from the inventory, such as file shares, ticketing attachments or vendor portals. Encryption keys or key administrators omitted from the access population.
Part 6.3: Removal within the next calendar day	Auditor selects termination actions and compares the termination timestamp with the time provisioned BCSI access was actually removed in each system. Evidence includes HR termination records, directory disable logs, repository and cloud account removal logs, and key or badge return records.	Removal completed by the next calendar day in the primary directory but not in a secondary repository, cloud tenant or shared account. Removal recorded as a ticket close date with no system log.
Part 6.3: Termination action definition	Auditor asks how the entity defines a termination action and whether that definition covers involuntary, voluntary and contractor separations. The test looks for the trigger, the owner of the removal task, and the clock start.	Contractor or vendor separations not treated as termination actions, or the clock start recorded inconsistently between HR and IT.
Findings and enforcement	The Compliance Enforcement Authority, a Regional Entity or NERC, reviews the evidence and decides whether a possible violation exists. Entities can self-report, and the outcome can include mitigation, penalties or a compliance exception under the Sanction Guidelines.	Entities often assume an internal audit result equals a CIP finding. Only the Compliance Enforcement Authority determines findings, and an independent auditor's report is not a CIP certificate.

How to implement BCSI access management step by step

This sequence turns CIP-004-7 R6 into a working program: every place BCSI lives is identified, access paths are mapped, and each grant, review and removal leaves a record an auditor can follow from start to finish.

Inventory every location where BCSI is stored
The compliance lead and system owners list every repository holding BCSI for high and medium impact BES Cyber Systems and their associated EACMS and PACS. Include on-premises file shares, databases, engineering workstations, cloud storage, SaaS ticketing and document tools, vendor portals, email attachments, and removable media such as USB drives and printed diagrams. Confirm the list against CIP-011 information categorization so the two standards describe the same data. The output is a dated BCSI location register with an owner and a classification for each entry, which is the first thing an auditor will ask to see.
Map the access paths to each location
For each entry in the register, the system owner records every means by which a person could obtain and use the information. CIP-004-7 R6 treats provisioned access as the physical keys, access cards, user accounts with rights and privileges, or encryption keys that enable access, so the map must cover all of them. Include service accounts, administrator rights, shared folder groups, and key custody for encrypted stores. Ask any cloud or third-party provider to confirm in writing who on its side can reach the data. The output is an access path map that ties each location to the mechanisms that grant entry, so no route to BCSI is left out of the program.
Build the need-based authorization workflow
The access management owner defines who may approve BCSI access, what business need must be documented, and which role or work function justifies each grant. Requests should name the individual, the location, the access path, the reason, and the approver. Approvers should be separate from the requester where the organization can manage it. Written criteria should cover exceptions, and the CIP Exceptional Circumstances process should be documented in advance. The output is an approved workflow procedure and a request template, which show the auditor how authorization is tied to need under Part 6.1.
Provision access only after authorization is recorded
Provisioning teams grant access only when a completed authorization record exists for that individual, location and access path. Automated provisioning helps here: where a directory group or role controls a repository, changes to membership should require a linked approval ticket. Physical key and card issuance should follow the same rule. Spot-check provisioning logs against authorization records each period to catch grants made outside the workflow. The output is a set of provisioning logs that match the authorization records one to one, showing that no access was granted before authorization except under documented CIP Exceptional Circumstances.
Run the 15-month verification as an access certification campaign
At least once every 15 calendar months, the access management owner verifies that everyone with provisioned BCSI access has an authorization record and still needs that access for current work. Running this as a certification campaign gives designated reviewers a list of access items to keep, change or revoke within a set timeframe. Open-source identity governance tools such as midPoint support this kind of review and track the decisions. Reviewers should not approve their own access. The output is a completed campaign report with each reviewer decision, the date of each decision, and the revocations that followed, which evidences Part 6.2.
Wire termination actions to next-day revocation
HR and identity administrators connect termination actions in the HR system to the access inventory, so that every account, key, card and encryption key tied to BCSI is identified when someone leaves. Removal of the ability to use BCSI must occur by the end of the next calendar day after the termination action, as Part 6.3 requires. Include contractor and vendor accounts, and confirm that cloud and SaaS providers process deprovisioning on the same timeline. The output is a termination checklist and system logs showing revocation timestamps compared with termination dates, so the auditor can confirm the next-day window was met.
Retain authorization, verification and revocation records
The compliance lead keeps the register, access path map, authorization records, provisioning logs, campaign reports and revocation evidence together under a retention schedule that covers the audit period set by the Regional Entity. Store records in a controlled repository that itself meets the BCSI protections in CIP-011 and is covered by the access program. Test retrieval by pulling a sample of individuals and tracing each one from request to revocation. The output is an evidence package that can be produced for a Compliance Audit, Spot Check or Self-Certification without rebuilding records after the fact.

Evidence that passes R6 and how to keep it current

An auditor testing CIP-004-7 R6 works backward from each place BCSI can be obtained or used, then asks for proof that access was authorized, verified and revoked on time. The cards below cover the record groups that answer those questions. Tools such as midPoint, Nextcloud and OpenBao can produce parts of this evidence, but the organization still owns the program and must confirm the records match its real access paths.

BCSI access list by location

Keep a current inventory of every location where BCSI is stored, including file shares, ticketing systems, engineering tools, backups and any cloud or third-party service. For each location, record who holds provisioned access and through which path, such as a user account, physical key, access card or encryption key. Confirm the list covers off-premise copies, because the R6 test is whether an individual can both obtain and use the information. Gaps in this list usually surface first during an audit.

Authorization records with need and date

Each provisioned access grant should have an authorization record that states the business or work-function need, the approver and the date of approval. Under Part 6.1, authorization must happen before provisioning, except during CIP Exceptional Circumstances, so the record date should precede the provisioning timestamp. Ask whether your ticketing or identity workflow enforces that order or whether staff can provision first and document later.

Provisioning and access logs

Retain logs showing when access was granted, changed and used for each BCSI location, tied to the same individual identifiers used in authorization records. Logs are what let an assessor match a provisioned account to an authorization. Confirm which systems log file-level access and which only log login events, and identify any location that produces no log at all, since that location needs a compensating record or a different control.

Verification campaign results and reviewer decisions

Part 6.2 requires verification at least once every 15 calendar months that each person with provisioned access still has an authorization and still needs it. Record the campaign scope, the designated reviewers, each keep, change or revoke decision and the completion date. midPoint access certification campaigns can route these decisions to reviewers within a set timeframe and keep the outcome for audit. Ask whether the campaign covers BCSI locations or only directory roles, because a role-only review can miss file-level grants.

Termination timestamps and revocation proof

Part 6.3 requires removing the ability to use BCSI access by the end of the next calendar day after a termination action. For each access path, keep the termination action timestamp and proof that the access was removed, such as an account disable log, a deprovisioning ticket, a key or card return record or a changed encryption key. Reconcile the termination time against each location separately, because one path cleared on time does not show that another did. Test this with a sample of recent departures.

Encryption key access and rotation records

Where BCSI is protected by encryption, the key itself is a provisioned access path, so key grants and removals belong in the same evidence set. OpenBao's transit secrets engine encrypts and decrypts data without storing it, supports versioned keys and supports key rotation, and its audit output can show who used a key and when. Record which identities hold decrypt rights, when rights changed and when keys were rotated. Nextcloud server-side encryption protects file contents at rest with keys held on the server, but it does not encrypt file names or folder structure, so file and folder metadata needs its own access record and control.

Keeping the evidence current

Evidence goes stale quickly, so assign an owner to each record group and set review points that fall well inside the 15-month verification cycle. Store records where they can be retrieved for the audit period rather than scattered across personal folders. These tools support evidence and do not make the organization compliant on their own. A qualified CIP assessor, the Regional Entity or NERC decides compliance, and an implementation partner can help configure the records but does not issue audit findings.

What meeting BCSI access management costs

This table breaks the effort of running a CIP-004-7 R6 program into components, showing who pays for each, whether it is one-time or recurring, and what drives its size. Use it to scope a quote and to see where open-source tools reduce license spend without removing engineering and upkeep work. No dollar figures are supplied here, so ask for each component to be priced separately in writing.

Cost component	One-time or recurring	Who is paid or who carries it	Main cost drivers
BCSI location inventory and mapping	One-time, then updated on change	Entity staff, with an implementation partner if it helps map systems	Number of repositories, file shares, backups, ticketing tools and cloud accounts holding BCSI
Authorization workflow design	One-time, revised when roles change	Entity compliance and access owners, with outside help if scoped	Number of job roles needing BCSI, number of approval paths, and whether electronic and physical access are handled separately
Tooling or licenses	Recurring if commercial, often one-time setup if self-hosted	Entity pays license fees or hosting and staff time for self-hosted tools	Number of users and identity sources, and the license edition needed for the required features (confirm with each vendor)
Engineering to connect provisioning and revocation	One-time build, then recurring maintenance	Entity platform or IT teams, or a partner under a fixed-scope agreement	Number of provisioned paths such as user accounts, encryption keys, cloud roles and shared folders that must be revoked by the next calendar day
Quarterly or 15-month verification campaigns	Recurring, every 15 calendar months at minimum	Entity reviewers and access owners who confirm each record	Number of individuals with BCSI access and number of access items per person
Evidence upkeep	Recurring	Entity compliance staff, with tool administrators providing exports	Number of locations, systems in audit scope and how much evidence is generated automatically
Third-party and cloud provider assurance	Recurring at each review, one-time at onboarding	Entity procurement and compliance staff, sometimes with external review	Number of cloud and SaaS providers storing BCSI and their access to keys and logs
Auditor sampling during a Compliance Audit	Episodic, tied to the audit schedule	Entity staff produce evidence, and the Regional Entity or NERC samples it	Size of the audit sample, and how quickly records can be pulled for each individual and location

Who owns R6 access management and what can be outsourced

Your organization owns the R6 access management program. The registered entity decides who needs access to BES Cyber System Information (BCSI), approves each authorization, performs the periodic verification, and removes access when the need ends. Those decisions and their records are the program, and they cannot be delegated to a vendor or consultant. Your compliance and operations staff also answer auditor questions about why a given person held access on a given date.

Authorization decisions: Named owners approve provisioned electronic and physical access to BCSI before it is granted, based on documented need.
Verification results: Staff run the verification at least once every 15 calendar months and record whether each access holder still needs that access.
Revocation actions: Operations removes the ability to use BCSI by the end of the next calendar day after a termination action.
BCSI location inventory: The entity knows where BCSI lives, including cloud storage and third-party platforms, and keeps that list current.
Program ownership: A named senior role signs off on the program and its exceptions.

Before engaging anyone, confirm that your own staff can explain each authorization and verification record without help from a consultant.

Where BCSI access programs usually fall short

Most BCSI access problems are not missing policies. They sit in copies of BCSI nobody inventoried, access paths that bypass the normal request process, and reviews that check accounts but not need. Each card below names one gap an assessor is likely to find under CIP-004-7 R6 and the action that closes it.

BCSI copies in unlisted locations

BCSI often leaks into ticketing systems, email attachments, shared drives, wiki pages and engineering notebooks, where no one has recorded it as a storage location. CIP-004-7 R6 covers BCSI wherever it is stored, so an unlisted copy is an unmanaged access path. Close it by running a data discovery sweep of those tools against the BCSI definition in your program, recording each location, and either moving the content into an authorized repository or applying the same access controls there.

Shared accounts and unrecorded keys

Shared service accounts, shared administrator logins and encryption keys handed between engineers can give people the ability to obtain and use BCSI with no authorization record tied to them. Under R6, provisioned access includes user accounts with rights and privileges and encryption keys, so these are in scope. Close it by mapping every shared credential and key to a named owner, restricting who can retrieve them, and logging each retrieval so the authorization record matches actual use.

Verification that checks existence, not need

A verification step that confirms an account is still active tells an assessor nothing about whether the person still needs BCSI for their current work. Part 6.2 asks whether each individual has an authorization record and still requires that access for a current work function, at least every 15 calendar months. Close it by comparing each entry against the current role and project assignments, and requiring the reviewer to record a keep, change or revoke decision for each one.

Revocation that waits on manual tickets

When removal of BCSI access depends on someone opening a ticket and another person acting on it, the process can miss the deadline in Part 6.3, which requires removing the ability to use provisioned access by the end of the next calendar day after a termination action. Revocation that runs through several systems also tends to leave one copy or key behind. Close it by tying termination and transfer events from HR to automated removal for each BCSI repository, and testing the path with a sample departure before an audit.

Cloud provider access paths not evaluated

Cloud and SaaS providers can reach stored BCSI through support staff, administrator consoles, backup operators and key management services, and these paths rarely appear in the access program. R6 applies wherever BCSI is stored, including with third-party providers, so the provider's own personnel and tooling are part of the review. Close it by requesting the provider's documented access paths, confirming which ones can obtain and use the data, and bringing the relevant ones into your authorization and revocation records.

BCSI access management questions buyers ask

How much effort does CIP-004-7 R6 take, and what drives it?

Effort depends mostly on how many places BCSI lives and how many people hold provisioned access to it. R6 requires a documented program that authorizes access before it is provisioned, verifies that every individual with provisioned access still needs it at least once every 15 calendar months, and removes access by the end of the next calendar day after a termination action. The main drivers are the number of repositories, file shares, ticketing systems, cloud tenants and physical storage locations holding BCSI, the number of people and service accounts with access, how often roles change, and whether authorization records already exist. A one-time build of the program and a recurring verification cycle are both part of the cost. Ask any provider to break the quote into inventory, program design, system configuration, evidence collection and recurring verification.

Can a small team run CIP-004-7 R6 in-house?

A small team can run R6 in-house if it has clear ownership, a current inventory of BCSI locations and someone who can change access on each system. The work is manageable when the list of BCSI repositories is short and access is mostly granted through one identity source. It becomes harder when access is spread across file shares, engineering tools, cloud storage and vendor portals, because each one needs its own authorization record and its own revocation path. Small teams often underestimate the verification cycle, since every access grant must be reviewed on a fixed schedule and evidenced. Before deciding, confirm who will maintain the authorization records, who approves them, and who will produce evidence for an auditor when the Regional Entity asks.

What does an implementation partner do for R6, and what does it not do?

An implementation partner can plan the program, inventory BCSI locations with you, configure access controls and reviews on systems you operate, and document the procedures and evidence trail. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, and can support access review tooling in that environment. The partner does not own your CIP controls, make your authorization decisions, or certify your compliance. Your organization remains the registered entity accountable for R6. Independent auditors and the Regional Entity assess compliance, and no partner issues audit reports or certificates. Ask any partner to state this split in the written scope.

How long does the first R6 implementation take?

Timelines depend on scope, and the schedule is set in a written plan agreed before work starts. The main variables are the number of BCSI repositories, the state of existing access records, the number of systems that need integration, and how quickly your decision owners can approve authorizations. Most engagements are fixed-scope, so the plan should list deliverables, dependencies and the point at which your staff must act. Ask for milestones covering inventory, authorization model design, system changes, a first verification cycle and evidence handover. No general duration applies to every organization, so treat any single figure you hear as unverified until it is tied to your environment.

What does the organization need to provide for R6 to work?

R6 needs three things from your side: a complete inventory of where BCSI is stored and who can reach it, named decision owners who approve or deny access, and system owners who can apply changes on each platform. Without the inventory, provisioned access can be missed during verification, which leaves gaps in the 15-month review and the next-day revocation. Without decision owners, authorization records exist on paper but no one can approve access in time. Without system owners, approved changes stay in a ticket queue. Check that each BCSI location has a named owner, that access is granted through a documented path, and that someone can produce the authorization record for any individual on request.

Does cloud-held BCSI change the R6 work?

Yes. Under R6, an individual has access to BCSI when they can both obtain it and use it, and provisioned access includes things like user accounts with rights, keys and encryption keys. Cloud storage adds identity providers, administrator roles, service accounts, key management and provider-side personnel paths that must be inside the access model. Encryption at rest helps protect content but does not replace authorization, because someone who can reach the keys or the storage account can still obtain the data. Ask whether the provider's administrative access, key custody and retrieval paths are included in your inventory and verification cycle, and how revocation propagates to cloud identities within the next-day window.

How DeployOpen scopes and prepares R6 evidence

DeployOpen works on CIP-004-7 R6 by first fixing which BCSI repositories, provisioned access paths and EACMS or PACS are in scope, then preparing the access management program and its evidence inside the client's own environment. The organization keeps ownership of its controls, and an independent auditor or the Compliance Enforcement Authority judges whether the program meets the requirement.

How we scope

Agree in writing which high and medium impact BES Cyber Systems, EACMS and PACS hold or reach BCSI.
Inventory every location of electronic and physical BCSI, including cloud storage and third-party hosted systems.
Map each provisioned access path, such as accounts, keys, access cards and encryption keys, to a named owner.

How we build

Configure authorization workflows so provisioned BCSI access requires a recorded need before it is granted.
Set up recurring access certification campaigns that support the 15-calendar-month verification in Part 6.2.
Wire revocation steps to the termination process so access ends by the end of the next calendar day.

How we hand over

Deliver the documented access management program, procedures and role descriptions for internal review.
Provide evidence packages showing authorization records, verification results and revocation timestamps for each reviewed system.
Document test results and known gaps so the organization can decide remediation before any Compliance Audit.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic evidence reviews are available as a retainer after handover.
Ask any provider, including DeployOpen, to confirm which parts of R6 the organization still owns after handover.