Running Flood Response Like a SOC: A Detection-and-Response Blueprint for Thailand’s Water Crises

In July 2026 the Thai government relaunched ThaiWater, the national water data platform run by the Hydro-Informatics Institute. The new version integrates data from 56 agencies under 13 ministries, puts rainfall radar, water levels, dam status and risk zones on one interactive map, and adds provincial water data sites for all 76 provinces.

That solves a problem Thailand has had for decades: flood data scattered across agencies that didn’t agree with each other. But it exposes the next problem, and it’s one security teams will recognise immediately.

Having the data is not the same as acting on it. A rising gauge upstream at 3 AM is only useful if something notices it, decides it matters for your site, opens a case, wakes the right person, and triggers the right playbook — without also waking them for every rain shower in the catchment.

That is exactly the problem a Security Operations Center (SOC) exists to solve. This post lays out what a "Flood SOC" looks like: the same detection-and-response patterns we build for cyber threats, pointed at water.

1. Floods and cyberattacks have the same operational shape

Strip away the domain and a SOC does five things: collect signals from many noisy sources, correlate them into something meaningful, score how bad it is, track the response as a case, and automate the first moves. Flood response needs all five.

SOC concept	Flood equivalent
Log sources (firewalls, endpoints, VPN)	Water-level sensors, rain gauges, radar, CCTV, citizen reports
SIEM ingestion and decoding	Normalising sensor feeds and public data into one event format
Correlation rules	"Upstream rising fast AND heavy rain forecast AND downstream gate offline"
Impossible-travel detection	Expected-travel prediction: when will the upstream surge reach us?
Risk scoring and severity	Site-specific flood risk score
Case management (DFIR-IRIS)	One flood event = one case, with timeline and owner
SOAR playbooks	Alert residents, trigger factory BCP, dispatch field teams
Alert fatigue and tuning	False alarms that teach people to ignore warnings
Silent-agent alerts	A sensor that stops reporting during a storm

The last two rows matter more than they look. Most flood-warning projects fail on them, not on sensors.

2. Why the private sector should care: the 2011 lesson

The 2011 floods caused THB 1.43 trillion (about USD 46.5 billion) in damage and losses. The detail most people forget: the manufacturing sector bore roughly 70% of that total, because six industrial estates in Ayutthaya and Pathum Thani went under water, and about 90% of all damage and losses fell on the private sector.

Central Plains floodwater moved slowly — often only a few kilometres a day. Many of those factories had days of warning in theory. What they lacked was a system that turned province-level information into a site-level decision: move the inventory now, shut down the line safely now, call the customer now.

A national platform can’t make that call for a specific factory. A Flood SOC can, because its rules are written for one perimeter, one set of assets and one set of playbooks.

3. The architecture

flowchart TD
    S1["River and canal level sensors"] --> N["Normalizer and enrichment"]
    S2["Rain gauges and radar"] --> N
    S3["ThaiWater and provincial feeds"] --> N
    S4["CCTV staff gauge reading"] --> N
    S5["LINE citizen reports"] --> N
    H["Sensor heartbeat monitor"] --> R
    N --> R["Correlation and risk scoring engine"]
    R -->|low score| L["Log only"]
    R -->|medium score| C["Open flood case"]
    R -->|high score| P["Open case and page duty officer"]
    C --> I["Case management in DFIR-IRIS"]
    P --> I
    I --> PB["Response playbooks via SOAR"]
    PB --> A1["Multilingual LINE and SMS alerts"]
    PB --> A2["Factory BCP actions"]
    PB --> A3["TAK map for field teams"]

Every box on this diagram already exists in a production SOC. What changes is the data going in and the playbooks coming out.

Signal layer. Low-cost radar or ultrasonic level sensors on canals, bridges and perimeter drains, reporting over LoRaWAN or NB-IoT. Public data from ThaiWater and provincial water centres where data-sharing terms allow. Existing CCTV that can read painted staff gauges. Citizen reports sent as a photo plus location to a LINE Official Account.

Correlation layer. A normalizer turns every feed into one event schema (station, reach, value, rate of change, timestamp). The correlation engine holds state — which is exactly the part a stateless rule engine can’t do alone. It’s the same reason our SOC integrator, not Wazuh, handles multi-event correlation and deduplication.

Response layer. DFIR-IRIS holds the case. Shuffle runs the playbooks. For field coordination, cases push to a TAK common operating picture, which we covered in how TAK transforms flood disaster response. The Flood SOC is the layer that decides when to wake TAK up.

4. Detection rules: from thresholds to correlation

SOC maturity usually moves through three levels. Flood detection follows the same path.

Level 1 — Thresholds. "If the water level at station X exceeds Y, alert." This is what most local warning systems do today. It is better than nothing, and it produces a lot of noise.

Level 2 — Risk scoring. Combine several weak signals into one explainable score. An illustrative model for a riverside factory:

Signal	Score
Upstream gauge rising faster than 20 cm per hour	+35
Nearest gauge within 50 cm of bank crest	+30
Very heavy rain (over 90 mm in 24 h) forecast for the catchment	+20
Downstream gate or pump station reported offline	+15
Two or more citizen reports within 1 km in 30 minutes	+15

Score of 70 or more → critical: open a case and page the duty officer. Between 40 and 69 → open a case, no page. Under 40 → log only.

These numbers are illustrative. Real weights and thresholds come from the site’s flood history, a hydrologist’s input and — most importantly — tuning against actual events.

Level 3 — Stateful correlation. This is where a SOC mindset pays off:

