CIP-007-6 R3 malicious code prevention requirements

What CIP-007-6 R3 malicious code prevention requires

If your organization is a registered entity with high or medium impact BES Cyber Systems, you need a malicious code control that covers those systems and their associated EACMS, PACS and PCA. CIP-007-6 R3 has three parts. Part 3.1 requires you to deploy methods to deter, detect or prevent malicious code. Part 3.2 requires you to mitigate the threat of any malicious code you detect. Part 3.3 applies where your chosen method relies on signatures or patterns, and requires a documented process to keep them current, including how updates are tested and installed. The standard does not name a product. Traditional antivirus, system hardening, application allowlisting and policy-based controls can all count, as long as you can show they run.

The reason this matters is practical. Malware that reaches a control system, a jump host or a workstation with a path into an Electronic Security Perimeter can disrupt operations or create a route to the systems that matter most. A control that is installed but silently stopped, or that reports nothing for months, leaves the same exposure as having no control at all. That is why the requirement is harder than it first looks. You choose the method, but the auditor tests whether the method ran as designed, on the systems in scope, over the audit period.

Start by listing every high and medium impact Applicable System, and for each one record the method in use, who owns it, and where its signatures or patterns come from if it uses them. Then confirm the evidence exists for each system: deployment records, update logs, alerts and the records of how each detection was handled. Ask your vendor or integrator to confirm in writing which parts of the method are automatic and which depend on a person. Also confirm which evidence the tool keeps and for how long, because gaps in that history are where audit findings usually come from.

Which systems and scoping decisions change the malicious code work

CIP-007-6 R3 applies to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, so the scope is set before any tool is chosen. The cards below cover the decisions that determine which systems carry the malicious code obligation and why one method rarely fits every system class.

CIP-002 sets the in-scope population

The starting point is the impact rating from CIP-002-5.1a. Only BES Cyber Systems rated high or medium impact fall under R3 at the system level, so a rating change can add or remove systems from this requirement. Confirm the current categorization list and its approval record before scoping R3 work. Re-check ratings whenever a system is added, reconfigured or retired, because the malicious code work follows the rating rather than the system's name or function.

Associated systems pulled in by design

R3 also reaches the Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets associated with those high and medium impact systems. Entities often scope the BES Cyber Systems themselves and miss the access servers, badge controllers and monitoring hosts that sit beside them. Build an inventory that traces each associated system back to the BES Cyber System it supports, and record the association so an assessor can follow it.

Protected Cyber Assets need their own check

Protected Cyber Assets are in scope when they are associated with applicable systems, even though they do not perform the core control function. Engineering workstations, historians and file transfer hosts are common examples to review. Ask whether each Protected Cyber Asset can run the chosen method, such as an agent or a signature engine, and whether it has the resources and network access that method needs. Document any system where the method cannot run and the compensating approach.

Vendor-supplied hosts and appliances

Many control system components arrive as vendor-managed appliances or hosts with restricted operating systems. The entity still owns the R3 obligation, so it must confirm what the vendor permits, such as whether an agent is supported, whether signatures can be pushed, or whether the vendor's update process is the only route. Ask vendors in writing for their supported malicious code methods and update procedures, and keep those answers with the evidence set.

Low impact assets fall under CIP-003

Low impact BES Cyber Systems are not covered by this requirement. Their controls come from the CIP-003 cyber security plan, which sets the expectations for those assets. Confirm the impact rating of each asset before deciding which standard governs it, and keep low impact assets out of the R3 evidence package unless they are also associated with a high or medium impact system. Mixed sites need a clear boundary so that the two control sets do not get confused in an audit.

One method does not fit every class

A method that works on a Windows engineering workstation, such as an endpoint agent with signature updates, may not run on a Linux relay, a protective device or a vendor appliance. Each system class needs its own method choice, justification and evidence source. Record the method per class, state why it suits that class, and identify the alternative used where the first choice is not feasible. Mismatched methods are a common source of gaps during review.

How an assessor tests malicious code prevention

