CIP-008-6 R1 incident response plan requirements

What the CIP-008-6 R1 incident response plan must contain

CIP-008-6 Requirement R1 asks a registered entity to maintain one or more documented Cyber Security Incident response plans that cover its high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS). The plan must contain four elements: how incidents are identified and classified and how they are responded to (Part 1.1), the criteria for deciding whether an event is a Reportable Cyber Security Incident or an attempt to compromise an applicable system (Part 1.2), the roles and responsibilities of the people or groups who respond (Part 1.3), and the handling procedures that run from detection to recovery (Part 1.4). Part 1.2 is the element teams most often leave vague, because it feeds the notification duties in R4. The criteria should name the specific systems in scope, the conditions that count as an attempt to compromise, and who makes the call and how quickly.

The risk this requirement addresses is slow or inconsistent response to intrusions into grid control systems. When an alert fires at 2 a.m., an operator should not be deciding from scratch whether it matters, who to call, or which steps come first. A written plan with defined thresholds and named responders lets the team act on the same facts the same way every time, and it gives the entity a defensible record of its decisions. The plan also has to fit the environment it protects. Criteria written for enterprise IT often miss operational signals, so the reader should confirm that the plan reflects how the control center, substations and vendor connections actually work.

Teams find this requirement hard because a plan is easy to write and hard to show as operating practice. An auditor will look for evidence that the plan was used, such as tickets, classification records, role assignments that match current staffing and handling notes from exercises or real events. Your first step is to check each of the four parts against a current org chart and asset list, then ask who would hold each role during a shift change or vacation. Plan the work to keep those records from the start, because reconstructing them after an audit notice is far more costly than capturing them as incidents occur.

Which systems and teams the plan must cover

The plan's scope comes from the CIP-002 categorization, not from a judgment made when the plan is written. The cards below follow the chain from impact rating to the systems inside scope, then to the teams whose roles the plan must name.

High and medium impact BES Cyber Systems

CIP-008-6 R1 applies to high and medium impact BES Cyber Systems identified under CIP-002. Start from the approved CIP-002 list and confirm that every system rated high or medium has a place in the incident response scope. A system missing from the categorization will also be missing from the plan, so an assessor who finds an uncategorized control system will question the whole scope. Check that the list matches the current network diagrams and asset inventory.

Associated EACMS in scope

The plan must also cover the Electronic Access Control or Monitoring Systems associated with high and medium impact BES Cyber Systems. These are the systems that grant or log access, such as authentication servers, jump hosts and intrusion detection sensors. Teams often treat them as IT infrastructure and leave them out of the control system plan. Map each EACMS to the BES Cyber Systems it protects so that an attack on the access layer triggers the same response path.

Low impact assets under CIP-003

Low impact BES Cyber Systems do not fall under the R1 plan requirement. Their incident handling is addressed through the cyber security plan under CIP-003 instead, so the entity should document that split explicitly. Confirm with your Regional Entity or compliance adviser how the low impact controls are reflected in your program, because a mixed site can carry both obligations. Keep the low impact scope written down so the boundary between the two plans is clear.

Operations and control engineering roles

Control room operators usually detect the first signs of an incident, such as unexpected setpoint changes or loss of communication with field devices. Control system engineers know which Cyber Assets are safe to isolate without disrupting the grid. The plan should name these groups as responders and define what each one decides and reports. Without that, operators may wait for IT to confirm an event that already affects the bulk electric system.

IT security and vendor contacts

IT security typically leads classification, evidence preservation and reporting decisions, while vendors and integrators can contribute forensic data and remediation support for systems they maintain. The plan should list vendor contacts, escalation paths and how they are reached outside business hours. Confirm that vendor contracts allow them to respond within the timeframes your plan sets, because an unreachable vendor can stall containment.

Named roles and their owners

Part 1.3 requires the plan to define roles and responsibilities for each incident response group or individual. Each role should name a position rather than only a person, with a backup who holds the same authority. Review the role list whenever personnel or teams change, since outdated names are a common finding. Confirm that every role appears in the training and notification records the program keeps.

Writing reportable and attempt-to-compromise criteria that hold up

