> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/regulatory-framework-mappings/nerc-cip/cip-003-9-003-11.md). # CIP-003-9/003-11 Maps Dispel capabilities to NERC CIP-003-9 and CIP-003-11 for OT security and compliance This page explains how the **Dispel Zero Trust Engine (ZTE)** can support your program’s alignment to **NERC CIP-003 (Security Management Controls)**—with specific attention to **Low Impact** BES Cyber System environments (where CIP-003 contains prescriptive “plan” controls), and how those same Dispel capabilities could be leveraged in **Medium/High Impact** environments (where CIP-003 is primarily a governance/policy anchor and technical controls are implemented under other CIP standards). > **Audience:** OT security and compliance stakeholders evaluating whether Dispel can be used to satisfy or support CIP-003 controls and evidence expectations. *** {% hint style="info" %} ### Important notes (read first) * This mapping is provided for implementation guidance and audit preparation. **Your organization remains responsible** for determining applicability, documenting procedures, and demonstrating compliance. * **CIP-003 R2 (Cyber Security Plan(s) with Attachment 1 controls)** applies to **Responsible Entities with Low Impact BES Cyber Systems**. For Medium/High Impact BES Cyber Systems, CIP-003 primarily requires policies, accountability, and delegation; technical controls are largely implemented under other standards (e.g., CIP-005, CIP-007, CIP-010, CIP-011, etc.). * **CIP-003-11** has been filed and published for regulatory action with an associated implementation plan. You should confirm enforceability timelines for your jurisdiction and registration status. {% endhint %} *** ### In scope **Dispel product in scope** * **Dispel Zero Trust Engine (ZTE)**, including: * Dispel Virtual Desktops (VDIs) used as managed “jump hosts” * Session recording / replay * Integrated Threat Monitoring (optional add-on module) * Exportable audit logs and access governance controls (e.g., Access Windows) **Dispel deployment models referenced** * **SaaS**: Dispel-managed cloud-hosted platform services; customer/on-prem connectivity via customer-deployed gateways (Wicket ESIs). * **Customer Cloud (single-tenant hosted)**: Deployed into your cloud environment (e.g., AWS/Azure) with customer-selected residency and infrastructure ownership boundaries. * **On-Premises**: Fully contained deployment inside customer-controlled environments (including scenarios that are offline or air-gapped). *** ### How CIP-003 fits into the NERC CIP program (why this standard exists) CIP-003 is the **management-controls backbone** of NERC CIP. It does two things: 1. **Governance and accountability:** It requires a Responsible Entity to maintain leadership-approved cyber security policies, identify a senior accountable manager (the CIP Senior Manager), and document delegation of authority. 2. **Baseline technical expectations for Low Impact BES Cyber Systems:** Because Low Impact environments do not have the same breadth of prescriptive controls as Medium/High, CIP-003 includes a required set of baseline plan sections (Attachment 1) covering awareness, physical security, electronic access controls, incident response, and protections against malicious code introduction—plus vendor remote access controls (in CIP-003-9) and expanded communications security controls (in CIP-003-11). Dispel is most directly relevant where CIP-003 demands **c**ontrolled remote access, authentication, monitoring, logging, and evidence—especially in the Attachment 1 electronic access control sections for Low Impact environments. *** ### Version scope: CIP-003-9 vs CIP-003-11 (what changed and why it matters) {% tabs %} {% tab title="CIP-003-9" %} **CIP-003-9** strengthens Low Impact controls—especially around vendor electronic remote access (e.g., explicitly requiring a method to determine active vendor remote access, disable it when no longer needed, and detect known/suspected malicious communications associated with vendor remote access). Operationally, many Responsible Entities address CIP-003-9 by standardizing vendor remote access through a controlled access platform that can enforce least privilege, time-bound access, and strong auditability. {% endtab %} {% tab title="CIP-003-11" %} **CIP-003-11** builds on prior revisions by expanding communications security expectations for Low Impact environments (including Shared Cyber Infrastructure supporting Low Impact BES Cyber Systems). One key shift is that requirements that were previously “vendor remote access–specific” become part of a broader inbound/outbound electronic access control construct, including: * Detecting known/suspected malicious communications for inbound/outbound electronic access * Authenticating each remote user * Protecting remote user authentication information in transit * Determining active vendor access and disabling it when no longer needed This directly increases the value of platforms that deliver controlled remote access with strong authentication, encryption, monitoring, and audit evidence—which is where Dispel is typically positioned. {% endtab %} {% endtabs %} *** ### Dispel deployment considerations in BES environments (Low / Medium / High) CIP standards are generally technology-agnostic: they focus on the *control outcomes* you must demonstrate (e.g., access restrictions, monitoring, evidence), not a mandated product architecture. That said, Responsible Entities often apply risk-based architecture decisions based on: * Whether the environment is **internet-connected** (SaaS requires some form of connectivity). * Whether internal governance or regulatory posture requires single-tenant hosting, customer-controlled cloud, or on-prem-only deployment for specific tiers or assets. * How you intend to treat and protect audit evidence such as session recordings, logs, and identity metadata. Dispel’s recommended default is SaaS for speed of deployment, continuous updates, and a managed operating model; however, Customer Cloud and On-Premises exist for cases where the Responsible Entity requires tighter residency/ownership boundaries or offline operation. *** ### Data handling and audit evidence fundamentals (important for CIP-003 narratives) In typical use, Dispel stores/processes cyber-security-relevant operational data such as: * Identity and authentication metadata * Connection/session logs and administrative audit trails * Session recordings / replays (single-tenant recording infrastructure) * File transfer artifacts (when used) * Asset inventory metadata (targets, sites, zones, routes) **Retention (typical defaults):** * Logs are typically retained for near-term operational use and longer-term archive * Session recording retention is customer-configurable and typically deployed as a rolling window (commonly \~30 days), depending on the recording capacity purchased {% hint style="warning" %} #### Handling potential BCSI exposure in session recordings Dispel is not intended to be the system-of-record for BCSI. However, it is conceivable that a user could view screens containing sensitive information through a VDI or browser session and that screen content could be captured by session recording. Treat recordings as potentially sensitive operational evidence: restrict access, define retention deliberately, and align handling with your internal classification policy. {% endhint %} *** ## Requirement R1 — Cyber Security Policies ### What CIP-003 requires (control intent) CIP-003 R1 requires that the Responsible Entity maintain documented cyber security policies that collectively address required topic areas and that those policies are reviewed and approved by the CIP Senior Manager at least once every 15 calendar months. * In **Medium/High Impact** environments, R1 is primarily about ensuring your policies cover the topic areas aligned to the broader CIP family (personnel & training, electronic security perimeters, system security management, change management, information protection, etc.). * In **Low Impact** environments, R1 ensures your policies support the baseline plan/control sections that the entity must implement under R2. ### How Dispel supports alignment Dispel does not “create your policy” or act as the CIP Senior Manager. Instead, Dispel is commonly referenced *inside* your policies and standards as the approved remote access enforcement mechanism (e.g., “All interactive remote access to OT/BES assets must be brokered through Dispel with time-bound access approval, least-privilege ACLs, session recording, and logging forwarded to the monitoring stack.”). Dispel can also support policy maturity by making the policy enforceable in day-to-day operations: * You can implement least privilege and scoped access controls down to device/port/protocol level. * You can require time-bound access approval before access is permitted. * You can produce consistent evidence (logs, session recordings, access approvals) that supports policy compliance. ### What auditors typically expect Auditors typically expect to see: * The actual policy documents, revision history, and evidence of CIP Senior Manager approval within the required interval * Policy language that is consistent with how access is actually implemented * Traceability from policy statements → procedures/standards → technical implementation evidence #### Low / Medium / High summary (R1) | Topic | Low Impact BES Cyber Systems | Medium Impact BES Cyber Systems | High Impact BES Cyber Systems | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Is R1 applicable? | Yes | Yes | Yes | | What R1 primarily drives | Policy basis for Low Impact plan controls and governance cadence | Governance anchor; policy coverage across the CIP control families | Same as Medium, typically with higher internal rigor and stronger evidence expectations | | How Dispel helps | Provides a standard, enforceable remote access mechanism you can reference in policy; produces audit-ready access evidence | Used as a controlled remote access implementation referenced in CIP-005/CIP-007 aligned policies and procedures | Same as Medium; often paired with more restrictive deployment decisions (Customer Cloud / On-Prem) based on risk posture | | SaaS vs On-Prem considerations | SaaS often acceptable when connectivity exists and policy permits; otherwise Customer Cloud/On-Prem | Same decision model—entity risk posture typically drives deployment boundaries | Same decision model; stricter internal constraints are more common | *** ## Requirement R2 — Cyber Security Plan(s) for Low Impact (Attachment 1) ### What CIP-003 requires (control intent) CIP-003 R2 requires Responsible Entities with Low Impact BES Cyber Systems to implement one or more documented cyber security plan(s) that include the sections in Attachment 1. The intent is to ensure Low Impact environments have baseline controls for awareness, physical protection, access restrictions, incident response readiness, and malware/removable media risk mitigation—plus explicit controls around remote/vendor access and monitoring. **Key practical point:** R2 is satisfied by demonstrating: 1. your plan(s) include each required section, and 2. you can show implementation evidence for each section. ### How Dispel supports alignment (where it fits—and where it does not) Dispel is most directly mapped to the **Electronic Access Controls** sections, where auditors will look for: * Restriction to only necessary inbound/outbound connectivity paths * Strong authentication for remote users and connectivity methods (as applicable) * Evidence that access is controlled, monitored, and reviewable Dispel is *supporting*, not primary, for Awareness, Physical Security, and Incident Response governance. Those remain primarily customer-owned processes. *** ### Attachment 1 — Section 1: Cyber Security Awareness #### What the section requires This section requires that the entity reinforce cyber security practices at least once every 15 calendar months for personnel with cyber or authorized access responsibilities related to Low Impact environments. #### How Dispel supports alignment Dispel is not a security awareness training platform. However, Responsible Entities commonly incorporate Dispel operational requirements (e.g., no shared accounts, access request justification, recording notice, approved workflow expectations) into: * security awareness reinforcement communications * role-based training for OT operators, engineers, and vendors who use remote access #### What auditors typically expect Auditors typically expect to see dated evidence of reinforcement (communications, training artifacts, meeting notes, etc.). *** ### Attachment 1 — Section 2: Physical Security Controls #### What the section requires This section requires physical access controls for: * the Low Impact asset or the locations of Low Impact BES Cyber Systems, and * the cyber systems that provide the electronic access controls (where applicable) #### How Dispel supports alignment Dispel cannot enforce your facility physical security program. The relevant Dispel contribution is helping you identify which components in your architecture are “security-enforcing” and therefore should be included in your physical protection scope. For example: * On-Prem deployments: your hosted Dispel components (recording servers, gateways, virtual infrastructure) become physical assets you must protect. * SaaS deployments: customer-side gateways (i.e. Wicket ESIs) and any customer-hosted components remain in your physical protection scope; cloud infrastructure physical security is part of the provider/operator model. *** ### Attachment 1 — Section 3: Electronic Access Controls This is the most directly relevant section for Dispel. {% tabs %} {% tab title="CIP-003-9 (Section 3 + Section 6)" %} #### What CIP-003-9 requires (control intent) CIP-003-9 requires Low Impact environments to: * Permit only inbound and outbound electronic access that the entity deems necessary for routable protocol communications. * Authenticate dial-up connectivity (if used). * Additionally (in Section 6), implement vendor remote access controls including the ability to determine active vendor remote access, disable it when no longer needed, and detect known/suspected malicious communications for vendor electronic remote access. #### How Dispel supports alignment Dispel is designed to make “only what’s necessary” implementable and auditable by centralizing remote access through a controlled pathway: * **Least privilege enforcement:** Access can be scoped down to device/IP and port/protocol using ACL concepts rather than broad network access. * **Time-bound access:** Access Windows allow administrators to grant just-in-time access; without an access window, user access can be restricted. * **Vendor visibility and shutdown:** You can identify who has access, who approved it, and the time window; you can revoke or disable access quickly when work is complete or risk is identified. * **Monitoring and detection:** Dispel can provide high-fidelity session/connection telemetry and, with Integrated Threat Monitoring, a managed detection layer; otherwise, forwarding Dispel logs to your SIEM/monitoring stack supports the “detect known/suspected malicious communications” outcome for remote access pathways. #### SaaS vs On-Prem relevance In SaaS, the control plane and managed session infrastructure are cloud-hosted, while customer-side gateways provide the controlled path into customer networks. In Customer Cloud/On-Prem, you can place more components under your direct control to align with stricter internal architecture policies or offline needs. {% endtab %} {% tab title="CIP-003-11 (Expanded Section 3)" %} #### What CIP-003-11 requires (control intent) CIP-003-11 consolidates and expands electronic access expectations so Low Impact environments can better resist coordinated cyber threats. In addition to restricting connectivity, it emphasizes: * Detecting known/suspected malicious communications for inbound and outbound electronic access * Authenticating each remote user * Protecting remote user authentication information in transit * Determining active vendor access and disabling it when no longer needed #### How Dispel supports alignment Dispel’s contribution is strongest where the standard requires both **control enforcement** and **evidence**: **1) Restricting connectivity (“only what’s necessary”)** Dispel can implement access down to device/port/protocol and enforce that non-permitted connections are not established. **2) Authenticating each remote user** Dispel supports federated identity (e.g., OIDC-based SSO) and role-based access models so each remote user is uniquely authenticated and authorized according to policy. **3) Protecting authentication information in transit** Dispel sessions and tunnels are designed to be end-to-end encrypted, supporting the control intent of protecting authentication data while traversing networks. **4) Detecting known/suspected malicious communications** Dispel can produce detailed logs and session telemetry for detection and investigation, and Integrated Threat Monitoring can add continuous monitoring and response. Where customers operate their own SOC/SIEM stack, Dispel telemetry can be forwarded for centralized detection and alerting. **5) Determining and disabling vendor access** Access Windows and administrative controls provide a direct mechanism for proving: * when vendor access was permitted, * who approved it, * what the vendor could access, and * how access is revoked/disabled when no longer required. {% endtab %} {% endtabs %} *** ### Attachment 1 — Section 4: Cyber Security Incident Response #### What the section requires This section requires that the entity have a cyber security incident response plan, including roles/responsibilities, handling steps, testing at least once every 36 months, and updates after tests/incidents. #### How Dispel supports alignment Dispel does not replace your incident response plan. It strengthens incident response execution and evidence by providing: * session recordings and session logs to support investigation and reconstruction * administrative audit trails showing who approved access and what changed * telemetry that can be integrated into the entity’s detection and response workflows *** ### Attachment 1 — Section 5: TCA & Removable Media Malicious Code Risk Mitigation #### What the section requires This section requires methods to mitigate the introduction of malicious code for applicable systems, including handling of Transient Cyber Assets (TCAs) and Removable Media, and special handling where a party other than the Responsible Entity manages the TCA/removable media process. #### How Dispel supports alignment Dispel is not an endpoint anti-malware solution for your field laptops or removable media process. However, Dispel can reduce risk by: * reducing the need for uncontrolled vendor endpoints to directly touch OT assets (vendors work inside controlled remote sessions) * providing audit evidence for remote activities and file transfer workflows when used * integrating logs/telemetry into your broader monitoring program *** ### Low / Medium / High summary table (R2 and Attachment 1) {% tabs %} {% tab title="CIP-003-9 (R2 Attachment 1 + Vendor Section 6)" %} | Attachment 1 / Section | Low Impact BES Cyber Systems | Medium Impact BES Cyber Systems | High Impact BES Cyber Systems | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Section 1 — Awareness | **Applicable.** Customer-owned. Dispel supports role-based operational training inputs and evidence context. | Not applicable under CIP-003 R2 (covered by other CIP requirements/program elements). | Same as Medium. | | Section 2 — Physical Security | **Applicable.** Customer-owned. Include customer-side gateways/recording components in physical scope where relevant. | Not applicable under CIP-003 R2 (physical requirements addressed elsewhere). | Same as Medium. | | Section 3 — Electronic Access Controls | **Applicable.** Dispel strongly supports this: least privilege ACLs, controlled paths, session logging/recording, and SIEM integration. | Not applicable under CIP-003 R2, but similar outcomes are typically implemented under CIP-005/CIP-007 for Medium. Dispel is often used to support those outcomes. | Same as Medium, typically with stricter internal design constraints. | | Section 4 — Incident Response | **Applicable.** Customer-owned plan; Dispel provides investigation evidence (logs + recordings). | Not applicable under CIP-003 R2 (incident response requirements addressed elsewhere). | Same as Medium. | | Section 5 — TCA & Removable Media | **Applicable.** Customer-owned; Dispel can reduce exposure by brokering access and providing audit evidence for remote workflows. | Not applicable under CIP-003 R2; similar concerns are typically addressed under other controls and internal policy. | Same as Medium. | | Section 6 — Vendor Electronic Remote Access (CIP-003-9 construct) | **Applicable.** Dispel strongly supports: time-bound access approvals, vendor session visibility, termination/disablement, and monitoring/telemetry. | Not applicable under CIP-003 R2, but vendor remote access control is typically a major focus under CIP-005/CIP-007. | Same as Medium. | | {% endtab %} | | | | {% tab title="CIP-003-11 (R2 Attachment 1 consolidated Section 3)" %} | Attachment 1 / Section | Low Impact BES Cyber Systems | Medium Impact BES Cyber Systems | High Impact BES Cyber Systems | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Section 1 — Awareness | **Applicable.** Customer-owned. Dispel supports role-based operational training inputs and evidence context. | Not applicable under CIP-003 R2. | Same as Medium. | | Section 2 — Physical Security | **Applicable.** Customer-owned. Include customer-side gateways/recording components in physical scope where relevant. | Not applicable under CIP-003 R2. | Same as Medium. | | Section 3 — Electronic Access Controls (expanded) | **Applicable.** Dispel strongly supports: least privilege, per-user authentication, encrypted sessions, monitoring/detection via Integrated Threat Monitoring or SIEM forwarding, and vendor access determination/disablement via Access Windows and admin controls. | Not applicable under CIP-003 R2, but similar outcomes are typically implemented under CIP-005/CIP-007 for Medium. | Same as Medium, typically with stricter internal design constraints. | | Section 4 — Incident Response | **Applicable.** Customer-owned plan; Dispel provides investigation evidence (logs + recordings). | Not applicable under CIP-003 R2. | Same as Medium. | | Section 5 — TCA & Removable Media | **Applicable.** Customer-owned; Dispel can reduce exposure by brokering access and providing audit evidence for remote workflows. | Not applicable under CIP-003 R2. | Same as Medium. | | {% endtab %} | | | | | {% endtabs %} | | | | *** ## Requirement R3 — CIP Senior Manager ### What CIP-003 requires (control intent) R3 requires the Responsible Entity to identify a **CIP Senior Manager by name** and to document changes within the required timeframe. The intent is accountability: a named senior individual is responsible for approving policies and ensuring the program is resourced and maintained. ### How Dispel supports alignment Dispel does not provide or replace this role. Where Dispel helps is indirect: * As an operational control platform, Dispel provides evidence and reporting that a CIP Senior Manager (or their delegates) can rely on for oversight, periodic reviews, and program assurance. ### What auditors typically expect Auditors typically expect a dated designation document and change tracking. #### Low / Medium / High summary (R3) | Topic | Low Impact BES Cyber Systems | Medium Impact BES Cyber Systems | High Impact BES Cyber Systems | | ----------------- | ------------------------------------------------------------------------------------------- | ------------------------------- | ----------------------------- | | Is R3 applicable? | Yes | Yes | Yes | | Control ownership | Customer-owned | Customer-owned | Customer-owned | | How Dispel helps | Indirect only: provides operational oversight evidence (access approvals, logs, recordings) | Indirect only | Indirect only | *** ## Requirement R4 — Delegation of Authority ### What CIP-003 requires (control intent) R4 requires a documented process for delegation of authority (if used), including who is delegated, for what actions, when, and approval by the CIP Senior Manager. The intent is to ensure delegated CIP actions remain controlled, auditable, and current. ### How Dispel supports alignment Dispel does not define your delegation process, but it does support the *operational reality* behind delegations by allowing you to: * separate administrative roles and operational approver roles * enforce workflow approvals for access * produce audit trails showing who approved/changed access and when ### What auditors typically expect Auditors typically expect: * the delegation documentation itself (names/titles, delegated actions, dates) * evidence that operational approvals and actions match the delegation model #### Low / Medium / High summary (R4) | Topic | Low Impact BES Cyber Systems | Medium Impact BES Cyber Systems | High Impact BES Cyber Systems | | ----------------- | --------------------------------------------------------------------------- | ------------------------------- | ----------------------------- | | Is R4 applicable? | Yes | Yes | Yes | | Control ownership | Customer-owned | Customer-owned | Customer-owned | | How Dispel helps | Supports enforceable role separation and audit trails for approvals/changes | Same | Same | *** ## Practical evidence mapping: what you can typically export from Dispel for audits When Responsible Entities use Dispel to implement remote access controls, common audit artifacts include: * Access Windows (who requested/approved access, scope, time bounds, justification, and changes) * User lists and role/group membership * Device/asset inventories and per-device ACL mappings (including allowed ports/protocols) * Administrative audit logs (changes to policies, users, ACLs, approvals) * Session logs and session recordings (as applicable) * SIEM-forwarded logs and correlation references (if used) * Threat monitoring alerts and investigation notes (if Integrated Threat Monitoring is in scope) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dispel.com/regulatory-framework-mappings/nerc-cip/cip-003-9-003-11.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.