NERC CIP-003-9: Requirements, Vendor Remote Access and Compliance Guide + CIP-003-9 Audit Evidence Checklist.

The standard requires applicable Responsible Entities to update their cybersecurity policies and implement processes that allow them to determine when vendor electronic remote access exists, disable that access and detect known or suspected malicious communications associated with it.

CIP-003-9 became effective on April 1, 2026. Organizations subject to the standard should therefore have implemented controls and supporting evidence in place. A project plan showing that implementation is still underway is not equivalent to meeting an already-effective requirement.

The update matters because low-impact environments frequently depend on third parties for maintenance, monitoring, troubleshooting and operational support. Vendor access may pass through VPNs, remote desktop tools, firewalls, enterprise networks, managed gateways or persistent system-to-system connections.

CIP-003-9 does not prescribe one required technology. Instead, it establishes security outcomes and gives each Responsible Entity flexibility to select operational, procedural and technical methods suited to its architecture.

That flexibility can be useful, but it also creates a compliance challenge. An organization must define the scope of vendor electronic remote access, document how its chosen controls meet the standard and maintain evidence proving that those controls operate.

NERC CIP-003-9 at a Glance

What Is NERC CIP-003-9?

CIP-003-9 is the ninth version of NERC’s Cyber Security — Security Management Controls standard. Its stated purpose is to establish consistent and sustainable management controls that create responsibility and accountability for protecting BES Cyber Systems against compromise.

The standard is not exclusively a low-impact standard. It contains security-management obligations that support high-, medium- and low-impact BES Cyber Systems.

CIP-003-9 contains four principal requirements:

Requirement R1: Cybersecurity policies

Each Responsible Entity must review and obtain CIP Senior Manager approval for its documented cybersecurity policies at least once every 15 calendar months.

For assets containing low-impact BES Cyber Systems, the policies must collectively address seven subjects:

1. Cybersecurity awareness
2. Physical security controls
3. Electronic access controls
4. Cyber Security Incident response
5. Transient Cyber Assets and Removable Media
6. Vendor electronic remote access security controls
7. CIP Exceptional Circumstances

Vendor electronic remote access was added as Part 1.2.6. Evidence can include the approved policies, review history and workflow records demonstrating the required review and CIP Senior Manager approval.

Requirement R2: Low-impact cybersecurity plans

Each Responsible Entity with at least one asset identified under CIP-002 containing low-impact BES Cyber Systems must implement one or more documented cybersecurity plans covering Attachment 1.

The evidence must include both:

• The documented plans
• Additional records demonstrating that those plans were implemented

The standard specifically notes that R2 does not require an inventory, list or discrete identification of low-impact BES Cyber Systems or their BES Cyber Assets. It also does not require lists of authorized users.

This does not mean that an organization can operate without adequate visibility. It means NERC does not prescribe a particular formal inventory under this requirement. A Responsible Entity still needs enough information about its architecture, access methods and vendors to implement and demonstrate its controls.

Requirement R3: CIP Senior Manager

Each Responsible Entity must identify its CIP Senior Manager by name and document a change to that individual within 30 calendar days.

The CIP Senior Manager provides named accountability for implementation of applicable CIP requirements.

Requirement R4: Delegated authority

Where the CIP Senior Manager delegates permitted actions, the entity must maintain a documented delegation process.

The documentation must identify:

• The delegate by name or title
• The specific actions delegated
• The date of delegation
• CIP Senior Manager approval

Changes must be updated within 30 days.

What Changed From CIP-003-8?

CIP-003-8 already required cybersecurity plans for low-impact BES Cyber Systems covering awareness, physical security, electronic access, incident response, and malicious-code risks associated with Transient Cyber Assets and Removable Media.

CIP-003-9 adds a sixth section to Attachment 1:

Vendor Electronic Remote Access Security Controls

It also adds vendor electronic remote access to the policy subjects under R1.2.6.

The practical difference is that a Responsible Entity can no longer rely solely on general low-impact electronic-access controls where vendor electronic remote access is allowed. It must implement a documented process specifically addressing that vendor access.

The new process must provide methods to:

• Determine vendor electronic remote access
• Disable vendor electronic remote access
• Detect malicious inbound and outbound communications associated with that access

The official standard presents failure to document and implement the Section 6 process as a potential violation of Requirement R2.

You can refer to the NERC website, and CIP-003-9 section to know more about CIP-003-9 Cyber Security — Security Management Controls.

Why Did NERC Introduce CIP-003-9?

NERC’s supply chain analysis identified a significant level of external connectivity in low-impact environments. Its technical rationale states that 87% of the entities responding to the relevant data request reported low-impact BES Cyber Systems, and approximately 66% of those respondents reported external connectivity that could permit vendor electronic remote access.

The risk is not limited to the compromise of one individual low-impact location.

