What should an OT cybersecurity engagement define?
An OT cybersecurity engagement should define the operational question, included systems, review criteria, available evidence, deliverables, participating owners and acceptance decisions. For an assessment, agree how gaps will be supported and reported. For finding-to-closure support, agree the actions, owners and evidence needed to review each finding. For recovery readiness, agree one process's digital boundary, recovery materials and the conditions that can be reviewed or demonstrated. Record exclusions and unresolved dependencies before work begins.
This guide helps operational sponsors, IT/OT owners and procurement evaluate a proposed scope and review the resulting work. It describes starting criteria to agree together. The final scope should reflect your environment, the evidence available and the decision your team needs to make.
Keep three decisions separate.
Accepting a deliverable confirms that the agreed work has been supplied and reviewed. Closing a finding requires an authorized decision about the relevant requirement and evidence. Returning equipment to service remains a site-authorized operational decision. A single project sign-off should not blur these responsibilities.
Make the purchase concrete
A scope record that a buyer can review.
The example below is fictional and illustrative. It shows the fields that make an engagement understandable; it is not a client case, a finding about your facility or a completed result.
Illustrative starting point
A provider handover left agreed findings open.
Operational question
What still prevents the site from making an evidence-based disposition of the agreed handover findings?
Engagement
OT Finding-to-Closure Support for the finding register named in the scope.
Included boundary
One production process, the selected operational systems identified in the register and their agreed provider interfaces.
Starting evidence
The existing report, available handover records, current ownership and the requirement behind each finding.
Illustrative agreement
Define the work and the decision owner.
Outputs
Work packages, implementation owners, dependencies, evidence requirements and a progress and decision record.
Reviewers
The named IT/OT owner and relevant provider review the evidence. The designated site authority makes acceptance or risk decisions.
Acceptance criteria
Each agreed finding has a traceable action or decision, an owner, an evidence status and a visible next step where work remains.
Open dependency
A provider record is unavailable. Record its effect on the conclusion and who will decide whether to obtain it or revise the scope.
Example exclusions: Additional systems, an expanded assessment, live-system changes and restoration exercises require their own explicit scope and authorization. The illustrative engagement does not assume that every finding can be closed.
Before the scope is agreed
Bring the question and the evidence you already have.
Begin with a nonconfidential summary. Detailed records and access arrangements can follow an agreed scope and information-handling process.
The trigger: a customer requirement, existing finding, system change, supplier handover or recovery question.
The boundary: the process, line, facility area or systems that the decision concerns, including relevant shared dependencies.
The decision: what an authorized owner needs to decide and any relevant target date or maintenance constraint.
The evidence: whether an inventory, assessment, requirement, finding register, recovery plan or provider record exists.
The participants: the internal owner, technical reviewers and providers whose knowledge, records or actions are needed.
The known limits: missing records, uncertain ownership, access restrictions and dependencies outside your team's control.
A previous report can be a useful input. Check its boundary, criteria, evidence and limitations against the present decision and any known changes. Identify what can be reused before commissioning additional review.
Service-specific review criteria
Agree how each engagement will be accepted.
Acceptance criteria should describe evidence a reviewer can examine. The following criteria are starting points for an agreed scope, not universal certification requirements.
OT Security Assessment
Can the reviewer follow the finding back to its scope and evidence?
Inputs and deliverables
Start with the included systems, applicable review criteria and available records. Receive a documented boundary, evidence record, prioritized gaps and recommended actions.
Responsible reviewers
The system owner confirms the environment and available evidence. The designated technical reviewer examines the findings and limitations. The sponsor reviews whether the agreed deliverables support the intended decision.
Useful acceptance criteria
The included systems and review criteria are identified.
Findings distinguish reviewed evidence, assumptions and unresolved questions.
Priorities explain their operational relevance and known constraints.
Recommended actions and evidence limitations are visible to the responsible owners.
Acceptance decision: Does the assessment deliver the agreed review with conclusions supported to the stated extent? Accepting the report does not implement its recommendations or certify compliance.
OT Finding-to-Closure Support
Does every status have an owner, supporting evidence and a next decision?
Inputs and deliverables
Start with the agreed findings, their requirements, existing evidence and known blockers. Receive work packages, implementation owners, dependencies, evidence requirements and a record of progress and decisions.
Responsible reviewers
Implementation owners and providers supply records of their authorized work. The agreed reviewer examines the evidence. The designated authority decides closure, interim treatment or acceptance of remaining risk.
Useful acceptance criteria
Every included finding is traceable to an action, decision or documented blocker.
Implementation ownership and evidence requirements are explicit.
Completed and checked, interim control, scheduled, risk accepted and unresolved statuses remain distinct.
The record identifies outstanding work and the authority responsible for each remaining decision.
Acceptance decision: Has the agreed coordination and evidence-review work been delivered, with each finding's actual state visible? Completing an action alone does not establish that the underlying finding is closed.
Critical Process Recovery Readiness
Can owners distinguish the recovery materials from the recovery evidence?
Inputs and deliverables
Start with one process, its required digital functions, available recovery materials and the people responsible. Receive a dependency boundary, materials register, ordered workpack, readiness gaps and maintenance and handover needs.
Responsible reviewers
IT/OT owners and technical providers review the materials, dependencies and equipment-specific responsibilities. The operational owner confirms the process context and retains site acceptance and return-to-service authority.
Useful acceptance criteria
The workpack identifies included digital functions, prerequisites and responsible owners.
Materials have identified custodians, with missing or uncertain items recorded.
Documented, demonstrated, failed and untested conditions are clearly distinguished.
Any exercise evidence records its agreed scope, conditions, limits and follow-up decisions.
Acceptance decision: Does the workpack accurately show the recovery arrangements and evidence available within the agreed scope? A readiness review does not guarantee restoration. Exercises require separate agreement, site authorization and appropriate technical providers.
Make acceptance accountable
Name the people who can review and decide.
Assign responsibilities by name or role before work begins. One person may hold several responsibilities, but each decision still needs a clear owner.
Operational sponsor
Defines the process priority, business decision and operational constraints. Identifies the authority for acceptance and escalation.
Technical owners and reviewers
Explain system boundaries and evidence. Review conclusions and their limits against the agreed criteria.
Implementation owners and providers
Own authorized technical work, equipment-specific procedures and the records needed to review what was done.
Procurement or project owner
Confirms the deliverables, participation requirements, scope-change process and completion review. Keeps commercial acceptance distinct from technical and operational decisions.
Zeroday leads the agreed assessment, prioritization, evidence review and coordination. Your authorized site teams and technical providers control live-system changes and equipment-specific procedures.
Finish with an honest record
Keep exclusions and unresolved decisions visible.
A scope should identify omitted systems and activities, evidence that is unavailable, provider dependencies and the treatment of additional work. Ongoing monitoring, emergency response coverage, major implementation projects and process engineering approval are not implied by these three engagement scopes.
Use a decision register for anything that prevents a supported conclusion or an agreed next step. Each entry should identify:
The affected system, finding or recovery step.
The unresolved question and evidence already available.
The missing input, dependency or authorization.
The effect on the conclusion, deliverable or next activity.
The responsible decision owner and agreed next action.
Illustrative entry: A provider's recovery record is unavailable for an included workstation. Its recovery condition remains untested in the current evidence record. The provider supplies the requested material; the site owner decides whether further review or a separately scoped exercise is needed. The gap stays visible until that decision is supported.
Decisions at review
Questions buyers should be able to answer.
Can an engagement be accepted while findings remain open?
Yes, if the agreed deliverables have been completed and the record accurately shows the remaining work, limitations and decisions. Acceptance of coordination or assessment deliverables is separate from a decision to close each finding. Agree that distinction in the scope.
Who decides whether an OT security finding is closed?
The authorized decision owner identified in the scope decides against the relevant requirement and agreed evidence criteria. Zeroday coordinates and reviews evidence within the engagement; implementation owners provide their records. A completed task, scheduled change or accepted risk should not be silently relabeled as an implemented and checked control.
Can a recovery workpack be accepted before an exercise?
Yes, when the agreed deliverable is a documented readiness review and workpack. The record must identify what remains untested and any missing materials or prerequisites. Accepting that document does not demonstrate successful recovery. An exercise requires its own agreed conditions, authorization and technical participation.
What happens when required evidence is missing?
Record what is missing, which conclusions it affects and who owns the next decision. The parties may agree additional information gathering, limit the conclusion or revise the scope. An unknown condition should remain an unknown until evidence supports a different status.
IEC 62443-3-3:2013 specifies control-system security requirements and security levels. Where this standard informs an assessment, agree the applicable requirements and system boundary in the scope.
The acceptance examples in this guide are practical scoping guidance from Zeroday Cyber. They do not replace the applicable standard, an agreed contract or your site's authorization process.
Put the guide in your operating context
Explore the scope for your industry.
Manufacturing
Customer requirements, production lines, equipment handovers and critical-process recovery questions.
Share the system or process involved, what triggered the request and the people who need to decide. A nonconfidential summary is enough to begin a scoping conversation.