This table compares what an assessor does for each part of CIP-007-6 R3 (deterring or detecting malicious code, mitigating detected code, and keeping signatures or patterns current), what records they ask for, and where entities typically fall short. Read each row as a test step, then check your own records against the evidence column before an audit notice arrives.

Test area	Test approach and evidence requested	Common findings
Part 3.1: Methods to deter, detect or prevent	Sample in-scope high and medium impact BES Cyber Systems and associated EACMS, PACS and PCA. Compare the documented method (antivirus, hardening or policy) against records showing it ran on each sampled asset during the audit period.	Method documented for one asset type but absent on others, or coverage records that show gaps for PCA and PACS hosts.
Part 3.2: Mitigation of detected malicious code	Review a set of detected events from the audit period and trace each to its mitigation ticket, showing containment, removal or other action taken and the date completed.	Detections logged with no ticket, tickets closed without stated action, or mitigation that cannot be tied to the specific asset.
Part 3.3: Signature or pattern update process	For methods that rely on signatures or patterns, confirm the documented update process and compare it to update records. Check that each sampled update shows testing before installation.	Update records present but no evidence of testing, or the process covers only the central console and not every in-scope device.
Process documentation	Confirm the written process names owners, the update frequency the entity chose, and how exceptions are approved and recorded. Ask whether the process matches what staff actually do.	Procedure written generically, last reviewed long ago, or describing a tool no longer in use.
Sampling scope	Assessors choose samples from the entity's asset lists. Keep an accurate, current list of in-scope Cyber Assets so the sample can be drawn from it without delay.	Asset inventory missing PCA or PACS, so some in-scope systems were never tested.
Detection source consistency	Compare detections across tools if more than one method is used, such as file integrity alerts and endpoint query results, to confirm events are captured and routed to the same review process.	Alerts from one tool never reach the review queue, leaving detected events without a mitigation record.
Evidence retention	Ask whether records for the full audit period are retained and retrievable in a form that can be exported on request.	Logs rotated out before the audit window closes, or records kept only on the analyst's workstation.

How to implement R3 in sequence

This sequence turns CIP-007-6 R3 from a policy statement into a working, documented malicious code program for each in-scope system class. Each step produces an artifact an auditor can trace from scope to method to mitigation to signature update.

Confirm in-scope systems from the CIP-002 categorization
Start from your CIP-002 categorization and list the BES Cyber Systems rated high or medium impact, along with their associated EACMS, PACS and Protected Cyber Assets. R3 applies to these high and medium impact systems and their associated assets, so low impact systems are outside this requirement. The operations or compliance lead owns this step, and the output is a system inventory that names each in-scope asset and the class it belongs to. Confirm the list with the CIP Senior Manager before moving on, because every later step depends on it.
Group in-scope assets into system classes
Group the inventory into classes that share an operating system, role and exposure, such as Windows workstations in a control room, Linux servers in a substation network or engineering laptops that connect to the BES Cyber System. Grouping keeps the method decision tractable and makes the evidence easier to sample. The output is a class register that maps each asset to exactly one class. Record any asset that cannot run an agent or signature-based tool, because those assets will need a different method in the next step.
Choose and document the method for each class
For each class, select a method to deter, detect or prevent malicious code. Part 3.1 accepts traditional antivirus, system hardening, policy or a combination, so document which one applies and why it fits the class. A class that cannot run signature-based software may rely on hardening, application allowlisting or access policy, and the rationale should say so plainly. The output is a method decision record per class, approved by the system owner and kept with the plan. Reviewers will look for the reasoning, not only the product name.
Deploy and configure the chosen methods
Install the selected tools or apply the hardening baseline to each asset, then configure it to match the documented method. Test the configuration in a non-production environment where possible, and confirm that the tool runs on each asset in the class rather than only on a sample. Where the BES Cyber System has operational constraints, record the change through your change management process. The output is a deployment record listing each asset, the method, the version in use and the date it was confirmed active.
Define the mitigation procedure for detected malicious code
Write the procedure for what happens after a detection, which covers isolating the affected asset, identifying the code, removing or containing it, verifying the removal and documenting the outcome. Assign who performs each action and who approves the return to service. Part 3.2 requires that the threat of detected malicious code be mitigated, so the procedure should state the mitigation steps as well as the escalation path. The output is a signed mitigation procedure and a blank incident record template that technicians can use during an event.
Set up the signature and pattern update process
For each method that relies on signatures or patterns, define how updates are obtained, tested and installed. Part 3.3 requires a process that addresses testing and installation, so specify the test environment, the test criteria, the approver and the installation window or trigger for each class. Note any class that updates by policy or hardening instead, because it has no signature cycle to govern. The output is a documented update procedure with named owners and a log template that records each update and its test result.
Establish the records that prove each step ran
Set up the evidence trail so that each earlier step leaves a record an auditor can sample. This includes the method decision records, deployment confirmations, detection and mitigation logs, and the signature update log with test and installation dates. Store the records in a location that is access-controlled and retained according to your CIP program. Run a sample walkthrough from one asset back to its method, deployment, update and any detections to confirm the chain holds together. The output is an evidence index that maps each R3 part to the records that show it operating.

