How do you dispose of BCSI stored in the cloud under CIP-011-3?
When BES Cyber System Information sits with a cloud provider, the storage drives are not yours to wipe, so the Responsible Entity has to act on the data itself. CIP-011-3 requires you to take action to prevent unauthorized retrieval of BCSI before a Cyber Asset is reused or disposed of, and a SERC CIP auditor has described crypto shredding (encrypting the data, then destroying the encryption key) as the best option for cloud-held BCSI because the physical media belong to the provider. The approach works only if you can show that the key is gone and that no copy of the key survives elsewhere, so the design decisions start well before disposal day.
The right method depends on three things: who owns the encryption keys, what the provider's deletion terms say, and what evidence you can produce. NERC's cloud guidance describes several key arrangements, including vendor-owned keys with detection of unauthorized key use, customer-owned keys in a cloud key vault with access monitoring, customer-owned keys held on premises or in a separate cloud, and customer keys in a cloud hardware security module. Confirm with the provider whether key destruction is a customer action you can perform and whether backups, replicas and snapshots holding the ciphertext are also covered by that destruction. Ask for written deletion commitments that cover all copies and the timelines for them.
The Responsible Entity owns this outcome, even though a provider runs the infrastructure. NERC's cloud guidance says the division of security responsibilities with a cloud provider does not transfer compliance responsibility, so you must be able to demonstrate the disposal yourself. There is no CIP certificate. Compliance is monitored by the Compliance Enforcement Authority, a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications and other monitoring, and the auditor decides whether your evidence meets CIP-011-3. Before an audit, prepare key destruction records, provider attestations about deletion, and a dated log tying each disposal to the BCSI it covered.
How to run a cloud BCSI disposal step by step
This sequence turns a general disposal decision into documented steps that remove a provider-held copy of BCSI from every location, cut off the means to read it, and leave records an auditor can test against CIP-011-3.
Inventory every BCSI location in the cloud
The compliance lead and the cloud platform owner list every place BCSI sits in the cloud service, including primary storage, backups, snapshots, replicas, logs, search indexes, caches and analytics copies. Each entry names the service, the region, the owning account and the system it supports. The step is done when the inventory is reconciled against the BCSI identification records from CIP-004-7 and CIP-011-3 work, so no copy is known only to a single engineer. Anything that cannot be found is treated as an open gap until it is traced.
Confirm the encryption and key ownership model
The security engineer records how each copy is encrypted and who controls the key: vendor-owned keys with detection of unauthorized key use, customer-owned keys in a cloud key vault with access monitoring, customer keys held outside the cloud, or customer keys in a cloud hardware security module. The output is a key register that maps every encrypted BCSI location to its key, the key holders and the key's deletion path. If a copy is not encrypted, or its key is shared with other tenants, that copy is flagged for remediation before disposal proceeds.
Define the trigger for reuse or disposal
The CIP owner writes the event that starts disposal, such as contract termination, decommissioning of a system, migration to another provider or a change in the BCSI retention decision. The trigger is tied to the specific Cyber Assets or cloud resources it covers and to the CIP-011-3 requirement it satisfies, either before reuse outside other applicable systems or before disposal. The approver signs the trigger record, which becomes the first entry in the disposal file.
Destroy the keys or delete the data
Using the approved method, the operator either destroys the customer-owned keys that protect the encrypted BCSI or deletes the storage objects and their snapshots and replicas through the provider's management interface. For crypto shredding, the key destruction is the action that makes the ciphertext unreadable, so key deletion is performed on every copy and key version, including backup keys. The operator captures the change ticket, the identifiers of the destroyed keys or deleted objects and the timestamps from the provider's audit logs.
Verify that BCSI cannot be restored
A second person who did not perform the destruction checks that the key state is destroyed or disabled and pending deletion where the provider uses a waiting period, that no backup or replica still holds a usable key, and that a restore attempt against the retired location fails. The verifier also reviews the provider's deletion or destruction commitment in the contract or documentation and confirms it applies to the services used. The step closes when the verification results are attached to the disposal file with the reviewer's name and date.
Retain the disposal records
The compliance lead assembles the disposal file: the inventory, the key register, the trigger approval, the destruction and deletion logs, the verification results and the provider's commitment excerpt. The records are stored under the entity's CIP evidence retention rules, and the file is linked to the system's CIP-011 evidence index. The output is a single disposal package that lets an auditor trace one BCSI location from identification to unreadable state without reconstructing the work from memory.
What to get in writing from the cloud provider
Cloud providers rarely describe disposal in their standard terms with the precision a CIP auditor expects. The cards below list the terms the Responsible Entity should confirm in its own contract, because the NERC cloud guidance makes the entity responsible for demonstrating compliance even when the provider runs the storage.
Key destruction commitments
Ask the provider to state, in writing, what happens to encryption keys when the entity closes its account or deletes a dataset, and how long that takes. Under a crypto shredding approach, the destruction of the key is the disposal event, so a vague promise to delete data is not enough. Confirm whether the provider destroys key material or only schedules deletion, and whether it covers keys the provider holds for the entity. Record the stated timeframe so it can be compared with the entity's own disposal procedure.
Backup and replica handling
BCSI rarely sits in one copy. Providers replicate storage across zones, keep snapshots and retain backups for recovery, and any of these copies could outlive the primary data. Ask which copies exist, where they are held, how long they persist after deletion, and whether their encryption keys are destroyed on the same schedule as the primary keys. An entity should not accept disposal of the live data while unknown copies remain readable.
Key deletion and recovery windows
Many key management services hold deleted keys in a pending state for a recovery period before permanent removal, so the key may still exist after the entity believes it is gone. Ask the provider to name the recovery window, whether it can be shortened or disabled for CIP-designated keys, and who can cancel a scheduled deletion. Confirm that the window is documented in the contract and that the entity's disposal record shows the final destruction date, not the date of the deletion request.
Notification of key use or retention
The key holder should tell the entity when a key is used after disposal was requested, when a key is retained for legal or operational reasons, or when the provider receives a legal demand for data. The NERC guidance on key options assumes the entity can monitor key use, so the contract should commit the provider to alerts or logs the entity can review. Confirm the notification method, the recipients and the time within which notice is given.
Evidence the provider supplies on request
Decide now which artifacts the entity will need during a Compliance Audit, such as a written statement of destruction, key deletion logs, service-level records of when the key was destroyed, and the provider's independent assurance reports covering key management. Ask whether the provider will sign a certificate of destruction for each disposal event and how quickly it responds to a request. The entity remains responsible for presenting this evidence to the auditor.
What evidence a CIP auditor will ask to see
The first thing an auditor looks for is a written, approved procedure that links the disposal method to the requirement. CIP-011-3 requires action before reuse and before disposal that prevents unauthorized retrieval of BCSI, so the procedure should name the requirement parts it satisfies (Part 2.1 for reuse and Part 2.2 for disposal) and describe the cloud-specific method, such as crypto shredding. Because the storage drives belong to the provider, the procedure must explain why the entity's control, encrypting the data and destroying the key, is the action that meets the requirement.
- Requirement mapping: Each step ties to CIP-011-3 R2 Part 2.1 or Part 2.2, with the applicable Cyber Asset types listed.
- Roles and approvals: The procedure names who initiates, who performs and who verifies a key destruction, and shows the approval sign-off.
- Provider interface: It describes how the entity requests deletion, receives confirmation and records the outcome.
- Exception handling: It covers failed or incomplete destruction and how the event is escalated and tracked.
- Review cycle: It shows the date of last review and the change history.
Confirm that the procedure matches what staff actually do, since auditors compare the document with interviews and records.
Each reuse or disposal event needs its own record. A procedure alone does not show that the control ran. Auditors will sample events and ask for the entity's record of each one, including what BCSI was involved, which key protected it, and when the key was destroyed. Records should be traceable back to the affected Cyber Asset or storage object, so the auditor can follow one event from the request to the closed ticket.
- Event identifier: A unique reference for each reuse or disposal event.
- Asset and data scope: The cloud resource, storage container or Cyber Asset identifier, and the BCSI category involved.
- Key identifier: The key ID or key reference that encrypted the data, so the record links to the key destruction evidence.
- Dates and actors: When the request was made, when the key was destroyed and who approved and performed each step.
- Closure status: Whether the event was completed, and any follow-up items.
Confirm that your ticketing or change system can produce these records for any date range in the audit period.
For crypto shredding, the central evidence is proof that the encryption key no longer exists in a usable form. Depending on who owns the key, that proof comes from the entity's key management logs or from the provider's destruction certificate or attestation. The auditor will want to see that the key was destroyed, not simply disabled or scheduled for deletion, and that the destruction is tied to the specific key identifier recorded for the event.
- Destruction log entry: The key management system record showing the key state changed to destroyed, with timestamp and actor.
- Provider certificate: Where the provider holds the key, a written confirmation of destruction that names the key identifier and date.
- Key state history: Records showing transitions such as active, disabled, pending deletion and destroyed, to show the key was not restored.
- Backup and replica coverage: Evidence that key copies in backups or replicas were also destroyed, or a description of how the provider handles them.
- Scope reconciliation: A check that every key protecting retired BCSI has a matching destruction record.
Confirm with the provider what its destruction evidence contains and how long it retains it, since the entity must produce it during the audit period.
Destroying a key only matters if nothing can use it afterward. Auditors expect records showing that no decryption or key request succeeded against the destroyed key, and that access attempts were monitored. The NERC cloud guidance describes key options that include vendor-owned keys with detection of unauthorized key use and customer-owned keys in a cloud key vault with access monitoring, so the monitoring evidence depends on which model the entity chose. The records should cover the window between the destruction event and the end of the audit period.
- Access logs after destruction: Logs of key operations for the destroyed key, showing failed or no successful use.
- Alerting records: Alerts raised for attempted use of destroyed or disabled keys, and the response to each.
- Key holder tracking: Records of who could administer the key before destruction, and evidence that those permissions were removed.
- Log retention: Confirmation that key logs are retained long enough to cover the audit period.
- Review evidence: Records showing someone reviewed the key access logs on a defined schedule.
Confirm which logs the provider exposes to you and whether you can export them without asking the provider to run queries on your behalf.
The NERC cloud guidance is clear that dividing security responsibilities with a cloud provider does not transfer compliance responsibility. The Responsible Entity, as data owner, must apply the required controls, including at third parties, and must be able to demonstrate compliance. The contract is therefore evidence in its own right. It should commit the provider to the actions the entity depends on, including deletion or key destruction on request, the format of destruction confirmation and the timeline for delivering evidence.
- Deletion commitments: Clauses requiring the provider to destroy keys or data on instruction, and to confirm completion in writing.
- Evidence delivery: Terms for providing destruction certificates, key logs and incident notices within a set period.
- Subcontractor flow-down: Requirements that any subcontractor holding key material or storage follows the same deletion obligations.
- Audit cooperation: The provider's obligation to support the entity's CIP audit and to answer evidence requests.
- Notice of change: Commitments to notify the entity before changes to key management or storage locations.
Confirm that legal and procurement teams have reviewed these terms against CIP-011-3 and CIP-013 supply chain obligations before the cloud service carries BCSI.
Where cloud BCSI disposal usually fails an audit
Disposal of BCSI in the cloud fails less often because the cryptography is weak and more often because the paperwork and verification trail do not match what the entity claims. Each pitfall below is a gap between what the entity believes the provider did and what it can show an auditor. Check each one before you rely on crypto shredding as the disposal method.
Keys stored alongside the ciphertext
If the encryption key sits in the same bucket, volume or account as the encrypted BCSI, destroying the key does not remove access to the data for anyone who can reach both. Under CIP-011-3 R2 Part 2.2, the question is whether unauthorized retrieval is prevented. Confirm that the key lives in a separate trust boundary that the BCSI storage administrators cannot read, and document where each key is held.
Forgotten backups and snapshots
Encrypted copies often persist in provider backups, replicas, snapshots and archive tiers after the primary object is deleted. If the key is destroyed but a copy is encrypted under a different key that still exists, the disposal is incomplete. Inventory every location where BCSI was written, including replication and backup settings, and confirm each copy is covered by the same destruction step.
Provider deletion terms not in writing
A provider's general statement that data is deleted on request does not show how deletion happens, how long it takes, or what is retained for operational reasons. Disposal terms should appear in the contract or service agreement, covering key destruction, backup expiry and certificates of deletion. Ask the provider to state these commitments in writing before BCSI is loaded, not after a disposal is needed.
No record linking keys to BCSI
An auditor will ask which key protected which BCSI, and when that key was destroyed. Without a register that maps key identifiers to datasets, systems and retention dates, the entity cannot prove that the destroyed key covered every copy. Maintain this mapping as part of the BCSI inventory and update it whenever a dataset is created, copied or moved between services.
Reliance on provider assurance alone
The NERC cloud guidance states that a provider's shared responsibility model does not transfer compliance responsibility. The Responsible Entity, as data owner, must be able to demonstrate that disposal occurred. Relying on the provider's statement or a third-party report without running the entity's own check, such as confirming a key is disabled and attempting a read of a test object, leaves the entity without its own evidence.
Unlogged key destruction
Key destruction that happens through an administrator console without a recorded event is difficult to defend. The entity should capture who requested the destruction, the approval, the key identifier, the time and the provider's confirmation, and retain these records with the disposal evidence. Ask the provider which audit logs record key deletion, how long they are kept, and whether the entity can export them.
Who does what in a cloud BCSI disposal
The Responsible Entity owns the compliance obligation. NERC's cloud guidance says that dividing security duties with a cloud service provider does not transfer compliance responsibility, so the entity, as data owner, must apply the required controls at third parties and be able to demonstrate them. For disposal, the entity decides the method, writes the procedure, and keeps the evidence that a reviewer will ask to see.
- Procedure ownership: Define when BCSI reaches end of life and which disposal method applies, such as crypto shredding for cloud-held storage.
- Key governance: Decide who holds key administration rights and who may schedule or approve key destruction.
- Provider contract terms: Confirm the provider's deletion and key destruction commitments are written into the agreement.
- Evidence file: Retain the procedure, approvals, key destruction records and provider attestations for the period the auditor reviews.
- Oversight: Review provider records periodically rather than assuming the service behaves as described.
Check that your procedure names a specific owner for each disposal step and that the evidence can be produced without the provider's involvement.
The cloud provider operates the storage hardware and the key management service. It cannot make the compliance determination for the entity, but its controls and records often supply the facts the entity relies on. Under a crypto shredding approach, the provider's role is to destroy the storage it controls and to record key operations accurately.
- Deletion terms: State how and when the provider deletes or overwrites data, and how it handles backups and replicas.
- Key destruction: Describe how keys are scheduled for deletion, how deletion is confirmed, and whether deleted keys can be recovered.
- Key logs: Provide audit logs of key creation, use, disablement and deletion that the entity can export.
- Hardware disposal: Explain how the provider sanitizes or destroys drives it retires, if the entity needs that statement.
- Certification reports: Supply independent reports, such as a SOC 2 Type 2 report, as administrative evidence where available.
Ask the provider which of these records it produces by default, how long it retains them, and whether they can be exported in a form an auditor can review.
An implementation partner such as DeployOpen prepares the configuration, key workflows and evidence collection that support the entity's procedure. The partner works inside the entity's accounts and documents what was built. It does not own the control, does not decide that disposal is compliant, and does not issue audit reports or certificates.
- Configuration: Set up encrypted storage, key policies and logging so that the disposal method can be executed and verified.
- Key workflows: Build and document the steps for disabling and destroying keys, including who approves each step.
- Evidence collection: Script or document the exports that show key destruction and access history, so they can be produced on request.
- Runbooks: Write test procedures that confirm recovery of BCSI is not possible after key destruction.
- Handover: Deliver the documentation and training so the entity can operate the workflow after the engagement ends.
Confirm the scope, deliverables and timing in writing before work begins, and make sure the entity remains the owner of every procedure and record.
The independent auditor, or the Compliance Enforcement Authority when it conducts the monitoring, tests whether the entity meets CIP-011-3. There is no CIP certificate. Findings come from the audit process run by the Regional Entity or NERC, and no consultant or partner can substitute for that review.
- Test design: The auditor samples disposal events and checks whether each followed the documented procedure.
- Evidence review: The auditor examines key destruction records, provider attestations and the entity's approvals for consistency.
- Technical validation: The auditor may ask the entity to demonstrate that stored BCSI cannot be retrieved after key destruction.
- Findings: The auditor records any gaps, which the entity then addresses through its own mitigation process.
- Scope: The auditor reviews the entity's program, not the provider's internal operations, unless the provider's records are the evidence presented.
Before an audit, confirm with the Regional Entity which evidence it will request and when it will be due.
Questions about disposing of cloud-held BCSI
Is crypto shredding accepted for disposing of BCSI in the cloud?
Yes, crypto shredding is the approach a SERC CIP auditor described as the best option for cloud-held BCSI, because the storage drives belong to the cloud provider and the entity cannot physically destroy them. The method encrypts the BCSI, then destroys every copy of the encryption key so the stored ciphertext cannot be read. The auditor still tests the outcome, not the technique alone. You need to show that the key was destroyed, that no other copy of it exists in a key vault, HSM, backup or on-premises store, and that the BCSI could not be recovered by any holder. Document the key lifecycle from creation to destruction and keep the record for your audit period. Confirm the exact destruction procedure with your Regional Entity and your cloud provider before you rely on it.
Is deleting BCSI through the cloud provider enough on its own?
Usually not on its own. A provider deletion request removes the data from the service, but CIP-011-3 asks you to prevent unauthorized retrieval, and the provider's internal deletion process is outside your control and visible to you only through its contract and reports. Ask the provider in writing how deletion works for each storage tier, how long deleted objects persist in backups or replicas, whether it certifies sanitization, and what it will provide as proof. Combine that commitment with encryption and key destruction where the BCSI is sensitive. Treat a provider deletion statement as one piece of evidence, and retain it with your own record of the request and the time it was completed.
What disposal work must the entity do itself?
The entity remains the Responsible Entity and owns the compliance outcome, so several tasks stay with your team regardless of who runs the technical steps. You decide which BCSI sits in the cloud, classify each copy, define the disposal procedure in your program, and approve and record each disposal event. You also control the encryption keys if you have chosen customer-managed keys, which means you must destroy them yourself or direct the destruction and confirm it. The NERC cloud guidance states that dividing security responsibilities with a provider does not transfer compliance responsibility. Your contracts should assign the provider duties in writing, and your internal reviews should check that those duties were carried out.
How long does cloud BCSI disposal take and what drives the timing?
No general duration applies, and the timing depends on your environment. The main drivers are how many storage locations and copies hold BCSI, whether encryption keys were already customer-managed, how many keys and key vaults must be inventoried, the provider's own deletion and backup cycles, and how much existing evidence you must reconstruct for an audit. Disposal is also tied to events such as system retirement or a change in BCSI handling, so the work often runs alongside other program changes. Ask any partner or provider to break the plan into discovery, key inventory, destruction, verification and evidence collection, with a stated effort for each. Those components are where the timing will vary.
How should backups and replicas of cloud BCSI be handled at disposal?
Backups and replicas are copies of BCSI, so they fall within the disposal scope and must be addressed in your procedure. Identify every backup, snapshot, replica and archive that contains BCSI, including copies held by the provider in other regions. For encrypted copies, the same key destruction approach applies, and you must confirm that no backup retains a usable copy of the key. For unencrypted copies, you need a documented deletion path and a record of when it completed. Check the provider's retention window for backups, because deleted data may persist until the backup expires. Record the decision for each copy type so an auditor can trace how every copy was handled.
Can a partner prepare the evidence for cloud BCSI disposal?
A partner can prepare systems, procedures and evidence for disposal, but only the Responsible Entity owns the controls, and only the Compliance Enforcement Authority decides whether they meet the standard. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can prepare disposal procedures, key inventories, destruction records and verification steps that fit the systems it helps you run. It does not issue audit reports or certifications. Scope, deliverables and timelines are agreed in writing before work starts, and any quote follows from that written scope. Ask for a list of the evidence each deliverable produces so you can check it against what your auditor will request.
How DeployOpen prepares cloud BCSI disposal evidence
DeployOpen plans, implements and documents the self-hosted open-source platforms that run inside your own infrastructure, so the key handling and disposal steps for cloud-held BCSI can be scoped and evidenced before an assessor asks. The organization remains responsible for its CIP controls, and only an independent auditor or Regional Entity reviews compliance.
How we scope
- We confirm which stores hold BCSI, including provider-hosted backups, snapshots and replicas that must be disposed of.
- The written, fixed scope names the encryption, key custody and disposal steps covered, along with the systems and accounts in each.
- We agree in writing which provider deletion commitments and key destruction records the engagement will document.
How we build
- We configure customer-managed encryption for BCSI stores so that key destruction can be performed and recorded in the your environment.
- We set up key lifecycle logging, restricted key administrator roles and scheduled key destruction workflows for disposal events.
- We test a disposal run end to end, confirming that retrieval of the BCSI is not possible once the key is gone.
How we hand over
- You receive written procedures for crypto shredding, key destruction and provider deletion requests, mapped to CIP-011-3 Part 2.1 and Part 2.2.
- Evidence packs include key destruction logs, configuration exports, test records and the provider's written deletion confirmations.
- We walk your compliance and operations staff through the evidence so they can present it to an independent auditor during a CIP audit.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement closes.
- Retainer work can repeat disposal tests and refresh evidence when key management or provider services change.
- Confirm with your auditor and your cloud provider which evidence formats they accept before the engagement starts.