A common vendor, technology, firewall, remote-access product or managed service may connect with multiple sites. A shared weakness could therefore be exploited across several assets, creating a coordinated or aggregated reliability risk.

FERC previously described an incident in which exploitation of a known vulnerability in a vendor firewall’s web interface caused device reboots and short communication outages affecting a low-impact control center and multiple low-impact generation sites. Although the event did not cause a grid disturbance, it demonstrated how a common remote-access weakness could affect several locations.

CIP-003-9 addresses this exposure by extending supply chain-related remote-access protections to applicable low-impact environments.

Who Must Comply With CIP-003-9?

The standard identifies the following functional entities as Responsible Entities:

• Balancing Authorities
• Certain Distribution Providers
• Generator Operators
• Generator Owners
• Reliability Coordinators
• Transmission Operators
• Transmission Owners

Applicability depends on the facilities, systems and equipment described by the standard. Distribution Provider applicability is limited to the identified BES protection and restoration systems, while the other listed Responsible Entities are generally evaluated across applicable BES Facilities. The standard also contains defined exemptions, including certain nuclear-regulated systems and communication links between discrete Electronic Security Perimeters.

For the new Section 6 requirement, the practical applicability test has three elements:

1. The organization is a Responsible Entity subject to CIP-003-9.
2. It has an asset identified under CIP-002 containing low-impact BES Cyber Systems.
3. That asset allows vendor electronic remote access established under Attachment 1, Section 3.1.

Organizations should document their analysis instead of relying on informal assumptions such as:

• “Our vendor uses our enterprise network, so this is not remote access.”
• “The account is read-only, so it is outside the requirement.”
• “The vendor works onsite frequently, so it should be treated as an employee.”
• “This is machine-to-machine traffic, not a vendor login.”
• “The equipment manufacturer owns the connection, so the utility is not responsible.”

The standard’s drafting team deliberately provided flexibility rather than narrowly defining every technology, account type or architecture. The technical rationale explains that electronic remote access can include onsite or off-premises nonphysical access, and that the standard avoided limiting its focus to the existing Interactive Remote Access definition.

What Is Vendor Electronic Remote Access?

CIP-003-9 does not introduce a glossary definition of “vendor electronic remote access.”

NERC’s technical rationale explains that the drafting team considered different architectures, including remote and local electronic access, vendor accounts, privileges, systems, applications, communication paths and physical processes used to establish or disable access.

The drafting team also avoided creating a separate low-impact definition of “vendor” to reduce potential conflict with other CIP standards. It instead allowed each entity to define processes appropriate to its policies, systems, configurations, operations and facilities.

In practice, an organization’s evaluation may need to cover:

• Vendor VPN access
• Remote desktop connections
• Managed remote-access gateways
• Cloud-managed support connections
• Equipment manufacturer support portals
• Third-party maintenance accounts
• Managed service provider access
• System integrator access
• Firewall rules permitting vendor-originated communications
• Persistent machine-to-machine connections
• Vendor-owned systems connecting electronically
• Connections passing through the Responsible Entity’s enterprise environment

The key issue is not the marketing name of the technology. It is whether a vendor has nonphysical electronic access associated with an asset containing low-impact BES Cyber Systems.

The Three Core Section 6 Requirements

Attachment 1, Section 6 is the central change introduced by CIP-003-9.

It applies to assets containing low-impact BES Cyber Systems that allow vendor electronic remote access established under Section 3.1. The entity must implement a process to mitigate the associated risks through three types of control.

Section 6.1: Determine Vendor Electronic Remote Access

The Responsible Entity must have one or more methods for determining vendor electronic remote access.

This requirement is about visibility.

The organization should be able to know when the relevant vendor access exists or occurs. The standard does not require one specific detection method or state that every session must be monitored identically.

Official evidence examples include:

• Preauthorization steps
• Alerts generated when a vendor logs on
• Session monitoring
• Security information management alerts
• Time-of-need session initiation
• Session recordings
• System logs
• Other procedural, operational or technical controls

These are examples, not a compulsory technology list.

Practical ways to meet Section 6.1

A Responsible Entity might use:

• Named vendor accounts
• Access request and approval workflows
• Vendor login alerts
• VPN session records
• Jump-server logs
• Firewall logs
• Remote-access gateway reporting
• Ticket-based session activation
• Session recording
• Real-time monitoring
• Periodic review of persistent connections

The selected method should match the type of access.

A login alert may help determine user-initiated access but may not provide adequate visibility into a persistent system-to-system connection. Conversely, continuous packet monitoring may be unnecessary for a vendor account that is activated only through a tightly controlled time-of-need process.

Evidence to retain

Useful evidence includes:

• Approved vendor access request
• Vendor identity
• Affected site or asset
• Account or communication path
• Access start and end dates
• Login alert or session record
• Reviewer name
• Access review history
• Exceptions or anomalies
• Corrective action where applicable

Section 6.2: Disable Vendor Electronic Remote Access

