CIP-014-3 R4 Physical threat and vulnerability evaluation

What CIP-014-3 R4 physical threat and vulnerability evaluation asks for

CIP-014-3 R4 requires a documented evaluation of the potential threats and vulnerabilities of a physical attack on each identified Transmission station, substation and primary control center. The duty falls on Transmission Owners that have identified and verified facilities under R1 and R2, and on Transmission Operators that were notified under R3. The evaluation is the bridge between identifying critical facilities and writing the physical security plan in R5, so an assessor will look for a clear line from each evaluated facility to the threats and vulnerabilities that drove the plan. The risk it addresses is a coordinated or opportunistic physical attack that could take a critical station out of service and contribute to instability, uncontrolled separation or cascading, the same consequences that the R1 analysis screens for.

The standard names three inputs. Parts 4.1 to 4.3 require the evaluation to consider the unique characteristics of each facility, the prior history of attack on similar facilities (frequency, geographic proximity and severity), and intelligence or threat warnings from law enforcement, the ERO, the E-ISAC and US or Canadian government agencies. The work is hard because those inputs come from several outside parties, arrive at different times and in different formats, and must be dated and traceable so an auditor can see which warning was known when the evaluation was signed. Site characteristics also change with fencing, lighting, sightlines, nearby development and staffing, so the evaluation needs a revision trigger, not just an annual date. Confirm with your Regional Entity how it expects each source to be recorded and how often it expects re-evaluation.

R4 carries a Medium Violation Risk Factor, and enforcement sits with the Compliance Enforcement Authority through the monitoring tools described in the NERC Rules of Procedure. Penalty exposure is significant: the maximum civil penalty referenced by NERC's Sanction Guidelines under 18 CFR 385.1602 is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906. Before an audit, pull the R4 evaluation for each facility, its dated source list, and the record of each review, and confirm that every R5 measure traces back to a documented threat or vulnerability.

Which facilities, teams and inputs R4 covers

R4 applies to a defined set of facilities and depends on three kinds of input that sit with different teams. Getting the scope and the input owners right before the evaluation starts prevents gaps that an assessor will find later.

Transmission Owner facilities from R1 and R2

R4 reaches Transmission Owners whose stations and substations were identified in the R1 risk assessment and verified under R2. Confirm the verified list is the one the evaluation uses, including any facility added or removed after verification. A station missing from the R4 scope is a finding even if its physical security is strong. Keep the R1 and R2 documents with the evaluation so the chain from identification to verification is traceable.

Transmission Operator notifications under R3

Transmission Operators fall into R4 when they receive notice under R3 that a Transmission station or substation is critical. The notice, not ownership, defines the obligation, so check which notices you have received and their dates. An operator that owns no facility on the list still needs a documented scope decision. Record who received each notice and where it is filed.

Primary control center for each station

Each identified station or substation has a primary control center, and R4 requires the evaluation to cover that control center as well. Map every station to its control center in writing, including control centers owned by another entity. Shared or backup control centers create the most confusion, so document which center is primary for each facility and who operates it.

Unique facility characteristics

The first input is what makes each facility different: site layout, perimeter, sightlines, access roads, nearby population, equipment exposure and the consequences of losing the site. Site surveys and engineering drawings usually supply this data, held by the operations, engineering and physical security teams. Ask each team to confirm its data is current, since a layout change after the last survey can alter the attack paths assessed.

Prior attack history by frequency, proximity and severity

The second input is the record of past attacks on similar facilities, judged by how often they occurred, how close they were to your sites and how severe they were. Security operations, the corporate security function and incident records usually hold this data. Document the sources searched and the time window, so an assessor can see that the review was not limited to your own incident log.

Threat warnings from named sources

The third input covers warnings from law enforcement, the ERO, the E-ISAC and US or Canadian government agencies. Assign one owner to subscribe to these channels, record each warning received, and note how it bears on each facility. Confirm with the E-ISAC and your Regional Entity how warnings are shared with registered entities, because the channel may differ from the one your team already uses.

How the evaluation connects R1, R2 and R5

The R4 evaluation sits between verification and the physical security plan, and it takes its inputs from both. The stations, substations and primary control centers it covers come from the R1 transmission risk assessment and from the R2 unaffiliated third-party verification of that assessment. Its findings then become the threat basis that the R5 physical security plan must answer. An assessor reading the chain will expect to trace each facility from identification, through verification, into a dated evaluation, and then into specific deter, detect, delay, assess, communicate and respond measures in the plan. If any link cannot be traced, the plan looks like a set of generic measures rather than a response to the threats at that site.

