Read this before touching anything in this Part

OT systems often control physical, sometimes safety-critical, processes — a pump, a valve, a circuit breaker. Techniques that are routine and safe in Part 4 (an aggressive Nmap scan, a vulnerability scanner) can crash a legacy industrial controller, and a crashed controller can mean a real-world safety incident, not just an IT outage. Every active technique in this Part comes with explicit caution; when in doubt, prefer passive observation over active testing, and never run anything against a live OT system without OT engineering staff present and explicit written authorisation naming the specific technique.

OT Audit Domain Map

flowchart TD F["5.1 Fundamentals:
IT vs OT, Purdue Model,
Standards, Risk Landscape"] --> S["5.2 Network Segmentation
& DMZ Audit"] S --> A["5.3 Asset Inventory,
Patch & Access Control"] A --> Y["5.4 Safety Systems
& CII/critical-infrastructure coordination body"] classDef def fill:#16284a,stroke:#2dd4bf,color:#e8eef9; class F,S,A,Y def;
Start with fundamentals even if you're experienced in IT security — OT's risk model genuinely is different, not just "IT with extra steps."
In plain terms: what is OT?

Information Technology (IT) processes and moves data — emails, records, web pages. Operational Technology (OT) directly senses and controls physical processes — opening a valve, spinning a turbine, tripping a circuit breaker. A crashed IT server is an inconvenience. A crashed OT controller can mean a power outage, a contaminated water supply, or a safety incident. That single difference — IT failures cost data and time, OT failures can cost physical safety — is why this Part exists separately from Part 4, and why every technique here is more conservative.

The Four OT Audit Modules