Integration Monitoring for Regulated Industries
An auditor does not want your dashboard. They want evidence that a control operated continuously, and that nobody could have quietly turned it off.
In a regulated environment, monitoring is a control, and a control has to produce evidence. The difference between a monitoring tool and an auditable one is not detection quality. It is whether you can demonstrate afterwards that the control was operating and that nobody could have silently disabled it.
This page describes what to require. Your specific obligations depend on your framework and your auditor, and this is not legal advice.
A log is not an audit trail
Most tools have logs. Auditors are asking for something narrower, and the gap between the two is where evaluations fail.
| Property | Ordinary log | Audit trail |
|---|---|---|
| Can be edited or deleted | Usually yes | No: append-only |
| Records who made a change | Rarely | Always, with identity |
| Records the before and after | No | Both values |
| Retention | Days to weeks | Outlives the audit period |
| Covers configuration changes | No | Yes, including deletions |
| Tamper evidence | None | Hash chain or equivalent |
The configuration row is the one auditors probe. It is not enough to show that alerts fired. You have to show that the alert thresholds were not widened, and that if somebody disabled a monitor, that act was itself recorded by something they could not also edit.
Deletion is the sharp edge. If an administrator can delete a monitor and the deletion leaves no trace, the control cannot be evidenced for the period in question, no matter how well it worked.
Retention has to outlive the thing being audited
Monitoring platforms default to short retention because storage costs money and most customers only look at the last week. Regulated customers need the opposite.
Establish two numbers during evaluation: how long alert history is kept, and how long configuration change history is kept. They are frequently different, and the second is usually shorter, which is the wrong way round for evidence purposes.
Compare both against your own obligation. A vendor retaining 90 days of history cannot evidence a control over a 12-month audit period, and discovering that during fieldwork leaves you no way to reconstruct the gap.
If the vendor's maximum retention is shorter than your audit cycle, plan to export continuously into your own system. Build that export before you need it, not during fieldwork.
Change control applies to monitors
If your framework requires change control on production systems, monitoring configuration is production configuration. A threshold change that reduces detection sensitivity is a change to a control.
Keeping monitor definitions in version control gives you this almost for free: the pull request is the change record, the reviewer is the approval, and the merge commit is the timestamp. It is considerably easier to evidence than a vendor's internal audit log.
The approach is described in integration monitoring for DevOps teams.
Data residency and what the vendor receives
Two questions decide most of this. Where is the data stored, and what does the vendor actually receive?
A heartbeat receiver that gets an empty POST holds no regulated data. A tool that stores webhook payloads for replay holds whatever those payloads contained. That architectural difference is often more persuasive in a review than any certification, because it narrows what a breach at the vendor could expose.
Design for minimal disclosure deliberately, and sanitise failure messages before they leave your boundary. An exception string forwarded verbatim will carry whatever the upstream system put in it.
Where SensaCat currently stands
Directly: an append-only audit trail is not yet implemented. Alert history is retained by plan tier, and configuration change history is not exposed as a separate auditable record today.
If tamper-evident audit logging is a hard requirement for your framework, that is a real gap and you should weigh it. We would rather tell you now than have it surface during fieldwork. Talk to us about timelines before committing.