The Responsible Entity must have one or more methods for disabling vendor electronic remote access.

This requirement is about control.

The organization should not merely know that access exists. It must be able to stop that access when necessary.

The official evidence examples include:

• Disabling user or system accounts
• Blocking hardware or software ports
• Removing application or firewall permissions
• Disabling VPN, remote desktop or remote-control access
• Disabling a communications protocol
• Removing physical network connectivity
• Powering down equipment
• Administrative documentation explaining how access is disabled

Again, these are examples rather than mandatory product requirements.

Practical ways to meet Section 6.2

A Responsible Entity might disable access by:

• Deactivating the vendor account
• Revoking a certificate
• Expiring an access token
• Disabling a VPN profile
• Removing a firewall rule
• Closing an inbound or outbound port
• Disabling a vendor gateway
• Blocking the vendor’s source address
• Disconnecting a modem or network cable
• Suspending the vendor’s managed service
• Activating an emergency isolation procedure

The selected method should be executable by the people expected to use it.

A procedure that requires a vendor to disable its own access may create unnecessary dependence during an incident. Similarly, an emergency process that can be executed only by one unavailable employee may not provide reliable operational control.

Test the disablement process

The standard requires a method, but an untested method can still fail operationally.

A strong program should periodically verify:

• Who has authority to disable access
• Who has the technical ability
• How quickly the action can be completed
• Whether both user and system connections are covered
• How emergency changes are recorded
• How access is safely restored
• What evidence is retained

Testing is a recommended operational practice, not a separate explicit testing interval in Section 6.

Section 6.3: Detect Malicious Communications

The Responsible Entity must have one or more methods for detecting known or suspected inbound and outbound malicious communications associated with vendor electronic remote access.

This requirement is about identifying potentially harmful activity in both directions.

The outbound element is important. A compromised BES environment might communicate with malicious vendor infrastructure, command-and-control systems or another external destination. Monitoring only inbound attacks may therefore leave part of the required scope unaddressed.

Official examples include:

• Anti-malware technology
• Intrusion detection systems
• Intrusion prevention systems
• Automated log reviews
• Manual log reviews
• Alerting
• Other procedural, operational or technical controls

Practical ways to meet Section 6.3

Depending on the architecture, detection methods could include:

• IDS or IPS alerts
• Firewall threat detection
• Secure remote-access monitoring
• Endpoint or server anti-malware
• SIEM correlation
• Network traffic analytics
• Vendor session monitoring
• Manual review of remote-access logs
• Domain or IP reputation monitoring
• Alerts for unusual protocols or destinations
• Detection of unexpected outbound traffic

The process should explain:

• Which communications are monitored
• Where monitoring occurs
• What qualifies as known or suspected malicious activity
• Who reviews alerts
• How alerts are investigated
• When vendor access is disabled
• How incidents are escalated
• What evidence is retained

The Relationship Between Sections 3 and 6

Section 6 does not operate in isolation.

Its scope refers to vendor electronic remote access established under Section 3.1, which covers electronic access controls for low-impact BES Cyber Systems with qualifying external routable connectivity.

This means the organization should maintain consistency between:

• Its Section 3.1 connectivity analysis
• Its network diagrams
• Its firewall and access-control configurations
• Its vendor access process
• Its Section 6 controls

A common compliance risk is documenting one architecture for Section 3 while operating a different vendor access model in practice.

For example, a diagram may show one approved VPN path, while a field device also maintains a manufacturer-controlled outbound connection. The organization should evaluate both pathways instead of limiting its review to the connection shown in the original compliance diagram.

Start your 21-day free trial and see how VComply helps your team bring structure, accountability, and visibility to your compliance operations

What If the Organization Does Not Allow Vendor Remote Access?

Section 6 applies to applicable assets that allow vendor electronic remote access.

Where an organization concludes that no qualifying access is allowed, the standard’s Section 6 control may not be triggered for that asset. However, the organization should be able to support that conclusion.

A defensible record may include:

• Architecture diagrams
• Firewall configuration reviews
• Confirmation from operational owners
• Vendor contract terms
• Review of support arrangements
• Confirmation that vendor accounts do not exist
• Confirmation that persistent vendor connections are blocked
• Change-management controls that identify new connectivity

This evidence approach is an inference from the requirement’s applicability language rather than a separate mandatory inventory or certification requirement.

The conclusion should also be reviewed when the environment changes. A software upgrade, new maintenance agreement, cloud service, firewall change or equipment replacement could introduce vendor connectivity that did not exist during the original analysis.

Mandatory Requirements vs. Security Best Practices

Organizations should distinguish clearly between what CIP-003-9 requires and what may strengthen the security program.

This distinction is important for both compliance credibility and product evaluation.

A technology provider may describe its preferred architecture as necessary for CIP-003-9. The standard, however, permits various operational, procedural and technical methods. Responsible Entities should select controls based on their risk, architecture and ability to demonstrate the required outcomes.

