What CIP-010-4 R4 asks for when laptops and USB media touch BES Cyber Systems
CIP-010-4 R4 requires a documented plan for every laptop, test set and USB drive that connects to a high or medium impact BES Cyber System or its associated Protected Cyber Assets. A technician who plugs a maintenance laptop into a control system, or copies a vendor patch onto a thumb drive, is exactly the event this requirement governs. The entity must implement one or more plans that cover the sections in Attachment 1, and the only stated exception is CIP Exceptional Circumstances. Low impact systems are not in scope of this requirement, so the first decision is confirming the impact rating from CIP-002 for every target system the plan will touch. The risk is simple to describe and hard to control. A device that moves between an office network, a vendor site and an isolated control network can carry malicious code, out-of-date operating systems or unapproved software into the environment, and it can also be used by someone who should not have access. Temporary connections are hard to govern because they happen quickly, often outside change windows, and the device may never appear in the asset inventory. Many organizations discover their Transient Cyber Assets only after an incident, so the plan has to make these devices visible before they connect.
Attachment 1 divides the work into three paths. Section 1 covers entity-managed Transient Cyber Assets, where the entity must manage them, authorize users, locations and uses, and mitigate software vulnerabilities, malicious code and unauthorized use. Section 2 covers devices managed by another party, where the entity must review that party's patching and malicious code mitigation and add mitigation before connection if needed. Section 3 covers Removable Media, where the entity must authorize users and locations and detect malicious code on the media using a Cyber Asset that is not a BES Cyber System or PCA before the media connects. Confirm with your Compliance Enforcement Authority and your own legal team how they read these sections for contractor devices, since the distinction between entity-managed and third-party-managed drives the evidence you must keep. A practical first step is a written inventory of every laptop, test device and removable media type that has touched a control system in the last audit period, along with the person who authorized each use. Pair that inventory with an endpoint inventory tool. The GLPI Assets module can record computers and peripherals, and the Wazuh Syscollector module collects installed software and running services from endpoints, which helps show patch state at the time of connection. Confirm with the tool vendor which fields are retained and for how long, since your evidence period depends on it.
Which devices, media and teams fall under the R4 plan
The R4 plan applies only where CIP-002 categorization puts a high or medium impact BES Cyber System, so scoping decides everything that follows. Within that scope, the devices and media that touch these systems fall into three groups, and several teams handle them.
Systems that trigger the plan
R4 covers high and medium impact BES Cyber Systems and their associated Protected Cyber Assets. Low impact systems are not in the R4 scope, but the categorization record must be current before anyone decides that. Confirm the categorization list, the PCA associations and the date of the last CIP-002 review before drafting the plan's scope statement.
CIP-002 sets the boundary
CIP-002-5.1a uses bright-line criteria to rate each BES Cyber System high, medium or low impact. A laptop that connects to a high impact Control Center is in scope, while the same laptop used only at a low impact asset may fall outside R4. Re-run categorization whenever a system is added, retired or reconfigured, because a change in rating changes which devices the plan must cover.
Entity-managed Transient Cyber Assets
These are the organization's own laptops, test sets and diagnostic tools that connect temporarily to in-scope systems. Attachment 1 Section 1 expects an inventory of who may use them, where, and for what purpose, plus controls such as patching and malicious code protection. Check that each device has a named owner and that the inventory reflects devices that are actually used, not only those issued.
Third-party devices and vendor laptops
Contractor and vendor laptops are Transient Cyber Assets managed by another party. Attachment 1 Section 2 requires a review of that party's patching and malicious code mitigation before connection, plus any added mitigation the entity needs. Ask vendors for their patch status and anti-malware configuration in writing, and record the review before the first connection.
Removable Media and its checks
USB drives, optical discs and similar media fall under Attachment 1 Section 3. The plan must authorize users and locations and describe how malicious code is detected on the media using a system outside the BES Cyber System or PCA. Confirm that a scanning station exists, that it is not itself connected to the in-scope network, and that media are logged to a named user.
Teams that touch these devices
Operations, field engineering, IT, and vendors all handle these devices, and each group needs a clear role in the plan. Operations usually authorizes locations and uses, field engineering often connects test equipment, IT maintains patching and endpoint tools, and vendors bring their own laptops. Assign one owner for the plan, and confirm that each group knows the authorization and review steps before its next site visit.
How to build the R4 plan in six steps
This sequence takes an entity from an unknown population of laptops, test sets and USB media to a documented R4 plan that names each device class, its authorized users and locations, its mitigations, and the people who keep it current. Each step produces an artifact an auditor can read and test against Attachment 1.
Inventory every device class that connects
Start by listing each type of device that touches high or medium impact BES Cyber Systems or their associated PCA, including entity-owned laptops, vendor-owned diagnostic tools, engineering workstations and removable media such as USB drives. Include temporary connections made during commissioning, troubleshooting and firmware work, because these are the connections auditors most often find missing. Confirm the list with operations and field staff, not only with IT. The output is a device class register that names each class, who owns it, and which systems it reaches. The step is complete when someone outside the project can point to a device class and find its row.
Map each class to an Attachment 1 section
Sort the register into the three Attachment 1 paths: entity-managed Transient Cyber Assets under Section 1, Transient Cyber Assets managed by another party under Section 2, and Removable Media under Section 3. Some devices, such as a vendor laptop that the entity also manages, may need more than one path, so record the primary path and any secondary one. Draft the plan language for each section in terms the operators will recognize. The output is a short mapping table tied to the plan text. The step is complete when every device class has exactly one primary section and the plan text for that section is written.
Define authorization for users, locations and uses
For each entity-managed device class and for removable media, record who may use it, where it may connect and for what purpose. Attachment 1 requires authorization of users, locations and uses for these classes, so the authorization record must be specific enough to answer whether a given person could connect a given device to a given substation or control room on a given task. Decide how authorizations are granted, who approves them, and how they are withdrawn when a person changes role. The output is an authorization matrix with named approvers. The step is complete when a sample connection can be traced back to a documented authorization.
Select mitigations for each device class
Choose the mitigations that address software vulnerabilities, malicious code and unauthorized use for each class. The standard's examples include patching, read-only live operating systems, antivirus, application whitelisting, full-disk encryption and multi-factor authentication, but the entity chooses what fits each class and records why. A vendor-managed laptop under Section 2 may rely on the vendor's patching and malicious code controls, reviewed before connection, plus any additional mitigation the entity adds. Confirm each chosen control with the device owner and test that it works on a representative device. The output is a mitigation table per device class. The step is complete when each class has mitigations recorded, a stated rationale and a test result.
Set up malicious code detection for removable media
Section 3 requires a method to detect malicious code on removable media before it is connected to a BES Cyber System or PCA, using a Cyber Asset that is not itself a BES Cyber System or PCA. Build a scanning station or workflow on a separate system, document which tool and signature process it uses, and define the steps that hold media until it passes. Record the mitigation applied when malicious code is found. Tools for inventory and endpoint telemetry can support the record, but the scanning method itself must be defined and repeatable. The output is a documented scanning procedure and a log of scans. The step is complete when a test item is scanned, logged and released or quarantined as the procedure says.
Assign owners and set the review cadence
Name an accountable owner for the plan as a whole and an operational owner for each device class, then set how often the plan is reviewed and how changes to it are approved. Connect the R4 plan to the other CIP-010 activities, such as baseline and monitoring records, so that a reviewer can follow a device from authorization through to its monitored state. Agree the evidence each owner keeps, such as authorization logs, scan logs and mitigation records, and where it is stored. Confirm the review interval against the entity's own compliance calendar and any Regional Entity expectations. The output is an ownership table and a review record. The step is complete when each owner has signed up to their evidence duties and the first review date is on the calendar.
Open-source tools that can support R4 records and checks
Several self-hosted open-source tools can help an entity keep the asset records, software inventories and endpoint evidence that R4 work depends on. Each one covers a different part of the picture, so the set works together only when the entity decides which tool is the system of record for each item.
GLPI asset register
GLPI's Assets module holds computers, monitors, software, network equipment, peripherals and other devices. Entries can be typed in by hand or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. For R4, the register is a place to record which laptops and test equipment are entity-managed Transient Cyber Assets, their owners and authorized locations. Confirm that the register is kept current, since an unlisted device cannot be shown as authorized. GLPI is licensed under GPL-3.0-or-later.
osquery scheduled host queries
osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. Its osqueryd daemon can schedule the same queries across a fleet of hosts. For R4, scheduled queries can help show whether an entity-managed Transient Cyber Assets has unexpected processes or network connections before it reconnects to a high or medium impact system. Note that osquery reports state but does not decide whether a device is authorized. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only.
Wazuh Syscollector inventory
The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users, groups and Windows updates from each endpoint. It stores this data in the Wazuh indexer for inventory views and reports in the dashboard. For R4, this inventory can support patch and software-version evidence for entity-managed Transient Cyber Assets under Attachment 1 Section 1. Confirm that the agent runs on the devices you need to cover, since laptops that are powered off or never enrolled will not appear. Wazuh is licensed under GPL-2.0-only.
Velociraptor artifact hunts
Velociraptor collects forensic artifacts defined in VQL from endpoints. Its hunts collect one or more artifacts across a group of systems, schedule collection on offline machines when they reconnect, and create a notebook per hunt for analyzing combined results. For R4, a hunt can gather evidence from every device that connected to a Cyber Asset in scope during a window, which helps when an entity must show what a Transient Cyber Asset ran. Plan the artifact definitions with counsel and your security team before deployment. Velociraptor is licensed under AGPL-3.0-only.
How an auditor tests the R4 plan and its records
This table maps each likely auditor test step for CIP-010-4 R4 to what the auditor asks to see, the evidence requested and the findings that commonly follow. Use it to walk your records before an audit, and remember that the auditor chooses the sample and issues the findings.
| Test step | What the auditor asks to see | Evidence requested | Common findings |
|---|---|---|---|
| Confirm a documented plan exists | One or more documented Transient Cyber Asset and Removable Media plans that address each Attachment 1 section for high and medium impact BES Cyber Systems and associated PCA | Current plan documents with revision history, owner approval and a section-by-section cross reference to Attachment 1 | Plan omits one Attachment 1 section, covers only entity-managed devices or lacks an owner approval date |
| Sample entity-managed Transient Cyber Assets | Each sampled laptop or test device is managed under the plan, with ongoing or on-demand management and the vulnerability mitigations the plan names | Asset inventory entries, patch or update records, malicious code protection status and encryption or MFA settings for the sampled devices | Inventory missing devices that have connected, or mitigations listed in the plan that are not applied on the device |
| Check authorization for users, locations and uses | Named users, authorized locations and permitted uses for each device and each media item, approved before use | Authorization records, access lists or ticket approvals showing who, where and for what purpose | Authorizations are generic or undated, or actual connection locations and uses fall outside what was approved |
| Review third-party devices before connection | Evidence that the owning party's patching and malicious code mitigation was reviewed, plus any added mitigation, before the device first connected | Pre-connection review records, vendor attestations or screenshots of the other party's controls, and mitigation tickets | Review happens after connection, or the review does not address the device's current patch and malicious code status |
| Check removable media malicious code detection | A documented method to detect malicious code on each media item, run on a Cyber Asset that is not a BES Cyber System or PCA, with mitigation before connection | Scan logs or reports from the scanning host, media identifiers, and records showing findings were resolved before the media was used | Scanning runs on an in-scope system, scan records do not tie to a specific media item, or detected items are connected anyway |
| Compare logs or tickets to connection events | That each connection event on high or medium impact systems traces back to an authorized device or media item, a documented location and a permitted use | Connection or endpoint logs from in-scope systems, matched against tickets, authorization records and the device or media inventory | Connection events with no matching authorization, or tickets that were closed without a recorded connection |
| Verify the plan is followed in practice | That staff follow the plan as written, including exceptions handled under CIP Exceptional Circumstances | Training or acknowledgment records, exception logs and any incident reports tied to Transient Cyber Assets or Removable Media | Practice differs from the written plan, or exceptions are used without a documented basis |
Which evidence passes R4 and how to keep it current
An auditor testing CIP-010-4 R4 looks for a documented plan, and then for records showing that each connection of a Transient Cyber Asset or Removable Media followed that plan. The cards below cover the artifacts that carry that proof, and the routine that keeps each one current between audits so the evidence does not need to be rebuilt before a Compliance Audit.
Approved plan and version history
The plan is the anchor record. Keep one approved document per TCA and removable media approach, with an owner, an approval date and a revision log that shows which Attachment 1 section each change touched. Review it on a fixed internal schedule and after any change to tooling, such as a new scanning method or a new contractor laptop model. Confirm with your Compliance Enforcement Authority how they expect version history to be presented, since the format is not set by the standard.
Device register for entity-managed TCAs
Maintain a register of every entity-managed laptop, test set and portable tool that can connect to high or medium impact systems. Each entry should record the asset owner, the assigned use, the mitigations applied and the last verification date. Inventory tools can populate this register automatically, but someone must reconcile it against physical custody. A device that appears on the network without a register entry is the gap auditors most often find.
User and location authorization lists
Attachment 1 requires authorization of users and locations for the connection of TCAs and removable media. Keep dated lists that name who may connect what, where and for which purpose, and tie each entry to a role or training record. Review the lists on a set cadence and when staff change roles or leave. Remove access promptly so that the list an auditor sees matches who could actually plug in on the audit date.
Mitigation configuration and pre-connection check records
For each TCA, keep records showing that patching, malicious code protection and the other mitigations chosen in the plan were in place before connection. Exported configuration snapshots, patch reports and antivirus status are typical evidence. For vendor-managed devices under Section 2, keep the review of the other party's patching and malicious code practices, plus any added mitigation applied before connection. Confirm which mitigations your plan selects, because the evidence must match the plan's own commitments.
Removable media scan and custody logs
Section 3 requires a method to detect malicious code on removable media, using a Cyber Asset that is not a BES Cyber System or PCA, and mitigation before connection. Log each media item with its identifier, the authorized user, the scan date, the scanning station, the result and the destination system. Custody logs show who held the media between scan and use. Test the logging with a sample media item before an audit so that gaps surface early.
Exception records under CIP Exceptional Circumstances
Where R4 is not followed because of CIP Exceptional Circumstances, the record of the exception is evidence in its own right. Document the circumstance, the date and time, the people involved, the compensating steps taken and the closing action. Keep these records with the plan rather than in a separate incident folder, so that a reviewer can see the deviation alongside the control it touched. Ask your compliance lead how your region defines the boundary of an exceptional circumstance before you rely on one.
What meeting CIP-010-4 R4 costs in money and effort
This table breaks the cost of an R4 plan into components, showing who is paid, whether each cost is one-time or recurring, what moves it, and what to request in a quote. No prices or durations are published here, so use the questions in the final column to compare written quotes on equal terms.
| Cost component | Who is paid | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|---|
| Tooling and licenses | Software vendors or subscription providers | Recurring license or subscription fees; one-time setup | Number of Transient Cyber Assets, edition limits, and whether a platform is commercial or open source. Self-hosted open-source tools such as osquery, Velociraptor, GLPI and Wazuh can remove license spend but still need hosting, upgrades and support staff. | Itemized license terms, edition limits, support tiers, and an estimate of hosting and administration hours if self-hosted |
| Engineering time for mitigations and configuration | Internal staff or an implementation partner | One-time build; recurring upkeep when mitigations change | Number of device types, how many mitigations per device (patching, read-only operating systems, antivirus, encryption, multi-factor authentication), and how much the existing estate already meets | Named tasks, role mix, hours per task, and which mitigations are included in fixed scope |
| Device register and authorization upkeep | Internal staff, sometimes with an inventory tool provider | Recurring | Turnover of contractor laptops and test equipment, number of authorized users and locations, and whether the inventory is automated | Whether inventory is automated, how authorization records are kept, and who reviews them |
| Third-party device review | Internal staff, the device owner, or a reviewing party | Recurring per device or per engagement | Number of contractor or vendor devices, how much of the vendor's patching and malicious code mitigation can be verified, and whether vendors accept additional mitigation before connection | Review checklist, who performs it, how long approvals take, and what is charged per device or per vendor |
| Removable media scanning workstations | Internal IT, or hardware and software vendors | One-time hardware and setup; recurring maintenance and signature updates | Number of scanning stations, whether a non-BES Cyber System machine is dedicated, and the scanning method chosen | Hardware specification, malicious code detection method, update cadence, and isolation approach |
| External review or testing | Independent security testers or consultants | Usually one-time per scope, repeated when controls change | Scope of the review (sample of devices or whole program), testing depth, and whether testing is fixed scope or a retainer | Written scope, deliverables, retest terms, and the testing method applied to Transient Cyber Assets |
| Auditor sampling and evidence preparation | Regional Entity auditors (not paid by the entity for a compliance finding), and internal staff for evidence | Recurring on the audit cycle set by the Regional Entity | Size of the device population sampled, how well records are kept, and how quickly evidence can be produced | Evidence checklist that maps each R4 element to a record, retention period, and owner |
Who owns the R4 plan, what a partner does, and where the auditor stops
Your organization owns the CIP-010-4 R4 plan and every decision inside it. Your compliance and operations staff decide which Transient Cyber Assets and Removable Media may connect to high and medium impact BES Cyber Systems, who may use them, where, and for what purpose. Those decisions are the substance of the plan, and an auditor will ask who made them, when, and on what basis. Your team also keeps the signed records that show the plan was approved and followed.
- Plan ownership: Approve the documented plan or plans, assign a named owner, and review them when systems, vendors or tools change.
- Authorization decisions: Decide which laptops, test equipment and USB media are authorized, for which users, locations and uses, and record each decision.
- Device and third-party decisions: Accept or reject vendor-managed devices after reviewing their patching and malicious code mitigation.
- Records and sign-off: Keep the entity's own approval of the register and evidence, with dates and accountable names.
- Exception handling: Document any use under CIP Exceptional Circumstances and who authorized it.
Before engaging any partner, confirm internally who holds each of these decisions and whether that person can sign for the entity.
An implementation partner helps you build the controls and the evidence that supports the plan. DeployOpen, for example, plans, configures and documents open-source tools inside your own infrastructure, but it does not make your authorization decisions, approve the plan, or certify compliance. Work is normally fixed in scope and written down before it starts, so you can see exactly which systems and records are covered.
- Scoping and tooling: Define the asset boundary, then deploy and configure inventory and monitoring tools in your environment.
- Register and evidence preparation: Build the register of Transient Cyber Assets and Removable Media from inventory data, and assemble the records your team reviews.
- Mitigation testing: Test patching, malicious code detection and read-only or encrypted configurations on sample devices, and report the results.
- Procedures: Draft operating procedures for connecting and scanning media, for your team to review and adopt.
- Mock audits: Walk through evidence against the Attachment 1 sections before an external review, then document gaps for your team to close.
Common items to outsource are tool deployment, evidence preparation and mock audits. Ask any partner to state in writing which steps it will not perform.
The Compliance Enforcement Authority, a Regional Entity or NERC, monitors CIP compliance through audits, spot checks, self-certifications and other mechanisms. Under the NERC Rules of Procedure, these reviews test whether the entity's controls operated and left evidence. The auditor samples devices, media and records, then reports findings. It does not design the plan, choose the tools, or run the controls it tests, because that would remove the independence the review depends on.
- Sampling: The auditor selects devices, connection events and media from your records and asks for supporting evidence.
- Testing: It checks that authorizations existed before use, that mitigations were applied, and that malicious code detection happened before connection.
- Findings: It records what met and did not meet the requirement, and the entity responds through its own mitigation process.
- Limits: The auditor will not accept a partner's assurance in place of the entity's records.
- Timing: Audit timing and the evidence period are set by the Regional Entity, so confirm these with your registration contact.
Confirm with your Regional Entity which evidence formats it expects and how it treats records produced by outside parties.
Where R4 programs usually fall short and how to close each gap
Most R4 findings come from a plan that exists on paper but does not match what happens at the substation, control room or maintenance bench. The cards below pair each common gap with steps an owner can assign, so the documented plan, the device register and the connection records tell the same story.
Vendor laptops with no documented review
Contractors often bring laptops to plug into a relay or historian port, and the plan may say nothing about them. Under Attachment 1 Section 2, the review of the third party's patching and malicious code mitigation has to happen before connection. Assign the operations lead to collect a written statement of the vendor's patch level and anti-malware status for each visiting party, store it with the access request, and require any added mitigation, such as a scan on an entity-managed kiosk, before the device touches a high or medium impact system.
USB media with no detection method
Removable Media under Attachment 1 Section 3 needs a named method to detect malicious code, and that method must run on a Cyber Asset other than a BES Cyber System or PCA. Many programs list authorized users but never say where the scan happens. Assign one station-side workstation as the scanning host, document the scanning tool and its update routine, and keep a log entry for each media item showing the scan result before it is used on the protected network.
Plans that list devices but not authorizations
A plan that names a laptop model or a flash drive brand does not show who may use the device, where it may go, or for what task. Attachment 1 expects authorization of users, locations and uses, so the register needs those three fields for each entry. Assign the CIP senior manager's delegate to review the register against the access list each quarter and remove any device whose authorized use no longer matches its role.
No record of mitigation state at connection
Auditors often ask what the mitigation state was on the day a device connected, and a register updated later cannot answer that. Attachment 1 covers patching, malicious code protection, encryption and multi-factor authentication for entity-managed devices, so the connection record should capture those states at the moment of use. Assign the field technician to log the device ID, date, user, location, patch level, anti-malware version and encryption status in a form that is completed before the cable is connected.
A register that drifts from reality
Transient devices get reassigned, retired or lent to another site, and the register stays unchanged. Inventory tools can reduce this drift by collecting hardware and software facts from enrolled endpoints, though the entity must confirm each tool covers the devices it is meant to track. Assign the asset owner to reconcile the register against the inventory export every month and to record each addition, reassignment and disposal with a date and an owner.
Exceptions used without records
CIP Exceptional Circumstances can allow a plan to be set aside, but an exception used without a record is hard to defend. The plan should say who may declare an exception, what it covers, and how it is documented and closed. Assign the CIP senior manager to approve each exception in writing, set a closure date, and keep the record with the connection log so that the reason, the scope and the follow-up can all be shown to the Compliance Enforcement Authority.
How much effort R4 takes and whether to do it in-house
How much effort does CIP-010-4 R4 take to run day to day?
The ongoing effort depends on how many Transient Cyber Assets (TCAs) and Removable Media your personnel connect to high and medium impact BES Cyber Systems, and how often they do it. R4 requires one or more documented plans, so the recurring work is authorizing users, locations and uses, checking each device's patch and malicious code status before connection, scanning removable media, and keeping the records current. Most of the cost sits in those repeated connection checks rather than in writing the plan once. Ask any provider to estimate effort from your actual device counts and connection pattern, and to separate the one-time plan build from the recurring operating work.
What drives how long it takes to stand up an R4 program?
Stand-up time is driven by the state of your starting point, not by a fixed duration. The main drivers are how many TCA and removable media types exist, whether you already have an asset inventory, how many third-party devices must be reviewed, how many teams need to adopt the plan, and how much tooling must be installed and tested inside your own networks. Entities with a current inventory and an established change process generally have less to build. Request a written schedule in any engagement that breaks out inventory, plan drafting, tool deployment, staff training and evidence dry runs.
Can a small team run CIP-010-4 R4 on its own?
A small team can run R4 alone if its device population is limited and its connection process is simple, but it must still cover every Attachment 1 section that applies. The team needs one person who can authorize devices and users, one person who can verify patching and malicious code status, and a backup for each role so that approvals do not stop when someone is away. Small teams often struggle with after-hours connections, vendor visits and emergency work, which is where a documented exceptions path and clear records matter most. Assess whether your team has the time to review each connection, not only whether it can write the procedure.
What does the entity need to supply for R4 to work?
The entity must supply the people and decisions that no outside party can make on its behalf. In practice that means:
- Device owners who keep their laptops, test equipment and media current and report when they connect them
- A change authority who approves which users, locations and uses are permitted
- A register owner who maintains the list of authorized TCAs and Removable Media and reviews it on a set schedule
- A security owner who accepts mitigation methods and decides when a device may not connect
The organization owns its controls. An implementation partner can prepare the workflow, tooling and evidence, but the entity's own staff must make and document these decisions.
Can open-source tools produce the records R4 needs?
Open-source tools can produce much of the supporting evidence for R4, particularly the inventory and the malicious code checks, but they do not replace the documented plan or the approval decisions. GLPI's Assets module can hold a register of computers, peripherals and other equipment, including entries pushed by its agent. Wazuh's Syscollector can record installed software and system state for endpoints it monitors, and osquery can query running processes and file hashes across hosts. Velociraptor can collect artifacts from endpoints, including offline machines when they reconnect. Confirm each tool's license terms and whether its coverage matches the devices in scope, and confirm with your compliance team what the auditor will accept as a record.
How should third-party devices be handled under R4?
Third-party devices are covered by Attachment 1 Section 2, which applies to Transient Cyber Assets managed by another party. The entity must review the other party's patching and malicious code mitigation and apply any additional mitigation before the device connects. In practice, this means setting a written intake step for vendor laptops and test equipment, requesting the vendor's patch and malware status before each visit, and deciding in advance which mitigations are acceptable. Ask vendors to confirm their controls in writing and keep those confirmations with the connection record. Vendor-related contract terms are usually handled alongside CIP-013 procurement.
What will the auditor ask first about R4?
Auditors typically begin by asking for the documented R4 plan and then ask you to show that it is applied, with records for specific connections. Expect requests to see your list of in-scope high and medium impact systems, the authorization records for TCAs and Removable Media, the patch and malicious code evidence for a sample of connections, and the method used to scan removable media. Compliance is monitored by the Compliance Enforcement Authority through audits, spot checks and self-certifications, and there is no certificate issued. Ask your compliance lead to walk through a sample connection from start to finish before any engagement begins.
How DeployOpen works on this
DeployOpen approaches CIP-010-4 R4 as a set of documented plans and working controls that your team owns, built inside your own infrastructure. We prepare the systems, procedures and evidence for Transient Cyber Assets and Removable Media, while your CIP Senior Manager and compliance team retain responsibility for the program and any audit outcome.
How we scope
- Confirm which high and medium impact BES Cyber Systems and associated PCA the R4 plan covers, based on your CIP-002 categorization.
- Inventory every laptop, test set and USB device that connects to in-scope systems, separating entity-managed, third-party and removable media.
- Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope and priced from that scope.
How we build
- Configure open-source asset inventory and endpoint query tools to record Transient Cyber Assets and their software, patch and malicious code status.
- Set up authorization records for users, locations and uses, with inventory data that supports the Attachment 1 Section 1 controls you select.
- Test the detection workflow for Removable Media on a non-BES Cyber System Cyber Asset, and confirm mitigation steps run before connection.
How we hand over
- Deliver the documented R4 plan sections for entity-managed, third-party and removable media, mapped to the Attachment 1 sections.
- Provide configuration, runbooks and sample evidence exports, such as inventory reports and scan results, with the dates they were generated.
- Document open items, owners and assumptions so your compliance team can review the evidence trail before any Regional Entity request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, if your team wants help keeping the plan current.
- Ask in the quote which tool licenses, editions and hosting costs are included, because those recur separately from the engagement fee.
- Confirm with your compliance lead and the Regional Entity how long evidence must be retained, since DeployOpen does not issue audit reports or certifications.