Part 1.2 of CIP-008-6 requires your plan to contain a process for determining whether a Cyber Security Incident is a Reportable Cyber Security Incident or an attempt to compromise an applicable system, using criteria you define yourself. Those criteria are the trigger for the R4 notification duties, so an assessor will read them first and test whether your staff applied them the same way every time. The standard leaves the wording to you, which means the burden falls on you to show that the wording is specific enough to produce a consistent answer. Vague language such as "significant impact" or "suspicious activity" fails this test because two analysts can reach opposite conclusions about the same event and both can point to the same sentence in the plan.

Write each criterion as a decision rule with three inputs: the impact rating of the affected BES Cyber System (high, medium or low, as set under CIP-002), whether the affected asset is an applicable system or an associated EACMS, PACS or PCA, and the indicators that were observed, such as confirmed unauthorized access, malicious code execution, loss of monitoring or an attempt that was blocked before reaching the perimeter. Ask the question for each rule: could a reviewer, given only the rule and the facts, reach the same classification? If the rule needs a judgment call, define who makes it, what evidence they must have, and what they do when the evidence is incomplete. Confirm with your Compliance Enforcement Authority how they read the scope of attempts, because interpretations of that term are where audit findings often arise.

Record every classification decision in your case management system, not only the final outcome. A useful record names the criteria applied, the facts relied on with timestamps, the analyst and reviewer, the reasoning in a few sentences, and any change made after new information arrived. DFIR-IRIS can hold this as part of the case record with its audit trail, and a wiki with version history, such as XWiki, can keep the criteria themselves under change control so you can show which wording applied on the date of an incident. Test the process with a tabletop exercise that includes a borderline event, because the first real decision is rarely the first time the team has had to apply the rules.

Building the plan in order

The sequence below turns the CIP-008-6 R1 requirements into a plan an auditor can trace from scope to handling procedure. Each step produces a document or record that the next step depends on.

Confirm scope from the CIP-002 list
Start from your approved CIP-002 categorization and list the high and medium impact BES Cyber Systems, along with their associated EACMS. R1 applies to these systems, so the plan's scope must match that list exactly. Owners of the categorization, usually the CIP Senior Manager or a delegate, confirm the list and any systems added since the last review. The output is a scoping statement that names each applicable system category and points to the approved CIP-002 record it came from.
Define classification and reportable criteria
Write the categories you will use to classify a Cyber Security Incident and the criteria that separate a Reportable Cyber Security Incident from an attempt to compromise an applicable system. Part 1.2 leaves these criteria to the entity, so they must be specific enough that two responders would reach the same answer. Security operations and compliance staff draft them together, and the CIP Senior Manager approves them. The output is a classification table with worked criteria, which the R4 notification steps will reference.
Assign roles and named backups
Document the incident response groups or individuals and what each one does, covering detection, triage, technical analysis, containment, communications, and reporting. Name a primary and a backup for each function so that absence does not leave a gap during a live incident. Confirm each named person has accepted the role and knows how to reach the others after hours. The output is a roles and responsibilities matrix with contact paths, which Part 1.3 requires and which auditors check against staff records.
Write handling procedures for each phase
Write the incident handling procedures required by Part 1.4 for each phase of response, including identification, containment, eradication, recovery, and lessons learned. Each procedure should name the trigger, the responsible role, the tools used, and the record produced. Keep the steps concrete enough for an on-call responder to follow without the author present. The output is a procedure set that maps each phase to a responsible role and a required record.
Approve and version the plan
Route the complete plan through your internal approval process, record the approver and date, and assign a version number. Store the approved version in a controlled repository where changes are tracked, so you can show an auditor what the plan said on any given date. Confirm that superseded versions are retained, not overwritten. The output is an approved plan document with a revision history and an approval record.
Connect the plan to case records
Link the procedures to the tools that will hold incident evidence, such as a case management platform for tracking assets, indicators, tasks, and evidence with a timeline. Test that a sample incident can be opened, classified, assigned, and closed in the tool, and that the record shows who did what and when. Confirm the tool retains records long enough to meet your evidence retention needs. The output is a tested workflow and a sample case record that demonstrates the plan in use.

How an auditor tests the incident response plan

This table compares, for each element of the CIP-008-6 R1 plan, how an auditor typically tests it, what evidence is requested and where findings usually arise. The Compliance Enforcement Authority tests through Compliance Audits, Spot Checks or Self-Certifications, and the auditor decides whether the evidence is sufficient. The main takeaway is that a plan that exists on paper but cannot be traced to real practice is the most common source of findings.