A Practical CIP-003-9 Implementation Framework

Step 1: Update the cybersecurity policy

Confirm that the policy set addresses vendor electronic remote access security controls under R1.2.6.

Record:

• Policy owner
• Revision
• Review date
• CIP Senior Manager approval
• Next review date
• Related procedures

The policy should establish direction and accountability without attempting to contain every technical instruction.

Step 2: Define vendor and electronic remote access

Create internal definitions that reflect the organization’s operating environment.

Address:

• Contractors
• Equipment manufacturers
• Managed service providers
• Integrators
• Software providers
• Long-term onsite third parties
• Vendor-owned devices
• User-based access
• Machine-to-machine communications
• Persistent and temporary connections

Document why the definitions are appropriate.

Step 3: Map access pathways

For each applicable asset or group of assets, identify:

• Vendor
• Business purpose
• Connection pathway
• Source and destination
• Account or system identity
• Access technology
• Whether access is persistent or time-bound
• Who approves access
• Who operates the access mechanism
• How the activity is logged
• How the connection is disabled

Although R2 does not require a discrete low-impact asset inventory, an access map can help the organization operate Section 6 effectively.

Step 4: Select the determination method

Match the control to the connection type.

For user sessions, this may include login alerts, account reports or session records.

For system-to-system communications, it may include firewall logs, connection monitoring, application logs or network-flow records.

Step 5: Select the disablement method

Document both routine and emergency disablement.

Identify:

• Authorized personnel
• Technical steps
• Dependencies
• Expected completion time
• Escalation contacts
• Restoration approval
• Evidence produced

Step 6: Establish malicious-communication detection

Define where detection will occur and which technology or review method will be used.

Ensure that the control addresses both inbound and outbound communications.

Connect the resulting alerts with the organization’s incident-response process under Attachment 1, Section 4.

Step 7: Test the operating process

Walk through realistic scenarios such as:

• Vendor account compromise
• Malicious outbound traffic
• Vendor termination
• Emergency access shutdown
• Unavailable primary administrator
• Failure of the remote-access platform
• Discovery of an undocumented connection

Record the results and correct any gaps.

Step 8: Build the evidence package

Do not wait for an audit request.

Maintain requirement-level records showing:

• Policy approval
• Process documentation
• Access determination
• Disablement capability
• Detection activity
• Alert review
• Exceptions
• Testing
• Remediation
• Management oversight

CIP-003-9 Evidence Matrix

Common CIP-003-9 Compliance Mistakes

Updating the policy without implementing the control

R1.2.6 addresses policy. Section 6 under R2 requires implementation.

An approved policy alone does not prove compliance with the operating requirement.

Treating all vendor access as interactive logins

Some vendor access occurs through persistent system-to-system communication, cloud management platforms, monitoring agents or outbound connections.

The analysis should cover the actual architecture.

Looking only at inbound communications

Section 6.3 expressly includes inbound and outbound malicious communications.

Relying on a VPN as the complete control

A VPN may form part of the solution, but it does not automatically prove that the entity can determine access, disable it and detect malicious communications.

Depending entirely on the vendor

The Responsible Entity remains accountable for its compliance process. Vendor tools and records can support the program, but responsibilities and evidence should be clearly established.

Failing to document internal interpretations

Because terms such as vendor electronic remote access permit architectural flexibility, entities should document definitions, boundaries and decision rules.

Maintaining procedures that do not match technology

A procedure may refer to an old VPN, firewall or vendor account process that is no longer used.

Ignoring changes after implementation

New equipment, service contracts, firmware, cloud systems and network changes can create additional access paths.

Inability to demonstrate disablement

Knowing that an account “could probably be disabled” is weaker than having a defined, owned and verified method.

Failing to connect alerts with incident response

Detection provides limited value when no one is assigned to investigate, classify and escalate the alert.

Lessons From Previous Low-Impact Audits

FERC’s 2022 report on CIP audits identified 21 findings relating to CIP-003 Requirement R2 across U.S. registered entities from 2016 through 2022. Audit staff found that some organizations’ low-impact policies, procedures and controls would benefit from regular reassessment, particularly in incident response and management of Transient Cyber Assets.

The lesson for CIP-003-9 is broader than the individual findings.

Organizations should not assume that a control remains effective simply because it was accepted during implementation. Personnel, vendors, networks, tools and business processes change. The cybersecurity plan should evolve with them.

CIP-003-9 Audit-Readiness Checklist

Applicability and scope

• Confirm applicable Responsible Entity functions.
• Confirm assets containing low-impact BES Cyber Systems.
• Document which assets allow vendor electronic remote access.
• Review persistent and temporary access.
• Review user and system-to-system connections.
• Document conclusions where access is not allowed.

Governance