A weak or undated evaluation undermines the R5 plan and the R6 review in practical ways. If the R4 analysis does not describe the site's characteristics, its attack history or the intelligence it considered, the R5 plan has no documented reason for its chosen controls, and the R6 reviewer has nothing specific to test the plan against. Disagreements that the reviewer raises then become harder to resolve, because the entity cannot show how the threat picture was built. Missing dates create a similar problem: the reviewer and any auditor will want to see that the evaluation was current when the plan was written. Confirm with the standard text, and with your Regional Entity, which events and intervals start the clock for re-evaluation and how they relate to the R5 plan's own review cycle. Do not assume the cadence carries over from another requirement.

Before the next audit, check that each facility in the R4 record matches the current R1 and R2 outputs. Reconcile the facility list against the most recent R1 identification, confirm that the R2 verification covered the same stations and control centers, and confirm that each R4 record names the date it was completed and the R5 plan version that relies on it. Ask the team that owns the physical security plan to confirm which threat assumptions the plan uses and where each one appears in the R4 record. Where you bring in an implementation partner to organize this evidence, that partner prepares the records, while the registered entity owns the determinations and the independent reviewer under R6 reviews them.

How an assessor tests the R4 evaluation

This table walks through the steps an auditor or Regional Entity typically takes when testing the CIP-014-3 R4 evaluation, from the facility list through to the cycle. Read each row as a test step, the evidence the assessor asks for, what passes, and where entities most often lose findings.

Test step	What the assessor requests	Evidence that passes	Common findings
Confirm the facility list matches R1 and R2	The R1 risk assessment, the R2 verification report, and the current list of identified and verified stations, substations and primary control centers	Facility list in the R4 evaluation matches the verified list, with dates and version history showing how it was updated after R2	Facilities added or dropped between R2 and R4 with no documented reason
Check every identified facility is evaluated	The R4 evaluation document and a cross-check against the facility list	A separate evaluation section or record for each station, substation and primary control center, including the associated control center	Primary control centers missing from the evaluation, or evaluated only as a group
Trace Part 4.1 to a documented input	Records showing how unique facility characteristics were identified and what sources informed them	Site descriptions, one-line diagrams, access routes and surveys dated and tied to the specific facility	Generic descriptions copied across facilities that do not reflect each site
Trace Part 4.2 to attack history	Attack history records considered, with the search scope and the reasoning for relevance	Incident records covering frequency, geographic proximity and severity, with a statement of how each informed the evaluation	No stated search scope, or history that was reviewed but not connected to conclusions
Trace Part 4.3 to threat intelligence	Threat warnings and intelligence reports relied on, with their source and date	Dated entries from law enforcement, the ERO, the E-ISAC or government agencies, each linked to a finding in the evaluation	Intelligence cited without a source or date, or sources that cannot be produced on request
Sample threat intelligence to its source and date	A sample of cited intelligence items with the original report or notice	Original reports retrievable and dated before the evaluation was signed off	Secondhand summaries that cannot be traced back to the original source
Check the evaluation ran on the stated cycle	Prior evaluation, current evaluation, and the schedule used to decide when the next one is due	Evaluation dates that fall within the required interval, with the approving sign-off recorded	Evaluation completed late, or the cycle was not tracked after a facility change
Check the evaluation covers changes since the last cycle	Change records for facilities, threat intelligence and attack history since the prior evaluation	A documented update that addresses new or changed inputs, even where the conclusion is unchanged	Evaluation reused without reviewing new intelligence or facility changes

Sequence for building a defensible R4 evaluation

This sequence turns the R1 and R2 outputs into a dated, evidence-backed R4 evaluation for each identified station, substation and primary control center. Each step ends with a record an auditor can trace from the threat conclusion back to its sources.

