In IT, a control that causes an outage is an incident. In OT, a control that causes an outage can be a safety event. That asymmetry is why most OT security programmes stall: the security team proposes a segmentation design drawn from an IT playbook, the plant engineer refuses it because it would interrupt a control loop, and the conversation ends with a spreadsheet of unimplemented recommendations and an estate nobody has inventoried.
The instinct is to apply the IT hardening standard harder. The instinct is wrong and it costs credibility on the plant floor. What works is discovery that is passive by default, segmentation designed with the plant engineer against control-loop and safety-interlock preservation, compensating controls for devices that cannot be patched safely, and an explicit record of the controls we recommend against and why. B12 does that work on a fixed scope in 6–10 weeks. Safety interlocks stay untouched.
Six streams,
ending in hardened continuity.
Discovery and risk assessment front-load weeks 1–3. Segmentation design, logging, and playbooks overlap through weeks 3–9. Validation and on-site handover close weeks 9–10.
Device discovery
Passive discovery preferred, active only where the plant engineer confirms it is safe. Complete device inventory with owner attribution.
Risk assessment
Per-device criticality, patch status, exposure, and compensating-control candidates for devices that cannot be patched safely.
Segmentation design
Designed with the plant engineer and tested against control-loop and safety-interlock preservation. Designs that would trip an interlock are recommended against, in writing.
Logging
Collection from OT devices where the protocol supports it, from segmentation boundaries where it does not.
Edge incident playbooks
Playbooks for the specific incident classes your estate actually faces, tested with the on-site team rather than written for them.
Validation & handover
Device coverage verified, segmentation change-window validated, on-site team trained. 30/60/90-day check-ins scheduled.
Ten weeks maximum.
Six minimum. Four phases.
Phase count is fixed. Duration flexes with estate size, site count, and the change windows the plant can actually offer. Milestones are signed gates — not aspirations.
Controls scored,
not on IT-first assumptions.
Every engagement runs a six-criteria scorecard in weeks 1–2. Each candidate platform scored 1–5 against your estate and its safety context. Signed by the CISO and the plant engineer before Phase 2 begins.
From unknown estate
to governed edge.
A typical pre-engagement state has a partially inventoried OT estate on a flat converged network, no logging on OT segments, and no edge incident playbooks. The engagement adds a security overlay without touching the process it protects.
Reference pattern. Some engagements keep a coarser segmentation model than an IT estate would accept, because the finer design would interrupt a control loop. That trade-off is documented, not quietly dropped.
A UAE utility,
edge hardened.
Representative pattern for a UAE utility of this scale — no OT inventory, flat segmentation, unpatchable legacy devices in service. Ranges reflect target outcomes NexITC underwrites in scope for this class of engagement. N=1 — illustrative composite, not a specific client.
Four artifacts,
each with signed acceptance.
Every deliverable has documented acceptance criteria signed at engagement kickoff. Nothing more, nothing less.
Device Inventory & Governance
Complete inventory with owner attribution, criticality, patch status, and the compensating controls applied where patching is unsafe.
Segmentation Model
Designed with the plant engineer and tested against process integrity — control loops preserved, safety interlocks untouched.
Logging Improvements
Collection from OT devices where the protocol supports it and from segmentation boundaries where it does not.
Edge Incident Playbooks
Playbooks for the specific incident classes your estate faces, tested with the on-site team, plus a documented list of segmentation designs we recommended {{i:against}} and why — the record that survives the audit conversation about "why isn't this segmented too."
Six outcome metrics,
measured pre and post.
Success is not "the estate is hardened." It is measured against six specific outcomes captured in a baseline report at engagement start and re-measured at post-handover steady state — including the one that must stay at zero.
Honest scoping.
B12 is a fit when specific conditions are met. It is not a fit when other conditions are. We say so before the scope conversation, not after the commercial commitment.
Sites, process areas, and rough device populations known. Full inventory is our work; the perimeter of that work is yours.
Segmentation is designed with them. Without that seat filled, designs get refused in week six.
Named windows for segmentation and logging changes. Windows decide the timeline more than estate size does.
Hardware-based or process-based — either works, but the choice must be made rather than assumed.
Where patching isn't possible, compensating controls cost money. That decision needs authority behind it.
That's B9 Zero-Trust Core Build™ — identity, privileged access, segmentation, logging on the IT estate.
That's B11 EdgeSense™ Build — telemetry into tickets and runbooks.
A different engagement entirely. We will say so in the clinic rather than scope around it.
Hard no. We do not sign to that trade-off, and we will recommend against controls that buy posture with a safety risk.
Fixed fee.
Milestone-based.
Total engagement fee agreed in the scope statement. Not time-and-materials. Not day rate. Every engagement is preceded by a scope conversation to ensure fit before commitment.
Five, most asked.
Q_01Won't segmentation break OT operations?
Some proposed segmentation absolutely would. We identify which specific segmentation designs would trip a safety interlock or interrupt a control loop, and we recommend against them explicitly — in writing, with the reason recorded.
Segmentation that survives industrial context is designed with the plant engineer, not for them.
Q_02Which OT vendors do you work with?
Q_03How do you handle unpatched legacy devices?
Q_04Do you cover industrial IoT specifically?
Q_05What comes next?
One name
on the engagement letter.
A named Practice Lead is accountable for delivery, commercial outcomes, and the client relationship throughout the engagement. Not a project manager who disappears after kickoff. Not a partner who nods at the SOW and vanishes.
Practice Lead — Cybersecurity
Present at every phase gate, every scope decision, every difficult conversation. Available for 30/60/90-day post-handover check-ins as part of the engagement.
Including scope amendments.
Signs off all 4 deliverables.
With executive sponsor.
Authorised to negotiate.
CEO within 24 hours.
30/60/90-day check-ins.
Prior. Peer. Next.
Security Posture Scorecard™
3-week security posture assessment adapted for OT context — surfaces the actual exposure vs the assumed exposure before hardening begins.
EdgeSense™ Build
Peer IoT build focused on operational integration (telemetry → tickets → runbooks) rather than security specifically. Often paired B11 + B12 for a full IoT ops + security rollout.
SecOpsCommand™
Managed security operations with OT-competent operators. Runs the segmentation change control, exception management, and edge incident response continuously.
Thirty minutes.
No slide deck.
A structured 30-minute scope conversation with the Practice Lead. You describe the estate, the sites, and the change windows the plant can offer. We describe whether B12 is the right engagement — and if not, what is.