Plan element	Test approach	Evidence requested	Common findings
Identification and classification (Part 1.1)	Reads the plan for processes that identify, classify and respond to Cyber Security Incidents, then checks that the steps match the entity's tooling and staffing.	The current plan with version history, plus records showing how past alerts were identified and classified.	Classification steps are generic, or no record shows the process was followed for a real alert.
Reportable and attempt criteria (Part 1.2)	Checks that entity-defined criteria distinguish Reportable Cyber Security Incidents from attempts to compromise, and that the criteria cover applicable systems.	Written criteria, the decision record for sampled incidents and any attempts, and the link to R4 notification steps.	Criteria are undefined, do not mention attempts to compromise, or are applied inconsistently across sampled cases.
Roles and responsibilities (Part 1.3)	Compares the named groups or individuals in the plan with current staff, on-call rosters and contractor responsibilities.	Role definitions, current contact lists, on-call schedules and evidence that named roles are current.	Plan names departed staff or teams, or responsibilities for vendor-operated systems are not assigned.
Incident handling procedures (Part 1.4)	Walks through the handling steps against sampled incidents or exercise records to confirm the plan was followed.	Handling procedures, case records showing actions taken, timestamps and evidence of preservation.	Procedures are described at a high level only, or case records do not show the plan's steps were used.
Plan review and currency	Confirms the plan reflects the current environment and that changes were made when systems, roles or lessons learned required them.	Revision history, approval records and cross-references to test results and post-incident reviews.	The plan is not updated after tests or incidents, or revisions are not dated and approved.

Evidence that satisfies R1 and how to keep it current

An auditor testing R1 wants to see a plan that exists, has been approved, and is the version in force, along with supporting records that show the entity acted on it. The cards below cover the artifacts that carry that proof and the tools that can hold them, with the retention and access rules your own compliance program must confirm.

Approved plan with version history

The core artifact is the documented Cyber Security Incident response plan itself, with a version history showing each revision, its approval date and the approver. Auditors check that the version in force covers the high and medium impact BES Cyber Systems and their associated EACMS in your scope. Confirm that superseded versions are retained, because a gap between a plan change and its approval is a common finding. A wiki with page history can hold this, provided it records who changed what and when.

Classification and reportable criteria record

Part 1.2 requires entity-defined criteria for deciding whether an incident is a Reportable Cyber Security Incident or an attempt to compromise an applicable system. Keep that criteria document as its own controlled artifact, with the classification levels used in Part 1.1 and the decision points that move an event from triage to notification. Record the reasoning behind any incident classified as not reportable, since reviewers ask for it during audits. Confirm the criteria match the terms used in the standard and in your R4 reporting procedure.

Roles matrix with named individuals and backups

Part 1.3 requires the roles and responsibilities of response groups or individuals to be defined. A roles matrix should name a primary and a backup for each role, including who can declare an incident, who makes the reportability decision and who submits notifications. Names alone are not enough, so pair each entry with a current contact method and a review date. Confirm that role assignments in your knowledge base or case platform match this matrix, since mismatched access is easy to miss.

Handling procedures and access control

Part 1.4 covers the incident handling procedures, from identification through containment, eradication, recovery and lessons learned. Store the procedures where responders can reach them during an incident, and restrict who can edit them. Role-based permissions let you grant read access to responders and edit rights only to the plan owner, with overrides applied at page or book level where needed. A knowledge base such as BookStack assigns abilities through roles, so confirm that the permission model matches your change approval process.

Incident records showing the plan was in effect

Auditors look for records that prove the plan was used, not only written. A case platform can hold one record per incident with assets, indicators, tasks and evidence, plus an audit trail of who did what. DFIR-IRIS also logs evidence with SHA-256 verification and chain of custody, which supports the handling record. Where no reportable incidents occurred, keep the triage records that show the plan was applied to alerts. Confirm the platform's retention period and access restrictions against your own policy before relying on it as the system of record.

What meeting CIP-008-6 R1 costs in money and effort

This table separates one-time work to build the R1 plan from recurring work to keep it current and evidenced. Read each row for who is paid, what drives the cost up or down, and what to request in a written quote. No dollar or hour figures are given because none are supplied, so use the quote request column to compare proposals on equal terms.