• Update policies for R1.2.6.
• Obtain CIP Senior Manager approval.
• Confirm the 15-calendar-month review schedule.
• Document delegated authority.
• Assign owners for Sections 6.1, 6.2 and 6.3.

Section 6.1

• Define the method for determining vendor access.
• Identify the systems producing access evidence.
• Verify that vendor sessions or communications are visible.
• Retain access approvals and records.
• Review exceptions.

Section 6.2

• Document how each access type can be disabled.
• Identify authorized personnel.
• Address emergency disablement.
• Verify access can be stopped without vendor assistance where practical.
• Retain disablement evidence.

Section 6.3

• Cover inbound communications.
• Cover outbound communications.
• Define known and suspected malicious activity.
• Assign alert reviewers.
• Connect detection with incident response.
• Retain alert and investigation records.

Evidence and assurance

• Link evidence to the correct requirement.
• Confirm dates and owners are visible.
• Retain procedures and implementation records.
• Track identified gaps.
• Verify corrective-action closure.
• Reassess controls after material changes.

How VComply Supports CIP-003-9 Governance

VComply helps energy and utility organizations manage the compliance operating layer surrounding CIP-003-9. Teams can map R1.2.6 and Attachment 1, Section 6 to internal controls, assign owners, schedule recurring reviews and collect evidence showing that vendor-access processes were completed.

VComply can also centralize policy approvals, access-review records, risk decisions, control exceptions, audit requests and corrective actions. Dashboards help compliance leaders see which activities are complete, which evidence is missing and which issues require escalation.

VComply does not replace:

• Remote-access technology
• Firewalls
• VPNs
• IDS or IPS tools
• SIEM platforms
• Malware protection
• OT security monitoring

Those systems implement or support technical controls. VComply connects the requirements, owners, reviews, evidence and remediation surrounding them.

CIP-003-9 Audit Evidence Checklist

Use this checklist to review whether your organization has documented and implemented the governance and vendor electronic remote access controls required under NERC CIP-003-9.

CIP-003-9 requires applicable Responsible Entities to maintain approved cybersecurity policies, implement documented cybersecurity plans for assets containing low-impact BES Cyber Systems, designate a CIP Senior Manager, and manage permitted delegations of authority. Attachment 1, Section 6 requires methods to determine vendor electronic remote access, disable that access, and detect known or suspected malicious inbound and outbound communications associated with it.

1. Applicability and Scope

• Confirm the organization is a Responsible Entity subject to CIP-003-9.
• Confirm the applicable registered functions.
• Identify the assets determined under CIP-002 to contain low-impact BES Cyber Systems.
• Determine which applicable assets allow vendor electronic remote access.
• Confirm that the relevant vendor access is established through electronic access permitted under Attachment 1, Section 3.1.
• Review temporary, permanent, interactive, and system-to-system vendor connections.
• Review connections passing through corporate IT, cloud platforms, managed gateways, or third-party networks.
• Document the organization’s interpretation of “vendor electronic remote access.”
• Document the business purpose for each permitted vendor access path.
• Record the technical and compliance owners responsible for each access method.
• Document the basis for concluding that Section 6 does not apply to an asset where vendor electronic remote access is not allowed.
• Establish a process for reassessing applicability after network, vendor, equipment, software, or service changes.

Evidence examples:

• Applicability assessment
• CIP-002 categorization records
• Network and architecture diagrams
• Vendor access register
• Firewall and remote-access configuration reviews
• Asset-owner confirmations
• Vendor contracts or support agreements
• Change-management records

CIP-003-9 does not require a discrete inventory or list of low-impact BES Cyber Systems or their BES Cyber Assets under Requirement R2. An organization may still maintain an access or connectivity map to support implementation and audit readiness.

2. Cybersecurity Policy Governance

• Confirm the cybersecurity policy addresses vendor electronic remote access security controls.
• Verify that vendor electronic remote access is included under the low-impact policy topics required by R1.2.6.
• Identify the policy owner.
• Confirm the current policy version is approved.
• Confirm the CIP Senior Manager approved the policy.
• Verify that the policy was reviewed and approved within the required 15-calendar-month period.
• Confirm the review date is clearly documented.
• Record the next scheduled review date.
• Confirm policy changes are reflected in related procedures and operating controls.
• Retain previous policy versions and approval histories.

Evidence examples:

• Approved cybersecurity policy
• Policy revision history
• Document-management workflow
• Review record
• CIP Senior Manager approval
• Policy publication or distribution record
• Related procedure references

Requirement R1 requires review and CIP Senior Manager approval of the applicable documented cybersecurity policies at least once every 15 calendar months.

3. Documented Cybersecurity Plan

