What CIP-005-7 R1 requires for an electronic security perimeter
CIP-005-7 R1 applies to high and medium impact BES Cyber Systems and requires the entity to draw a boundary around them. The entity must define Electronic Security Perimeters (ESPs), route every External Routable Connectivity path through identified Electronic Access Points (EAPs), and deny access by default, with a documented reason for each rule that allows traffic. The requirement exists because a routable network path into a control system is an entry point for an attacker, and each unmanaged path widens the area that must be defended. Parts 1.1 and 1.2 cover placement inside the ESP and the funneling of external connections through EAPs. Part 1.3 covers the inbound and outbound permissions on each EAP and the justification for them. Part 1.4 covers authentication for dial-up connections where it is technically feasible. Part 1.5 requires one or more methods for detecting known or suspected malicious communications at EAPs for high impact systems and for medium impact systems at Control Centers. Scoping is usually the hardest part of R1. The entity has to trace every routable connection from its high and medium impact systems, including engineering workstations, historians, vendor support links, telemetry paths and the Cyber Assets that reach them, and then decide which of those assets sit inside the ESP. The entity should confirm its current categorization under CIP-002 before it draws any boundary, because the categorization sets which systems the ESP protects. A practical first step is a network inventory that lists each routable connection, its direction, its owner and its business reason, and then compares that list against the ESP drawings. The evidence an auditor expects is concrete: a list of every ESP with the uniquely identifiable Cyber Assets inside each, and firewall or access control rules that show only permitted access, each with a documented reason. Confirm with your Regional Entity which diagram format and rule export it accepts, and confirm how your firewall or access control platform records rule changes over time, since the auditor will test whether the documented rules match the rules in production. Verify the current text of the standard in the NERC CIP-005-7 standard PDF before you finalize your procedures.
Which systems, paths and teams fall inside the ESP
Scoping decides how much of the CIP-005-7 R1 work applies to you. The cards below cover the categorization that sets impact level, the routable assets and connections that must sit behind an Electronic Access Point, and the teams and vendor paths that are easy to overlook.
Impact rating from CIP-002
Start with the high, medium and low impact ratings that CIP-002-5.1a assigns to each BES Cyber System, because they decide whether Part 1.1 applies at all. High and medium impact systems fall under R1, while low impact systems are handled through the CIP-003 plan. Confirm the rating against the bright-line criteria in Attachment 1 and keep the rationale on file, since an auditor will ask how each system was rated and whether the rating still holds after plant or network changes.
Routable Cyber Assets and PCA
Part 1.1 reaches every applicable Cyber Asset and Protected Cyber Asset that connects through a routable protocol, not only the BES Cyber Systems themselves. Build the inventory from network discovery, not from the asset register alone, and include engineering workstations, historians, relays with Ethernet ports and embedded devices that many teams forget. Each asset in the list should show which ESP it sits in, because the evidence is a list of every uniquely identifiable routable Cyber Asset inside each perimeter.
External Routable Connectivity paths
Every path that leaves the ESP over a routable protocol counts as External Routable Connectivity and must pass through an identified Electronic Access Point under Part 1.2. Typical paths include corporate network links, historian replication, cloud connectors, remote monitoring and time or patch servers reached across the boundary. Map each path on a diagram and confirm that no alternate route, such as a spare modem bridge or a dual-homed server, bypasses the EAP.
Dial-up connections
Dial-up connectivity to applicable Cyber Assets falls under Part 1.4, which requires authentication where technically feasible when the connection is established. Modems left in service for vendor support or legacy telemetry are common findings, so check serial and dial-up hardware during site walkdowns as well as during network scans. Where authentication cannot be applied, document the technical reason and the compensating control, and confirm that the approach fits your own risk assessment and the Regional Entity's expectations.
Control Center and other medium impact sites
Part 1.5 requires methods for detecting known or suspected malicious communications at EAPs for high impact systems and for medium impact systems at Control Centers. Medium impact assets outside a Control Center are not subject to that detection requirement under Part 1.5, but they still need the ESP, EAP and access permission controls in Parts 1.1 through 1.3. Confirm the site type for each medium impact asset early, because it changes the detection design and the evidence you collect.
Vendors, integrators and cloud management paths
Vendor sessions, integrator laptops, cloud-hosted monitoring consoles and SaaS management portals are in scope whenever they connect to an applicable Cyber Asset over a routable protocol. Ask each vendor and cloud provider for a written list of the endpoints and tunnels they use, and check which of them terminate inside the ESP. Teams that own these relationships, including procurement and operations, should review the list together so that new connections are caught before they go live.
How an auditor tests each R1 part
This table sets out, for each part of CIP-005-7 R1 and its measures, what an assessor checks, the evidence usually requested and the findings that appear most often. Use it to walk your own evidence against the same questions before a Regional Entity engagement, and confirm sampling practice with your Regional Entity because it varies by audit.
| Requirement part | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Part 1.1 ESP membership | Whether every applicable routable-connected Cyber Asset and PCA of high and medium impact systems sits inside a defined ESP | ESP list with each uniquely identifiable routable-connected Cyber Asset, reconciled against the CIP-002 categorization | Assets added during projects or virtualization changes never recorded in the ESP inventory |
| Part 1.2 External Routable Connectivity | Whether all ERC enters and leaves through an identified EAP, with no unmanaged paths around it | Network diagrams, EAP inventory and routing or firewall configuration showing the EAP as the only ERC path | Undocumented dual-homed hosts, vendor links or cloud connections that bypass the EAP |
| Part 1.3 Deny-by-default access | Whether inbound and outbound EAP permissions are documented with a reason for each and all other access is denied | Firewall or access control list rules with a documented reason per rule and the default deny rule | Rules without business justification, broad any-to-any rules or stale rules for retired systems |
| Part 1.4 Dial-up authentication | Whether dial-up connections to applicable Cyber Assets authenticate where technically feasible, and whether infeasibility is justified | List of dial-up connectivity, authentication settings and documented technical feasibility reasoning where used | No dial-up inventory kept, so the team cannot show that none exists |
| Part 1.5 Malicious communication detection | Whether methods detect known or suspected malicious inbound and outbound traffic at EAPs in scope, including Control Center EAPs | Detection tool configuration, rule or signature sources, alert records and the reviews that followed them | Detection enabled on paper but not covering all in-scope EAPs, or alerts not reviewed or retained |
| R1 measures and evidence | Whether the evidence set matches the measures and is current, consistent and retrievable for the audit period | Current ESP and EAP lists, rule sets with reasons, and records that show changes over time | Evidence that reflects the design at a single past date rather than the changes made since |
How to build and document an ESP that passes review
This sequence turns CIP-005-7 R1 from a diagram into evidence an auditor can test. Each step produces a record that ties a Cyber Asset, a boundary or a rule back to a documented reason and to the impact rating that drives the scope.
Confirm the CIP-002 impact categorization
Start from the CIP-002 categorization that the organization has already approved. Confirm which BES Cyber Systems are rated high impact and which are rated medium impact, and note which medium impact systems have External Routable Connectivity, because those determine which assets the ESP must cover. The output is a signed list of in-scope BES Cyber Systems with their ratings, dated and owned by the CIP Senior Manager's delegate. If the categorization is out of date, fix it before defining any perimeter, since every later step depends on it.
Inventory routable Cyber Assets and PCA
For each in-scope system, list every Cyber Asset that connects using a routable protocol, along with each Protected Cyber Asset associated with it. Record a unique identifier, function, network location and communication path for each one, including vendor laptops, engineering workstations and embedded devices if they connect routably. Teams usually build this list from network scans, switch and firewall configurations and asset management records, then reconcile the differences. The output is a complete inventory that matches the list an assessor would later request, with each gap either closed or assigned an owner.
Define the ESP boundaries
Group the inventoried assets into one or more Electronic Security Perimeters, drawing each boundary around the routable communication paths that enter and leave the group. Document where each ESP starts and ends, and confirm that every in-scope routable Cyber Asset falls inside one of them. Diagrams help, but the diagram must match the inventory and the firewall configuration. The output is an ESP register and network diagrams that an engineer can trace to specific interfaces, subnets and VLANs.
Identify every Electronic Access Point
Find each point where External Routable Connectivity crosses an ESP boundary, including remote access paths, vendor connections, data historian links and corporate network connections. Assign each one as an Electronic Access Point and record the device, interface and direction of traffic it controls. Check for undocumented paths such as dual-homed hosts, cellular modems and cloud gateways, because an unidentified path is a common audit finding. The output is an EAP inventory where every external path has exactly one documented control point.
Write and justify inbound and outbound rules
Write the access permission rules for each EAP in both directions, naming source, destination, port and protocol, and record the business reason for each rule. Begin with a deny-all baseline and add only the permitted flows, so that any traffic not in the list is denied by default. Review each rule with the system owner and remove any that cannot be justified. Firewall platforms such as OPNsense can express these rules with aliases and per-rule logging, but the reasons must be written in the rule documentation, not left to memory. The output is a rule set and a justification register that together show only permitted access.
Set dial-up authentication where technically feasible
Identify any dial-up connectivity to applicable Cyber Assets and confirm that authentication is in place when establishing that connection, wherever the technology allows it. Where it is not technically feasible, document the technical reason and the compensating measure. Confirm that the same review covers modems and serial gateways that may have been forgotten in earlier inventories. The output is a dial-up register that lists each connection, its authentication method or documented infeasibility, and the owner who reviewed it.
Deploy malicious communication detection at in-scope access points
For high impact BES Cyber Systems, and for medium impact systems at Control Centers, deploy one or more methods to detect known or suspected malicious inbound and outbound communications at each in-scope EAP. Tools such as Suricata, which writes EVE JSON alerts, and Zeek, which logs connections by protocol, can supply this detection, but the organization must confirm that the chosen method covers the traffic at each EAP. Test that alerts fire on controlled inputs and that logs reach the review process. The output is a documented detection configuration per EAP, with sample alerts and records showing that detection works.
Keep the ESP list current
Establish a change process that updates the inventory, ESP register, EAP list, rule justifications and detection configuration whenever a Cyber Asset, path or rule changes. Review the full set on a schedule the organization sets and record each review with a date and approver. Link the change process to CIP-010 baseline management so that a new firewall rule or a new remote path cannot go live without its record. The output is a current ESP package and a change history that an assessor can use to confirm the ESP was accurate throughout the audit period.
Evidence that proves the perimeter exists and works
CIP-005-7 R1 is tested by documents and records, not by a walk through the control room. Each artifact below answers one question an auditor will ask, and each must stay current between audits, not be rebuilt the week before one.
ESP inventory by routable Cyber Asset
The measure example is a list of every ESP with each uniquely identifiable Cyber Asset that connects by a routable protocol inside it. Auditors compare this list against network diagrams and asset records, so a host that appears on a switch but not on the list is a finding. Ask the team to tie each entry to the CIP-002 categorization of the BES Cyber System it supports, and to show who approved the last change to the list.
EAP inventory and external connectivity map
Every path of External Routable Connectivity must pass through an identified Electronic Access Point. Keep one register that names each EAP, the ESP it protects, the external networks it faces and the owner of the device. Check it against the live routing and firewall configuration, because a documented EAP that no longer carries traffic leaves an undocumented path open.
Rule exports with documented reasons
The evidence for Part 1.3 is an export of inbound and outbound permissions at each EAP, showing that only permitted access is allowed and that each rule carries a documented reason for access. Export rules on a schedule and store them with the change ticket that created each rule. A rule with no stated business reason, or a broad any-to-any entry, will be questioned even when the traffic is legitimate.
Dial-up configuration records
Part 1.4 applies only where dial-up connectivity to applicable Cyber Assets exists, and it requires authentication where technically feasible. Confirm whether any modem or dial-up path exists before the audit, and if none does, record that finding with the date of the check. Where a path exists, keep the device configuration, the authentication method and the reason it cannot be stronger if authentication is limited.
Malicious traffic detection logs
Part 1.5 requires detection of known or suspected malicious inbound and outbound communications at EAPs for high impact systems and for medium impact systems at Control Centers. Retain alert records and the sensor configuration that produced them, such as Suricata EVE output or Zeek logs for connection and protocol activity. Confirm retention periods with your Compliance Enforcement Authority and your own records policy, because the standard's evidence needs depend on the audit period.
Linking rule changes to CIP-010 records
Every change to an ESP boundary device, EAP rule or detection signature should trace to a change ticket that records the request, the approval, the test and the reviewer. This is where CIP-005 evidence meets the baseline and change management process in CIP-010, so the same ticket supports both standards. Review the ticket trail at a fixed interval, and reconcile it with the exported rule set to find changes that were made without a record.
Open-source tools that can produce ESP evidence
OPNsense is a BSD-2-Clause licensed firewall platform built on a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, which maps directly to the deny-by-default posture that CIP-005-7 Part 1.3 expects at each Electronic Access Point. Aliases let an entity group address ranges, such as a vendor subnet or a Control Center management network, so the rule list stays readable for an assessor.
- Rule export for the access list: The rule set can be exported and reviewed as the list of firewall rules showing only permitted access that the R1 measures describe.
- Rule-level logging: Enabling logging on a rule records each match, which helps show the access is in use and was reviewed.
- Aliases as documentation: Named address groups tie each rule to an asset list, supporting the documented reason for each permitted path.
- Change history: Configuration changes should be tracked in version control or the platform's backup records to support change evidence under CIP-010.
- Live log review: The live log view supports spot checks, but retain exports for the audit period.
Confirm that your rule export format, log retention and access controls on the firewall itself meet your evidence requirements before relying on them.
Coraza is an Apache-2.0 licensed web application firewall that works with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It integrates with Caddy, HAProxy, Traefik and Nginx. It targets application-layer attacks such as SQL injection, cross-site scripting and code injection. It is relevant where an entity exposes web interfaces at an EAP or inside an ESP, but it does not replace a packet filter at the perimeter.
- Rule set documentation: The ruleset version and enabled rule groups are evidence of what inspection is in place for web traffic crossing the boundary.
- Audit logging: Blocked and matched requests can be logged for review, supporting the detection expectations for malicious communications at Control Center access points.
- Scope limits: Coraza inspects HTTP-based traffic only, so it does not show coverage for non-web routable protocols.
- Tuning records: Exclusions and rule changes should be documented with reasons, since an assessor will ask why a rule was disabled.
- Integration point: Confirm which reverse proxy or ingress handles traffic in your architecture, because the Coraza placement must sit on the path that crosses the EAP.
Confirm the placement, logging destination and tuning process in your own environment before you cite Coraza as evidence for any part of Part 1.5.
Suricata is a GPL-2.0-only intrusion detection and network monitoring engine. Its EVE output writes JSON records for rule match alerts, anomalies, flows and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, and these can be split into separate files for log management tools. Zeek is a BSD-3-Clause network analysis framework. It writes conn.log for who talked to whom, for how long, how much and over which protocol, plus protocol logs such as dns.log and http.log, and weird.log for anomalous events, all linked by a unique connection identifier. Together they provide the evidence base for detecting known or suspected malicious communications at EAPs.
- Alert records: Suricata EVE alerts document detection events that support the Part 1.5 detection method.
- Connection history: Zeek conn.log records show the communication pattern across the boundary for review.
- Anomaly records: Zeek weird.log and Suricata anomaly events help show that unusual traffic was surfaced.
- Log management: Splitting EVE output and exporting Zeek logs to a central store supports retention and access evidence.
- Sensor placement: Sensors must see traffic at the EAP, and their coverage must be documented.
Confirm sensor placement, retention periods and how detections are reviewed and acted on, because a log alone does not demonstrate that a detection method is in place.
What meeting R1 costs in money and effort
The table lists each cost component of meeting CIP-005-7 R1, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for scoping a quote, since most of the spend comes from engineering time and evidence upkeep rather than software licenses.
| Cost component | One-time or recurring | Who is paid, and what drives it |
|---|---|---|
| Tooling and licenses | Recurring where commercial | Firewall, intrusion detection and monitoring products are often licensed per device, throughput or subscription. Self-hosted open-source options such as OPNsense, Suricata and Zeek remove license spend but still need hardware, hosting and support staff. Ask the quote to separate license, subscription and support lines. |
| Inventory of ESP Cyber Assets | One-time, then recurring upkeep | Engineering staff or an implementation partner build the list of every uniquely identifiable routable Cyber Asset in each ESP. Cost rises with the number of sites, legacy devices and undocumented connections. Reduces with a current asset baseline from CIP-010 work. |
| Engineering time for rule review | One-time build, recurring review | Staff trace each EAP rule to a documented business reason and remove rules that allow any-to-any access. Cost rises with the count of legacy rules and the number of vendor and third-party paths. Ask whether the quote includes a rule-by-rule justification workbook. |
| Deployment of EAP and access point controls | One-time | Work covers placing Electronic Access Points, configuring deny-by-default policy and testing failover. Cost depends on the number of EAPs, the degree of change in existing networks, and whether maintenance windows must be scheduled around live grid operations. |
| Malicious traffic detection at Control Centers | One-time build, recurring tuning | Required detection methods at applicable EAPs need sensor placement, alert routing and tuning to reduce noise. Cost depends on traffic volume, the number of Control Center access points and the staff available to triage alerts. |
| Evidence upkeep | Recurring | Lists of ESPs, rule sets with reasons, and change records must stay current. Cost is driven by how often rules change and whether evidence is generated automatically from configuration exports or assembled by hand before each audit. |
| External testing or review | Recurring, periodic | Independent testing of the perimeter, such as penetration testing or configuration review by a qualified firm, is optional but useful before an audit. Ask for scope, the tester's qualifications and whether retesting after changes is included. |
| Auditor sampling and audit support | Recurring, per audit cycle | The Regional Entity or NERC selects samples of ESP lists and rules during an audit, and the entity pays its own staff time and any consultant support. Cost rises when evidence is missing, inconsistent or spread across many systems. Confirm the audit schedule with your Regional Entity. |
Where ESP programs usually fall short
Most Electronic Security Perimeter findings come from the gap between the diagram and the network as it actually runs. The cards below cover the places where routable assets, allow rules, vendor paths and Control Center detection drift out of step with the documented perimeter.
Routable assets missing from the ESP list
Cyber Assets with routable connectivity often appear after the perimeter was first documented, such as added historians, engineering laptops, or monitoring sensors installed during a project. Each one that connects to a high or medium impact BES Cyber System must reside inside the defined ESP and appear in the list of uniquely identifiable assets. Check the ESP inventory against switch MAC tables, DHCP leases and asset management records, and confirm that anything new was added before it went live.
Allow rules without documented reasons
Firewall and access control rules often accumulate over years, with temporary exceptions that were never removed and rules whose original purpose nobody can name. R1 expects each permitted inbound and outbound access to carry a documented reason, and all other access to be denied by default. Export the rule set from the EAP, sort it by last hit date, and assign a written justification to every rule. Remove any rule that cannot be justified.
Vendor paths that bypass the EAP
Remote support tools, vendor VPNs and maintenance laptops sometimes connect through a side channel, such as a cellular modem or a second firewall that no one included in the perimeter diagram. Any External Routable Connectivity must pass through an identified Electronic Access Point. Trace every route into the ESP, including vendor-managed equipment, and confirm that each path terminates at a documented EAP rather than an undocumented gateway.
Dial-up access without authentication
Legacy dial-up modems, serial-over-IP converters and out-of-band management connections are easy to forget because they seldom appear in network diagrams. Part 1.4 requires authentication, where technically feasible, when establishing dial-up connectivity with applicable Cyber Assets. Inventory every modem and console server, then record whether authentication is enabled and, if it is not technically feasible, document why and which compensating measures apply.
Malicious traffic detection gaps at Control Centers
Part 1.5 requires one or more methods for detecting known or suspected malicious inbound and outbound communications at EAPs for high impact systems and for medium impact systems at Control Centers. Teams often rely on the firewall's block logs alone, which do not show suspicious traffic that the firewall allowed. Confirm that a detection capability such as an intrusion detection sensor or equivalent monitoring sees traffic at each in-scope EAP, and that alerts reach a person who reviews them.
Stale ESP diagrams and evidence
An ESP diagram and asset list that were accurate at the last audit can drift quickly as systems change. Auditors compare the documented perimeter against the live network and the access rule export, so mismatches are visible quickly. Assign an owner to update the diagram, asset list and rule justifications whenever a change request touches the ESP, and keep dated exports so the evidence matches the period under review.
Who owns the ESP, who prepares it, and who audits it
The registered entity owns R1 in full. Its CIP Senior Manager and operations staff decide which Cyber Assets sit inside each ESP, approve every External Routable Connectivity path and EAP rule, and remain accountable for the evidence even when a partner built the tooling. Ownership also covers the decisions no partner should make on the entity's behalf, such as accepting residual risk on a permitted rule or deciding whether a Control Center detection method meets the requirement.
- Scope decisions: confirming which high and medium impact BES Cyber Systems, PCA and associated systems fall inside the ESP, using the output of CIP-002 categorization.
- Rule approval: signing off each inbound and outbound EAP permission with its documented business reason, and removing rules that no longer have one.
- Ongoing operations: running the review cadence, handling change requests and keeping the ESP inventory current as assets move.
- Evidence custody: holding the ESP lists, rule sets and logs in a form the Compliance Enforcement Authority can request and verify.
- Vendor coordination: managing the contract terms that give a partner access to systems in scope.
Check that each of these roles has a named person, and that the ESP inventory and rule justifications exist before any partner begins work.
An implementation partner such as DeployOpen can plan, build and document the technical parts of the ESP. That typically includes designing segmentation, deploying firewalls or access control lists at EAPs, writing rule sets that map to documented reasons, and producing inventories and configuration exports the entity can present as evidence. The partner prepares systems and evidence. It does not issue compliance determinations, and it cannot tell the entity or an auditor that R1 is met.
- Architecture and build: designing ESP boundaries and deploying self-hosted perimeter tooling inside the entity's own infrastructure.
- Evidence preparation: exporting ESP lists, rule sets with justifications and log samples in a repeatable format.
- Testing: verifying that deny-by-default behavior works as documented, through configuration review and controlled tests, under a written scope.
- Documentation: writing runbooks and procedures the entity's staff can operate after handover.
- Independence limit: a partner that designed the controls should not also be the party that certifies them, and it should not select the evidence an auditor sees as proof of compliance.
Ask the partner to state in writing which deliverables are configuration and evidence, and which decisions remain with the entity.
Compliance is judged by the Compliance Enforcement Authority, which is a Regional Entity or NERC. It tests R1 through Compliance Audits, Spot Checks, Self-Certifications and investigations, and it decides whether a requirement was met. There is no CIP certificate issued to the entity. Independent assessors can support the entity's internal review, but the regulator decides the outcome, and no partner or consultant can substitute for that determination.
- Testing approach: sampling ESP lists against network diagrams, checking rules against stated reasons, and confirming that Control Center access points have detection in place.
- Evidence requests: asking for records through the regulator's request process, within the audit period.
- Audit frequency: under Section 403.10.1 of the NERC Rules of Procedure, Balancing Authorities, Reliability Coordinators and Transmission Operators receive an audit at least once every three years, while other entities are scheduled on a risk basis.
- Findings: issuing findings and potential noncompliance determinations that the entity then responds to.
- Independence: the auditing body must stay separate from the party that built the controls.
Confirm your Regional Entity's audit schedule and request process before preparing evidence, so the packages you assemble match what will be asked.
Questions buyers ask about CIP-005-7 R1 cost, effort and scope
How long does ESP scoping take for CIP-005-7 R1, and what drives it?
The duration depends on how many high and medium impact BES Cyber Systems you have, how many of their Cyber Assets connect by a routable protocol, and how well the current network is documented. Scoping starts from the impact ratings produced under CIP-002, so an entity with an unsettled categorization will spend extra time before any perimeter can be drawn. Each routable connection to a Cyber Asset in scope must be traced, including vendor links, historian feeds and management networks. Before you request a quote, confirm with your Compliance Enforcement Authority and your own records which systems are in scope, since the written scope sets the effort a partner will plan for.
Can an in-house team scope and build the ESP without outside help?
Yes, many registered entities do this with internal staff, and the requirement itself does not require an outside party. The work needs people who know the network topology, the BES Cyber System inventory and the firewall and access control configuration, plus someone who can write defensible evidence. Teams that lack network engineers familiar with the affected systems, or that have no capacity to test changes in a control environment, often bring in a partner for specific parts such as network mapping, rule review or evidence packaging. The organization still owns the ESP, the rules and the compliance decision.
What does CIP-005-7 R1 ask of operations staff day to day?
Operations staff must keep the ESP accurate as the environment changes. Every new routable Cyber Asset in scope needs to be placed inside an ESP, every external connection needs to pass through an identified Electronic Access Point, and every permitted access rule needs a documented reason. In practice this means change requests that touch firewalls or network segments must be checked against the ESP list before they go live. Operators also need a working process for reviewing rule sets, retiring stale access and recording why each remaining rule exists, because those records are what an assessor will sample.
Can a partner prepare the evidence for CIP-005-7 R1?
A partner can prepare systems and evidence, but cannot issue the compliance determination. For R1, typical evidence includes a list of each ESP with every uniquely identifiable routable Cyber Asset inside it, and a list of firewall or access control rules that show only permitted access, each with a documented reason. An implementation partner can help build and organize these records, document the rule set, and configure logging so reviews are traceable. The registered entity owns the controls and submits the evidence to its Regional Entity, which makes the monitoring decision. Confirm the exact evidence format and retention expectations with your Regional Entity before the engagement starts.
How often does CIP-005-7 R1 evidence need to be refreshed?
The standard does not set one fixed refresh interval for every artifact. Instead, the ESP inventory and rule records must be accurate at any point the Regional Entity asks for them, which means they have to be kept current through normal change activity. Many entities update the ESP list and rule documentation whenever a Cyber Asset is added, removed or moved, and they review the full rule set on a schedule their own program sets. Ask your Regional Entity what it expects to see during a Compliance Audit or Spot Check, since audit preparation shapes how often you pull and archive snapshots.
What does an ESP project cost, and who gets paid for what?
Cost has three main parts: internal staff time, any outside work on network mapping, rule review or evidence packaging, and the firewall or access control platform itself. Outside work is usually priced from a written scope, so the drivers are the number of networks, the number of Electronic Access Points, the state of existing documentation and whether rules must be tested in a non-production environment. Some costs are one time, such as the initial mapping and rule cleanup, while others recur, such as annual reviews and staff time for change control. DeployOpen does not publish a price list. Ask any provider for a quote that lists the scope, deliverables, assumptions and what is excluded.
Does R1 require detecting malicious traffic at every access point?
No. Part 1.5 requires one or more methods for detecting known or suspected malicious inbound and outbound communications at Electronic Access Points for high impact BES Cyber Systems, and for medium impact BES Cyber Systems at Control Centers. Entities with only medium impact systems outside Control Centers do not carry that detection obligation under this part. Confirm how your systems are categorized before designing detection, because the scope determines which access points need it. Tools such as a stateful packet filter, a web application firewall and network intrusion detection can each play a role, and their logs help build the evidence trail.
How DeployOpen prepares ESP evidence for NERC CIP
DeployOpen prepares the technical side of an Electronic Security Perimeter (ESP) for the entity that owns it. The work starts with a written scope that names the high and medium impact BES Cyber Systems in view, the Cyber Assets inside each proposed ESP, every External Routable Connectivity path, and the Electronic Access Points (EAPs) that will carry it. Before any change is made, the entity should confirm the categorization that drives this scope under CIP-002, because an ESP built around the wrong systems produces evidence that fails review. DeployOpen then plans and implements self-hosted open-source platforms, such as a stateful packet filter for EAP rules, inside the client's own cloud accounts, data centers or air-gapped networks, and hardens them against the configuration baseline the entity approves. Where a platform's capability is not yet confirmed for a specific use, the reader should ask for that confirmation in writing before it is designed in.
The evidence package is where most ESP programs are tested. DeployOpen prepares the inventory of every uniquely identifiable Cyber Asset connected by a routable protocol inside each ESP, the rule documentation for each EAP showing permitted inbound and outbound access with a documented reason, and the deny-by-default posture that the rule set must demonstrate. It also configures the logs that show rule matches and the detection methods required under Part 1.5 at Control Center EAPs, so that the entity can show detection is running rather than described. Each artifact should be dated, versioned and tied to a named owner inside the entity. Ask for a sample evidence package in the quote so you can see the format before work begins.
DeployOpen does not issue audit reports, attestations or certifications. Only the Compliance Enforcement Authority, a Regional Entity or NERC, monitors compliance with CIP-005-7, and the entity owns its controls, its compliance program and every submittal. DeployOpen's role is to prepare systems and evidence, and the entity remains accountable for what it attests to and submits. Fees for this work are set by the written scope rather than a published price list, and the entity should expect the quote to separate one-time build and documentation effort from any recurring support or testing retainer. Confirm the final scope, deliverables and responsibilities with your compliance lead and internal counsel before signing.

