Who holds the encryption keys for BCSI in the cloud, and why it matters for CIP audits
If your organization must place BES Cyber System Information (BCSI) in a cloud or SaaS service, your CIP program has to show who can actually use that information. Under CIP-004-7 R6, an individual has access to BCSI only when they can both obtain it and use it, and encryption keys are one of the means that provide that ability. In practice, the choice of who holds the keys is the main variable in the access analysis: a provider or administrator who can obtain the keys can potentially use the encrypted data, while a person who holds encrypted BCSI without the keys cannot. That is why the key holder decision belongs in your CIP-004 and CIP-011 evidence, not only in an IT architecture document.
Responsibility for this is split in a specific way. Your organization owns its CIP controls and makes the key holder decision, including whether keys stay with the provider, sit in a customer-managed key vault, are held on premises or in a separate environment, or are protected in a cloud hardware security module. An implementation partner can prepare the key configuration, access lists and supporting records, such as who holds key access and how that list is kept current. Only the Compliance Enforcement Authority, a Regional Entity or NERC, assesses compliance, and there is no CIP certificate to obtain. Before you commit, confirm with your provider exactly which key options its service supports and where its key administrators sit in the access chain.
Plan for this decision early, because it affects how you will answer an audit. Ask the provider to document every path by which its personnel or your own administrators could reach keys or decrypted data, and confirm how key access changes are logged. Then set a revocation procedure that removes key access for departing staff within the window CIP-004-7 Part 6.3 requires, and rotate keys when a key holder leaves, as the SERC guidance suggests. The NERC cloud guidance on BCSI sets out the key management options your auditor will expect you to have considered.
Which key option fits the organization's risk and tooling
With vendor-owned keys, the cloud provider generates, stores and rotates the encryption keys for the service, and the entity does not manage them. The entity still decides whether BCSI goes into the service and who on its side can use the service, but it has little direct control over key use inside the provider. The NERC cloud guidance pairs this option with detection of unauthorized key use, so the entity needs the provider to show how that detection works and how it reports to the customer.
- Entity control: Account roles, provisioned user access and the decision to store BCSI in the service.
- Provider control: Key generation, storage, rotation and the people and systems that can use the keys.
- Evidence to collect: The provider's description of unauthorized key use detection, its alerting commitments and its business agreement terms.
- Access review impact: Because the entity holds no keys, its access list covers user accounts and roles only.
- Provider personnel: Track how provider administrators could reach BCSI, since the NERC guidance asks entities to identify those paths.
Confirm with the provider whether vendor-owned keys are the default for the service, whether detection is included at no added charge, and what reports the entity receives.
With customer-owned keys in the provider's key vault, the entity creates and controls the keys inside its own cloud account, and the provider stores them in a vault the entity administers. The entity sets key policies, decides who can use the keys and can rotate or disable them. The provider still runs the underlying infrastructure and may have administrator paths that the key policy does not block, so the entity must confirm how those paths work.
- Entity control: Key creation, key policies, rotation schedule and the ability to disable a key.
- Provider control: The physical hosting, the vault service itself and provider administrator access to the platform.
- Evidence to collect: Key policy exports, key access logs, rotation records and monitoring of key use.
- Access revocation: Removing a departing employee's key permissions is a key change that the entity must document, in line with the guidance to change the key after key holders leave.
- Tracking: Keep a running list of the people who hold key permissions, not only the people who hold BCSI access.
Confirm whether the service supports customer-managed keys in its vault, which logs the vault records and how long those logs are retained.
The NERC guidance also describes customer-owned keys held on premises or in a separate cloud, so the keys are not stored with the BCSI. This separation means a provider that holds the encrypted data cannot read it without a request the entity can refuse or log. The cost is operational: the entity must run or contract for a key system that is available whenever the service needs to decrypt data, and that system becomes part of the scope of its own controls.
- Entity control: The key system, its access list, its availability and its change process.
- Provider control: The encrypted storage and the service that calls the external key system, which depends on the entity's key service being reachable.
- Evidence to collect: Records of the key system's access, network paths between the service and the key system, and change tickets for key holder changes.
- Availability risk: If the key system is down, the cloud service may stop working, so the entity should document that dependency in its recovery planning.
- Separate cloud: If the keys sit in another cloud, that second provider must also be assessed.
Confirm that the service can call an external key system and which key interfaces it supports before choosing this model.
The last option stores customer keys in a cloud hardware security module, a dedicated device that performs cryptographic operations and does not release the key material in ordinary use. The entity controls the keys and their policies, and the hardware module adds a physical and logical barrier against extraction. Like other managed services, the provider still operates the module and the hosting environment, so the entity must read the provider's documentation on who can administer it.
- Entity control: Key creation, key policies, rotation, and the choice of which services may use the module.
- Provider control: Hardware operation, firmware, facility security and administrator access to the module platform.
- Evidence to collect: Module configuration records, usage logs, the provider's attestation or assurance documentation for the module, and key holder lists.
- Key holder tracking: Record which administrators and applications can use each key, and update the record and rotate the key when an employee with key access leaves.
- Cost driver: Dedicated modules are usually priced differently from software-managed keys, so ask for the quote to show module and key charges separately.
Confirm whether the service offers a dedicated module, what assurance the provider can document for it and whether the module is in the same region as the BCSI.
No single option is correct for every entity. The choice depends on how much control the entity needs over key use, whether it can run or contract for key infrastructure, and what the provider offers for the service in question. Entities should decide on a model before storing BCSI, because moving keys later usually means re-encrypting the data and re-documenting access.
- Lower operational burden: Vendor-owned keys require the least setup but give the entity the least direct control.
- More control inside the cloud: Customer keys in the vault put key policy in the entity's hands while the provider runs the platform.
- Stronger separation: External keys and cloud HSMs keep keys apart from the stored data, with added availability and cost questions.
- Tooling fit: Check whether the entity's identity, logging and key tools can produce the evidence each option requires.
- Written decision: Record the chosen option, the reasons and the provider's confirmation in the BCSI program documentation.
Before deciding, ask the provider in writing which of these four models it supports for the specific service, and what evidence it will give the entity for each.
How provider and internal personnel could still reach BCSI
Encrypting BCSI in the cloud does not by itself settle who can read it. The NERC cloud guidance asks entities to identify every path through which provider or internal personnel could reach BCSI under CIP-011-3, and the cards below cover the paths auditors ask about most. Each one is a place where access can exist outside the access list you maintain.
Password protection alone is not enough
Password protection of storage hardware alone may not be sufficient when BCSI is not encrypted. If a provider administrator or anyone with physical or logical access to the underlying storage can read the data in plain form, a password on the device does not stop that read. Ask the provider whether BCSI is encrypted at rest and who holds the keys. Keep the provider's encryption configuration and your record of the data classification decision as evidence.
eDiscovery tools
Provider eDiscovery and legal hold features can search, export and copy customer content for litigation or regulatory requests. Those tools can reach BCSI even when your own users cannot. Ask the provider which eDiscovery roles exist, who can invoke them, whether customers are notified, and whether the tool decrypts data for the operator. Keep the provider's documentation of these features and any internal approval records for holds that cover BCSI.
Cloud administrator roles
Subscription owners, tenant administrators and platform operators often hold rights that override the permissions you grant to application users. A user who can assign roles, reset credentials or change key policies can gain read access to BCSI without ever opening the data store directly. Review which built-in administrator roles exist in your tenancy, who holds them and whether they are provisioned as BCSI access under CIP-004-7 R6. Keep the role assignment export and the review record.
Break-glass accounts
Break-glass accounts are emergency credentials that bypass normal approval so that someone can restore service during an outage. In a BCSI environment they are a standing path to the data unless they are controlled. Confirm where the credentials are stored, who can retrieve them, how each use is alerted and logged, and how the password or key is rotated after use. Keep the vault access log, the rotation record and the post-use review for each emergency event.
Provider support and escalation access
Provider engineers sometimes need temporary access to customer environments to troubleshoot incidents. That access can include viewing data, reading logs that contain BCSI or joining a session in your tenancy. Ask the provider for its support access model: whether access is granted per request, how long it lasts, whether you can approve it, whether it is logged for you, and whether the provider's own staff are screened. Keep the support access policy and each approval or customer-lockbox record that the provider makes available.
How to track key holders and rotate keys when staff leave
This sequence keeps a current, reviewable record of everyone who can reach cloud-held BCSI and everyone who can reach the keys that decrypt it, so a departure can be closed out on both sides. It produces evidence an auditor can trace from a termination record to revoked access and, where the keys were exposed, to a key change.
Inventory every path to BCSI
Start by listing each way a person or account can obtain and use BCSI in the cloud service. Include named user accounts, administrative and support roles, service accounts, shared storage locations and break-glass accounts. The NERC cloud guidance expects you to cover provider personnel reach too, such as eDiscovery tools and cloud administrator roles, not only your own staff. The output is a register of access paths, each with an owner and a note on whether the path needs a key to be usable. You know it is done when a reviewer can pick any BCSI location and name every path that reaches it.
Map key holders and key permissions
Next, list every principal that can use each encryption key protecting that BCSI. Cover key administrators who can rotate, disable or delete keys as well as principals who can decrypt. Record which keys are vendor-owned, customer-owned in a cloud key vault, held on premises or in a separate cloud, or held in a cloud hardware security module, because that choice decides who you must track. The output is a key holder list tied to each key identifier. You know it is done when every key that protects BCSI has a named set of holders and a recorded location.
Link both lists to the personnel access process
Connect the BCSI access list and the key holder list to your CIP-004-7 provisioning and authorization records. Under CIP-004-7 R6, access to BCSI means the ability to both obtain and use it, and provisioned access can come from a user account with rights or from an encryption key. A person holding encrypted BCSI without its key cannot use it, so each key grant should trace to an authorization record. The output is a cross-reference from each individual to their BCSI access and key permissions. You know it is done when no key holder appears without a matching authorization.
Review both lists on a set schedule
Run a recurring review that compares the current lists against the authorization records and the provider's account data. Confirm that each key holder still needs their permission and that no shared or service accounts have picked up key rights unnoticed. Record any removals, the reviewer and the date. The output is a signed review record for each cycle. You know it is done when the review shows the lists match reality and every exception has a documented disposition. The review cadence should be set in your own program, and you should confirm how your CIP-004 access review cycle aligns with it.
Act on a termination event
When a personnel termination action is recorded, pull the individual's entries from both the BCSI access list and the key holder list. Remove their ability to use every provisioned path, including user accounts, cloud roles and key permissions. CIP-004-7 Part 6.3 requires removing the ability to use provisioned access to BCSI by the end of the next calendar day after the termination action. The output is a removal ticket with timestamps for each path. You know it is done when the provider's own logs show the account and key permissions are disabled within that window.
Rotate keys after a key holder leaves
Where the departing person held key permissions, plan a key change so they cannot use any copy of the key material they may have retained. SERC recommends changing the key once an employee with key access leaves. Versioned key systems, such as the OpenBao transit secrets engine that supports key rotation, can support this, but you should confirm how your chosen platform or provider handles rotation, re-encryption of existing data and retention of old key versions. The output is a rotation record showing the old and new key versions and the BCSI re-encryption status. You know it is done when the old key can no longer decrypt new data and the rotation is logged.
Confirm the provider meets the removal timeline
Ask your provider in writing how it removes key and account access for your tenant after your instruction, how quickly that happens, and what logs it returns. Your CIP-004-7 Part 6.3 timeline is yours to meet, so you need to know whether the provider's processing can meet it, including for keys it holds and for any provider personnel access paths. The output is a documented provider commitment in your contract or service records, with a test or sample log. You know it is done when you can show, from the provider's evidence, that removal happens within the required window. Confirm this with the provider and your compliance lead before relying on it.
Retain termination and rotation evidence
Collect the termination record, the removal timestamps, the key rotation record and the provider's logs into one evidence set for each event, and link it to the access lists and the review records. Keep the set for the retention period your CIP program requires and make it retrievable by person and by key identifier. The output is a traceable evidence chain that an auditor can follow from a personnel action to revoked access. You know it is done when a sample termination can be walked through end to end in a few minutes using only the stored records.
What evidence an auditor will ask to see for encrypted BCSI
CIP-011-3 expects an entity to show how it protected BCSI stored off premise, using electronic, physical and administrative methods together. The cards below list the artifacts that connect those methods to who can actually decrypt BCSI in the cloud.
Key policy and configuration exports
Export the key policy or key vault access policy for every key that protects BCSI, and keep dated copies. An auditor will compare the principals named in the policy with the access list you provide. Check that the policy grants decrypt rights only to the roles you approved, and that the export shows the key type (vendor-owned, customer-owned in the cloud, held outside the cloud, or held in a cloud hardware security module) for each BCSI store.
Key holder access list
Maintain a running list of every person and service identity that can use the encryption keys, separate from the list of people who can reach the storage. The SERC guidance suggests keeping both lists. Auditors will test whether anyone on the key list is missing from your personnel records, and whether the list shows the date each grant was made and who approved it.
Key-use logs and alerts
Provide logs of key operations such as decrypt, wrap and key-policy changes, with alerts for use outside approved identities. For vendor-owned keys, ask the provider for documented detection of unauthorized key use and retain the notifications. A log that exists but is never reviewed will not satisfy an auditor, so keep records of who reviewed the logs and what they found.
Key rotation and change records
Keep change tickets showing when keys were rotated, when a key holder was removed and when the key was changed after an employee with key access left. SERC recommends changing the key once such an employee leaves. Pair each change record with the termination record so the auditor can see the key change happened within the access revocation window in CIP-004-7 Part 6.3.
Badge and custody records for key custodians
Where keys or key material are held on premises or in a separate location, show the physical controls: lock and key or badge management, access logs for the room or cabinet, and alarm records. For hardware security modules, show who holds the physical or administrative custody of the module. Treat custodians' badge records as part of the same evidence set as the key list, since both answer who can reach the key.
Vendor risk assessments and business agreements
Keep the vendor service risk assessment and the signed business agreement that covers encryption, key handling, provider personnel access and notification of key or access incidents. CIP-011-3 lists these administrative methods as evidence for off-premise BCSI. Ask the provider whether its own SOC 2 or other independent reports cover key management, and confirm the scope of those reports before relying on them.
Where open-source key management fits
An entity that wants customer-held keys for cloud-stored BCSI can keep key custody on its own infrastructure, and an open-source option for that is OpenBao. Its transit secrets engine, licensed under MPL-2.0, encrypts and decrypts application data without storing the data itself, signs and verifies data, and supports versioned encryption keys with key rotation. In the NERC guidance's terms, this kind of service is a way to hold keys on premises or in a separate environment so that the keys are not stored alongside the encrypted BCSI. The entity, not the software, remains responsible for who can call the service, how those roles are assigned, and how the keys are protected.
Before relying on it, confirm in the edition you plan to deploy that the transit engine supports the operations your design needs, including the key types, the signing and verification functions, the rotation behavior and the audit logging you will cite as evidence. Document the exact version, the configuration of the transit mount and the policies that limit which identities can encrypt, decrypt, rotate or export. Check the OpenBao transit secrets engine documentation against your own test environment rather than relying on a summary.
Plan for the operational work that comes with self-hosting. The entity must maintain the availability and patching of the key service, back up its configuration and key material under controls that CIP-011-3 would treat as protected, and keep a current list of the people and service accounts that can reach it. If the cloud provider's own staff or break-glass roles can reach the BCSI, the key service does not remove that path, so the entity should document both sides together. An implementation partner can prepare the deployment and its evidence, but the entity owns the decisions about custody and access.
What an implementation partner can prepare and what stays in-house
Key decisions for cloud-held BCSI split into engineering work a partner can prepare and accountability that stays with the registered entity. DeployOpen prepares systems and evidence for the entity's review, while only an independent auditor issues reports, and no partner certifies CIP compliance.
Key architecture design
The partner can document how each key option maps to the BCSI stores, which key vault or HSM holds each key, where key material lives relative to the ciphertext, and which provider or internal roles can reach the keys. The entity decides which of the four key options from the NERC cloud guidance fits its risk profile. Check that the design answers the question of whether a holder of encrypted BCSI can also obtain the keys.
Configuration of the chosen key option
The partner can configure the selected option, such as customer-owned keys in a cloud key vault, keys held on premises, or a cloud hardware security module, and set key rotation and access policies. For a self-hosted approach, OpenBao's transit secrets engine can encrypt and decrypt application data without storing it and supports versioned keys with rotation. The entity confirms that the configuration matches the design it approved and that the key service is itself protected under CIP controls.
Access list and logging setup
The partner can build the running lists of who can use BCSI and who can use the encryption keys, then wire key usage and access events into logs the entity can review. Separate lists for data access and key access make a gap visible, such as a person with key access who no longer needs BCSI. Confirm that log retention and review match the entity's CIP-007 and CIP-004 procedures before go-live.
Evidence packages for review
The partner can assemble evidence that shows the key design, configuration, access lists, key rotation records and revocation tickets for each in-scope BCSI store. Each package should map to the CIP-011-3 evidence examples for electronic technical methods and to the CIP-004-7 provisioned access requirements. The entity reviews every package for accuracy before it is retained, since the entity is responsible for its own compliance record.
CIP program ownership and risk acceptance
The entity's CIP Senior Manager or delegate owns the CIP program, decides which BCSI may leave premises, and accepts residual risk from the chosen key model. A partner can describe the trade-offs in each option, but it cannot accept risk on the entity's behalf. Document the decision, the approver and the review date in the entity's own records.
Provider contracts and key custodian approvals
Contract terms with the cloud provider, including who can access keys and what the provider commits to on personnel access and notification, are negotiated by the entity's procurement and legal teams. Named key custodians must approve key creation, rotation and recovery, and those approvals stay with the entity. Ask the partner to produce a list of decisions requiring sign-off, but make sure the signatures and approvals come from the entity.
Questions CIP teams ask about BCSI encryption and keys
Does encrypting BCSI in the cloud satisfy CIP-011-3 on its own?
Encryption helps, but it does not settle the question by itself. The NERC cloud guidance says that password protection of storage hardware alone may not be sufficient when BCSI is unencrypted, and encryption only protects BCSI to the degree that the people who can reach the keys are controlled. Your entity still needs to identify how provider personnel or your own administrators could reach BCSI, for example through eDiscovery tools, cloud administrator roles or break-glass accounts, and show how those paths are limited and monitored. Read the NERC RSTC cloud guidance alongside your own risk assessment of the provider. The protection method you choose should follow from that assessment, not from the vendor's default settings.
Are vendor-owned encryption keys acceptable for BCSI?
They can be acceptable, but only with controls that make unauthorized key use detectable and that your entity has assessed. The NERC guidance describes vendor-owned keys paired with detection of unauthorized key use as one option. The alternatives are customer-owned keys in the provider's key vault with access monitoring, customer-owned keys held on premises or in a separate cloud so they are not stored with the BCSI, and customer keys in a cloud hardware security module. The choice drives who can decrypt BCSI and therefore who counts as having provisioned access under CIP-004-7 R6. Ask the provider exactly who can use or export keys, how that use is logged, and whether you can receive those logs. Document the decision and the reasoning in your CIP-011-3 evidence.
What drives the effort and cost of customer-managed keys for BCSI?
The main drivers are the key model you choose, the number of systems that store BCSI, and how much integration your environment needs. Customer-owned keys bring costs that vendor-owned keys avoid: you own key creation, rotation, access policy, backup and the logging pipeline that proves who used each key. Keys held on premises or in a separate environment add infrastructure to operate and patch, while a cloud hardware security module adds a service to procure and govern. Recurring work includes access reviews for key holders, rotation records and periodic testing of recovery. Ask any provider or consultant for a written scope that names the key model, the systems covered, the logs delivered and who runs each recurring task. No fixed price or duration applies across entities, so the scope and your environment set the figure.
Can our internal staff set up and run BCSI key management?
Often yes, if the team has cloud key management experience, a clear owner for the key policy and time for recurring evidence work. The harder part is usually the paperwork: a running list of who can reach BCSI and who can reach the encryption keys, change records for each key, and proof that revocation happened on time. SERC suggests keeping both lists current, and recommends changing the key once an employee with key access leaves. If your staff lack that capacity, a fixed-scope engagement can cover design, configuration, documentation and evidence preparation, while your organization keeps ownership of the controls. DeployOpen prepares systems and evidence, but only your independent auditor or the Regional Entity assesses them.
How do we show that key access was revoked when someone leaves?
Show a dated record that links the termination action to the removal of the person's ability to use BCSI and keys. CIP-004-7 Part 6.3 requires removing that ability by the end of the next calendar day after a termination action, and under CIP-004-7 R6 a person needs both the ability to obtain and to use BCSI, so the key is part of the test. Useful evidence includes the termination ticket, the directory or identity provider change, the key policy or grant that was removed, and the key-change record if the SERC recommendation was followed. Confirm with your provider how it logs key policy changes and how long those logs are kept, because you will need them during an audit.
What should we ask an auditor or consultant before starting BCSI key work?
Ask what they expect you to show, not only what they will test. Useful questions include: which key model they consider defensible for your BCSI and how they weigh vendor-owned keys with detection, whether they expect a running access list for both BCSI and keys, how they treat provider personnel access paths, and which evidence they want kept and for how long. For a consultant, ask for a written scope that lists the systems, the key model, the logs delivered and the owner of each recurring task. Remember that a Regional Entity or an independent auditor is the party that judges compliance, and your entity's own risk assessment is the document that justifies your choices. Start from that assessment and bring it to the first discussion.
How DeployOpen prepares key management and evidence for CIP audits
DeployOpen helps a registered entity build the key management and access logging behind its cloud-held BCSI, and it does so under a fixed scope agreed in writing before work starts. In practice that means planning which key option the entity will use from the NERC cloud guidance, such as customer-owned keys in a cloud key vault, keys held on premises, or keys in a cloud hardware security module, and then implementing or hardening the self-hosted pieces inside the client's own cloud accounts, data center or air-gapped network. Where the client chooses an open-source option, DeployOpen can configure components such as OpenBao's transit secrets engine, including key rotation settings, and wire up access logging so the entity can show who could use each key and when. The written scope names the systems, the key holders, the logging sources and the deliverables, so the entity knows exactly what it is paying for before work begins.
On the evidence side, DeployOpen prepares records that the entity's own CIP program can present. That usually includes the running list of who holds access to BCSI and who holds access to the encryption keys, the key rotation and revocation procedure, the logs that show removal of a departing employee's access by the end of the next calendar day under CIP-004-7 Part 6.3, and the CIP-011-3 documentation of how provider or internal personnel could reach BCSI through eDiscovery tools, administrator roles or break-glass accounts. These artifacts are prepared for the client's CIP program owners to review, approve and maintain. DeployOpen does not issue audit reports, attestations or certifications. Only the Regional Entity that monitors the entity, or an independent auditor where one is engaged, assesses compliance, and hiring DeployOpen does not guarantee any audit result. Confirm with your Compliance Enforcement Authority which evidence it expects before the scope is signed.
