Most industrial environments don't fail at monitoring because the tooling is bad. They fail because monitoring was bolted on before anyone answered the basic questions: what's actually on the network, where does production depend on IT, and who decides what happens at 2 a.m. when something fires.

Use this checklist to take an honest read of where you stand. Every "no" is not a reason to delay monitoring — it's usually the first thing a monitoring engagement fixes. But knowing your answers changes the conversation with any provider from a product pitch to a plan.

1. Asset visibility

  • ☐ We have a current inventory of every device on the plant network — including PLCs, HMIs, historians, engineering workstations, and the things nobody remembers installing.
  • ☐ We know which assets run firmware or operating systems that can no longer be patched.
  • ☐ We would notice if a new, unknown device appeared on the OT network this week.
  • ☐ Our network diagram matches reality, not the as-designed drawing from commissioning.

Why it matters: you cannot monitor what you haven't mapped. Passive discovery — listening to a mirror of network traffic without probing a single controller — is how this gap gets closed without touching production.

2. The IT/OT boundary

  • ☐ We can name every connection between the enterprise network and the plant network — including the temporary ones that became permanent.
  • ☐ We know which IT systems production actually depends on (ERP, MES, virtualization, licensing servers) — the systems that stop the line without an attacker ever touching a controller.
  • ☐ Vendor and integrator remote access goes through a path we control and log — not a cellular modem in a cabinet.
  • ☐ Segmentation between IT and OT exists in practice, not just in the architecture slide.

Why it matters: in recent industrial ransomware incidents, disrupting enterprise IT alone was often enough to halt production. The boundary is where most attacks cross — and where monitoring earns its keep.

3. Who is watching today

  • ☐ Someone — a person, not just a tool — reviews OT network alerts within hours, around the clock, including weekends and holidays.
  • ☐ Our monitoring is passive: nothing in the security stack probes, scans, or injects packets into the control network.
  • ☐ Alert volume is low enough that the people responsible actually read them.
  • ☐ Detections are mapped to a recognized framework (MITRE ATT&CK for ICS), so we can say what stage of an attack we're seeing.

Why it matters: a SIEM nobody watches is a compliance artifact, not a control. The honest version of this section for most plants is "the day shift glances at it" — which is exactly the gap a managed OT SOC closes.

4. Response readiness

  • ☐ We have written runbooks for the most likely OT incidents — and they respect uptime (isolate and investigate, not "reboot everything").
  • ☐ It is decided, in writing, who has the authority to take containment actions that could affect production — and containment on OT assets stays in our hands, not a vendor's.
  • ☐ We have named escalation contacts on both the plant side and the security side, with an after-hours path.
  • ☐ We have walked through at least one OT incident scenario as a tabletop in the last year.

Why it matters: detection without a decided response path just moves the panic earlier. The best engagements pair 24/7 eyes with response guidance that plant engineers can actually execute.

5. Compliance and evidence

  • ☐ We know which frameworks and regulations apply to us — IEC 62443, NIS2 or the EU CRA for European exposure, FDA §524B for medical device makers.
  • ☐ We can produce evidence of continuous monitoring if an auditor, customer, or cyber insurer asks for it this quarter.
  • ☐ Security reporting reaches plant leadership in operational terms — risk to production, not raw alert counts.

Why it matters: monitoring evidence is increasingly the price of admission — in insurance questionnaires, customer security reviews, and regulatory audits. Framework-mapped reporting turns the same work into answers for all three.

Questions to ask any managed OT SOC provider

  1. Is your deployment fully passive? If the answer involves agents on controllers or active scanning of the OT network, understand exactly what touches production and when.
  2. Who takes containment actions on OT assets? The right answer keeps that authority with your team, with the provider guiding — not acting unilaterally on your plant.
  3. Do your analysts speak OT? Ask how they handle industrial protocols and what MITRE ATT&CK for ICS coverage looks like in their reporting.
  4. What arrives at each service tier? Monitoring, investigation, and threat hunting are different depths of work — a granular tier structure lets you buy what you need now and grow.
  5. Can we see the evidence trail? Independent, tamper-resistant records of what was detected and what was done — useful for audits, insurers, and your own oversight of the provider.
  6. How do you work alongside what we already have? An existing IT MSSP, a SIEM, in-house engineers — a good OT SOC provider has a clear answer for coexistence.

Where MBCTG fits

MBCTG runs a Managed OT SOC built exactly this way: passive visibility with GreyCortex NDR that never probes a controller, 24/7 monitoring in granular T1/T2/T3 tiers, containment always customer-directed, and framework-mapped reporting. If the checklist surfaced more "no" than you'd like, the fastest next step is a security assessment — see what's actually on your plant network before deciding anything else.