What CIP-003-9 R2 asks a low impact entity to document and do
If your only BES assets are low impact, CIP-003-9 R2 is most of your mandatory CIP program. The requirement is that each entity with at least one asset containing low impact BES Cyber Systems implements documented cyber security plans that include the six sections of Attachment 1. You are not asked to build a full CIP program, and the requirement itself does not call for a complete inventory of low impact systems or a list of authorized users. Your job is to write a plan that addresses each Attachment 1 section for the assets you actually have, then show that you do what the plan says. Confirm the asset list and categorization outcome against your CIP-002 record before you draft anything, because that record decides which assets the plan covers.
The six sections cover reinforcing cyber security practices at least once every 15 calendar months, need-based physical access control, electronic access controls that permit only necessary inbound and outbound routable communications and authenticate Dial-up Connectivity, a Cyber Security Incident response plan with E-ISAC notification and testing every 36 calendar months, malicious code mitigation for Transient Cyber Assets and Removable Media, and vendor electronic remote access security. The vendor section is the new element. CIP-003-9 became enforceable on 1 April 2026 and requires methods to determine, disable and detect known or suspected malicious communications for vendor electronic remote access. Attachment 2 of the standard lists example evidence such as preauthorization steps, alerts on vendor log on, session monitoring or recording, and system logs. Check whether any vendor, integrator or remote support tool reaches your low impact assets today, because that path needs its own documented method.
Organizations usually find three things hard. The first is scoping: deciding which sites and cyber assets fall under the plan and keeping that list current as systems change. The second is evidence: the standard does not ask for a list of authorized users, but it does require you to show how access is controlled, how vendor sessions are logged and how incidents are handled, so you need records that exist before an assessor asks. The third is vendor remote access, where the technical method (for example, a jump host with session recording and alerting) often depends on tools that were never built for CIP evidence. Review the NERC CIP-003-9 standard with your compliance lead, and ask any implementation partner to scope the plan in writing before work begins.
Which assets, vendors and teams fall under the low impact plan
The CIP-003-9 R2 plan applies to any entity with at least one asset containing low impact BES Cyber Systems, so the first job is confirming that categorization under CIP-002-5.1a. Once scope is set, the work splits across operations, IT, and every vendor or contractor who can reach those assets, and a few scoping choices decide how much of the plan is real work.
Trigger: low impact asset categorization
The trigger is any asset containing a low impact BES Cyber System, as categorized under CIP-002-5.1a. Requirement R2 applies to each entity with at least one such asset, so the categorization record is the starting point. Confirm which listed assets hold low impact systems, and keep the categorization current as sites, relays, or control equipment change. Note that the R2 plan does not require a low impact inventory or authorized user lists, which narrows the documentation you must maintain.
Operations and field staff
Operations teams usually own the physical sites and the field equipment where low impact systems sit, so they carry the need-based physical access controls in Attachment 1 Section 2. Ask who can enter each location, how access is granted and removed, and whether contractors escort or work alone. Operations also knows which sites have dial-up connectivity, which Section 3 requires you to authenticate.
IT and network administration
IT typically runs the routable connections, firewalls, and jump points that carry electronic access to low impact assets. They must map which inbound and outbound routable communications are needed, then configure electronic access controls to permit only those. IT also owns the incident response plan under Section 4, including E-ISAC notification of Reportable Cyber Security Incidents and the 36-month test cycle.
Vendors and contractors with remote access
Any vendor that reaches low impact assets electronically is the scope driver for CIP-003-9 Attachment 1 Section 6. Section 6 requires methods to determine, disable, and detect known or suspected malicious communications for vendor electronic remote access. List every vendor path, including managed service providers, equipment manufacturers with remote support, and integrators. Check how each vendor connects, who authorizes sessions, and whether sessions are logged or recorded for the evidence examples in Attachment 2.
Transient Cyber Assets and Removable Media
Laptops, diagnostic tools, and USB media that connect to low impact systems fall under Attachment 1 Section 5, which addresses malicious code risk mitigation. Ask whether engineers bring laptops onto site, whether they plug into control equipment, and whether any media moves between offices and field locations. Each use case changes the malicious code controls and the evidence you need, so inventory these devices by how they are used rather than by who owns them.
Compliance and governance owners
The CIP Senior Manager and the compliance lead own the plan as a whole, including the review cycle for the reinforcing cyber security practices in Section 1, which must occur at least once every 15 calendar months. This group decides whether an asset's scope has changed, approves plan updates, and tracks the 2026 vendor remote access change and the CIP-003-11 requirements effective 1 July 2029. Confirm early who signs off on scope decisions so the plan has a single accountable owner.
How to build the plan section by section
This sequence turns the low impact asset list into a documented cyber security plan that maps to the six Attachment 1 sections, carries the vendor remote access method and its monitoring, sets review cycles, and ends with approved, versioned and retained evidence.
Confirm the low impact asset list
Start from the CIP-002 categorization output and pull every asset where the entity has at least one BES Cyber System rated low impact. The CIP Senior Manager or a delegate reviews the list against the current asset register and records which sites are in scope. Note that R2 does not require a system-by-system inventory or lists of authorized users, so the output is a site-level scope statement. The step is done when each in-scope asset is named and the scope statement is signed off.
Draft the plan around Attachment 1
Create one or more documented cyber security plans that address the six sections of Attachment 1: reinforcement of cyber security practices, need-based physical access, electronic access controls, Cyber Security Incident response, malicious code risk for Transient Cyber Assets and Removable Media, and vendor electronic remote access. The plan owner writes each section against the asset scope from the previous step. The output is a draft plan with a section-by-section mapping that shows where each Attachment 1 element is addressed.
Define the vendor remote access method
Describe how vendors reach low impact systems, which accounts and paths they use, and the methods used to determine, disable and detect known or suspected malicious communications. Attachment 2 gives evidence examples such as preauthorization steps, alerts on vendor log on, session monitoring or recording, and logging with alerts. Engineering and the vendor management owner confirm the method with the systems in your environment. The output is a written vendor access procedure and a list of the monitoring evidence each step produces.
Set the review and test schedules
Schedule the reinforcement of cyber security practices so it occurs at least once every 15 calendar months, and schedule the Cyber Security Incident response plan test at least once every 36 calendar months. Also record the 180-day update window that follows a test or an actual incident. Assign an owner for each recurring activity and add the dates to the compliance calendar. The output is a dated schedule with named owners and a record of each planned activity.
Approve and version the plan
Route the draft through the entity's internal approval process, with the CIP Senior Manager or an authorized delegate signing off. Record the version number, effective date and summary of changes in a revision history. Any change to the plan after approval should follow the same route and keep the prior version. The output is an approved plan with a revision log that shows who approved it and when.
Store the outputs as audit evidence
Place the approved plan, the scope statement, the vendor access procedure, the test and training records, and the monitoring logs in a controlled repository with retention and access rules. Tag each file with the Attachment 1 section it supports so an auditor or Compliance Enforcement Authority can trace evidence to each requirement. Spot-check that the logs can be retrieved and read. The output is an evidence index that links each Attachment 1 section to its supporting records.
How an assessor tests the low impact plan
This table shows how a Regional Entity assessor typically tests CIP-003-9 R2 and each Attachment 1 section, the evidence requested and the gaps found most often. Read the findings column as two groups: documentation gaps, where the plan does not say what the entity does, and implementation gaps, where the entity does not do what its plan says. Implementation gaps tend to carry more risk in an audit.
| Requirement or section | What the assessor checks | Evidence usually requested | Common findings |
|---|---|---|---|
| R2 overall | Each entity with at least one low impact asset has documented plan(s) that address all six Attachment 1 sections | Plan documents with revision history, a mapping of each section to the controls that implement it | Documentation gap: a section is missing or only partly addressed. Implementation gap: the plan describes controls the entity does not operate |
| Section 1, reinforcing practices | Cyber security awareness is reinforced at least once every 15 calendar months | Dated training or awareness materials, communication records, attendance or distribution logs | Documentation gap: no stated frequency. Implementation gap: last reinforcement falls outside the 15-month window |
| Section 2, physical access | Physical access is controlled on a need basis at the asset | Access control procedures, access lists or badge configurations, sample access grants and removals | Documentation gap: the plan does not explain how need is decided. Implementation gap: access granted without a documented need or not removed when no longer needed |
| Section 3, electronic access | Only necessary inbound and outbound routable communications are permitted, and Dial-up Connectivity is authenticated | Firewall rule sets, rule justifications, firewall configuration exports, dial-up authentication settings | Documentation gap: no rationale for allowed ports or services. Implementation gap: broad or stale rules, such as any-to-any rules left after a project ends |
| Section 4, incident response | A Cyber Security Incident response plan covers E-ISAC notification, is tested at least once every 36 calendar months and is updated within 180 calendar days after a test or actual incident | Response plan, test records with dates, after-action reports, dated plan revisions, E-ISAC notification procedure | Documentation gap: no test date or update trigger recorded. Implementation gap: test older than 36 months or update finished after the 180-day window |
| Section 5, transient and removable media | Malicious code risk is mitigated for Transient Cyber Assets and Removable Media | Procedures for scanning or controlling laptops and USB media, logs of use, inventory of transient devices | Documentation gap: no defined method for the entity's assets. Implementation gap: devices connected without the documented check |
| Section 6, vendor electronic remote access | Methods exist to determine, disable and detect known or suspected malicious communications for vendor remote access | Preauthorization steps, vendor log-on alerts, session monitoring or recording, SIM or system logs, disablement procedure | Documentation gap: the plan names no method for detection or disablement. Implementation gap: vendor sessions cannot be shown in logs or the entity cannot disable a session on request |
| Vendor remote access evidence | Evidence matches the examples the standard's Attachment 2 gives for vendor access | Sample vendor sessions with timestamps, approvals and alert records | Documentation gap: evidence exists but is not linked to a plan section. Implementation gap: sessions cannot be traced to an approved vendor or purpose |
What the vendor electronic remote access section requires in practice
Attachment 1 Section 6 asks the entity to have methods that determine, disable and detect known or suspected malicious communications for vendor electronic remote access to low impact assets that the plan covers. In practice, the entity needs three things it can point to: a way to see when a vendor connects, a way to cut that connection off, and a way to spot traffic that looks malicious while the session is open. The plan should name who decides which vendor sessions are allowed, which system enforces the decision, and which person can end a session quickly. Confirm the exact wording of the requirement and its measures in the standard itself, since the measures section is what an auditor will read first.
Attachment 2 gives examples of evidence an auditor may accept for vendor remote access. These include records of preauthorization steps, alerts generated when a vendor logs on, session monitoring or recording, alerts from security information management logging, and system logs. A team typically assembles these by mapping each example to a system it already runs, such as a jump host, a firewall or a log collector, then exporting dated records that show the vendor, the approval, the session and the alert. Open-source firewall or proxy logs can support the traffic side, and a case management tool such as DFIR-IRIS can hold the investigation record for an alert. Neither tool proves compliance alone. Before relying on any product for detection or session recording, the team should confirm in its own environment which capabilities it actually has, and whether its logs are retained long enough to show the evidence the auditor asks for.
The cost of this section is mostly staff time for approval workflows, log review and documentation, plus any licensing for a remote access gateway or monitoring tool that the entity does not already own. One-time work includes designing the preauthorization process and setting up alerting. Recurring work includes reviewing vendor access logs, testing the disable procedure and keeping the evidence current. When requesting help from an implementation partner, ask for a written list of which Attachment 2 examples the design will produce, which system generates each one, and who will own the review. An independent auditor, not the partner, decides whether the evidence is sufficient.
Evidence that satisfies each part of the plan
A CIP-003-9 R2 plan is only as good as the records behind it. The cards below map the evidence an auditor will ask for to each part of the plan, and note how to keep each record current between audits so the file does not have to be rebuilt before a monitoring engagement.
Dated and approved plan documents
Keep each cyber security plan as a versioned document with its approval date, the approver's name and the date each revision took effect. The plan must cover all six Attachment 1 sections, so check that the document structure matches those sections one for one. Between audits, review the plan on a fixed calendar, record the review even when nothing changes, and keep superseded versions so an assessor can see what was in force on any given date.
Reinforcement records within 15 months
Section 1 expects reinforcement of cyber security practices at least once every 15 calendar months. Evidence is a dated record of what was done, such as awareness material issued, a short training session, or a bulletin with a distribution list and acknowledgments. Keep one record per cycle in a single log so the most recent date is visible at a glance and any gap is obvious before the 15-month window closes.
Access configuration and firewall rule records
Section 2 covers need-based physical access, and Section 3 requires electronic access controls that permit only necessary inbound and outbound routable communications. Export the current firewall rule set with its change history, and keep the rationale for each allow rule tied to a documented business need. In OPNsense, rule logging and aliases help show which address groups are permitted. Review rules on a schedule and retain exports so the rule set in force on an audit date can be reproduced.
Incident response plan and test records
Section 4 requires a Cyber Security Incident response plan that covers E-ISAC notification of Reportable Cyber Security Incidents. Keep the plan, the notification procedure and contact list, and a dated test record for each exercise. The plan must be tested at least once every 36 calendar months and updated within 180 calendar days after a test or an actual incident, so record the update date alongside each test. Confirm the procedure with the E-ISAC reporting guidance current when you test it.
Vendor remote access logs and alerts
Section 6 requires methods to determine, disable and detect known or suspected malicious communications for vendor electronic remote access. Attachment 2 gives examples of acceptable evidence, including preauthorization steps, alerts on vendor log on, session monitoring or recording, and system logs. Retain vendor access tickets, the approval that preceded each session, and the alert history. Confirm log retention periods with your compliance lead, because the auditor will ask for records from the period under review.
Malicious code controls for transient and removable media
Section 5 covers mitigation of malicious code risk for Transient Cyber Assets and Removable Media. Evidence includes an inventory of devices that are authorized for use, the scanning or hardening step performed before each connection, and a log of media checked in and out. Keep scan results and exception approvals with the device record. Review the inventory on a routine cadence so that devices retired from service are removed and cannot be connected without a new record.
What meeting CIP-003-9 R2 costs in money and effort
This table lists each cost component of running the low impact cyber security plan, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for scoping a quote, and note that no dollar figures are given because none were supplied for this requirement.
| Cost component | One-time or recurring | Who is paid or who carries the work | Main cost drivers and how to contain them |
|---|---|---|---|
| Drafting the six Attachment 1 sections | One-time | Internal engineering, compliance and operations staff; optionally an implementation partner for documentation support | Number of asset sites with low impact BES Cyber Systems and how many distinct plans you maintain. Consolidating into one plan with site-specific appendices usually reduces drafting effort. |
| Maintaining the plan and its approvals | Recurring | Internal compliance staff and the CIP Senior Manager's review cycle | Review must happen at least every 15 calendar months under the related R1 policy process. Keep a single owner and a calendar so review does not become a fire drill. |
| Vendor electronic remote access controls (Section 6) | One-time build, then recurring operation | Internal network and security teams; tooling spend if a commercial gateway or log platform is bought | Number of vendors and remote paths. Self-hosted open-source gateways and firewall logging can remove license spend, but staff time to configure, patch and monitor them remains. |
| Firewall logging and inbound and outbound rule review (Section 3) | One-time setup, recurring review | Network engineering; firewall platform licensing if commercial | Rule count and logging volume. OPNsense is open source under BSD-2-Clause and can log rule matches, but confirm the license and edition terms for your deployment before relying on them. |
| Incident response plan testing and updates (Section 4) | Recurring every 36 calendar months, with updates within 180 calendar days | Internal incident response team; external facilitator if used | Scope of the test and whether an actual incident triggers an update. Case records kept in an open-source tool such as DFIR-IRIS, licensed under LGPL-3.0-or-later, can reduce tooling spend. |
| Reinforcing security awareness and training (Section 1) | Recurring at least every 15 calendar months | Internal security or training staff; learning platform if used | Audience size and content refresh. An open-source LMS such as Moodle (GPL-3.0-or-later) can track completion, but hosting and administration cost still apply. |
| Evidence collection and retention | Recurring | Internal compliance and system owners | Number of sampled items an auditor may request. Standardized evidence folders and automated log exports lower the effort per sample. |
| External testing or review | Recurring, when used | External testers or consultants, under a written fixed scope | Scope, depth and frequency of testing. Ask for a fixed-scope quote with deliverables listed before work starts. |
| Auditor or Regional Entity sampling effort | Recurring, per monitoring engagement | Internal staff who answer evidence requests; the auditing body carries its own cost | Audit notification timing and evidence readiness. Ready evidence shortens the engagement. Confirm the process with your Regional Entity. |
Who owns the plan, who can prepare evidence, and who audits it
The registered entity remains accountable for its cyber security plan under CIP-003-9 R2. Internal staff decide which low impact assets fall under the plan, approve the documented plan through the CIP Senior Manager process, and run the recurring cycles that keep it current. Nothing in the standard transfers that accountability to a vendor or consultant.
- Plan ownership: Named owners maintain each of the six Attachment 1 sections and decide how each is met at each asset.
- Approval and review: The CIP Senior Manager or a delegate approves the plan and its changes, as covered in the sibling topics on R1, R3 and R4.
- Recurring cycles: Staff run the reinforcing practice reminders at least once every 15 calendar months and the incident response plan test at least once every 36 calendar months.
- Vendor access decisions: Internal teams decide which vendors may reach low impact systems remotely and approve the preauthorization steps.
- Retained records: Staff keep the evidence that shows each cycle happened and was reviewed.
Before engaging anyone, confirm internally which person can sign off the plan and who has authority to accept residual risk on each Attachment 1 section.
An implementation partner such as DeployOpen can plan, configure and document the technical controls that the plan depends on, and can help assemble the evidence. The partner works inside the entity's own infrastructure and prepares systems and records. It does not decide compliance, approve the plan or issue any report or certificate.
- Electronic access controls: Configuring firewall rules that permit only necessary inbound and outbound routable communications, with rule logging enabled for review.
- Vendor remote access: Building the Section 6 controls, such as session logging, alerting on vendor log on and session recording, using the Attachment 2 evidence examples as a checklist.
- Incident response support: Preparing runbooks, tabletop material and test records for the Section 4 plan.
- Evidence packaging: Exporting configuration, log and case records in a form the entity can present, with the entity reviewing every item.
- Documentation: Writing system descriptions and change records that the entity's own staff validate and own.
Ask any partner for a written scope that lists each deliverable, which artifacts it will hand over, and confirmation that the entity, not the partner, signs the plan and attests to compliance.
Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC. Tools include Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, self-logging, periodic data submittals, investigations and complaints. There is no CIP certificate. The outcome is a determination by the enforcement authority, not a seal from a firm.
- Scheduled audits: Balancing Authority, Reliability Coordinator and Transmission Operator entities receive a Compliance Audit at least once every three years under Section 403.10.1 of the Rules of Procedure. Other registered entities are audited on a risk-based schedule set by the Regional Entity.
- Evidence testing: Auditors sample the records the entity produced, check dates against the 15-month and 36-month cycles, and test whether controls work as described.
- Self-reporting: Entities report their own missed requirements, which can affect how a violation is handled.
- Independence line: An implementation partner may not act as the auditor of its own work, and a partner's report is not a compliance finding.
- Enforcement context: Penalties are set under the Sanction Guidelines, referencing a maximum of $1,584,648 per violation, per day, as adjusted in 2025.
Before an audit, confirm the audit schedule and evidence request process with the Regional Entity, and confirm that every artifact has a named owner inside the organization.
CIP-003-9 R2 questions registered entities ask before hiring help
Does a low impact entity need an asset inventory for CIP-003-9 R2?
No. CIP-003-9 R2 does not require an inventory of low impact systems or lists of authorized users. The requirement is to implement documented cyber security plans that include the six sections of Attachment 1, for each entity with at least one asset containing low impact BES Cyber Systems. You still need to know where those assets are and what they do, because the plan has to address Attachment 1 for them, and a partner will ask for that scope early. Confirm the wording of your own plan against the standard PDF before you scope the work.
How often does the CIP-003-9 low impact plan need review?
The plan must be reviewed and approved on a cycle set by CIP-003-9, and the reinforcing cyber security practices in Attachment 1 Section 1 must be reinforced at least once every 15 calendar months. The Section 4 incident response plan must be tested at least once every 36 calendar months and updated within 180 calendar days after a test or an actual incident. Confirm the approval cycle in R1 and the current standard text with your Regional Entity or compliance counsel, since the cadence is part of what an assessor will check against your evidence.
What does the 1 April 2026 vendor remote access change require?
CIP-003-9 became enforceable on 1 April 2026 and adds Section 6 to Attachment 1. Section 6 requires methods to determine, disable and detect known or suspected malicious communications for vendor electronic remote access to low impact assets. Attachment 2 gives example evidence, such as preauthorization steps, alerts on vendor log on, session monitoring or recording, and security information management logging alerts. Your plan must show how you handle vendor sessions in practice, not only in policy. Start by listing every vendor path into low impact assets, including support tools and maintenance accounts.
How long does a CIP-003-9 R2 implementation take, and what drives it?
No supplied source gives a duration for this work, so treat any timeline you receive as an estimate that depends on your environment. The main drivers are the number and type of low impact asset sites, how much of Attachment 1 already exists in written form, how many vendor remote access paths you must control, and whether you can change firewall rules and access methods without long outages. Ask any partner for a timeline tied to a written scope, and ask which sections they expect to be mostly documentation and which need technical change.
Can a small team write and run a CIP-003-9 plan without outside help?
Often yes, if the entity has a clear owner for the CIP Senior Manager role, staff who understand the low impact sites, and enough time to keep evidence current. The plan itself is a set of documented practices, so the harder work is usually technical: restricting inbound and outbound routable communications under Section 3, controlling vendor remote access under Section 6, and keeping logs and test records. Teams that lack network or security engineering capacity often bring in a partner for the technical controls and keep ownership of the policy and approvals in-house.
What should you ask a partner for in a CIP-003-9 quote?
Ask for a written scope that names each low impact asset or site, each Attachment 1 section, and the systems that will be changed or documented. Ask which deliverables you receive, such as a plan document, configuration baselines, firewall rule sets, vendor access procedures, and evidence packages. Ask what is one-time and what recurs, including reviews, testing and evidence refresh, and what is excluded. Confirm who signs off on the plan and who the auditor or Regional Entity will meet. A reputable partner prepares systems and evidence, but only the entity owns its controls and only an independent auditor or the Compliance Enforcement Authority issues findings. DeployOpen works from a fixed written scope and does not publish a price list, so a quote follows from that scope.
What does CIP-003-11 change for low impact assets from 1 July 2029?
FERC Order No. 918 approved CIP-003-11, effective 1 July 2029. For low impact assets with external routable connectivity, it adds authentication of remote users, protection of authentication information in transit, and detection of malicious communications. Those additions build on the vendor remote access work you complete under CIP-003-9, so the design choices you make now will matter. Plan for the 2029 date when you choose remote access tools and logging, and check the Order No. 918 summary and the standard text for the exact obligations before you commit budget.
How DeployOpen prepares low impact plan evidence
DeployOpen works on the CIP-003-9 R2 cyber security plan as an implementation partner. We prepare the systems, documented controls and evidence for each Attachment 1 section, while the registered entity keeps ownership of its program and an independent Compliance Enforcement Authority decides compliance.
How we scope
- We confirm which assets contain low impact BES Cyber Systems and which Attachment 1 sections the written scope covers.
- We agree on the systems, deliverables and timelines in writing before work starts, since engagements are fixed-scope.
- We record which controls the entity owns, which we implement and which items the entity must confirm with its own compliance team.
How we build
- We configure electronic access controls so that only necessary inbound and outbound routable communications are permitted, with rule-match logging for review.
- We set up vendor electronic remote access controls covering preauthorization, vendor log on alerts, session logging and malicious communication detection.
- We test the controls and the Cyber Security Incident response procedure, then document results against the evidence examples in Attachment 2.
How we hand over
- We deliver the documented cyber security plan(s) mapped to the six Attachment 1 sections, written for the entity to review and approve.
- We provide an evidence package with configuration exports, access logs, test records and dated change history, organized by plan section.
- We walk the entity's staff through the plan and evidence so they can answer questions during a Regional Entity monitoring engagement.
How we support
- We confirm the 15 calendar month reinforcement cycle and the 36 month incident response test cycle are calendared with named owners.
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover updates for the CIP-003-11 changes effective 1 July 2029.
- Any independent audit, assessment or certification decision comes from the Regional Entity or the relevant independent assessor, not from DeployOpen.