What evidence passes an R3 review

An auditor testing CIP-007-6 R3 looks for a chain of proof: a documented method for each in-scope system class, records that the method ran, records of what happened when malicious code was found, and records that signatures or patterns were kept current. Each artifact should name the BES Cyber Systems and associated EACMS, PACS and PCA it covers so the evidence ties back to the in-scope system list.

Documented method per system class

Write down which method you use to deter, detect or prevent malicious code for each class of in-scope system, such as traditional antivirus, system hardening or policy controls. Auditors compare this document against the asset list, so a Control Center workstation and a substation Protected Cyber Asset should each have a stated method, even if the method differs. Review the document at least annually and whenever a system class changes. Confirm with your Compliance Enforcement Authority how much detail they expect in the write-up.

Records of the running process

Keep dated outputs showing the deterrence, detection or prevention method actually operated on the systems it claims to cover. Examples include scan logs, agent health reports and query results from a fleet tool such as osquery run through osqueryd. An auditor will sample a few systems and ask for proof that the method was running on the sample date, so the records must map to specific host names and identifiers.

Mitigation records for detected code

When a method flags suspicious or malicious code, the record should show what was found, which system it was on, who reviewed it, what action was taken (removal, isolation, restoration from a known-good copy) and how the team confirmed the threat was addressed. Keep the ticket or case number that links the detection to the response. Gaps here are common: a scanner alert with no closing record reads as an unmitigated finding.

Signature and pattern update records

Where a method relies on signatures or patterns, keep records of each update: the version obtained, the date, the test performed before deployment and the date of installation on each system class. CIP-007-6 Part 3.3 asks for a process that covers testing and installation, so the record should show both steps. Retain these entries across the audit period so an assessor can see that updates kept pace with the vendor's releases.

Policy and procedure set

The procedures set out who owns each method, how signatures are evaluated and deployed, how detections are escalated and how exceptions are approved. Assessors use this set to judge whether the records above are the product of a repeatable process rather than ad hoc activity. Version-control the documents, record approvals and link each procedure to the systems and roles it governs.

Scope tie-back to the asset list

Maintain a single register that matches each in-scope BES Cyber System, EACMS, PACS and PCA to the method, the owner and the evidence location. R3 applies to high and medium impact BES Cyber Systems and their associated systems, so an asset missing from this register is a likely finding even when it is protected. Reconcile the register against the categorization and configuration records at each review cycle.

What meeting R3 costs in money and effort

The table lists each cost component of running CIP-007-6 R3 malicious code prevention, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no price is given here and most of the cost depends on the in-scope asset count and the detection method you choose.

