# OT security: protect the process before probing devices

Original SecNet workpaper · 1.0 · 11 October 2026

Complete placeholders for your assessment. The example below is fictional; it is not an executed test or a legal decision.

## Assessment identity

- Record ID: [___]
- Objective and decision question: [___]
- Scope / exclusions: [___]
- Criteria and version: [___]
- Authorization and limits: [___]
- Owner / independent reviewer: [___]
- Period / artifact digest: [___]
- Evidence access / retention: [___]

## Planned procedure

1. Form a joint operations, engineering, safety and security team. Identify critical process states and agree who may stop an activity when plant behavior changes.
2. Build an asset and dependency map from engineering records and passive observation. Record controller/firmware versions, unsupported systems and the confidence of the inventory.
3. Define process zones and constrained communication paths. Separate vendor remote access with approval, time limits, logging and a recovery method suitable for operations.
4. Assess proposed tests with engineering and suppliers in a representative lab first. Prefer passive evidence; active tests need explicit validation, a maintenance window and a stop/rollback plan.
5. Treat patching as controlled engineering change. Where a patch cannot safely be applied, document compensating controls, residual risk, review date and accountable acceptance.
6. Exercise recovery of engineering workstations, logic/configuration backups and approved spare devices. Coordinate cyber response with plant emergency procedures and physical safety.

## Evidence and decision register

| ID | Criterion | Observation | Redacted evidence / origin / time | Conclusion and limitation | Owner / date | Recheck |
|---|---|---|---|---|---|---|
| [___] | [___] | [___] | [___] | [___] | [___] | [___] |

## Topic-specific deliverables

- [ ] Process-critical asset map and safety/change constraints.
- [ ] Zone/communication review and remote-access control record.
- [ ] Compensating-control register and tested restoration plan.

## Worked fictional decision example

Fictional plant: an older controller has a known weakness but no validated patch. The team does not launch an IT scanner at it. They review vendor guidance, narrow reachable services, restrict remote maintenance and test a representative spare in the lab. The risk record names the process owner and next review, while the restore exercise proves that backed-up logic can be recovered.

## Closure check

- [ ] Operations and safety owners approve the plan?
- [ ] Active tests validated in a representative lab first?
- [ ] Logic/configuration restoration demonstrated?

## Official references · checked: 2026-10-11

- [NIST SP 800-82 Rev. 3 · final](https://csrc.nist.gov/pubs/sp/800/82/r3/final)
- [Wireshark guide](https://www.wireshark.org/docs/wsug_html_chunked/)