Legionella compliance is a records discipline before it is anything else: risk assessments that stand up to audit, sampling logs that prove the monitoring regime was followed, corrective actions traceable from finding to resolution, and role separation so the right people see and sign the right things.
Off-the-shelf compliance platforms serve that discipline generically. Custom software earns its place when your obligations, your facilities, or your workflow don't fit the generic mold.
I've built in exactly this niche. Legionella 360 is a multi-tenant compliance SaaS I designed and built for the Italian market, where hotels and hospitals manage Legionella contamination risk under the ISTISAN 22/33 guidelines — auditable risk assessments, biological sampling records, and role-separated access for five distinct user types, from facility managers to laboratory staff. This article maps what custom Legionella monitoring software involves, when it beats the off-the-shelf options, and how the IoT sensor layer extends it from record-keeping to live monitoring.
What does Legionella compliance software actually have to do?
Four jobs — and auditability is the spine of all of them:
- 1.Risk assessment management — Modeling your facilities — buildings, water systems, sampling points — and maintaining the structured assessments a regulation like ISTISAN 22/33 expects, versioned so an auditor can see what was assessed, when, and by whom.
- 2.Sampling and results — Scheduling the monitoring regime, recording biological sampling with chain to the analyzing laboratory, and holding results against thresholds so exceedances surface instead of sitting in a spreadsheet.
- 3.Corrective action tracking — When a result or inspection demands intervention, the finding, the action, the responsible person, and the closure evidence form one traceable thread.
- 4.Reporting — The document an inspector asks for, generated from live data rather than reconstructed in a panic the week before.
The multi-tenant, multi-role dimension is what separates real compliance platforms from digitized spreadsheets. A hotel group's facility managers, external consultants, and laboratory partners are different roles with different rights on the same underlying records — in Legionella 360's design, five user types with separated permissions. That separation is itself a compliance feature: who may record a result, who may close an action, and who may merely read are questions a regulation implies and an audit will ask.
When does custom beat the off-the-shelf compliance platforms?
The dedicated Legionella SaaS vendors are competent at the common case. If your operation is the common case — standard facilities, one jurisdiction, workflows that match the vendor's template — subscribe and move on; custom software would buy you nothing but invoices. Custom wins on four triggers:
- Jurisdictional fit — Compliance software encodes a regulation, and a platform built for one country's guidance meets another's — ISTISAN 22/33's specific structures, in my case — only approximately. The delta lands on your staff as manual work.
- Workflow fit — Portfolios with mixed facility types, external consultant networks, or laboratory integrations that don't match the template.
- Product plays — If you're a water-safety consultancy or facilities group, a platform under your brand serving your clients is an asset, not a subscription — the multi-tenant shape Legionella 360 was designed around.
- Integration — When compliance data must flow into your existing facility-management or quality systems rather than living in another silo.
Where do IoT sensors fit into Legionella monitoring?
Legionella control is substantially temperature control — keeping hot water hot, cold water cold, and stagnation low. That makes it a natural fit for continuous sensing: temperature probes at sentinel points, publishing readings over MQTT into the same platform that holds the compliance records.
The value isn't replacing biological sampling, which regulation and biology still require. It's coverage between samples. A monthly manual temperature round tells you about one moment at each point; continuous telemetry turns the intervals between formal checks into data — flagging the calorifier that drifted low on Tuesday night, the dead leg that never reaches temperature, the anomaly worth investigating before the next scheduled sample finds it.
This is where my two practices meet, and I want to be precise about which is which. The compliance-records platform is shipped, cited work — Legionella 360. The sensor layer is my core IoT engineering applied to this domain: the same MQTT ingestion, device-time discipline, validation, and alerting architecture that runs my production telemetry platform, AetherMesh, across 1,000+ assets — documented with code in the technical guides linked below.
Bringing them together in one build — sensors feeding a compliance system that already models your facilities and sampling points — is precisely the kind of engagement this practice is shaped for. The records half and the telemetry half are usually two vendors, and the seam between them is usually where such projects fail.
What does auditability demand of the data model?
More than timestamps on rows. A compliance platform's defining property is that its history cannot quietly change: assessments are versioned rather than overwritten, so the state an auditor sees for any past date is the state that was true then. Results and corrective actions carry who-did-what-when as first-class data, not as an afterthought log. And corrections — because humans mis-enter data — happen as visible amendments with reasons, never as silent edits.
That append-only discipline is a design decision made at the first schema. It's cheap there and expensive everywhere later — a recurring theme across my platform work: the properties that matter most are the ones you can't retrofit.
Retention and export round it out. Compliance data outlives software: the regulation implies how long records must survive, and an audit implies they must be producible in a form an inspector accepts. In Legionella 360's design, the reporting surface sits directly on the versioned records for exactly this reason — the document handed to an authority is a view of the audit trail, not a parallel artifact that can drift from it.
How do laboratories and consultants fit the workflow?
Legionella compliance is inherently multi-party: the facility owns the risk, external consultants often run the assessments, and accredited laboratories analyze the biological samples — three organizations touching one record chain. Software that models only the facility forces the other two through email and attachments, which is where sampling chains lose integrity.
The design answer is to make the outside parties first-class roles with scoped access. The consultant works inside the assessments they're responsible for, the laboratory's results enter against the exact samples they analyzed, and the platform holds the chain from sampling point to result to any corrective action it triggers. This is precisely what role separation across user types exists for in Legionella 360's design — the roles mirror the real-world division of legal responsibility, so the access model documents who did what as a side effect of people simply doing their jobs.
What should a monitoring platform alert on?
Less than enthusiasm suggests, and more deliberately. Threshold breaches on temperature are the obvious layer — but raw-threshold alerting on noisy plumbing data produces the alarm fatigue that gets dashboards ignored. Production alerting evaluates validated readings with time-windows and hysteresis, so a boundary bounce is one event, not forty. The subtler alerts matter more:
- Absence — A sensor gone quiet is a monitoring-regime gap — which in a compliance context is itself reportable.
- Overdue actions — A sampling round not recorded by its scheduled date; a corrective action open past its deadline.
- Trend drift — A sentinel point whose weekly average is sliding toward the threshold it hasn't yet crossed.
Each of those turns the platform from a record of what happened into an instrument that changes what happens next — which is the entire argument for continuous monitoring in a compliance domain.
What does an engagement look like?
Scoped and sequenced like all my work, with the domain's own logic respected. The records platform and the sensor layer are separable: a compliance system can ship first and grow telemetry later, or an existing compliance process can gain a sensor pilot — a handful of probes at sentinel points, the MQTT path, and an alerting view — before any platform decision.
Either path is quoted fixed-bid within 48 hours of a brief. Multi-tenant and white-label shapes are natural here, since consultancies and facility-services firms are often the real buyers, and delivery lands on your infrastructure with the auditability that a compliance domain demands of its own tooling.
If your obligations sit under a different jurisdiction's guidance than the one I've built for, that's a scoping conversation, not a blocker. The structural jobs above are constant; the encoded regulation is the configurable part.
The one-line version
Compliance software proves what you did; sensors watch what's happening between the proofs. Building both on one platform — records discipline from shipped compliance work, telemetry discipline from production IoT — is the niche this page exists for.