• Confirm the organization has one or more documented cybersecurity plans covering all applicable sections of Attachment 1.
• Confirm the plan includes a specific vendor electronic remote access process under Section 6.
• Verify that the plan describes how the organization determines vendor access.
• Verify that the plan describes how the organization disables vendor access.
• Verify that the plan describes how malicious inbound communications are detected.
• Verify that the plan describes how malicious outbound communications are detected.
• Identify the owner responsible for maintaining the Section 6 process.
• Confirm the documented process matches the current technical environment.
• Confirm the process identifies the systems, teams, and technologies involved.
• Confirm the plan includes escalation and exception-handling procedures.
• Retain evidence showing that the documented process has been implemented.

Evidence examples:

• Low-impact cybersecurity plan
• Section 6 procedure
• Remote-access standard
• Workflow documentation
• Roles and responsibilities matrix
• Technical implementation records
• Control testing records
• Exception procedures

Requirement R2 requires both the documented cybersecurity plans and additional evidence demonstrating implementation of those plans.

4. Vendor Access Identification and Mapping

• Identify vendors with electronic remote access to applicable low-impact environments.
• Record the service or support activity requiring access.
• Identify whether access is user-initiated or system-to-system.
• Identify whether access is temporary, scheduled, persistent, or activated only when needed.
• Record the account, application, certificate, gateway, protocol, or connection used.
• Identify the source and destination of the connection.
• Record the facilities or systems that may be reached.
• Identify the business owner approving the access.
• Identify the technical owner administering the access.
• Record the date access was approved.
• Record the access expiration or review date.
• Confirm vendor access is limited to its approved business purpose.
• Confirm undocumented vendor access paths have been investigated and resolved.
• Review vendor access following contract termination or service changes.

Evidence examples:

• Vendor access register
• Vendor account report
• Network-flow documentation
• Access request and approval record
• Remote-access architecture diagram
• VPN or gateway configuration
• Vendor support agreement
• Account expiration record

5. Section 6.1: Determining Vendor Electronic Remote Access

• Document one or more methods used to determine when vendor electronic remote access exists or occurs.
• Confirm the method covers each relevant type of vendor connection.
• Confirm the organization can identify which vendor initiated or maintained the access.
• Confirm the organization can identify the affected asset, system, or site.
• Confirm access events include a date and time.
• Confirm evidence is retained for vendor login or session activity.
• Confirm alerts are reviewed by an assigned individual or team.
• Confirm unexpected or unauthorized sessions are investigated.
• Confirm persistent system-to-system connections are included in the process.
• Verify that failed or unavailable logging is detected and addressed.
• Retain evidence from a representative sample of vendor access activity.
• Record identified exceptions and corrective actions.

Possible evidence:

• Preauthorization records
• Vendor login alerts
• VPN logs
• Jump-server logs
• Remote-access gateway reports
• Session-monitoring records
• Session recordings
• SIEM alerts
• Firewall logs
• System logs
• Time-of-need session initiation records
• Manual access reviews

NERC lists preauthorization, login alerts, session monitoring, security information-management alerts, time-of-need session initiation, session recording, and system logs as possible Section 6.1 evidence. These are examples rather than mandatory technologies.

6. Section 6.2: Disabling Vendor Electronic Remote Access

• Document one or more methods for disabling each type of vendor electronic remote access.
• Confirm the method covers both user accounts and system-to-system connections.
• Identify the individual or role authorized to disable access.
• Identify the team technically capable of disabling access.
• Document routine access-revocation procedures.
• Document emergency access-disablement procedures.
• Confirm the organization can disable access without unnecessary dependence on the vendor.
• Confirm vendor accounts can be disabled.
• Confirm certificates, tokens, keys, or credentials can be revoked where applicable.
• Confirm VPN, remote desktop, or remote-control access can be disabled.
• Confirm firewall, router, switch, application, or gateway permissions can be removed.
• Confirm ports, services, or protocols can be blocked where applicable.
• Confirm physical network connectivity can be removed when required.
• Document how access is restored after authorized approval.
• Retain evidence of actual or tested access disablement.
• Record any failed disablement test and resulting corrective action.

Possible evidence:

• Disabled vendor account record
• Revoked certificate or token
• Firewall-rule change
• Disabled VPN profile
• Removed application permission
• Closed port or service
• Blocked source address
• Network-disconnection record
• Change-management ticket
• Emergency access-removal record
• Administrative procedure
• Test results

NERC identifies account disablement, removal of access permissions, blocking ports or services, disabling communication protocols, and removing physical connectivity as possible Section 6.2 evidence.

7. Section 6.3: Detecting Malicious Communications

• Document one or more methods for detecting known or suspected malicious communications associated with vendor remote access.
• Confirm the process covers inbound communications.
• Confirm the process covers outbound communications.
• Identify the systems or tools performing the detection.
• Define what constitutes known or suspected malicious activity.
• Identify the logs, events, alerts, or traffic reviewed.
• Assign responsibility for reviewing alerts.
• Define the expected alert-review frequency.
• Confirm alerts are investigated and documented.
• Confirm suspicious vendor activity can be associated with the relevant connection or vendor.
• Confirm significant events are escalated through the incident-response process.
• Confirm the organization can disable vendor access during an investigation when necessary.
• Document how false positives are evaluated and resolved.
• Retain evidence showing that monitoring or log-review processes operated.
• Track identified monitoring gaps through corrective action.
• Confirm detection processes continue to operate after system or vendor changes.

