An OT cybersecurity assessment is a structured review of how well an industrial environment is protected. It compares the controls in place with an agreed reference, records the evidence behind each conclusion and turns gaps into prioritized recommendations that operations can actually implement.
This guide walks through the stages of a practical assessment, from scoping to reporting. It is written for asset owners planning an assessment, and for engineers and security staff who will take part in one.
Define the scope first
Most assessment problems begin with an unclear scope. Before any document is reviewed, agree in writing:
- The question the assessment must answer. "Where are our biggest gaps against IEC 62443-2-1?" leads to a different assessment than "Is our remote access secure?"
- Sites, systems and zones in scope. Name them. "The plant" is not a scope; "the DCS, SIS interfaces, historian and remote access for Line 2" is.
- The reference framework. IEC 62443, NIST SP 800-82, the NIST Cybersecurity Framework, a regulator's requirements or an internal standard. Pick one primary reference so results are consistent.
- Methods allowed. Document review, interviews, site walkdowns, read-only configuration review and, only if explicitly approved, technical testing.
- Constraints. Site access rules, safety inductions, blackout periods and who can approve on-site activity.
A clear scope also defines what is out of scope. Writing that down avoids later disagreement about why a system was not covered.
Understand the industrial systems
Assessors cannot judge controls without understanding what they protect. Early in the assessment, build a working picture of:
- The process and which systems are most important to safety, production and the environment.
- The main control system platforms and vendors.
- Who operates, maintains and supports each system — internal teams, integrators, OEMs.
- Operational constraints: continuous processes, maintenance windows, validated or certified configurations.
This context changes recommendations. Monthly patching may be sensible for an office network and unrealistic for a controller that can only be updated during an annual shutdown.
Review asset and architecture information
Assets and architecture are the foundation of the assessment. Review:
- Asset records — whether an inventory exists, what it covers and how current it is. See Building an OT asset inventory.
- Network drawings — zones, boundaries, firewalls, the industrial DMZ and remote access paths.
- Data flows — which systems communicate across boundaries, and why.
- Shared dependencies — domain controllers, time servers, backup systems and management networks that connect zones.
Expect drawings and reality to differ. Noting where they differ is itself a valuable finding.
Evaluate security controls
Work through the control areas in your reference, rating each against defined criteria. A typical OT baseline includes:
| Area | Typical questions |
|---|---|
| Asset management | Are assets identified, owned and classified? |
| Segmentation | Is OT separated from IT? Are zones and conduits defined? |
| Remote access | Is all access through a controlled, logged path with MFA? |
| Accounts and privileges | Are default and shared accounts controlled? |
| Vulnerability management | Are advisories reviewed and decisions recorded? |
| Endpoint hardening | Are baselines, anti-malware and removable media controls applied? |
| Backup and recovery | Are configurations backed up offline and restores tested? |
| Monitoring and response | Are events reviewed? Is there an OT incident procedure? |
| Change management | Are logic and configuration changes reviewed and recorded? |
| Governance | Do OT-specific policies exist and are roles clear? |
Use a simple, defined rating scale, for example not implemented, partially implemented, largely implemented, implemented. Write down what each level means before you start so different assessors rate consistently.
Collect evidence
A conclusion is only as strong as the evidence behind it. Typical evidence includes documents, configuration exports, screenshots, records such as access reviews or restore tests, interview notes and direct observation.
For each control rating, record what evidence supports it and how strong it is. An interview claim that "backups are tested" is weaker than a dated restore test record. Recording evidence strength lets readers judge confidence and shows where the next assessment should look harder.
Handle evidence carefully. Architecture drawings and configuration exports are sensitive; agree how they are transferred, stored and destroyed.
Document findings
Write each finding so that someone who was not in the room can understand and act on it:
- Observation — what was found, factually.
- Requirement or expectation — what the reference expects.
- Evidence — what the observation is based on.
- Affected systems — which assets or zones are involved.
- Significance — why it matters in this environment.
- Recommendation — what should be done, with options where relevant.
Avoid vague findings such as "improve security awareness". Specific findings lead to specific actions.
Evaluate risk
Not every finding carries the same weight. Consider the criticality of affected systems, realistic threat scenarios, existing safeguards and potential consequences for safety, production and the environment. A structured approach is described in Prioritizing OT cybersecurity risks.
Prioritize improvement activities
Turn findings into a roadmap. Group actions by:
- Urgency — high-risk issues that need attention now.
- Effort and dependency — quick wins versus projects.
- Operational fit — what can be done while running and what needs an outage.
Assign an owner to each action. A roadmap without owners is a wish list.
Report assumptions and limitations
Every assessment has limits: systems not reviewed, evidence not available, interviews that could not be scheduled, tests not performed. State them clearly. Readers need to know what the assessment did not establish, so they do not draw more confidence from it than it supports.
A useful report usually contains an executive summary, scope and method, results by control area, a findings register, a prioritized roadmap and a limitations section. The best reports are short at the top and detailed underneath.
Key takeaways
- Agree a written scope, reference and method before starting.
- Understand the process before judging the controls.
- Rate controls against defined criteria and record the evidence for each.
- Write findings that someone else can act on.
- Prioritize with operational context and assign owners.
- Be explicit about what the assessment could not confirm.