Confirm the facility and control center list
Start from the identified and verified list produced under R1 and R2, including each station, substation and the primary control center linked to it. The compliance lead and the transmission planning owner confirm that every facility in scope appears once, with its identifier and the R1 and R2 dates that support it. The output is a signed facility register that serves as the scope baseline for every later step. Any facility added or removed later must be recorded with a reason and approval.
Gather site characteristics from engineering records
Engineering and physical security staff collect the unique characteristics of each facility, such as location, equipment type, voltage, perimeter layout, lighting, sightlines, nearby roads and access points, and the existing deter, detect and delay measures. Drawings, site surveys and existing security assessments are the usual sources. The output is a site characteristics file per facility, dated and signed by the owner of the records, so the reviewer can see what the evaluation assumed about each site.
Compile attack history for similar facilities
The team searches internal incident logs, industry reports and public records for prior physical attacks on similar facilities, then records each event's frequency, geographic proximity to the facility and severity, as Part 4.2 expects. Entries that do not match the facility's characteristics are kept and marked as excluded, with a reason. The output is an attack history register with its sources listed, so an auditor can see how each event affected the evaluation.
Collect threat warnings from authorized sources
The team gathers threat intelligence and warnings from law enforcement, the ERO, the E-ISAC and US or Canadian government agencies, as Part 4.3 requires. Each item is logged with its source, date received, the facilities it could affect and who reviewed it. Where a threat platform is used, such as MISP or OpenCTI, the export or report is retained as the underlying record. The output is a threat intelligence log that shows which warnings were considered and which were judged not relevant, with the reasons.
Assess threats and vulnerabilities per facility
For each facility, the assessors combine the site characteristics, attack history and threat warnings to identify credible physical attack scenarios and the vulnerabilities each scenario could exploit. They rate the threat and vulnerability for each scenario using the entity's documented method, and state the assumptions behind each rating. Reviewers from engineering and security should challenge the scoring before it is accepted. The output is a per-facility evaluation worksheet with scenarios, ratings and assumptions visible.
Record conclusions and obtain sign-off
The evaluation owner writes a summary for each facility that states the threats and vulnerabilities found, the evidence behind them, and any items that need action. An accountable senior manager reviews and signs the evaluation, and the approval date is recorded. Changes after sign-off go through version control with a reason for each change. The output is a signed R4 evaluation report with a version history that an auditor can match to the underlying worksheets.
Hand findings to the R5 plan owner
The signed evaluation is passed to the owner of the R5 physical security plan with a transfer record that lists each vulnerability and the scenarios it relates to. The R5 owner confirms receipt in writing and notes which findings the security plan will address and which are accepted or deferred. The output is a handoff memo and receipt that connects the R4 findings to the R5 plan, giving an auditor a traceable path from threat to control.

Evidence that satisfies R4 and how to keep it current

R4 is judged on the records behind each facility evaluation, not on the evaluation alone. The six artifacts below show an assessor how the R1 and R2 results, the site facts, the attack history and the threat intelligence fed into each conclusion, and how the record stayed current between evaluations.

Dated facility list tied to R1 and R2

This is the list of Transmission stations, substations and primary control centers that R4 applies to, and it must trace back to the R1 risk assessment and the R2 third-party verification. Record the R1 assessment date, the verifier's name and completion date, and any facility added or removed after verification. Check that every facility in the R4 evaluations appears here with the same identifier, and that a change to the list starts a new evaluation for the affected facility. Ask your Regional Entity or auditor which identifiers they expect to see.

Site characteristics record per facility

Each facility needs a current record of the features that shape a physical attack, such as perimeter layout, access routes, nearby roads and rail, sightlines, lighting, fencing, cameras, guard coverage and the staffing model. R4 requires the evaluation to consider the unique characteristics of each facility, so this record is the basis for that consideration. Assign an owner, version the record, and re-verify it after any construction, fence change or staffing change at the site.

Attack history register with sources

The attack history register lists prior physical attacks on similar facilities, with the date, location, target type, severity and the source of each entry. Record the selection criteria as well, including the geographic radius and time window you used, because R4 asks about frequency, geographic proximity and severity. Keep the source citation for every entry so an assessor can check it. Review the register on a set schedule and document when it was last checked, even when no new entries were found.

Threat intelligence log with handling

The threat intelligence log records each warning or intelligence item that bears on physical attack, with the source, the date received, the handling restrictions and the action taken. R4 names law enforcement, the ERO, the E-ISAC and US or Canadian government agencies as sources to consider, so log the origin of every item and note whether it came through a formal channel. Use MISP or OpenCTI to hold the entries if your team already runs them, and confirm that handling markings meet your information protection rules before sharing.

Per-facility evaluation document

Each facility needs its own evaluation document that states the threats and vulnerabilities considered, the evidence used from the three sections above, and a written conclusion for that facility. A generic evaluation covering every site is weak evidence because R4 applies facility by facility. Date each conclusion, name the reviewer, and record which inputs changed since the prior evaluation. Ask the auditor whether they want the rationale for a conclusion that is unchanged.

Approval and revision history

