Your SIEM watches the network. Your control chart catches the intrusion.

Here is an uncomfortable observation from this week's security news. The Russian crews that camped inside water-utility networks were not stopped by prevention; they exploited a detection gap that standard security tooling has never closed. The same pattern runs through CERT Polska's write-up of an energy-sector intrusion that tunnelled through a VPN and a private APN into the OT network, and through the Copeland refrigeration vulnerabilities Claroty documented in systems keeping commercial cold chains running. All three lived quietly exactly where the tooling was blind.

And here is the part that should sting anyone who runs a plant: every one of those sites already operated a detection system tuned to the physical process, printing its evidence on a control chart shift after shift. Nobody connected it to security.

The gap widens every quarter. Sixty per cent of manufacturers are targeting full digitalisation, and every historian link, MES integration and AI agent granted authority over a setpoint grows the attack surface faster than a SOC can instrument it. You do not have to buy the missing detection layer. It is already installed. It lives in quality.

Why network tools cannot read a process

SIEMs read logs. Firewalls read packets. Neither reads physics. A SIEM can tell you who authenticated and which port opened; it cannot tell you that the curing oven now sits six degrees below where it has held for eleven months. Control limits are different. They are computed from the process itself, so they flag any intervention in the process, whatever its origin. Worn tool. Drifting thermocouple. Suspect batch of steel. A keyboard. The chart does not care; the pattern breaks the same way.

This is why I trust a well-built SPC system more than most log pipelines for OT detection. At the greenfield plant where I built the QA/QC department for 900+ employees, we charted critical parameters with run rules – points beyond limits, step changes, sustained trends – and the alarm logic separated common-cause noise from something that had genuinely changed. A step change at 03:40 with no maintenance work order attached is a signal, whatever caused it. The work order is the alibi. Without one, the chart is testimony.

I hold both passports. Certified Ethical Hacker, on T-Mobile's bug-bounty Hall of Fame for a clickjacking disclosure, and architect of that QA/QC detection system. The hardest part of both jobs was identical: proving the signal was real to the people who owned the process. In responsible disclosure you cannot force anyone to look; on a control chart you cannot force an escalation. The physics is honest. The organisation decides what happens next.

An intruder can edit the log. He cannot edit the oven.

The gap is organisational, not technical

The chart never reaches the SOC for a reason that has nothing to do with bandwidth or protocols. It is the org chart. Security assumes quality owns anything that happens on the line; quality assumes IT owns anything with a cable. Both are correct, which is the most reliable way to build a gap. The artefacts follow: incident response plans that never mention product impact, quality response plans that never mention attackers.

A war story, the uncomfortable version. QRQC – quick response, quality control – is the discipline I credit with cutting defect cost by 70% at that plant. One night a dimensional parameter walked out of its limits at 02:50. The team triggered QRQC, contained suspect parts within 40 minutes, swapped a worn insert, re-ran first-off, recorded "tool wear" as root cause and closed the case inside 24 hours. Textbook speed. I was proud of it.

Now replay it assuming the cause was not the insert but a tampered offset. Containment resets the parameter before anyone images the HMI. The root cause gets authored by the response team rather than evidenced by the system. Quarantine, reset, closure – every habit that saves defect cost would have shredded the forensic trail. We would have QRQC'd an intrusion out of existence and filed it under tool wear. Quality closed the nonconformance; nobody ever asked whether the cause was mechanical or malicious.

Wiring the two detection systems together

No new platform required. A handful of connections and one honest conversation.

• Route SPC and process alarms into the incident classification tree alongside the SIEM feeds. An alarm that can only reach quality is half a detection system.
• Define a new trigger: unexplained special cause, no assignable process cause – no work order, no material change, no tool change – escalates to security review, not to closure.
• Score cyber tampering honestly in the PFMEA detection row using both layers. If detection rests on network monitoring alone, the score is worse than you think; wire the SPC layer in and it improves. Write down whichever truth applies.
• Run a joint drill. Inject a benign setpoint change on a non-critical loop and time both teams. My money says quality sees the excursion in hours and the SOC learns of it in weeks, if the chart ever reaches it. That delta is your real detection architecture.

The drill matters more each quarter, not less. Manufacturers are bolting AI agents onto process control faster than they are defining who may touch which parameter, and every legitimate new hand on a setpoint makes "unexplained" harder to adjudicate without a disciplined joint review.

The lesson from the water utilities was not that we need another prevention tool. Prevention was in place; detection was not. The plant that wins the next round is the one where the quality engineer and the SOC analyst sit in the same incident review, practising the same discipline from different chairs. A tampered parameter is a nonconformance. A nonconformance with no assignable cause might be an intrusion. Same discipline, different certification.