Cost component	One-time or recurring	Who is paid or who does the work	What drives it up or down
Tooling or licenses for the chosen method	Recurring (subscription or support) or one-time (perpetual license)	Software vendor or reseller for commercial antivirus or hardening tools; none for open-source agents such as osquery, Wazuh or Velociraptor, though support contracts may still apply	Number of in-scope BES Cyber Systems, PCA, EACMS and PACS; per-endpoint pricing; whether the license covers offline or air-gapped sites. Open-source options can remove license spend but not engineering or support effort
Engineering time to deploy and configure	One-time	Internal staff or an implementation partner preparing the method, agents, policies and hardening baselines	Operating system mix, number of distinct configurations, and whether the method must be tested on each platform before rollout
Method design and documentation	One-time, with periodic review	Internal compliance and OT engineering staff, who record which methods are used for each Applicable System	Number of asset types and whether one method covers several systems, since Part 3.1 evidence must show the method for each in-scope system
Signature or pattern update process	Recurring	Operations staff who run the update cycle, test updates and record installation, plus any vendor update subscription	Frequency of vendor signature releases, the testing window required before installation in production OT environments, and whether updates must be staged across many sites
Mitigation of detected malicious code	Recurring, event-driven	Security or operations staff who investigate alerts, contain affected Cyber Assets and record the mitigation	Alert volume, quality of detection tuning, and whether isolation of a BES Cyber System requires coordination with control room operations
Air-gapped or remote site handling	Recurring	Field technicians or staff who carry updates or collect evidence on site, or the team that maintains an offline update path	Number of isolated sites, distance and travel, and whether updates must be transferred through removable media that is itself governed by other CIP requirements
Evidence upkeep	Recurring	Compliance staff who collect update records, detection logs and mitigation tickets for each audit period	Degree of automation in evidence collection, retention settings, and the number of systems each evidence record covers
External testing or review	Recurring or periodic	Independent testers or consultants who verify that methods work, and sometimes the auditor's own sampling	Scope of testing, number of sites sampled, and whether testing is fixed-scope or retained
Auditor sampling effort	Recurring, per audit cycle	The Compliance Enforcement Authority's auditors, whose sampling your staff must support with records	Number of in-scope systems, clarity of evidence indexing, and how quickly records can be produced

Which self-hosted open-source tools can support the evidence

CIP-007-6 R3 asks the entity to choose methods that deter, detect or prevent malicious code, mitigate detected threats and keep any signatures current. The tools below can record what a system is running, what has changed and what was found, which gives an assessor records to review. None of them establishes the chosen method on its own, so the entity must confirm with its assessor which method it relies on and what evidence that method needs.

osquery fleet 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, so a team can record whether unexpected processes or kernel modules appear on in-scope Cyber Assets. Teams should confirm which hosts are in scope for each query, how query results are retained and whether the chosen detection method is documented as the one in use. Licensing is dual, Apache-2.0 OR GPL-2.0-only, so the entity should confirm which license it relies on before distributing modified builds.

Velociraptor hunts

Velociraptor collects forensic artifacts defined in VQL from endpoints. Its hunts collect one or more artifacts across a group of systems, schedule collection for offline machines when they reconnect and create a notebook per hunt for analyzing combined results. This supports the mitigation side of R3 Part 3.2, since a team can scope a detected malicious code finding across affected systems and document the response. Confirm whether the systems in scope can run the client and whether the hunt records meet the retention expectations of the entity's program. The project is licensed AGPL-3.0-only, which carries source-availability obligations if the software is modified and offered to users over a network.

Wazuh file integrity monitoring

Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories. It then raises an alert when a user or process creates, modifies or deletes a monitored file, on a schedule or in real time, with details on how and when the change occurred and who made it. For R3, this can show that an entity detects unauthorized changes to malware-relevant paths such as binaries and configuration. Teams should confirm which directories are baselined, who reviews the alerts and how baselines are approved after authorized change. The project is licensed GPL-2.0-only, so the entity should review those terms for any modifications it distributes.

Bareos Verify jobs

Bareos Verify jobs compare files against previously cataloged attributes, which gives a Tripwire-like capability for detecting changes after a suspected compromise. This is useful as an independent check against the backup catalog, which may survive an attack that alters live systems. Teams should confirm that the catalog itself is protected from the same threat, that verify jobs run on a schedule the entity can document and that results are kept as evidence. Bareos is licensed AGPL-3.0-only, so the same network-use obligations apply as for other AGPL tools in the stack.