The approval and revision history shows who signed each evaluation, when, and which version they approved, along with the trigger for every revision. Use version control for the evaluation documents and the registers, and keep the signed copies in a location you can produce on request. Define change triggers in advance, such as a new threat warning, an attack on a similar facility, a site modification or the R1 cycle, so an out-of-cycle review is recorded rather than discovered by the auditor.

What meeting R4 costs in money and effort

This table breaks the R4 evaluation into its cost components, showing who is paid, whether each cost is one-time or recurring, what pushes it up, and how to contain it. No supplied figures exist for these costs, so use the table to structure a written quote and to confirm scope with your Regional Entity before work starts.

Cost component	One-time or recurring	What drives it up	How to keep it down
Internal engineering and physical security time	Recurring, at each evaluation cycle	Number of identified stations, substations and primary control centers, and how many people must review site conditions and document results	Keep a standing evaluation template, assign one owner per facility, and reuse prior findings where site conditions have not changed
Threat intelligence subscriptions or memberships	Recurring	Number of intelligence sources the team must review, such as law enforcement, the E-ISAC and government agency warnings, and whether intake is manual	Confirm which sources you already receive through E-ISAC membership, and use a self-hosted platform such as OpenCTI to organize what you collect
Data collection from utilities and site records	One-time for the first cycle, then recurring updates	Gaps in site characteristics documentation, dispersed records across operations, security and engineering, and the age of attack history data	Maintain a single facility record for each station and substation that holds unique characteristics, and log attack history with date, location and severity
External evaluation or third-party review (see R6)	Recurring, tied to the R6 review cycle	Scope of the evaluation and plan under review, reviewer qualifications, and the number of recommendations that must be acted on or documented	Ask for a fixed-scope written proposal that names the deliverables, and prepare the R4 evaluation and R5 plan so the reviewer can work from a complete package
Tooling and storage for evidence	Recurring for storage and hosting, one-time for setup	Volume of retained evaluations, threat records and supporting material, and the retention period your program sets	Use open-source tools that run in your own environment, define a retention schedule, and store evidence in one controlled location
Auditor sampling effort	Recurring, at each Compliance Audit or Spot Check	Number of evaluations and facilities the auditor samples, and gaps between your documented reasoning and the evidence behind it	Keep an index linking each facility to its R4 evaluation, supporting intelligence and review decisions so an auditor can trace the reasoning quickly

Which open-source tools can organize R4 threat intelligence

MISP and OpenCTI can organize the threat intelligence that R4 requires you to consider, but they do not perform the physical evaluation. R4 asks you to weigh the unique characteristics of each station, substation and primary control center, prior attacks on similar facilities, and warnings from law enforcement, the ERO, the E-ISAC and government agencies. MISP (AGPL-3.0-only) correlates indicators by exact match and by patterns such as fuzzy hashes and CIDR overlaps, records sightings, and exports to STIX, CSV and Suricata, Snort and Zeek rule formats through its REST API. OpenCTI (Apache-2.0) stores threat knowledge as STIX-based entities, relationships and containers, and ingests feeds through connectors, TAXII, RSS, CSV, JSON or manual upload. Either tool can hold dated records of what you received, from whom, and what you concluded, which is the trail an assessor will ask for. The judgment about threat applicability to each facility remains the Transmission Owner's responsibility and should be documented as such.

CISO Assistant (AGPL-3.0-only) can track the R4 evaluation itself as an assessment, with its more than 200 bundled frameworks and automatic mapping between them. That helps when the same evaluation informs other programs, but any mapping it shows should be checked against the authoritative NERC requirement text rather than accepted as a finding. Before you choose a stack, confirm several points in your own environment: which sharing feeds and sharing groups your organization is permitted to join under its information handling rules, which ingestion options your security operations team can run and maintain, whether the E-ISAC and government sources you rely on can be fed into MISP or OpenCTI in your setup, and how access to sensitive facility information is restricted. Review the MISP features page and the OpenCTI overview against those answers.

Licensing is a separate decision. AGPL-3.0-only requires that if you modify these tools and make them available to others over a network, you must offer those recipients the corresponding source code under the same license. Running an unmodified copy internally generally carries different obligations than running a modified copy for a vendor or affiliate, so have counsel confirm your position before you customize, host for third parties, or embed the software in a service. OpenCTI's Apache-2.0 license is more permissive, but its connectors and any third-party components still carry their own terms. Record the license and version of each tool in your evidence set, since the evaluation and its supporting records must be reproducible at audit.

Who owns the R4 evaluation, who prepares evidence and who audits it

