What CIP-011-3 R2 requires before a Cyber Asset is reused or disposed of
CIP-011-3 R2 requires you to act before a Cyber Asset that holds BES Cyber System Information (BCSI) leaves your control for reuse or disposal. The action must either prevent unauthorized retrieval of BCSI from the device's data storage media or destroy that media. Part 2.1 covers release for reuse, meaning the asset is moved to a use outside the applicable systems where it was protected. Part 2.2 covers disposal, where the asset is discarded, sold, scrapped or returned. The residual-data risk is simple: deleting files or reformatting a drive often leaves recoverable data behind, and a retired server or workstation can end up with someone who has the tools to read it. The requirement does not prescribe a method, so the organization must choose and document one that fits each media type, such as sanitization for reuse, or physical destruction for drives that will not be reused.
The hard part is knowing where BCSI actually sits. Engineers copy diagrams, procedures and configuration exports into local folders, email attachments and browser caches, so a server's listed purpose may not describe what it stores. Confirm with the asset owner which data sets were in scope before any sanitization decision. Hardware managed by a vendor, leased equipment and warranty replacements add another layer: you need contract terms that require either return with media intact for your own handling, or documented destruction with a certificate. Virtual machines and cloud disks raise the same questions. Snapshots, backups, replicas and thin-provisioned volumes can hold copies of BCSI long after the guest is deleted, so you must identify every copy before you decommission it.
Treat R2 as a documented workflow with a named owner, not a one-time wipe. Practical checks include a decommissioning checklist tied to the asset inventory, a record of the sanitization or destruction method and who performed it, and evidence such as tool logs, vendor certificates or photographs of destroyed media. Ask your auditor or a qualified consultant how they expect you to show that each reused or disposed asset was covered. R2 carries a Lower Violation Risk Factor, but a gap in evidence can still be a finding. No certificate is issued for CIP compliance: the Compliance Enforcement Authority reviews your records during an audit or other monitoring engagement, so keep them in a form that stands alone.
Which Cyber Assets and retirement events fall under R2
R2 applies to any applicable Cyber Asset that holds BCSI when it leaves the CIP environment for reuse or goes to disposal. The scoping questions below decide which devices, copies and retirement paths are in play, and each one changes the evidence you need to produce.
Applicable Cyber Assets holding BCSI
Start from the Applicable Systems your CIP-002 categorization produced, then identify which Cyber Assets in those systems store BCSI, such as configuration exports, network diagrams, vulnerability scan results and recovery documentation. R2 only reaches Cyber Assets that contain BCSI, so an inventory that tracks where BCSI is written is the first deliverable. Confirm the list with the Cyber Asset owners, because BCSI often sits in places the CIP asset list does not show, such as an engineer's exported spreadsheet on a shared drive.
The reuse exception for other applicable systems
Part 2.1 does not require sanitization when a Cyber Asset moves to another applicable system and stays within the CIP environment. The exception is narrow: moving a device to a lower-protection network, a corporate pool or a vendor's shop ends it. Document each reuse decision with the source and destination systems so an assessor can see that the exception applied to that specific move.
Reuse versus disposal
Reuse releases a Cyber Asset to continue operating, while disposal ends its service life. Part 2.1 covers reuse outside the applicable systems, and Part 2.2 covers disposal, where the choice is either preventing retrieval from the device or destroying the storage media. Treat them as separate workflows with separate tickets and sign-offs, since a device that is reused for a time and later disposed of must pass through both controls.
Laptops, removable media and temporary devices
Laptops used for remote access, USB drives carrying BCSI and engineering workstations that move between sites are the cases most often missed. A laptop reassigned to a general staff member is a reuse event, while a failed drive returned under warranty may be a disposal event. Confirm that removable media and portable devices are in the inventory, and record how each one was last used for BCSI before it leaves the program.
Virtual machines, snapshots and cloud volumes
Deleting a virtual machine does not necessarily remove the BCSI it held, because copies can persist in snapshots, backup sets, replicated disks and cloud volumes that were never reclaimed. Check each storage layer that could hold a copy, and decide whether the virtual disk is a Cyber Asset in its own right. Ask your cloud or virtualization provider how deleted volumes are overwritten or destroyed, and what evidence they can supply.
Leased, vendor-returned and off-premise storage
Leased hardware, warranty returns and devices sent to a vendor for repair can carry BCSI out of your control. Off-premise BCSI, including storage in a cloud or hosted service, shifts part of the retrieval risk to the provider, so the contract and the provider's disposal records must support your evidence. Ask whether the provider will destroy media on your behalf, or whether you will need to destroy it before shipment, and record that answer in the retirement procedure.
How the two paths differ: reuse wiping versus destruction at disposal
CIP-011-3 R2 treats reuse and disposal as two separate paths, and each path accepts different actions. Before a Cyber Asset that holds BCSI is released for reuse outside the CIP environment, the responsible entity must take action to prevent unauthorized retrieval of BCSI from the data storage media. Before disposal, the entity must either prevent retrieval from the Cyber Asset or destroy the storage media. Reuse within other applicable systems is excluded from the reuse obligation, so the first decision for any asset is which path it is actually on. An engineer should record that decision explicitly rather than assume that a device leaving a high impact environment falls under the same treatment as one going to a storage shelf.
A logical delete does not prevent retrieval. Deleting a file, reformatting a volume or removing a partition typically removes only the pointers to the data, so the underlying content can often be recovered with ordinary forensic tools until the blocks are overwritten or the media is destroyed. Sanitization therefore has to be judged against the storage media itself, including flash controllers, spare areas and remapped sectors that an operating system cannot address directly. Whether a given method works depends on the media type, and the entity should confirm with the device or media vendor which sanitization methods are supported. Verification is the step most often skipped: the entity should be able to show how the outcome was checked, for example by sampling reads from the media after sanitization, and not only that a tool reported success.
Physical destruction of the media is the only defensible option when the media cannot be sanitized in a way the entity can verify, when the device has failed in a way that prevents writes, or when the media type is known to retain data under overwriting. Records for each asset should capture the asset identifier, whether it held BCSI, the path taken (reuse or disposal), the method and tool or procedure used, who performed and who verified the action, the verification result, and the handling of any media that was destroyed or sent to a third party. Ask any hosting provider, recycler or contractor for written sanitization evidence, and confirm before work starts whether that evidence is acceptable for the entity's own audit records.
How an assessor tests R2 and what they ask to see
This table compares what an assessor samples, requests and typically finds for CIP-011-3 R2 reuse (Part 2.1) and disposal (Part 2.2). Read each row as a test step paired with the evidence that lets the entity pass it. The main takeaway is that an assessor follows the asset from inventory to release or destruction, so every hop needs a record.
| Test area | What the assessor does and asks to see | Common findings |
|---|---|---|
| Asset inventory tie-out to retirement records | Starts from the list of applicable Cyber Assets that contain BCSI and traces each to a reuse or disposal record. Asks for inventory exports, asset identifiers and the date each asset left service. | Assets missing from disposal records, or inventory entries never closed out after removal from the CIP environment. |
| Sampling of reused assets (Part 2.1) | Selects a sample of assets released for reuse outside the applicable systems. Asks for the sanitization or removal action taken, who performed it and the verification that followed. | Reuse without a documented method, or a method that was described in policy but not applied to the sampled asset. |
| Sampling of disposed assets (Part 2.2) | Selects a sample of assets disposed of and asks whether data was rendered unretrievable or storage media was destroyed. Checks the record matches the asset's storage media type. | Disposal records that name the asset but not the method, or records that show the device left the site without a destruction step. |
| Sanitization method records | Asks for the documented method for each media type, the tool or procedure used and the operator's record of completion. Expects the method to be suitable for the storage media in the asset. | Procedures that are generic and do not address solid-state or hybrid media, or logs that were never retained. |
| Chain of custody for destruction | Follows custody from the point the asset leaves the CIP environment to the point it is destroyed. Asks for transfer forms, handler names, dates and any intermediate storage locations. | Gaps in custody between internal staff and a third party, or assets held in storage with no record of who had access. |
| Vendor certificates of destruction | Asks for the certificate for each vendor-handled asset and checks that it names the serial numbers or asset identifiers, the method and the date. Confirms that the entity reviewed the certificate. | Reliance on a vendor's general claim of secure destruction without verification, or certificates that do not reference the specific assets. |
| Exceptions and deviations | Asks for any asset where the planned method could not be applied, the justification, the compensating action and the approval record. Confirms the exception is tracked to closure. | Undocumented exceptions discovered during the audit, or exceptions that never received the required review. |
Implementing R2 from retirement request to closed record
This sequence turns a retirement or reuse request into a documented decision, a verified sanitization or destruction, and an inventory that matches what physically left the CIP environment. Each step ends with a record an auditor can trace back to a specific Cyber Asset.
Identify BCSI-bearing Cyber Assets from the inventory
Start from the asset inventory, not from memory. Filter for Cyber Assets in scope of CIP-011-3 that store or process BES Cyber System Information, including laptops, servers, storage arrays, removable media and any device used for vendor support or maintenance. Your CIP program owner or delegate confirms each flagged asset against your BCSI repository list. The output is a scoped list of assets per retirement request, with a yes or no BCSI determination and the reason recorded for every asset.
Define the sanitization or destruction method per media type
For each media type on the list, such as spinning disk, solid-state drive, flash media, network appliance memory or virtual disk, document the method that prevents unauthorized retrieval of BCSI before reuse, and the method that either prevents retrieval or destroys the storage media before disposal. Confirm the method with the media vendor's guidance and with your own risk owner, since CIP-011-3 requires action without prescribing one technique. The output is a per-media-type procedure that names the tool or process, the operator role and the verification step.
Build the retirement workflow with a release gate
Create a workflow that routes each request through the inventory, the BCSI determination and the chosen method before any asset leaves the CIP environment. The gate is a documented approval that blocks release for reuse outside applicable systems until sanitization is recorded as complete. Decide who can approve, who can override and how exceptions are logged. The output is a written procedure and a request template that an assessor can follow from the request to the closing record.
Execute sanitization or destruction and verify the result
Perform the approved method on each asset, under the operator role named in the procedure. Verification should confirm that the method ran as intended, for example by checking the tool's completion output, a read-back test on a sample, or a destruction witness log. Where destruction is used, record the destruction method and who witnessed it. The output is a sanitization record for each asset (or a destruction certificate from the vendor or internal destruction log) showing the asset identifier, method, date, operator and verification result.
Record chain of custody through transfer
Track each asset from the point it leaves the CIP environment until it is reused, returned to a vendor, or destroyed. Log every handoff, including couriers, recycling contractors and third-party destruction firms, with names, dates and signatures or electronic acknowledgments. If a third party performs the work, obtain its written records and confirm what it commits to in its contract. The output is a custody log that links each asset identifier to every holder and location change.
Reconcile the inventory against the physical record
Close the loop in the asset inventory. Mark each retired asset with its final status (reused outside the CIP environment after sanitization, or disposed of), attach the sanitization record or destruction evidence, and confirm that no BCSI-bearing asset remains active without a documented disposition. Compare the closed list against the original request and the custody log to find gaps. The output is an updated inventory with every line closed, plus a short exceptions list, if any, with an owner and a resolution date.
Close the record and retain the evidence
Assemble one closed record per request: the scoped asset list, the approved gate, the per-media procedure, sanitization or destruction evidence, the custody log and the reconciled inventory entries. Confirm the retention period and storage location with your compliance lead, and make sure the record is retrievable by asset identifier for an audit request. The output is a complete, indexed record that lets an assessor trace a single Cyber Asset from retirement request to closure without relying on interviews.
What meeting R2 costs in tooling, labor and upkeep
Sanitization tooling is the first cost component to scope. R2 Part 2.1 requires action to prevent unauthorized retrieval of BCSI from data storage media before a Cyber Asset is released for reuse outside the applicable systems, so the entity must decide which method it will use for each media type. Software-based overwriting, cryptographic erase on self-encrypting drives and degaussing or shredding each carry different tooling needs and different costs. Software tools are typically a one-time procurement or an open-source deployment, while hardware such as drive erasers or shredders is a capital purchase with its own maintenance.
- Software erasure licenses: Commercial erasure products may charge per device or per seat, and open-source options may carry no license fee but still need configuration and validation effort.
- Hardware purchases: Degaussers, shredders and drive erasers are one-time capital items, though they add calibration, service contracts and storage space.
- Cryptographic erase setup: Using encryption-based erasure requires confirming that drives support it and that keys are destroyed on each retirement, which adds engineering time up front.
- Validation testing: Confirming that a chosen method actually prevents retrieval is a one-time test effort that should be repeated when methods or drive models change.
- Media mix: Each additional media type usually means another method and another validation run, so heterogeneous fleets cost more to cover.
Ask for a written list of tools, licenses and hardware, with the method assigned to each media type and the validation evidence produced for it.
Labor per retirement event is the recurring cost that most often surprises teams. Each time applicable Cyber Assets are reused or disposed of, someone must identify which assets contain BCSI, run the chosen action, record the result and link it to the asset record. Engineering time goes into scripting or configuring the process, while operations time goes into executing it, handling exceptions such as drives that fail to erase, and tracking chain of custody. Effort scales with how many retirement events occur and how many assets each event includes, so it is rarely a fixed amount.
- Identification effort: Staff must determine whether each asset ever held BCSI, which is simpler when inventory records already tie assets to BCSI storage locations.
- Execution time: Running erasure or destruction for each asset includes handling media, verifying completion and resolving failures.
- Exception handling: Assets that fail erasure need a defined path, such as re-running the process or destruction, and that path takes additional time.
- Records and chain of custody: Documenting who handled each asset and when adds recurring administrative work.
- Event frequency: Teams that retire assets in small, frequent batches often spend more total effort than teams that batch retirements, although batching can delay release of equipment.
Ask the provider or internal team to estimate hours per retirement event for each media type, based on their own asset counts, and to state whether that estimate includes exception handling.
Some entities send media for physical destruction or rely on a third party to dispose of hardware. Under Part 2.2, disposal of applicable Cyber Assets that contain BCSI requires either preventing retrieval from the asset or destroying the data storage media, so an outside destruction service is a common option. Cloud and vendor-hosted BCSI adds a different question: when storage is held by a provider, the entity must confirm that deletion occurs and can be evidenced, which usually involves contractual terms and provider reports rather than hands-on work.
- Destruction services: Costs are typically per unit, per pickup or per volume, and depend on the media type and whether the provider issues a certificate of destruction.
- Onsite versus offsite destruction: Onsite shredding may reduce transport risk but requires equipment and staff, while offsite services shift that work to the provider.
- Cloud deletion verification: Confirming deletion from provider storage may require contract clauses, provider attestations or deletion logs, which should be negotiated before the service is used.
- Vendor retention practices: Where a vendor holds backups or replicas, the entity should ask how those copies are removed and how long removal takes.
- Documentation requirements: Certificates and logs need to be retained as evidence, so the storage and review of those records is an ongoing task.
Request the destruction service's written scope, its certificate format and its handling of media in transit, and confirm whether cloud deletion statements are provided per request or only on a schedule.
Evidence upkeep is the recurring cost that continues after the process runs. Entities need to keep records that show which assets were reused or disposed of, what action was taken, and the result, and they need to keep those records in a form an auditor can sample. Compliance Audits and Spot Checks may select a subset of retirement events and ask for proof, so the effort to pull and explain those records is part of the total cost. Auditor sampling effort depends on how many events exist and how cleanly they are documented, and the Regional Entity sets its audit schedule, so the entity should not assume a fixed interval.
- Record retention: Retirement records, certificates and tool logs need a retention plan that matches the evidence period set by the Compliance Enforcement Authority.
- Traceability: Linking each asset ID to its retirement record, method and outcome reduces the time needed to answer sample requests.
- Periodic review: Reviewing the process and tool output at a set cadence adds recurring effort but catches gaps before an audit.
- Sampling burden: Larger event populations and inconsistent records increase the number of items an auditor may ask about and the time spent explaining them.
- Change management: Method changes, new media types and new vendors each require updated procedures and evidence.
Ask how the provider or internal team will structure records for sampling, and what effort is included for responding to an auditor's request.
Evidence that passes an R2 audit and how to keep it current
An auditor testing CIP-011-3 R2 looks for a chain of records that starts with a documented procedure and ends with proof that BCSI could not be recovered from a Cyber Asset that left the CIP environment. Each card below is one artifact in that chain, with the routine that keeps it usable between audits.
Documented reuse and disposal procedure
This is the written method your organization follows before any applicable Cyber Asset is released for reuse or disposed of. It should name the sanitization or destruction method for each media type, the roles that approve and perform the step, and how exceptions are handled. Review it on a set schedule and after any change to asset types or disposal vendors, and record each revision with a date and approver so the auditor can see which version applied to a given disposal.
Asset retirement tickets
A retirement ticket links one Cyber Asset to its disposal or reuse decision, the BCSI it held, and the person who authorized the release. Open the ticket before the device leaves the CIP environment, not after. Check that tickets exist for every asset that left the environment in the audit period, and compare the count against your asset inventory rather than against memory.
Sanitization and destruction logs
These logs record what was done to the data storage media: the method, the tool or service used, the device identifier, the operator, and the completion time. A log that says only "wiped" will not show an auditor that BCSI was addressed. Keep the tool version and the exact procedure used, and record exceptions, such as a drive that failed a wipe and was physically destroyed instead.
Verification records
Verification shows the sanitization worked. Typical records include a post-wipe scan, a sample read attempt, or a report from the wiping tool confirming zero or overwritten blocks. Confirm that the method you chose is defensible for your media, and ask your vendor or tool documentation what verification output it produces. Store the output with the retirement ticket so the two can be matched.
Vendor certificates of destruction
When a third party destroys media or performs sanitization, the certificate is your evidence that the work happened. It should identify the devices or serial numbers, the date, the method, and the vendor's signatory. Your contract with the vendor should require these certificates and set how long the vendor keeps its own records. An auditor will ask whether you reviewed the certificate, so note who checked it and when.
Chain-of-custody and inventory reconciliation
Chain-of-custody forms track each device from removal to destruction or release, showing every handoff. Inventory reconciliation then checks the asset register against those forms and the retirement tickets, so no device disappears between systems. Asset inventory tools such as GLPI and Wazuh Syscollector can help track hardware and assets, but they do not prove sanitization, so use them as the list you reconcile against. Run the reconciliation on a schedule and before each audit window.
Open-source tools that support asset inventory and retirement records
This table compares four open-source platforms by the evidence each can help produce for CIP-011-3 R2, namely asset inventory tie-out and protection of BCSI on systems you keep. Read each row as a supporting record, since none of these tools erases media, and the disposal decision and its proof still come from your own sanitization or destruction process.
| Platform | Role in R2 evidence | What it cannot show | License caveat |
|---|---|---|---|
| GLPI (Assets module) | Asset records for computers, software, network equipment and other assets, entered manually or pushed by the GLPI Agent, with native inventory built in since version 10. Useful for tying retired assets to disposal or reuse tickets. | Whether data on a drive was sanitized or destroyed. Inventory alone does not prove BCSI removal. | GPL-3.0-or-later. Confirm the license terms that apply to your deployment and any modules you add. |
| Wazuh (Syscollector) | Collects hardware, OS, installed software, network interfaces, services and users from each endpoint into the Wazuh indexer, giving dated inventory views that can show a Cyber Asset was decommissioned or removed from the network. | Contents of storage media or whether a reused asset was wiped. Syscollector reports what is running, not what was erased. | GPL-2.0-only. Confirm license obligations with your legal team before distributing modified builds. |
| Nextcloud (server-side encryption) | Encrypts file contents at rest on local and external storage with keys kept on the server, which supports protection of BCSI stored in the platform while it is held. | File names and folder structure are not encrypted, so BCSI-sensitive names may remain visible. Does not sanitize storage after deletion. | AGPL-3.0-only. Confirm network-use obligations that apply if users access the service remotely. |
| OpenBao (transit secrets engine) | Encrypts and decrypts application data without storing it, supports versioned keys and key rotation, so BCSI encrypted with managed keys can be made unreadable by retiring keys. | Erasure of ciphertext already stored elsewhere. Key destruction must be evidenced separately, and the tool does not wipe media. | MPL-2.0. Confirm the license terms that apply to your version and any commercial add-ons. |
Who owns R2 and what an implementation partner can take on
The registered entity owns CIP-011-3 R2. It decides how each Cyber Asset that holds BES Cyber System Information (BCSI) is classified before reuse or disposal, which method is acceptable for each asset type, and who signs off on each release. Those decisions belong to the entity's CIP Senior Manager or delegate and to the people accountable for the procedure, not to an outside firm. The entity also decides whether a Cyber Asset is reused within another applicable system, which changes whether Part 2.1 applies.
- Procedure ownership: Approve the written reuse and disposal procedure and keep it current with the asset lifecycle.
- Method selection: Choose clearing, purging or destruction for each media type, based on the risk and the asset's history.
- Release authority: Record who approves each asset's release for reuse or disposal.
- Evidence retention: Keep the records an auditor will request for the audit period.
- Vendor accountability: Stay responsible for any destruction service the entity hires.
Before relying on any partner's output, confirm that your internal approvers have reviewed and accepted the method for each asset class.
An implementation partner can build the mechanics that make R2 repeatable. In a self-hosted environment, DeployOpen can help configure an asset inventory, define retirement workflows and capture evidence for each step. The partner prepares the systems and records. It does not decide whether a method is adequate, and it does not certify that the entity is compliant. Scope is set in writing before work starts.
- Inventory configuration: Set up asset records in GLPI so each applicable Cyber Asset has an owner, location and status, with inventory pushed by the GLPI Agent where suitable.
- Retirement workflow: Build a ticketed process that moves an asset from in-service to pending reuse or disposal, with required approval fields.
- Host inventory data: Use Wazuh Syscollector output to confirm the software and hardware recorded for each endpoint before it is retired.
- Evidence capture: Store completion records, destruction certificates and sign-offs in a controlled repository.
- Physical destruction coordination: Where the entity uses an external destruction vendor, the partner can help track chain of custody records, though the vendor's own process must be verified.
Ask for a written list of exactly which systems the partner will touch and which deliverables it will hand over.
The independent auditor tests whether the entity's R2 controls work as described. Compliance is monitored by the Compliance Enforcement Authority, typically a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications and other monitoring. There is no CIP certificate. Auditors request evidence, sample retired assets, compare records against the procedure and report findings. Neither a partner nor DeployOpen issues audit reports or certifications.
- Sampling: Select retired or reused assets and trace each one back to its approval and method record.
- Method verification: Check that the recorded method matches the documented procedure for that media type.
- Gap identification: Report any asset where the record is missing, inconsistent or incomplete.
- Timing checks: Confirm that action was taken before release or disposal, not afterward.
- Findings: Issue findings to the entity, which then responds through its own process.
Before an audit, ask your Regional Entity which evidence format it expects and how far back the audit period reaches.
Where R2 programs usually fail and how to close each gap
Most CIP-011-3 R2 failures are not missing procedures. They are gaps between the procedure and the systems it is supposed to cover: an asset that never reached the retirement step, a wipe that was never verified, or a copy of BCSI that sits in a backup nobody checked. The cards below cover the gaps we see most often and a practical fix for each.
No link from inventory to retirement
Reuse and disposal controls only work if the team knows which Cyber Assets hold BCSI and when they leave service. Many programs track hardware in one tool and retirement tickets in another, so a decommissioned server can drop out of view before anyone checks its storage. Tie each asset record to its BCSI status and require a retirement workflow step that cannot close until the media treatment is recorded. Use GLPI Assets or a Wazuh inventory export as the starting list, then reconcile it against change tickets each quarter. Confirm which asset attributes your tool can hold, since a BCSI flag may need a custom field.
Reliance on delete commands
Deleting files or running a quick format removes directory entries, not the underlying data, so BCSI can often be recovered with forensic tools. The standard asks for action that prevents unauthorized retrieval from the data storage media, which means your method must be chosen for the media type. Document a sanitization method per media class, such as cryptographic erase for self-encrypting drives or overwrite and verification for spinning disks, and confirm it against the media vendor's guidance. Keep the procedure in the CIP-011 evidence set, and test it on a sample device before relying on it.
Unverified vendor destruction claims
When a recycler or lessor collects drives, the entity still owns the outcome under R2. A certificate of destruction that names no serial numbers, no method and no date proves little about what happened to the media. Require the vendor's chain-of-custody record, asset-level serial reconciliation and the sanitization method in the contract, and sample a few returned devices against the paperwork. Ask whether the vendor's personnel are subject to background checks and where media is held before destruction. Your procurement file should show who verified each claim and when.
Cloud snapshots and backups left behind
A disposed virtual machine or retired storage volume often leaves BCSI in snapshots, replicated copies, backup sets or object storage versions that no one listed. These copies can outlive the asset by months if retention policies are long. Before disposal, enumerate every snapshot, replica and backup that references the asset, then delete or sanitize each one and record the outcome. Check provider retention settings and key deletion timing, and where encryption keys are destroyed, record that step too. The sibling page on cloud services covers provider-side disposal in more depth.
Forgotten removable media
USB drives, optical discs, portable drives and other Removable Media used with BES Cyber Systems are small, unlabeled and easy to misplace, so they often escape the reuse and disposal process entirely. Their storage media may hold BCSI from maintenance or file transfers long after the originating task ended. Include removable media in the asset inventory, assign each device an owner, and require sanitization or destruction when a project closes. Storage cabinets, lab benches and vendor laptops are common places where these devices are found during audits. Spot checks of these locations are a cheap way to test the control.
Missing records for warranty returns
Equipment returned to a manufacturer under warranty can leave the entity's control with BCSI still on its storage. Replacements often arrive before the defective unit is collected, so the record of what left and what came back is easy to lose. Treat every warranty return as a disposal event: sanitize the media before shipment where the vendor's process allows it, or document why the device was not sanitized and what compensating control applies. Keep the return authorization, shipping record and replacement serial number together. Ask the vendor how it handles returned drives and whether it will certify their destruction.
How much work, time and outside help does R2 need?
How much effort does CIP-011-3 R2 take to meet day to day?
Most of the effort is in the retirement workflow itself, not in the standard's wording. R2 has no fixed frequency. It applies each time an applicable Cyber Asset that holds BES Cyber System Information (BCSI) is reused outside the CIP environment or disposed of. Effort therefore depends on how many assets are retired each year, how many storage media types they contain, and whether each retirement leaves a record. A utility that retires a handful of workstations a year carries a small recurring load. An entity with frequent hardware refresh, many removable media or cloud-hosted BCSI carries more. Ask your team to count retirements over the last two or three years before estimating.
How long does it take to build a retirement workflow?
The duration depends on the number of asset classes, the sanitization methods you choose and how many systems must feed the record. The work usually breaks into four parts: confirming which assets hold BCSI, defining the reuse and disposal steps for each media type, assigning owners and approvals, and testing the process on a real retirement. No supplied timeline applies to your environment, so treat any duration in a proposal as an estimate to test against your own asset list. Ask the partner to show which steps depend on your procurement, IT and physical disposal vendors, because those dependencies often set the schedule.
Can we run CIP-011-3 R2 in-house without a consultant?
Yes, many registered entities run R2 with internal staff. The organization owns its controls, and the standard places the obligation on the entity, not on any outside firm. In-house teams are usually strongest on asset inventory and disposal logistics and weakest on evidence design and auditor expectations. Outside help makes sense when your staff lack capacity for the first build, when the asset inventory is incomplete, or when you want an independent review before a Regional Entity audit. An implementation partner can prepare systems and records, but only the Compliance Enforcement Authority assesses compliance.
What should we ask a partner to include in a fixed-scope quote?
A fixed-scope quote should state exactly what is delivered and what is excluded. Ask for:
- The list of Cyber Asset types and storage media in scope, with the reuse and disposal method for each
- Which systems and records will hold the evidence, and how they are retained
- Who approves a retirement, who performs it and who signs the record
- Whether testing, staff training and a dry run on a real retirement are included
- The handover format for the procedure and the evidence templates
- What the partner needs from you, such as access to asset data and named owners
- Whether ongoing support is a separate retainer
DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the written scope is what drives the quote.
How does R2 relate to CIP-011-3 R1 evidence?
R1 covers how you identify BCSI and protect it while it is stored and handled. R2 covers the moment a Cyber Asset that holds BCSI leaves the CIP environment through reuse or disposal. The two share an inventory. The R1 record of where BCSI lives, including off-premise storage, tells you which assets need an R2 step before release. If your R1 inventory is incomplete, your R2 workflow will miss assets. Build the two together so that one asset list drives both programs. Confirm the exact evidence expected for each part with the standard and your Regional Entity.
Which parts of R2 can an outside partner take on?
A partner can usually help with the work that produces evidence, such as mapping storage in scope, drafting the disposal and reuse procedure, configuring tools that record sanitization and inventory changes, and preparing records for audit. Work that stays with your organization includes accepting the risk of each method, approving individual retirements, and deciding how physical media are handled by vendors. Compliance responsibility does not transfer to a partner. Ask which tasks will be performed by partner staff, which by your team and which by a third-party disposal provider, and put that split in the scope.
What recurring work keeps R2 working after the first build?
After the initial build, recurring work is mostly operational. Each retirement needs the documented step completed and recorded. Inventory must be kept current, because a missed asset is a missed retirement. The procedure should be reviewed when hardware types, vendors or cloud storage change. Staff who retire assets need refresher instruction, and the evidence must be retained for the period your compliance program sets. Ask any partner whether ongoing review and upgrades are included or offered as a separate retainer, and confirm the retention period with your compliance lead.