Cost component	Who pays, and for what	What drives it up or down	What to request in a quote
One-time: scoping review	The entity pays staff time to confirm which high and medium impact BES Cyber Systems and associated EACMS are in scope, drawing on the CIP-002 categorization.	Number of Control Centers, sites and EACMS. A current, accurate CIP-002 list reduces rework.	Named scope list, assumptions about which systems are covered, and who signs off the scope.
One-time: incident classification and criteria design	Staff time, often with legal or compliance review, to write the entity-defined criteria for Reportable Cyber Security Incidents and attempts to compromise.	Number of system types and attack patterns covered, and how many internal reviewers must agree. Reusing existing severity definitions lowers effort.	Deliverable list for criteria, review rounds included, and whether the partner drafts or only reviews.
One-time: plan writing and handling procedures	Implementation partner or internal staff draft the plan and handling procedures. The entity owns the final text.	Depth of procedures per incident type and the number of platforms and sites the plan must cover. Open-source case tools can be configured rather than bought, which removes license spend, but configuration effort remains.	Fixed-scope deliverables, drafting hours assumed, and whether platform configuration for the case tool and wiki is included or billed separately.
One-time: role workshops	Staff time for responders, operations, management and the CIP Senior Manager to agree roles and responsibilities under Part 1.3.	Number of groups and shifts, and whether roles already exist in an incident response or on-call structure.	Workshop count, attendees expected, and facilitation responsibilities.
One-time: approvals and records	Internal approval time and the cost of setting up a version-controlled location for the approved plan.	Number of approvers and the number of revision cycles before sign-off. Version-controlled wikis such as XWiki can remove license cost for this record.	Approval workflow, format of the approved record, and who keeps the signed copy.
Recurring: annual plan review and updates	Staff time each cycle to check the plan against current systems, contacts and reportable criteria. Changes flow into R3 notifications.	Frequency of system or personnel change, and whether roles changed. Keeping contacts in one maintained location reduces the review burden.	Whether annual review support is included in a retainer, and what triggers an out-of-cycle update.
Recurring: evidence upkeep	Staff time to keep incident records, case timelines, evidence logs and version history complete. Self-hosted case management such as DFIR-IRIS can remove license cost, but hosting and backups stay with the entity.	Volume of alerts triaged into cases and the retention period. Clear case templates reduce manual entry.	Hosting responsibility, backup and retention settings, and who performs quarterly evidence checks.
Recurring: testing effort tied to R2	Staff and exercise time to test the plan at least every 15 calendar months, which feeds the R2 record of testing.	Test type (tabletop or simulated), number of plans, and whether an external team runs the exercise. Testing environments in a cyber range can reduce disruption.	Test design, number of exercises per cycle, and what written test record is delivered.
Recurring: assessor sampling	Staff time to produce evidence for a Compliance Audit or Spot Check. The Regional Entity, not DeployOpen, decides what it samples and issues findings.	Audit schedule set by the Regional Entity, the audit period, and how well evidence is indexed. Good indexing shortens sampling time.	Evidence index and who prepares it, and what support is included during an audit engagement.

Who owns the plan, who helps, and who audits it

The registered entity owns the Cyber Security Incident response plan required by CIP-008-6 R1. It decides the classification scheme, the criteria used to determine whether an event is a Reportable Cyber Security Incident or an attempt to compromise, the named roles, and the handling steps. Those decisions need documented approval by the people accountable for the program, and the entity must be able to show that responders actually use the plan. A plan that exists only as a document in a shared folder will not satisfy an auditor who asks for evidence of operating use.

Criteria and classification: The entity sets the Reportable incident and attempt-to-compromise criteria and the severity scheme, and records why they fit its environment.
Roles and approvals: The entity names the individuals or groups for each responsibility and records the approval of the plan.
Operating evidence: Tickets, case records, and notes from real events or exercises show the plan being followed.
Scope alignment: The entity confirms which high and medium impact BES Cyber Systems and associated EACMS the plan covers, using its CIP-002 categorization.
Ownership of records: The entity keeps the plan under version control and retains the evidence for the audit period.

Check that a named internal owner can explain each criterion and produce the record of the last time the plan was used.

Where incident response plans usually fail review

