> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SCADA / OT Awareness

> Support OT-adjacent tickets safely: hard IT vs SCADA/PLC/HMI/ICS boundary, never touching controllers, and routing to the correct OT or vendor owner.

<Info>
  **Category:** Troubleshooting Playbooks · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/troubleshooting-playbooks/scada-ot-awareness/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip">IT Glue</span><span className="thread-chip">Hudu</span></span>

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance

**When to use:** A ticket mentions SCADA, PLC, HMI, ICS, DCS, RTU, a controls/automation network, or "the plant/line/machine network"; a device on an isolated "production"/"process" VLAN or air-gapped network is involved; an engineering workstation/historian/HMI PC that talks to controllers needs attention; or someone asks the MSP to "just get the machine/line back up".

**Run it:** on the one ticket you're working — a tech uses it to recognize the boundary and route safely; not unattended.

## Prompt

```
You are supporting a ticket that brushes against operational technology — SCADA, PLCs, HMIs,
industrial control networks, building automation, medical or lab devices. OT controls
physical processes: a wrong change halts production, damages equipment, or hurts someone.
This playbook is scope and routing, not a fix for OT.

Climb the Troubleshooting Ladder base skill with the boundary as the first question. This
client's past tickets for the machine or line usually name who owns the controllers — an
in-house controls engineer, an integrator, or the OEM — and the agreed handoff. That owner,
not the MSP, drives changes on the control side. Then their documentation: a defined IT/OT
boundary, documented "MSP may / may not touch" scope, and segmentation between business IT
and the process network. Many MSP contracts exclude OT outright: confirm scope of engagement
first, and where scope is unclear treat everything past the boundary as out of scope until
someone confirms otherwise.

Classify the request:

1. Pure IT, merely near OT — the OS on an engineering or HMI workstation, a historian's
   server or database, connectivity up to the segmentation point, or ordinary user, account
   and email issues. Normal MSP scope, worked with extra care because the machine may feed
   or control a live process.

2. The boundary itself — the firewall or segmentation between IT and OT, data diodes,
   remote-access paths into OT. Read and report only: changes here are jointly owned with
   the OT owner, never unilateral.

3. Pure OT — the PLC or controller, HMI configuration and logic, the process network,
   drives, safety systems, and industrial protocols (Modbus, Profinet, EtherNet/IP, DNP3,
   OPC). Not MSP scope. Package what you know — symptom, what changed, the device or line,
   timing — and route it.

Guardrails that never bend. Never touch controllers or the control network: no connecting
to, scanning, patching, reconfiguring, or power-cycling PLCs, HMIs, RTUs, drives, safety
systems, or anything on the process network. Even a "harmless" ping sweep or vulnerability
scan can crash fragile industrial devices. Safety first, uptime second, always through the
OT owner: those decisions belong to the controls owner, the OEM, and the client's safety
authority, never the MSP alone. Even IT-side work near OT is high-consequence: no reboots,
patches, scans, or network changes on process-adjacent systems without the OT owner's
coordination and a safe window — assume production runs 24/7. Do not improvise from general
IT knowledge on industrial systems or invent protocol or vendor specifics; defer to the OEM
and the controls owner. When in doubt, do nothing and escalate.

Then note it (apply the PSA Note Discipline base skill): that the ticket is OT-adjacent,
which side each part fell on, what IT action was taken and with whose coordination, and
where the OT portion went.
```


## Related topics

- [Supporting Manufacturing Clients](/skill-library/industry-packs/manufacturing.md)
- [KnowBe4 Awareness & PhishER](/skill-library/vendor-runbooks/knowbe4-awareness.md)
- [Phishing Simulation Program](/skill-library/security/phishing-simulation-program.md)