When a supervisor asks who changed a setpoint at three in the morning, the answer has to come from somewhere. In a SCADA system it comes from the audit log, and the artifact that presents it in a readable, filtered form is the audit report. This guide is about that concrete, queryable record of user actions - the who-did-what-when of the system - as opposed to the general concept of an audit trail. It covers what the log captures, how the report is used for security reviews and incident forensics, and how a cloud SCADA platform keeps the record centralized and searchable.
SCADA Audit Report & Audit Log in one line: A SCADA audit log is the system-maintained record of user actions - logins and logouts, setpoint and configuration changes, alarm acknowledgments, and control commands - each stamped with who did it, what they did, and when. A SCADA audit report is the queryable, filtered view of that log that operators pull for security reviews and incident investigations. Together they answer the who-did-what-when questions no other record can.
The audit log records human interaction with the system, which is a different thing from the process data the historian keeps. Where the historian remembers what the pressure was, the audit log remembers that a named user lowered its setpoint at a specific time. The events it captures are the ones tied to accountability: authentication events like logins, logouts, and failed login attempts; changes to setpoints, control modes, and configuration; alarm acknowledgments; issued control commands such as starting a pump or opening a valve; and administrative actions like adding a user or changing a permission. Each entry carries the identity of the actor, the action taken, the object it acted on, and the time it happened.
The value of the log is that it makes the human layer of the system as observable as the process layer. A control system that records every reading but no user actions can tell you the state of the plant but not why it is in that state or who put it there. By logging actions against user identities, the audit log turns operator activity into evidence - a permanent, time-ordered account of every meaningful thing a person did through the interface. For this to be meaningful the log must be resistant to tampering, so that the record cannot be quietly edited by the same users it holds accountable; a log that its subjects can alter is not an audit log in any useful sense.
The raw audit log can hold an enormous volume of entries, so the practical artifact people work with is the audit report - a filtered, queryable presentation of the log answering a specific question. The queries follow the shape of the log's fields: show every action by this user, every change to this setpoint, every event in this time window, every failed login across the system last week. A security review runs the report by user and by sensitive action to confirm access was appropriate and nothing unexpected occurred. An investigation runs it around the time of an incident to reconstruct exactly what was done and by whom. The report is how the log becomes usable rather than just voluminous.
This is where the topic parts ways with the general idea of an audit trail. An audit trail is the concept - the principle that actions should be recorded and traceable. The audit report is the tool an operator actually pulls: a concrete, filterable artifact that produces the who-did-what-when answer for a defined scope. In a security review it is the evidence that access controls are working; in forensics after a bad control action or a suspected intrusion, it is the timeline that shows the sequence of events and pins each to an identity. A change-management process leans on the same report to confirm that only authorized changes were made, and by whom. The trail is the promise; the report is how you cash it in.
In a distributed operation with many sites and operators, the value of an audit report depends on the log being complete and unified. If each station keeps its own local record, reconstructing a cross-site incident means stitching together partial logs of uncertain integrity, and a determined actor might reach a local log to alter it. A cloud SCADA platform such as Merobix addresses this by keeping the audit record centrally: every user action across every site and every session lands in one time-consistent, server-side log, so a single audit report can span the whole operation and a single query can trace a user's activity everywhere they touched the system.
Central, server-side storage also strengthens the integrity the log depends on. Because the record lives on the platform rather than on the operator's workstation, it is out of easy reach of the users it holds accountable, which is exactly the separation an audit record needs to be trustworthy. Tie that to authenticated user accounts and every action carries a reliable identity, so the report can attribute each change, acknowledgment, and command to a specific person rather than an anonymous session. For a security review that means a genuinely complete picture of access; for an incident investigation it means a single, tamper-resistant timeline to work from. The audit log remains the underlying record and the report remains the tool that reads it - but centralizing both in the cloud is what makes them dependable across a real, multi-site operation.
An audit trail is the concept - the principle that user actions should be recorded and traceable to who did them. An audit report is the concrete, queryable artifact an operator actually pulls: a filtered view of the underlying audit log that answers a specific who-did-what-when question for a defined user, object, or time window. The trail is the recorded record; the report is the tool that makes it usable.
It records the human interactions tied to accountability: logins, logouts, and failed login attempts; setpoint, mode, and configuration changes; alarm acknowledgments; control commands like starting a pump or opening a valve; and administrative actions like adding a user or changing permissions. Each entry captures who did it, what they did, the object acted on, and when - the human layer that process data alone cannot explain.
Because its whole purpose is to be trustworthy evidence, and a log that the users it holds accountable can quietly edit is worthless. Central, server-side storage keeps the record out of easy reach of individual workstations and unifies actions across sites, so a single report can trace a user's activity everywhere and an investigation works from one integrity-protected timeline rather than stitched-together local logs of uncertain reliability.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.