Who does what for R3: your team, a partner, and the auditor

Your team owns the decisions that make R3 your program. The registered entity must decide which methods deter, detect or prevent malicious code on each in-scope system, and it must be able to explain why those methods fit the environment. That starts with an in-scope list drawn from your CIP-002 categorization, covering high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. Your team also approves signature or pattern updates, decides how detected malicious code is mitigated, and keeps the records that show those decisions were made. Accountability stays here even when a partner does the technical work.

Method selection: Choose the deter, detect or prevent methods for each Applicable System and document the reasoning, including any method that does not use signatures.
In-scope inventory: Maintain the list of Cyber Assets, including PCA and any EACMS or PACS, and update it when assets are added, retired or re-categorized.
Signature update approvals: Define how patterns are tested and installed, and name the person who signs off on each update.
Mitigation decisions: Decide and record how each detected instance is contained, cleaned or escalated, and who is notified.
Accountability: Keep the decision records in a location the compliance lead can produce on request, since the entity answers for the outcome.

Check that each decision has a named owner and a dated record, because an auditor will ask for those records before anything else.

Where R3 programs usually fall short and how to close the gap

Most CIP-007-6 R3 findings do not come from missing antivirus. They come from gaps between the method chosen, the systems it covers, and the records that prove it ran. The cards below pair each common gap with a fix the compliance lead can assign this quarter.

No documented method per system class

Teams often name one antivirus product for the whole environment, then discover that Windows workstations, Linux servers, engineering laptops and embedded devices each need a different deterrence or detection method. Document a method for each system class in scope for R3, including the high impact and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. Check that every class has a named method and an owner. Illustrative example: a Linux historian with no agent and no hardening record is a gap even if the Windows fleet is covered.

Signatures updated without recorded testing

Part 3.3 requires a process for updating signatures or patterns where a method depends on them, and that process covers testing and installation. Many programs push updates automatically but keep no record of which version was tested, where it was installed, or when. Ask the operator to show one recent update with its test result, approval and installation timestamp. If that record cannot be produced, the process is not yet operating as written.

Detections closed without mitigation records

Part 3.2 requires mitigating the threat of detected malicious code, and an alert that is dismissed without a record is hard to defend in an audit. Each detection should carry a ticket showing the affected Cyber Asset, the action taken, such as isolation, removal or restoration, and the reviewer's sign-off. Sample closed alerts from the last audit period and confirm each one links to a mitigation entry. Look especially at detections that were marked false positive without a written reason.

In-scope systems missing from deployment

Scope drift is a frequent cause of R3 findings. New servers, virtual machines, jump hosts and PACS workstations are added through change tickets, but the malicious code tool or hardening baseline is not always deployed to them. Reconcile the asset inventory from CIP-002 against the agent or management console at least once per audit cycle, and treat any unmatched asset as an open item. Osquery or a similar inventory query can help produce the comparison, provided the host list is complete.

Evidence scattered across tools

R3 evidence often lives in a console, a SIEM, an email thread and a spreadsheet, with no single owner or retention rule. Auditors then request a sample and the team spends days assembling it. Assign one evidence index that lists each method, each signature update, each mitigation and the location of its record, and set a retention period that matches the audit period in your program. Confirm the retention period with your Compliance Enforcement Authority contact before you set it.

Questions buyers ask about R3 cost, effort and outside help

How much effort does CIP-007-6 R3 take for a small versus a large in-scope population?

Effort grows with the number of in-scope Cyber Assets, not with the number of pages in the standard. R3 applies to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, so the first task is an accurate inventory of those assets under your CIP-002 categorization. A small population with a few Windows hosts and one tool can be documented quickly. A large population spread across control centers, substations and virtual environments needs more deployment work, more exception handling for systems where a tool cannot run, and more evidence collection. Ask any partner to state how many systems they assumed and which operating systems and platforms each system uses.

Can we meet CIP-007-6 R3 with our own staff?