Possible evidence:

• IDS or IPS alerts
• Firewall threat alerts
• Anti-malware records
• SIEM events
• Network-monitoring alerts
• Automated log reviews
• Manual log-review records
• Vendor-session alerts
• Investigation tickets
• Incident records
• Escalation records
• Corrective-action records

NERC identifies anti-malware technology, IDS or IPS, automated or manual log reviews, and alerting as possible evidence for Section 6.3.

8. Incident Response Integration

• Confirm malicious vendor communications are covered by the Cyber Security Incident response process.
• Define the criteria for escalating vendor-related alerts.
• Identify the personnel responsible for classifying an event.
• Document communication paths between compliance, cybersecurity, IT, OT, operations, and vendor-management teams.
• Define when vendor access should be suspended.
• Define when leadership or the CIP Senior Manager should be notified.
• Define when external reporting obligations should be evaluated.
• Retain investigation and response evidence.
• Document lessons learned following an actual event or exercise.
• Convert identified gaps into corrective actions.
• Verify that corrective actions are completed and reviewed.

Evidence examples:

• Incident-response plan
• Alert investigation
• Incident ticket
• Internal notification
• Vendor correspondence
• Access-suspension record
• Root-cause analysis
• Lessons-learned report
• Corrective-action record

9. Change Management and Ongoing Review

• Require a CIP-003-9 impact review when new vendor access is proposed.
• Review remote-access implications before approving network or firewall changes.
• Review access when vendors, contracts, equipment, or support models change.
• Review access when new cloud or remote-monitoring services are introduced.
• Confirm decommissioned vendor connections are removed.
• Verify diagrams and procedures remain aligned with the actual environment.
• Reassess assets previously determined not to allow vendor access.
• Review persistent connections periodically.
• Review expiring vendor accounts and credentials.
• Track temporary exceptions and confirm they have expiration dates.
• Obtain appropriate approval for material process changes.
• Retain change-review and approval evidence.

Evidence examples:

• Change ticket
• Security-impact assessment
• Updated network diagram
• Vendor-access review
• Configuration record
• Decommissioning record
• Exception approval
• Post-implementation review

10. Testing and Control Validation

The standard requires documented and implemented methods but does not prescribe a fixed testing interval for Section 6. Testing is a recommended way to demonstrate that the controls remain operational.

• Test whether vendor access can be identified.
• Test whether an authorized user can disable vendor access.
• Test emergency disablement when the primary administrator is unavailable.
• Test account-based vendor access.
• Test applicable system-to-system access.
• Confirm inbound malicious-communication alerts are received.
• Confirm outbound malicious-communication alerts are received.
• Confirm alerts reach the assigned reviewer.
• Confirm investigation and escalation procedures work.
• Record the systems, date, participants, and results of each test.
• Assign corrective actions for failed or incomplete tests.
• Retest after remediation.
• Obtain control-owner or compliance approval of the completed test.

Evidence examples:

• Test plan
• Test screenshots
• Alert records
• Access-disablement record
• Participant list
• Test results
• Identified findings
• Corrective-action evidence
• Retest approval

11. CIP Senior Manager and Delegation Records

• Confirm the CIP Senior Manager is identified by name.
• Retain the dated designation record.
• Confirm any change in CIP Senior Manager was documented within 30 calendar days.
• Determine whether authority has been delegated.
• If authority is delegated, document the delegate by name or title.
• Identify the specific actions delegated.
• Record the delegation date.
• Obtain CIP Senior Manager approval.
• Update delegation records within 30 calendar days of any change.
• Confirm expired or withdrawn delegations have been removed.

Evidence examples:

• CIP Senior Manager designation
• Delegation-of-authority record
• Approval record
• Change history
• Responsibility matrix

Requirements R3 and R4 establish the named CIP Senior Manager and permitted delegation documentation obligations.

12. Evidence Quality Review

For every evidence item, confirm:

• The applicable requirement or Section 6 part is identified.
• The evidence covers the correct asset, system, vendor, or connection.
• The activity date is visible.
• The performer or responsible owner is visible.
• The reviewer or approver is identified where required.
• The evidence shows implementation, not only policy intent.
• The evidence covers the applicable audit period.
• The evidence is readable and complete.
• Screenshots include enough context to understand what they prove.
• Logs include relevant timestamps and source information.
• File names follow a consistent naming convention.
• Sensitive information is stored with appropriate access restrictions.
• Exceptions are connected to approvals and remediation.
• Corrective actions include closure evidence.
• Evidence can be retrieved promptly during an audit.

13. Evidence Retention