• Expected travel, not impossible travel. In a SOC, two logins too far apart in too little time are flagged as impossible travel. In a Flood SOC, a surge at an upstream station plus the historical travel time along the river gives a predicted arrival window downstream. The alert says "expected at your perimeter in 9–14 hours," not just "water is high somewhere."
• Deduplication. If the same river reach is already in an open case, new readings append to that case instead of creating another. Without this, one storm generates fifty cases and nobody reads any of them.
• Escalation on trend, not just level. A case that sits at "medium" but whose rate of rise is accelerating gets re-scored automatically.

A decision from the engine looks like any SOC decision:

{
  "decision": "create_case_and_page",
  "severity": "critical",
  "risk_score": 80,
  "reach": "upstream-bridge-to-estate-north-gate",
  "reason": "Upstream rise 28 cm/h, bank crest margin 40 cm, very heavy rain forecast",
  "predicted_arrival_hours": [9, 14],
  "playbook": "estate-bcp-level-2"
}

5. Silence is a signal

In a SOC, an agent that stops sending logs is itself an alert — it might be a network outage, a crashed service or an attacker covering their tracks. simpliSOC ships this today for log sources: if no events arrive within a configured window, it raises an alert.

For flood monitoring, this rule is even more important. Sensors fail during the events you need them for: power drops, a solar panel is covered by debris, the cellular tower goes down, or the water simply rises over the device. A system that shows the last known reading — "level normal, 2 hours ago" — during a storm is worse than no system at all.

A Flood SOC treats sensor silence as a scored signal: a station that goes quiet while its neighbours are rising gets escalated, not ignored.

6. Tuning: a flood warning that cries wolf is worse than none

Every SOC team learns this the hard way: a rule that fires on everything trains people to ignore alerts. Flood warnings have the same failure mode, with worse consequences — residents who received three false evacuation messages last year are the ones who don’t move this year.

That means the first weeks after deployment are tuning work, just as in a SOC deployment: track every false alarm, adjust weights and thresholds, add suppression for known-benign patterns (a tidal reach that rises every evening, a gauge that spikes during maintenance), and only then widen the alert audience.

7. Who this is for

• Industrial estates and factories, especially those in the 2011 flood footprint or along the Chao Phraya, Pa Sak and Bang Pakong basins, where site-level BCP triggers matter more than province-level warnings.
• Provincial and local administrations that now have ThaiWater data but no operations layer to turn it into cases, owners and actions.
• Ports, logistics hubs and utilities, where a flood event is also an operational-continuity and safety event.
• Organisations that already run a SOC, and want one operations centre, one case system and one on-call rota for cyber and physical incidents.

8. What exists today, what’s built per project, and what’s out of scope

Available today:

• simpliSOC: Wazuh detection, DFIR-IRIS case management, Shuffle automation, and our integrator for correlation, deduplication and severity mapping — deployed on-premise with Docker Compose.
• Silence alerting for log sources that stop reporting.
• TAK integration as a service offering, including bridging cases and alerts into a common operating picture.

Built per engagement (not packaged features):

• Sensor ingestion, decoders and the normalized flood event schema.
• Flood-specific correlation rules, risk scoring and expected-travel logic, tuned to the site.
• Connectors to ThaiWater or provincial data, subject to the data provider’s terms.
• LINE Official Account alert flows and multilingual message templates.
• Factory BCP playbooks and ERP hooks (for example, flagging at-risk stock).
• Sensor heartbeat rules, applying the silence-alert principle to field devices.

Out of scope:

• Official public warnings and evacuation orders. Those belong to the Department of Disaster Prevention and Mitigation (DDPM), the Thai Meteorological Department and local authorities. A Flood SOC supports decisions; it does not replace official warnings.
• Hydrological modelling as a certified authority. We integrate forecasts and historical travel times; we don’t publish national forecasts.
• Manufacturing sensor hardware. We integrate devices from hardware partners.

FAQ

Is "Flood SOC" a product you sell off the shelf?
No. It’s a reference architecture built from components that exist today (simpliSOC, our integrator, TAK integration) plus per-site work: sensors, rules, playbooks and tuning.

Does this replace ThaiWater or official warnings?
No. ThaiWater is one of the most important inputs. The Flood SOC adds the site-specific operations layer: rules, cases, owners and playbooks for your perimeter.

Can Wazuh really process water-level data?
Wazuh can decode structured JSON events, so sensor readings can flow through it. But hydrological correlation — rates of rise, travel times, per-reach state — belongs in the integrator layer, just as stateful cyber correlation does. The split is decided per project.

Where does the data live?
On-premise or in your private cloud, like any simpliSOC deployment. Sensor data and resident contact lists never have to leave your infrastructure.

What does a first project look like?
A thin slice: one site, a handful of sensors, one public data feed, one alert channel, and a tuning period against real rainfall — before adding more sites or audiences.

Talk to us

If you run a site that flooded in 2011, or one that nearly did last monsoon, send us your site map, the waterways that threaten it, and who needs to be woken up at 3 AM. We’ll come back with a thin-slice plan: which signals to collect, which rules to start with, and which playbook runs first.

Email hello@simplico.net, or read more about simpliSOC and our TAK integration service.

---

Sources:

• All-in-One Page: Government Revamps ThaiWater App — Thairath English, 17 July 2026
• 2011 Thailand Floods — Rapid Assessment for Resilient Recovery and Reconstruction Planning — PreventionWeb / World Bank
• How to Build Automated Decision Logic in a Modern SOC — Simplico
• How TAK Systems Transform Flood Disaster Response — Simplico