Yes, an entity can perform R3 in-house, since the standard places the obligation on the registered entity and does not require an outside firm. The work splits into deciding methods, deploying them, mitigating detected malicious code, keeping signatures or patterns current with testing and installation, and keeping records. Most in-house teams struggle with the recurring parts, especially keeping the update process running and producing consistent records for an audit. An outside partner can help with design and tooling, but it does not own the control or issue any compliance finding.

What does R3 require from our staff day to day?

R3 needs named owners who can make decisions and keep records, not a large dedicated team. Someone must choose and approve each malicious code prevention method, someone must handle detections and document mitigation, and someone must run the signature or pattern update process, including testing before installation where the chosen method uses signatures. Staff also need to understand which systems are in scope, because an auditor will ask how you know a given asset is covered. Plan for time with operations and security engineers, and for periodic review of the process itself.

How long does preparation for R3 usually take?

The duration depends on the size of the in-scope population, how much of the environment already has a documented method, and how quickly you can deploy and test tools in production. No preparation timeline is set by the standard, and no duration figure applies here, so ask any provider to state its assumptions and milestones in writing. Ask for a schedule that separates inventory, method selection, deployment, signature update testing and evidence collection, because those steps often run in parallel and have different owners.

Does self-hosted open source reduce our license spend for R3?

It can reduce license fees for the detection and monitoring tools you choose, but it does not remove cost. Self-hosting moves spend toward engineering time for deployment, hardening, updates, backups and evidence handling, and those costs recur. Confirm the license terms of each component before you rely on it, because some open-source tools carry copyleft or network-use obligations that affect how you distribute or operate them. Also confirm whether the tool meets your need for signature or pattern updates, since R3 Part 3.3 applies only where a method uses signatures or patterns.

What does a partner's fixed-scope engagement for R3 cover?

A fixed-scope engagement covers what is written in the agreed statement of work, typically the systems in scope, the methods to be planned or deployed, the documentation to be prepared and the evidence to be collected. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for assessment. It does not issue audit reports or certifications, and it does not own your controls. Ask for the deliverables list, the systems covered, exclusions such as systems you run yourself, and the handover of runbooks and records. A quote follows from the written scope.

Can any firm certify that we comply with CIP-007-6 R3?

No firm can certify R3, because there is no CIP certificate. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, spot checks, self-certifications, self-reports and other monitoring. A consultant or implementation partner can prepare controls and evidence, but only the monitoring body reaches a compliance finding. Be wary of any offer that promises a CIP certificate or guaranteed outcome, and confirm with your Regional Entity how it expects R3 evidence to be presented.

How DeployOpen scopes and prepares R3 evidence

DeployOpen plans, implements and documents the malicious code prevention layer for CIP-007-6 R3 on self-hosted open-source platforms inside the entity's own infrastructure. The entity owns its controls and its compliance program; DeployOpen prepares the systems, configuration and evidence that the entity's auditor or the Compliance Enforcement Authority will review.

How we scope

Confirm which BES Cyber Systems, EACMS, PACS and PCA fall under R3 based on the entity's CIP-002 categorization.
Record which deter, detect or prevent methods each in-scope asset uses, and which of them rely on signatures or patterns.
Agree the scope, deliverables and timeline in writing before any work starts, since engagements are fixed-scope.

How we build

Configure the chosen detection methods, such as osquery queries or Wazuh file integrity monitoring, on the in-scope hosts within the entity's environment.
Set up a documented process for updating signatures or patterns, including how changes are tested and installed before rollout.
Test that detection alerts fire and that mitigation steps for detected malicious code are recorded for each asset class in scope.

How we hand over

Deliver a written R3 method description that maps each Part 3.1, 3.2 and 3.3 obligation to the configured tooling and its owner.
Provide sample evidence records, such as query schedules, alert logs, signature update records and mitigation tickets, in the entity's retention system.
Document runbooks and configuration files so the entity's own staff can operate and reproduce the controls after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
Review signature or pattern update records and tool configuration changes at the cadence the entity agrees in its retainer scope.
Confirm with the entity's compliance lead and auditor which evidence formats they accept before the first Compliance Audit or Spot Check.