• Retain evidence for each CIP-003-9 requirement for at least three calendar years.
• Confirm evidence covers the complete period since the previous audit where requested.
• Retain noncompliance-related information until mitigation is completed and approved, or for the standard retention period, whichever is longer.
• Follow any extended retention direction issued by the Compliance Enforcement Authority.
• Ensure records remain accessible after personnel, system, or vendor changes.
• Verify that evidence repositories are backed up and access-controlled.
• Document any approved evidence-destruction process.

CIP-003-9 specifies a three-calendar-year evidence-retention period, subject to longer retention for investigations or unresolved noncompliance.

Final Audit Readiness Review

Before submitting evidence, verify:

• The current policy addresses vendor electronic remote access.
• The policy was reviewed and approved within 15 calendar months.
• The cybersecurity plan documents all three Section 6 controls.
• The documented controls match actual operating practices.
• Vendor access paths have been evaluated.
• Evidence demonstrates how vendor access is determined.
• Evidence demonstrates how vendor access can be disabled.
• Evidence demonstrates detection of malicious inbound communications.
• Evidence demonstrates detection of malicious outbound communications.
• Alert investigation and incident escalation are documented.
• Findings and exceptions have assigned owners and due dates.
• Corrective actions include verification of closure.
• The CIP Senior Manager and delegation records are current.
• Evidence has been retained for the required period.
• Subject matter experts can explain the process and supporting evidence.
• Compliance has completed a final requirement-level review.

Ready to strengthen compliance management and compliance across your organization, Book a personalized demo with VComply and take the first step toward smarter compliance management.

Frequently Asked Questions

What is NERC CIP-003-9?

NERC CIP-003-9 is the Security Management Controls Reliability Standard. It establishes governance and cybersecurity-plan requirements for applicable BES Cyber Systems, including vendor electronic remote-access controls for low-impact environments.

When did CIP-003-9 become effective?

CIP-003-9 became effective on April 1, 2026.

What is the main change in CIP-003-9?

The main change is the addition of vendor electronic remote-access security controls under R1.2.6 and Attachment 1, Section 6.

What are the three Section 6 requirements?

Responsible Entities must implement methods for determining vendor electronic remote access, disabling that access, and detecting known or suspected inbound and outbound malicious communications.

Who must comply with CIP-003-9?

Applicable Responsible Entities include Balancing Authorities, certain Distribution Providers, Generator Operators, Generator Owners, Reliability Coordinators, Transmission Operators and Transmission Owners.

Does CIP-003-9 apply to every low-impact asset?

The Section 6 controls apply to assets containing low-impact BES Cyber Systems that allow vendor electronic remote access established under Section 3.1.

Does CIP-003-9 define “vendor”?

The standard does not create a specific glossary definition of vendor for Section 6. Entities should document how they interpret and apply the term in their environment.

Does it define vendor electronic remote access?

It does not establish a narrow glossary definition. NERC intentionally provided flexibility for different systems, configurations, accounts and communication paths.

Does the requirement cover system-to-system connections?

The standard is not limited to interactive user sessions. Organizations should evaluate vendor applications, systems, accounts, privileges and communication paths relevant to their architecture.

Is multi-factor authentication required?

Section 6 does not explicitly require multi-factor authentication. MFA may be a valuable security control, but it should not be presented as a universal express requirement of CIP-003-9.

Does CIP-003-9 require session recording?

No. Session recording is listed as one possible form of evidence for determining vendor access, not as a mandatory control.

Does the standard require a zero-trust platform?

No. The standard does not prescribe zero-trust architecture or one particular remote-access product.

Is a formal inventory of low-impact BES Cyber Systems required?

R2 states that an inventory, list or discrete identification of low-impact BES Cyber Systems or their BES Cyber Assets is not required.

What evidence can support Section 6.1?

Evidence may include access preauthorization, login alerts, session monitoring, SIEM alerts, time-of-need activation, session recording and system logs.

What evidence can support Section 6.2?

Evidence may include disabled vendor accounts, blocked ports, removed firewall permissions, disabled VPN access, revoked communications or physical disconnection.

What evidence can support Section 6.3?

Evidence may include anti-malware records, IDS or IPS alerts, automated log reviews, manual log reviews and alert investigation records.

What if an organization does not allow vendor remote access?

The organization should document and support that conclusion. It should also monitor changes that could introduce vendor connectivity later.

Does policy approval alone satisfy CIP-003-9?

No. R1 requires policy governance, while R2 requires the documented cybersecurity plans to be implemented.

Is CIP-003-9 the same as CIP-013?

No. Both address supply chain-related cybersecurity risk, but CIP-003-9 places specific vendor remote-access controls within the low-impact security-management standard.

Can VComply replace a remote-access security platform?

No. VComply supports compliance governance, ownership, policy, evidence, audits and remediation. It does not replace the technical systems used to provide, monitor or block remote access.