An automated logger can capture a temperature reading every fifteen minutes, all year, without anyone climbing into a plant room. That is genuinely useful. It is also the easy part. The hard part — the part an auditor, a new estates manager, or an incident investigator actually cares about — is whether all that data adds up to a story of control, or just a very large pile of numbers.

IoT logging changes what evidence you hold. It does not, on its own, change whether your water system is under control, or whether you can prove it was. Get that distinction right and the technology pays back. Miss it, and you end up with a tidy dashboard sitting on top of the same blind spots you had with a clipboard.

What automation actually changes

Strip away the sales deck and a connected setup does three things: it reads a value at a fixed point, timestamps it, and sends it somewhere you can see it. For Legionella control that usually means temperature at sentinel outlets, calorifier flow and return, and cold storage — sometimes flow or usage at outlets that are supposed to be flushed. The reading is captured continuously instead of monthly, and nobody has to be standing there with a probe.

What it does not do is decide whether the reading matters, flush a dead leg, descale a shower head, or sign off that a remedial action was finished. Those are still human jobs. So automated temperature monitoring is excellent at the measurable, fixed-point parts of a scheme and silent about everything else — which is most of a real control regime.

The records duty does not move because the data collection got easier. L8 still expects you to keep records of the precautions, the monitoring and the management arrangements, and to have competent people running the scheme [1]. A good digital logbook should feed those records. It cannot replace the thinking behind them.

Where the sensors earn their keep — and where they don’t

Three situations show the split clearly.

Continuous monitoring is where the technology is strongest. A sensor on calorifier flow and return, or on a far sentinel tap, will catch a slow drift that a once-a-month manual check would miss between visits; HSG274 sets out what monitoring a hot and cold water system is expected to cover [2]. The condition for it to be worth anything is unglamorous: alarm thresholds set from your written scheme, and a named person who acts when one fires. A reading nobody reads is not monitoring.

Low-use outlet flushing is where the gap shows. A flow sensor can tell you a guest room tap has not run in eleven days and raise a task — that is valuable. But the flush itself is manual, and the record only counts if it closes the loop: task raised, flush done, by whom, when, and confirmed. Plenty of systems log the prompt and never capture the action, which is worse than useless, because it looks complete.

Exception handling is where IoT either proves its worth or quietly fails. The whole point of continuous data is catching the out-of-range reading fast. The audit question is never “did a sensor go red” — it is “what happened next”. The audit trail has to show the escalation, the action taken, and the close-out, with the data point attached. A red spike followed by silence is a finding waiting to be written up.

The gap a dashboard hides

The failure mode that catches compliance managers out is not a sensor breaking. It is a dashboard that goes green because it only measures the part of the scheme that is easy to instrument. Temperatures look perfect; meanwhile the cleaning, the inspections, the descaling and the low-use flushing live on a separate clipboard nobody links back to the system. Control looks total. It is not.

An automated record is also only as trustworthy as its provenance. To stand up at audit or in an incident review, a reading needs to be tied to a named asset and monitoring point, carry a timestamp you can trust, and be impossible to edit silently after the fact. Calibration matters just as much — an uncalibrated sensor reporting, say, 53°C when the water at the tap is actually 47°C is generating confident, well-formatted, wrong evidence. (Those figures are illustrative; the real numbers come from your scheme.) Ask of any platform: if a sensor drops offline for a week, does that show up as an exception, or as a silent gap nobody notices until an auditor counts the days?

A checklist for audit-grade IoT records

Use this to pressure-test a system you are buying, or one you already run. The underlying test is simple — could someone who was not there reconstruct what happened?

Mapping and scope

  • Map every sensor to a named asset and the monitoring point in the risk assessment.
  • Write down what the automation does not cover — flushing, cleaning, inspection — and where those records live.

Thresholds and response

  • Set alarm thresholds from the written scheme, not the factory defaults.
  • Name who receives each alert and the time they have to act on it.
  • Confirm every alert records the action taken and the close-out, not just the alert itself.

Integrity and retention

  • Check each reading carries who, what and when, and cannot be edited without leaving a trace.
  • Keep sensor calibration records alongside the data they produced.
  • Confirm offline sensors and missing readings appear as exceptions, not blank space.
  • Agree how long records are retained, and actually test an export before you need one.

If a line cannot be ticked, that is where your evidence trail breaks — regardless of how green the dashboard looks. The same logic applies whether you are designing the wider plan (see Creating a site-specific Legionella monitoring plan) or tidying the habits behind your day-to-day logs (Staying organised: tips for thorough Legionella logs).

Before you trust the green dashboard

Automating the logging does not transfer the duty. The business operating the building remains the duty holder, whatever the sensors or the software supplier promise [3]. A sensor reading is evidence for one point at one moment, not proof that the whole system is controlled — the same limit that applies to a single lab sample. And every threshold, alarm setpoint and monitoring frequency the platform uses has to come from your site-specific risk assessment and competent review; HSE is clear that testing and monitoring should follow the system and its risk assessment, not a vendor’s default profile [4]. The technology is a better notebook. It is not a substitute for the person who understands the scheme.

Common questions

Does automated logging satisfy the record-keeping duty on its own?

No. It can capture monitoring data cleanly and continuously, but the duty covers more than readings — the precautions, the manual tasks, the management arrangements and the decisions behind them all still need recording, and the responsibility stays with the duty holder [1][3].

Can remote sensors replace manual temperature checks entirely?

Sometimes for the routine reading at instrumented points, but only if your risk assessment says so. Many schemes still want periodic human checks: to confirm a fixed sensor agrees with a calibrated handheld, and to catch things a single sensor cannot see. Treat sensors as extending coverage, not removing the person from the loop [2].

What happens to the audit trail if a sensor fails?

A gap has to be visible. A trustworthy system flags a dropped or offline sensor as an exception and prompts a fallback check, so the missing period is explained rather than blank. An unexplained hole in the data is exactly what an investigator will ask about first.

Sources

[1] HSE, “Legionnaires’ disease. The control of legionella bacteria in water systems - Approved Code of Practice and guidance (L8)”. https://www.hse.gov.uk/pubns/books/l8.htm [2] HSE, “Legionnaires’ disease: Technical guidance (HSG274)”. https://www.hse.gov.uk/pubns/books/hsg274.htm [3] HSE, “Legionnaires’ disease - what you must do”. https://www.hse.gov.uk/legionnaires/what-you-must-do/index.htm [4] HSE, “Testing and monitoring your water system for legionella”. https://www.hse.gov.uk/legionnaires/testing-monitoring-water-system.htm