Most CIP-008-6 R1 plans exist on paper but fail when an assessor tests whether they are specific, owned, current and used. The gaps below cluster around decision rules, named accountability, document control, linkage to records, scope and proof of operation.

Reportable criteria that restate the standard

Many plans repeat the definitions of Reportable Cyber Security Incident and attempt to compromise without saying how an analyst decides which one applies. Part 1.2 expects entity-defined criteria, so write decision rules tied to your own systems, such as which alerts on a high impact BES Cyber System count as an attempt to compromise and who makes the call. Check that an on-shift analyst could reach a classification from the plan alone.

Roles that name teams only

Plans often assign duties to a team such as the security operations center without naming the individuals, their alternates or the escalation path after hours. Part 1.3 asks for defined roles and responsibilities, so list each role with a primary and backup, the contact method, and the decision it owns. Confirm the roster against your current staffing and vendor support arrangements at least once a year.

Plans with no version or approval record

A plan kept as a shared file often has no record of who approved which version, what changed, or whether the copy in use is the current one. Assessors ask for evidence that the plan was reviewed and approved, and they check that responders used the version in force at the time. Keep the plan in a tool with version history and an approval step, and record the approver and effective date on the document itself.

Handling steps disconnected from case records

Handling procedures frequently describe containment and eradication without saying where the evidence, timeline and decisions get recorded. Part 1.4 covers the procedures, but the work only proves compliance when each step leaves a record tied to the incident. Name the case management system that will hold the timeline, the tasks, the evidence and the classification decision, and state which fields must be completed before an incident closes.

Scope that stops at IT systems

Plans frequently cover servers and workstations but omit the Electronic Access Control or Monitoring Systems, Physical Access Control Systems and vendor-operated remote access paths that the standard applies to. Map each applicable system category from your CIP-002 categorization to a detection source and a response owner, including remote access brokered by a third party. Ask your vendors how they would notify you and who on their side is authorized to act.

Plans never exercised before an audit

A plan that has never been run in a test, tabletop or real event often reveals missing contacts and unclear criteria only when an assessor asks for evidence. CIP-008-6 R2 requires testing at least every 15 calendar months, so the plan itself should name the test scenario, the participants and the record of results. Before any audit notice, walk one scenario from detection to classification to notification and keep the notes.

Common questions about the CIP-008-6 R1 incident response plan

How much effort does writing a CIP-008-6 R1 incident response plan take?

The effort depends mostly on how many applicable systems the plan must cover and how much of your incident handling is already written down. A single high impact Control Center with a mature security operations function usually needs less drafting than several medium impact sites that have never documented incident handling. The work follows the four parts of R1: identification and classification, criteria for Reportable Cyber Security Incidents and attempts to compromise, roles and responsibilities, and incident handling procedures. Each part needs decisions from the people who own the systems, not only from the people writing the document. Cost comes from internal staff time, legal or compliance review, and any outside help with drafting or validation. Ask any prospective partner to itemize these components in a written scope, and confirm with your Regional Entity how it expects the reporting criteria to be documented.

How long does it take to get the plan approved and in service?

No fixed duration applies to R1 itself, so the timeline depends on its inputs. The main drivers are how complete your CIP-002 categorization is, how many departments must sign off on roles, how quickly reporting criteria are agreed with legal and operations, and whether the plan depends on tooling that is still being deployed. Organizations with existing incident response procedures usually move faster because the work is mostly mapping and filling gaps. Plans that need new case management, evidence handling or communication channels take longer, because those systems must exist before the plan can point to them. Confirm which body must accept the plan, how many review cycles it expects, and whether any project dependency affects the date. A fixed-scope written plan should state its dependencies and the client decisions needed at each milestone.

What does the CIP-008 plan need from our own staff?

The plan needs named decisions from the people who run the systems, handle incidents and submit reports. Expect input from the CIP Senior Manager or delegate, control room and operations leads, the security operations team, IT, legal, and whoever files external reports. Typical requests include confirming which assets are in scope, agreeing the criteria for Reportable Cyber Security Incidents, naming the roles that declare an incident, and walking through how a shift would respond at night. Plan for several working sessions and a review cycle. Staff also need to provide current network diagrams, asset inventories and existing runbooks, because a plan written only from policy seldom matches practice. Ask who must approve the final document and who will keep it current after go-live, since the plan must be maintained under R3.

