What CIP-005-7 R3 vendor remote access requires for EACMS and PACS
If vendors can reach the systems that control access to, or monitor, your high or medium impact BES Cyber Systems, CIP-005-7 R3 requires you to manage those vendor sessions as deliberately as you manage access to the BES Cyber Systems themselves. Part 3.1 asks you to use one or more methods to determine authenticated vendor-initiated remote connections to the Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) associated with high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. Part 3.2 asks for one or more methods to terminate those connections and to control the ability to reconnect. The requirement was added in CIP-005-7 to address directives in FERC Order No. 850, which pushed the standards to close gaps in remote access to the devices that enforce the perimeter.
The risk is straightforward. An EACMS such as an Electronic Access Point or authentication server, or a PACS such as a badge controller, is the set of systems that decides who gets in and what gets seen. An unmanaged vendor session to one of them can weaken protection of everything behind it, and an attacker who rides a vendor's credentials may never touch the BES Cyber Systems directly. The difficulty in practice is that vendors use many tools, sessions are often opened by people outside your identity system, and the logs that prove a session was detected and ended sit in different places. Start by inventorying every vendor path into your EACMS and PACS, including support tools and vendor-managed monitoring, and confirm which of them your Intermediate System or other mechanisms can actually see and cut.
R3 carries a Medium Violation Risk Factor. The maximum civil penalty referenced in NERC's Sanction Guidelines is $1,584,648 per violation, per day, as adjusted in the eCFR, but actual penalties depend on the facts, including the duration, the risk and your compliance history. Compliance is monitored by your Regional Entity or NERC through audits, spot checks, self-certifications and self-reports. There is no CIP certificate. Your evidence of compliance is what you can show an auditor, and an outside party can help you prepare that evidence but cannot certify it on your behalf. Confirm the current text and effective dates against the NERC standard before you rely on them.
Which EACMS and PACS fall under vendor remote access controls
CIP-005-7 R3 applies to a narrower set of systems than the whole BES Cyber System environment, but the set is easy to get wrong. The cards below cover how categorization sets the boundary, who counts as a vendor, and which supporting systems are often left out of scope.
EACMS and PACS tied to high impact systems
R3 reaches every Electronic Access Control or Monitoring System and Physical Access Control System associated with high impact BES Cyber Systems. Start from the CIP-002 categorization, then trace which access control, monitoring and physical access hosts serve those high impact systems. Record each association in the asset inventory so the scope can be shown to an auditor without reconstruction.
EACMS and PACS tied to medium impact systems
For medium impact BES Cyber Systems, R3 applies only where those systems have External Routable Connectivity. A medium impact site without routable connections can fall outside R3 for its EACMS and PACS, while a site with one routable path to a vendor-accessible system does not. Confirm the connectivity status for each medium impact system before scoping the associated access hosts.
Who counts as a vendor
Vendors include outside maintainers, systems integrators, managed service providers, equipment manufacturers and their remote support engineers. Any party outside the entity's own workforce that opens a remote session to a covered system is in scope. Ask each contract holder to list the people and tools they use, because support staff employed by a third party often connect through accounts the entity never issued.
Vendor-initiated sessions versus staff sessions
R3 targets authenticated connections started by a vendor. Sessions opened by the entity's own staff from inside its network are handled by other controls, so the boundary depends on who starts the connection and from where. Document the initiation path for each remote method, including vendor-managed VPN clients and jump hosts, so the team can show which sessions R3 governs.
Badge controllers and camera hosts
Badge controllers, door and alarm panels, video management servers and alarm monitoring hosts often serve PACS roles and are maintained by integrators. These devices are easy to miss because they sit in facilities rather than control rooms. Check each device that grants or logs physical access, and confirm whether the vendor reaches it remotely for firmware, licensing or troubleshooting.
Identity and log systems with EACMS roles
Directory services, multi-factor authentication servers, log aggregators and security monitoring consoles can act as EACMS when they control or monitor access to high or medium impact systems. Vendors often administer these platforms for patching or tuning. Review each identity and logging host for an access control or monitoring function, and record its vendor access path alongside the systems it protects.
How to implement Part 3.1 and Part 3.2 in sequence
The sequence turns Parts 3.1 and 3.2 into a working vendor access control: each step produces a record an auditor can read, and the final test shows that a vendor session can be seen, cut off and not silently reopened. The entity owns each design decision, and an implementation partner prepares the configurations and evidence.
Inventory in-scope EACMS and PACS and their vendor paths
Start from the impact categorization under CIP-002 and list the EACMS and PACS that serve high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. For each one, record every route a vendor can use to reach it, including vendor-managed remote tools, jump hosts, VPN accounts, cloud consoles and on-site maintenance laptops. The output is a scoped inventory that the entity's CIP Senior Manager or delegate approves. The step is complete when the team can show that no in-scope system is missing from the list and that each vendor path has a named owner.
Document methods to determine vendor connections
For Part 3.1, document one or more methods that identify when an authenticated vendor-initiated remote connection to an in-scope system is active. Methods might include the remote access platform's session records, firewall state tables, or authentication logs from the identity provider. Record which method covers which path, how often it runs, and where the output is stored. For illustrative purposes, an OPNsense rule set can log each rule match for review in the live log view, which can support the network side of this record, but the entity should confirm the logging behavior in its own environment. The step closes when each vendor path maps to at least one documented detection method.
Document termination methods and reconnection controls
For Part 3.2, document the methods that end an authenticated vendor session to each in-scope EACMS and PACS, and the controls that stop it from being restarted without review. Typical controls include disabling the vendor account, revoking tokens, closing the tunnel at the firewall, and requiring a new approval before a session can be re-established. Where secrets or API tokens are issued for vendor activity, OpenBao audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed, which can help show who requested access and when. The output is a termination procedure with named tools and a reconnection rule. The step closes when a reviewer can follow the procedure from start to finish without asking the author questions.
Route vendor access through controlled logged points
Configure the approved vendor paths so that every session passes through a defined access point. The access point should enforce authentication before the session opens, record the session, and allow the entity to terminate it. Use firewall aliases to group vendor source addresses and target systems so rules stay readable and reviewable. Where the entity already runs a remote access platform for vendors, that platform may already provide these functions, and the design should use it rather than duplicate it. The output is a set of configuration baselines, change records and a rule list signed off by the system owner. The step closes when no in-scope system accepts a vendor connection through a path that is absent from the inventory.
Test detection, termination and reconnection blocking
Run a scripted test that an assessor could repeat. Open an authenticated vendor session to an in-scope EACMS or PACS, confirm the detection method records it, terminate it using the documented procedure, and then attempt to reconnect without the required approval. Capture the log entries, timestamps and the failed reconnection attempt as evidence. Repeat the test for each vendor path in the inventory. The output is a dated test record with pass or fail results and remediation tickets for any failure. The step closes when every path passes, or when each failure has an approved fix and a retest is recorded.
Set up recurring review of vendor access
Assign a recurring review of the vendor access inventory, detection logs, termination records and reconnection exceptions. The reviewer compares logged sessions against approved vendor work orders and investigates any session that has no matching request. Changes to vendor paths go through the same change control used for other BES Cyber System changes. Confirm the review interval, owner and retention period against the entity's CIP compliance program and the current text of CIP-005-7. The output is a review log, a list of follow-up actions and an updated inventory. The sequence is ongoing from this point, and the review record is the evidence that the controls still operate after the initial test.
How the work changes by where the EACMS and PACS run
When the EACMS and PACS sit in the entity's own data center, the entity owns the whole path from a vendor's session to the device. The entry point is usually a firewall, a jump host or an Intermediate System that the entity operates, so detection and termination can be built into systems it already runs. The main risk is assuming the path is known when it has not been mapped.
- Connection path: Map every route a vendor session can take to each EACMS and PACS, including out-of-band consoles and maintenance laptops, and record the routes in the network diagram.
- Detection: Log each authenticated vendor session at the Intermediate System or firewall, with rule match logging enabled on the packet filter, so every connection traces to a named vendor account.
- Termination and reconnect control: Configure session timeouts and an operator-initiated disconnect, and require a documented approval step before a vendor can reconnect.
- Self-produced evidence: Firewall rule exports, session logs, access lists and change tickets all come from systems the entity controls.
Check that session logs can be retrieved for the full audit period and that staff other than the vendor can disable a vendor account.
When the EACMS or PACS run in a cloud or colocation account the entity controls, the entity owns the configuration and the account, but the provider owns the physical facility and much of the underlying infrastructure. The control design must show which layer each method sits in. Confirm each capability with the provider before relying on it, since features differ by service and by account type.
- Connection path: Vendor routes may pass through gateways, VPN endpoints or bastion services that the entity configures in its own account, or through provider-operated access points. Identify which of these the entity administers and which the provider operates.
- Detection methods: Use entity-controlled logging of connections into the workload, and confirm whether provider-side connection records are retained, exportable and available for the audit period.
- Termination: Confirm that the entity can end a session and block reconnection at a network layer it administers, without waiting on the provider's support queue.
- Provider-produced evidence: Obtain written documentation of provider-side logging, retention and management-plane access, and agree which records the provider will supply on request.
Ask the provider for written confirmation of each capability and the format of each record, because the entity remains accountable for the control even when the provider runs the infrastructure.
When a vendor runs the EACMS or PACS as a managed service, the entity remains the Responsible Entity for the requirement, and the vendor's staff connect into the environment as part of delivering the service. The entity's leverage lies in its contract and in the points where it can observe or stop a session. Accountability for the control stays with the entity even when the operating work does not.
- Connection path: The vendor usually chooses how its staff connect, so require in writing that all vendor-initiated connections into the entity's environment pass through a point the entity controls or can observe.
- Detection and termination: Agree how each authenticated session is reported to the entity, who may end it, and how quickly. Confirm that the entity can see active sessions and not only historical ones.
- Vendor-produced evidence: Request session logs, access reviews and reconnect control records on a set schedule, and confirm the record formats and retention periods in advance.
- Contract terms: Include notification duties, log retention and export rights, audit rights, incident cooperation duties and disclosure of subcontractors who hold remote access.
Test whether the vendor can produce a complete session record for a sample period now, so the first request does not happen during an audit.
How an auditor tests CIP-005-7 R3 vendor remote access
This table compares each testing step an auditor or Compliance Enforcement Authority may take for CIP-005-7 R3, the test approach, the evidence requested and the findings that appear most often. Read it as a checklist for your own pre-audit review: each row names what the assessor will look for and where the entity's documentation or records tend to fall short. The auditor assesses the entity's own methods and records, and the audit report is issued by the auditor or Regional Entity, not by DeployOpen.
| Audit step | Test approach and evidence requested | Common findings |
|---|---|---|
| Identify in-scope EACMS and PACS | Confirm which EACMS and PACS associate with high impact BES Cyber Systems and with medium impact BES Cyber Systems that have External Routable Connectivity, starting from the CIP-002 categorization. Request the asset list and the categorization record. | Asset inventory omits a jump host, badge reader controller or monitoring server that serves vendor sessions into the in-scope environment. |
| Determine authenticated vendor-initiated connections (Part 3.1) | Ask for the documented method or methods used to determine authenticated vendor-initiated remote connections. Compare them against network logs, Intermediate System logs and access records for the audit period. | A method is documented, but no session records show it operated. Or the method only detects connections initiated through one path while vendors also use another. |
| Terminate connections and control reconnection (Part 3.2) | Request the documented termination and reconnect-control methods. Test with a sample session: confirm the connection ends and that a reconnect attempt is blocked or requires the defined control. | A reconnect path bypasses the termination control, such as a second VPN account or a cached session token that is still accepted after the session was ended. |
| Sample vendor sessions across the audit period | Auditors select a sample of vendor sessions from the period and ask for the access request, approval, authentication record, session start and end, and termination or reconnect evidence for each. | Sessions in the sample lack an approval record, or the termination timestamp is missing, so the entity cannot show the control operated for that session. |
| Verify documentation and operation | Check that the methods are written down, assigned to owners, reviewed on the defined cycle and followed in practice. Compare procedures with the tools actually configured. | Procedures describe a tool or setting that was retired or changed, and staff follow an undocumented workaround during vendor support. |
| Confirm evidence retention and integrity | Confirm that logs and records covering the audit period are retained, time-synchronized and protected from alteration, and that they can be produced on request through the Evidence Request Tool process. | Logs were rotated or overwritten before the audit period was reviewed, or timestamps across the access path do not agree. |
Evidence that proves CIP-005-7 R3 vendor remote access controls work
An auditor testing CIP-005-7 R3 will ask for records that show the methods exist, that they were applied to every in-scope EACMS and PACS, and that they worked in practice. The cards below cover the documents, inventories, logs and sampling records that connect those claims, and they explain how to keep them current between compliance audits.
Documented methods for Parts 3.1 and 3.2
Part 3.1 requires one or more methods to determine authenticated vendor-initiated remote connections to in-scope EACMS and PACS, and Part 3.2 requires one or more methods to terminate those connections and control reconnection. Keep a written document for each method that names the tool, the owner, the trigger and the step that ends a session. An auditor will compare this document against the sessions you actually recorded, so the procedure must match what staff do on the day, not only what the policy says. Review it after any change to the remote access path.
Inventory of in-scope EACMS and PACS
Build a list of every EACMS and PACS associated with high impact BES Cyber Systems and with medium impact BES Cyber Systems that have External Routable Connectivity. For each asset, record the vendor access path, including the jump host, VPN concentrator or Intermediate System it uses. The inventory is the scope statement for R3, so an asset missing from it is a gap an auditor will find by reconciling the CIP-002 categorization against your access records.
Session logs showing detection and termination
Export logs from the remote access platform showing when each authenticated vendor connection began, which account opened it, which in-scope system it reached, and when it ended. A forced termination should appear as a distinct event with an operator identity or automated rule behind it. Confirm that log timestamps are synchronized and that exports are dated, so you can show the sequence of detection, termination and any reconnection attempt.
Firewall rule sets with logged rule matches
Keep the gateway or firewall rule set that permits vendor traffic to EACMS and PACS, with the source, destination, port and protocol for each rule. OPNsense can log each rule match and display it in the live log view, which gives you a record of traffic that passed or was blocked under a specific rule. Confirm that match logging is enabled for the rules that matter, that logs are retained for your program's period, and that rule exports are taken before and after each change.
Vendor identity and credential audit logs
Vendor accounts should be individually named, authenticated and traceable to a contract or access request. OpenBao audit devices keep a detailed JSON log of each API request and response, including errors, and hash most sensitive values with HMAC-SHA256, so you can show who requested a credential without storing the secret itself. Confirm which systems in your environment write comparable audit trails, and check that vendor accounts are disabled when access ends.
Sampling records for reconnection controls
Auditors often sample a set of vendor sessions and check that reconnection was controlled. Keep a sampling log with session identifiers, the reconnection attempts that followed a termination, and the decision that allowed or refused each one. Link each approved reconnection to a change or access ticket. These records show the reconnection control operated in practice, which tool logs alone cannot prove. Tools record activity, but they do not by themselves satisfy the requirement; the procedures, approvals and reviews around them do.
What meeting CIP-005-7 R3 costs in money and effort
This table compares the main cost components of meeting CIP-005-7 R3 for vendor remote access to EACMS and PACS, who is paid for each, whether it is one-time or recurring, and what drives it up. No prices or durations are given because none were supplied, so use the table to shape a fixed-scope written quote. The main takeaway is that open-source tooling can remove some license spend but not the engineering, testing and evidence work.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses for vendor access gateways, session recording and firewall logging | Mostly recurring (subscriptions, support) with some one-time setup | Number of vendor access paths, concurrent sessions, retention period and whether the gateway is commercial or open source | Choose open-source components where the license fits your edition limits, and confirm those limits in writing before selecting a product |
| Engineering time to inventory vendor paths and build detection, termination and reconnection controls | One-time, with later changes when vendors or systems change | Count of EACMS and PACS tied to high and medium impact BES Cyber Systems, undocumented vendor access, and the number of vendor tools in use | Start from a current, accurate CIP-002 categorization and a single inventory of vendor connections before any build work |
| Configuration and testing effort for firewall rules, intermediate systems and session controls | One-time per environment, plus retesting after changes | Complexity of network segmentation, number of ESPs and access points, and how many environments (production, test, backup) need the same controls | Use reusable rule templates and aliases, and test each vendor path against a defined procedure once rather than ad hoc |
| Ongoing evidence upkeep and periodic review | Recurring | Log volume, evidence retention needs, frequency of vendor access changes, and how many people must review and sign off | Automate log collection and evidence exports, and set a fixed review cadence with named owners |
| External review or testing by an independent party, if the entity wants one | Recurring or periodic, scoped per engagement | Scope of systems tested, depth of testing, and whether the review is a readiness check or a penetration test | Limit the first review to in-scope EACMS and PACS and agree deliverables in writing before work starts |
| Auditor sampling time | Set by the auditor and Regional Entity, not by the entity's choice | Audit period, number of vendor sessions sampled, and quality of the evidence provided | Keep evidence complete and indexed so sampling does not expand into follow-up requests |
What the entity, an implementation partner and the auditor each do
The registered entity owns CIP-005-7 R3 in full. Its compliance team decides which EACMS and PACS fall in scope under the CIP-002 categorization, selects the methods that determine and terminate authenticated vendor-initiated connections, and defines when and how a reconnection is controlled. Operations teams run the vendor access process day to day, approve sessions and keep the records that prove each step happened. The entity also answers for the methods it chose, even when a partner built them.
- Scope decisions: confirming which EACMS and PACS serve high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity.
- Method selection: documenting the methods used to determine authenticated vendor connections and the methods used to terminate them and control reconnection.
- Process ownership: approving vendor access requests, assigning sponsors and maintaining the vendor access procedure.
- Evidence retention: keeping session records, termination records and change records for the audit period.
- Vendor agreements: writing contract terms that require vendors to use the entity's approved access paths.
Before relying on any tool or partner output, confirm that your compliance lead has reviewed the documented methods against the current text of CIP-005-7 and the enforcement records your Regional Entity expects.
An implementation partner such as DeployOpen prepares the systems and evidence that the entity needs for R3. Typical work is configuring the self-hosted components that gate vendor sessions, writing test scripts that show a connection is refused after termination, designing log collection so session data reaches the entity's retention store, and packaging evidence in a form the entity's auditors can follow. The partner does not decide the methods, sign off on compliance or issue any report or certificate. That authority stays with the entity and, for assessment, with the auditor or Regional Entity.
- Gateway configuration: building and hardening the access path that determines and terminates vendor connections, typically on self-hosted infrastructure in the entity's environment.
- Logging design: setting up audit trails for vendor sessions, including what is captured, where it is stored and how it is protected.
- Test scripts: writing repeatable checks that confirm termination and reconnection controls work as documented.
- Evidence packaging: organizing configurations, logs and test results against each part of R3 so the entity can present them.
- Runbooks: documenting the steps operations staff follow, which the entity reviews and adopts.
When scoping a partner engagement, ask for written deliverables that name which parts of R3 each item supports and confirm that the entity, not the partner, approves the final method.
Compliance with NERC CIP is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC. It assesses R3 through mechanisms such as Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and investigations. There is no CIP certificate, so no independent party issues a standalone certificate of R3 compliance. The assessor tests the entity's documented methods against actual records and decides whether the requirement was met during the audit period.
- Audit scheduling: Balancing Authority, Reliability Coordinator and Transmission Operator entities receive a Compliance Audit at least once every three years, while other registered entities are audited on a risk-based schedule.
- Sampling: the assessor selects vendor sessions and checks whether each was determined, terminated and controlled as the entity documented.
- Evidence requests: the assessor asks for records through the Evidence Request Tool and reviews them against the stated method.
- Findings: the Compliance Enforcement Authority decides whether a violation occurred and how it is resolved.
- Independence: an assessor may not design the controls it tests, so the entity should not expect the auditor to fix gaps during the review.
Before an audit, confirm the audit period, the evidence list and the Compliance Enforcement Authority's expectations with your Regional Entity contact.
Where organizations fall short on vendor remote access to EACMS and PACS
Vendor remote access to access control and monitoring systems is often the least documented path into a CIP environment. The gaps below cluster around four questions: which tools vendors use, whether the methods work in practice, how sessions end and restart, and whether the evidence exists before an auditor asks for it.
Untracked remote tools reaching EACMS and PACS
Vendors often connect to access control or monitoring systems through general-purpose remote support tools that nobody has inventoried. Under CIP-005-7 R3 Part 3.1, the entity must have methods to determine authenticated vendor-initiated connections to these systems, and that is impossible if a tool sits outside the inventory. Check every vendor path into EACMS and PACS, including tools installed by the vendor on its own laptops, and record each one in the CIP-002 associated system list.
Termination methods documented but never tested
Many entities write a procedure for ending a vendor session and never run it against a live EACMS or PACS. Part 3.2 requires methods to terminate authenticated vendor-initiated remote connections, so a procedure that fails under real conditions is a compliance gap. Run a scheduled test that starts a vendor session, terminates it using the documented method, and keeps the record of the attempt and result.
Reconnection without control
A session that is ended can often be reopened by the vendor at once, with no approval and no record. Part 3.2 also requires controls over the ability to reconnect, so reconnection needs its own gate. Confirm that the vendor account cannot re-establish a terminated session without a new authorization step, and that each reconnection attempt is logged with the approver's identity.
EACMS roles missed in CIP-002 work
Entities often classify the main BES Cyber Systems carefully but skip the access control and monitoring systems that protect them, such as authentication servers, jump hosts and log collectors. Because R3 reaches EACMS and PACS associated with high and medium impact systems, a missed role means a missed control. Walk through each CIP-002 categorization with the operations and security teams, and list every EACMS and PACS role that supports those systems.
Vendor accounts that bypass identity and logging
Shared or local vendor accounts on EACMS and PACS can sidestep the entity's central identity provider and log pipeline. The result is a session that the entity cannot tie to a named person or see in its monitoring. Require vendor access to authenticate through the entity's identity path and forward session events to the entity's log store, and test whether an account created outside that path can still log in.
Evidence gathered only at audit time
Teams often collect R3 evidence in the weeks before a Compliance Audit, which leaves gaps for the periods in between. An auditor will ask what the entity can show for the audit period, not what it can assemble afterward. Set up recurring exports of vendor session records, termination test results and reconnection approvals, and store them under the retention rules the entity follows for other CIP evidence.
How much work, time and cost does CIP-005-7 R3 take?
What drives the cost and effort of meeting CIP-005-7 R3?
The main drivers are the number of EACMS and PACS in scope, the number of vendors and remote access paths, and how many environments (production, backup Control Centers, test or disaster recovery sites) must be covered. R3 applies only to EACMS and PACS associated with high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity, so a precise CIP-002 categorization keeps the population small. Effort rises when vendor access is informal, uses shared accounts or spans many tools, because each path must be identified, authenticated, terminated and controlled for reconnection. Ask for a quote that lists the named systems, vendor access paths and deliverables.
Can our team meet CIP-005-7 R3 without outside help?
Many registered entities do this work with internal staff, and the requirement itself is a method-based control rather than a product purchase. The hard parts are usually identifying every vendor-initiated connection to in-scope EACMS and PACS, proving that each connection is authenticated before it is allowed, and showing that sessions can be terminated and reconnection controlled. Teams without network, identity and CIP documentation experience often find the evidence trail is the slowest part. An implementation partner can prepare the access design, configuration and evidence, but the entity must own its controls and the compliance determination stays with the Regional Entity.
What does R3 require from our own staff?
Expect involvement from several roles:
- System owners for each in-scope EACMS and PACS, who confirm the systems and their vendor access paths
- Vendor managers, who confirm which third parties connect, why, and how their accounts are issued and removed
- The CIP compliance lead, who maps the controls to the standard and owns the evidence and audit readiness
- Change approvers, who authorize configuration changes to access paths and their termination or reconnection controls
- Network and identity staff, who build and test the methods
How long does a CIP-005-7 R3 implementation take?
No general duration can be stated without knowing the scope. The timeline depends on the agreed written scope, the number of systems and vendor paths, and the entity's change windows, since changes to access controls on BES Cyber Systems support environments usually follow planned maintenance and approval cycles. Ask the partner for a schedule that separates discovery, design, configuration, testing and evidence collection, and that shows which steps depend on your change approval calendar. Also confirm how the work fits your audit period so that evidence exists for the full period under review.
Can a partner issue a CIP-005-7 R3 compliance report?
No. A partner can plan, configure, document and prepare evidence for R3, but it cannot issue a compliance report, attestation or certification. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other monitoring. There is no CIP certificate. Only that authority determines whether the entity complied, so your evidence should be written for an independent assessor to test.
How should we ask for a CIP-005-7 R3 quote?
Request a written quote based on a fixed scope that names the EACMS and PACS in scope, the vendor remote access paths, the methods to determine and terminate connections, and the deliverables, such as configuration documentation, test records and an evidence package. Ask which items are one-time work and which are recurring, such as access reviews, log retention, support or retainers. Confirm what the entity must provide, including system access, change windows and staff time. DeployOpen does not publish a price list, and a quote follows from the written scope.
What happens if a gap is found in R3 during an audit?
A gap is handled through the CIP enforcement process, which can include a Self-Report, a Mitigation Plan and a sanction determination by the Regional Entity. The Sanction Guidelines reference a maximum civil penalty of $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 and shown in the eCFR in October 2026. That figure is a ceiling set by 18 CFR 385.1602, not an expected outcome, and actual outcomes depend on the facts, the entity's compliance history and its mitigation. Early self-identification and a documented remediation plan are the usual focus of that process, so confirm the details with your compliance counsel.
How DeployOpen scopes, implements and prepares evidence for CIP-005-7 R3
DeployOpen works on CIP-005-7 R3 as an implementation partner: we scope the vendor remote access path to the EACMS and PACS in your environment, build and document the controls, and prepare the evidence your team owns. The organization remains responsible for its controls, and only the Regional Entity or NERC audit team assesses compliance.
How we scope
- Inventory which EACMS and PACS support high impact or medium impact BES Cyber Systems with External Routable Connectivity.
- Map every vendor access path into those systems, including support tools, jump hosts and vendor-managed consoles.
- Agree the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.
How we build
- Configure methods to determine authenticated vendor-initiated connections, logged against the named vendor and session.
- Set up methods to terminate those sessions and control reconnection, tested with live vendor sessions in a lab first.
- Route vendor access through the Intermediate System and rule sets your team approves, using self-hosted open-source components.
How we hand over
- Document each Part 3.1 and Part 3.2 method, its configuration, owner and the systems it covers.
- Deliver test records showing detection, termination and blocked reconnection, plus exported access and audit logs.
- Provide a handover session so your compliance team can explain the controls to an auditor without us present.
How we support
- Review the configuration after changes to vendor access, EACMS or PACS, so the evidence stays current.
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope build.
- Confirm with your compliance lead and the Regional Entity which evidence format and retention period they expect.