The Transmission Owner or Transmission Operator owns the R4 evaluation. Its leaders decide which threats apply to each station, substation and primary control center, judge how the facility characteristics and attack history bear on risk, and sign off on the conclusions. Those conclusions then feed the R5 physical security plan, so the same people must be able to explain why each threat was or was not considered credible. Nothing in the standard lets an outside firm take over this accountability.

Decision ownership: Name an accountable owner for the R4 evaluation and record who approved each station's conclusions and when.
Facility knowledge: Keep site characteristics, layout, access points and surrounding conditions in internal records that the evaluation can cite.
Input intake: Assign someone to receive threat warnings from law enforcement, the ERO, the E-ISAC and government agencies, and to log what was received and how it was used.
Attack history review: Document how the team searched for prior attacks on similar facilities and what frequency, proximity and severity findings it relied on.
Reassessment triggers: Define what new information or site change prompts a fresh evaluation, instead of waiting for the next scheduled cycle.

Before relying on any partner's materials, confirm that your own team can reproduce and defend each conclusion without them.

Where R4 evaluations usually fall short

R4 evaluations tend to fail on the paperwork around the analysis rather than the analysis itself. The gaps below cluster around scope, the quality and dating of inputs, and who stands behind the conclusions when an auditor asks.

Facility list drifts from R1 and R2

The R4 evaluation has to cover the facilities identified and verified under R1 and R2. Teams often keep an older station list in a spreadsheet while the R1 study, the verifier's comments or a later transmission change point to different sites. Before the evaluation is written, reconcile the R4 facility list line by line against the current R1 identification and the R2 verification record, and note any station added, removed or renamed with the date and the reason.

Threat intelligence without dates or sources

Parts 4.2 and 4.3 ask the evaluation to consider intelligence and warnings from named sources, including law enforcement, the E-ISAC and government agencies. A bullet that says a region is high risk does not show what was received, from whom or when. Keep each input with its source, its date of receipt and the facility it affected, so an assessor can trace every conclusion back to a document.

Attack history gathered without criteria

Part 4.2 asks for prior attacks on similar facilities, judged by frequency, geographic proximity and severity. Many evaluations list incidents from news searches without stating why those events count or which were excluded. Write down the search period, the sources, the similarity test and the rule for severity, then record which incidents were screened out and why. A short, reasoned exclusion list is easier to defend than an unexplained long one.

Primary control center left out

R4 covers each identified station, substation and the primary control center. Evaluations often focus on the yards and leave the control center to a separate document, or skip it because it sits inside a corporate campus. Give the control center its own section with the same site characteristics, attack history and threat inputs used for the stations, and confirm that its primary control center link from R1 is the one under review.

No record of approval

An evaluation with no named approver leaves the auditor unable to tell whether the conclusions were reviewed by anyone accountable. Record who prepared the analysis, who reviewed it, who approved the conclusions and the date of each step, and keep the signed version as the evidence copy. The approval record should match the version of the evaluation that feeds the R5 physical security plan.

Not refreshed after new warnings

An evaluation written once and left alone may not reflect a later threat warning, a nearby incident or a change in site layout. Set a review trigger for new intelligence, document each review even when nothing changes, and note which warnings were assessed and what was concluded. Reviewers look for this trail as much as for the original analysis.

Questions buyers ask about the R4 evaluation

How much effort does the R4 evaluation take, and what drives it?

The effort depends mainly on how many stations, substations and primary control centers are in scope, how complex each site is, and how much threat history and intelligence the team must gather and document. The standard requires the evaluation to consider the unique characteristics of each facility, prior attacks on similar facilities, and intelligence or threat warnings from named sources. Sites with many access points, remote locations or unusual topology take longer to characterize. The first evaluation is the heaviest because the baseline is built from scratch. Ask any provider for a fixed-scope quote that lists the facilities, the data sources to be reviewed and the deliverables, since those three items set most of the cost. No duration figure is given here because none is supplied for this topic; confirm expected effort with your Regional Entity and your own asset list.

Can an in-house team complete the R4 evaluation without outside help?

Yes, the standard does not require an outside party for R4, so an in-house team can perform the evaluation if it has the right skills and documentation. The team needs physical security knowledge, familiarity with the facilities, and access to threat sources such as law enforcement, the E-ISAC and government agencies. Many organizations find the gap is in structured documentation rather than in analysis, because each facility's characteristics, attack history and threat inputs must be recorded in a way an auditor can follow. Outside help is usually bought for facilitation, for building the method and templates, or for a second set of eyes before an audit. Confirm the specific documentation expectations and the acceptable method with your Regional Entity before you decide.