Can an in-house team write a CIP-008 plan without outside help?

Yes, an in-house team can write an R1 plan without an outside partner, provided it has people who know the BES Cyber Systems, the incident handling process and the CIP requirements. The entity owns the plan either way. Internal teams often struggle with three things: obtaining an independent view of gaps, keeping the criteria consistent with what the Compliance Enforcement Authority expects, and finding time to test the plan once it is written. An outside party can review drafts, challenge assumptions and run a tabletop walk-through, but it cannot certify compliance or replace the entity's own judgment. Assess whether your team includes someone who has worked a CIP audit or handled an incident, whether compliance and operations can both commit time, and whether the people who helped write the plan will also take part in the R2 test. Whichever route you choose, get the scope and deliverables in writing.

Can a partner take on the platform and evidence work for the plan?

A partner can take on the platform and evidence side of the plan, while the entity keeps ownership of the plan, its criteria and its compliance decisions. DeployOpen plans, implements, configures, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For R1, that can include setting up case management for incident records, a knowledge base for the plan and its procedures, and role-based access so responders see only what they need. Evidence work includes defining what each system records, how records are retained, and how each procedure traces to a CIP-008 part. DeployOpen does not issue audit reports or certifications and does not decide what your Regional Entity accepts. Confirm which platforms, access model and retention rules your scope covers, and who owns each system after handover. Engagements are fixed-scope, with scope and deliverables agreed in writing before work begins.

How does R1 connect to R2 testing and R3 review?

R1 defines the plan, R2 requires you to test it and keep records, and R3 requires you to update it and notify responders after tests, actual incidents or changes to roles, teams or technology. A plan that is written but never exercised usually shows its gaps during the first test, so drafting R1 with R2 in mind avoids rework. Give each procedure an owner, an input, a record and a test scenario. The R2 exercise can then check whether the procedure works, and the R3 update can be traced to specific findings. Check the exact testing interval and the notification windows against the standard, since the sibling topics on R2 and R3 set out how they apply. Read the standard text for the precise obligations: CIP-008-6 standard PDF.

Does the R1 incident response plan have to cover low impact assets?

CIP-008-6 R1 applies to high and medium impact BES Cyber Systems and their associated EACMS, so it does not require a CIP-008 plan for low impact assets. Confirm this against your CIP-002 categorization first, because the scope of R1 follows whatever the categorization assigns. Low impact assets are governed by the CIP-003 cyber security plan, which sets its own controls for them and has its own changes scheduled for 2026 and 2029. Entities with only low impact assets should read CIP-003-9 and check what it requires for incident handling and reporting in their environment. Entities with mixed portfolios should keep the boundaries clear. A plan may still cover low impact systems voluntarily, but document that choice as a voluntary practice and do not describe it as a CIP-008 obligation. Ask your Regional Entity or compliance advisor to confirm scope against your asset list.

How DeployOpen prepares CIP-008-6 R1 evidence

DeployOpen works on CIP-008-6 R1 by preparing the systems and documents an incident response plan needs to serve as evidence, inside your own infrastructure. Your organization owns the plan, its roles and its Reportable criteria. DeployOpen plans, builds and documents the supporting platforms, while the Compliance Enforcement Authority makes the compliance judgment.

How we scope

The written scope names the high and medium impact BES Cyber Systems and associated EACMS the plan covers.
Scope also lists which sites, teams and tools hold incident records, and who owns each one.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We draft a classification matrix for Cyber Security Incidents, with your Reportable and attempt-to-compromise criteria written in plain terms.
We configure case management, such as DFIR-IRIS, to hold assets, indicators, tasks and evidence for each incident.
We set up a documentation platform, such as XWiki or BookStack, so plan versions and role assignments stay traceable.

How we hand over

You receive a draft plan covering identification, classification, roles and incident handling procedures for review.
A traceability table maps each Part 1.1 to 1.4 element to the plan section that addresses it.
Handover includes administrator guides, role assignments and an evidence index your staff can maintain.

How we support

Ongoing support and continuous testing are available as retainers, separate from the initial fixed-scope work.
Testing under CIP-008-6 R2 and plan updates under R3 can be scoped as follow-on work.
Confirm in the quote which evidence items are your responsibility and which are DeployOpen's.