What does the R4 evaluation need from operations and physical security staff?

The evaluation needs operations staff to describe how each station, substation and control center is built, powered, accessed and restored, and it needs physical security staff to describe perimeters, barriers, detection, response times and existing incidents. Both groups should confirm what is documented versus what happens in practice. Operations knowledge shapes which attack scenarios matter, such as the loss of a critical transformer or a control room. Physical security input shapes the vulnerability picture. Plan a working session per facility group, and keep a record of who provided each input and when. Confirm with your own compliance lead which staff roles must sign off on the evaluation.

Can an outside party perform the R4 evaluation?

An outside party can help prepare the evaluation, but the Transmission Owner or Transmission Operator remains responsible for it under CIP-014-3. An external consultant can gather inputs, draft the method, run workshops and document results, while the registered entity owns the conclusions and keeps the records. Do not assume that a third party's involvement satisfies the requirement by itself. The independent checks in this standard are separate: the R2 verification of the risk assessment and the R6 review of the evaluation and plan are performed by unaffiliated parties. Confirm with your Regional Entity which parts of an outside engagement it expects the entity to carry out personally.

How does the R4 evaluation differ from the R6 third-party review?

R4 is the entity's own evaluation of threats and vulnerabilities at each identified facility, while R6 is an independent review of that evaluation and the R5 security plan by a qualified physical security reviewer. The organization performs R4 and owns its conclusions. The reviewer under R6 must be unaffiliated and must be completed within the timeline set in the standard, followed by a window to act on recommendations or document disagreement. In practice, the R4 record should be organized so the reviewer can follow the reasoning without interviews. Confirm the R6 timing and reviewer qualifications in the standard itself before scheduling either step.

What will an auditor ask about the R4 evaluation first?

An auditor will typically ask which facilities the evaluation covers, how each one was identified as in scope, and whether the evaluation considered the three elements R4 names: unique facility characteristics, prior attack history, and threat intelligence from the listed sources. Expect requests to see the dated evaluation, the inputs used, who performed it, and how it was kept current. Auditors also check that the evaluation links to the physical security plan that follows it. Prepare a single index that maps each facility to its evaluation record and its sources. Confirm the evidence expectations, retention period and audit timing with your Regional Entity, because the audit process itself is set by NERC and the Regional Entity rather than by this page.

Do open-source threat intelligence tools satisfy the R4 requirement on their own?

No. Tools such as MISP and OpenCTI can collect, correlate and organize threat information, but R4 requires a physical threat and vulnerability evaluation for each facility, which is an analytical judgment the entity must make and document. MISP can correlate indicators and record sightings, and OpenCTI can structure threat knowledge as STIX-based entities, so either may help assemble the intelligence input. However, these tools do not assess site characteristics or physical vulnerabilities, and they do not produce the evaluation. Note that the standard's threat sources, including the E-ISAC and government agencies, are not automatically supplied by a tool feed. Confirm with your Regional Entity how it expects tool output to be referenced in the evaluation record.

How DeployOpen prepares R4 evidence

DeployOpen helps owners and operators prepare the systems, records and evidence behind CIP-014-3 R4 physical threat and vulnerability evaluations. The organization owns its evaluation and its conclusions, while DeployOpen works inside the client's own environment to organize the inputs and documentation an independent reviewer will need to test.

How we scope

Agree in writing which stations, substations and primary control centers the R4 evaluation covers.
Define which threat sources, intelligence feeds and attack-history records the evaluation will draw on.
Confirm which deliverables, timelines and responsibilities sit with the client and which sit with DeployOpen before work starts.

How we build

Set up threat intelligence platforms in the client's infrastructure to collect and correlate indicators relevant to the facilities.
Structure site characteristic records and attack-history data so each facility's evaluation can be traced to its inputs.
Configure reporting templates that show how each R4 sub-part was considered, without making the threat judgments for the client.

How we hand over

Deliver documented evidence packages that map each facility to its threat sources, intelligence reviews and evaluation records.
Provide runbooks describing how analysts update intelligence inputs and when the evaluation should be revisited.
Walk the client's team through the platform configuration, data sources and retention settings so they can answer reviewer questions.

How we support

Offer ongoing support, upgrades and maintenance of the self-hosted platforms as a retainer where the client wants continuity.
Review evidence readiness ahead of a third-party review or Regional Entity audit, when the client asks for it in writing.
Confirm with the client's compliance lead which records must be retained and for how long under their own program.