Logging and Audit Trails for OT Systems: What to Collect and Where to Keep It

When an incident happens in a control system, the first question is always "what changed, when, and by whom?" Most plants cannot answer it - not because they lack logs, but because the logs are scattered, unsynchronized, and unreadable.

What to Collect

• Authentication events: logins, failed logins, and account changes on HMIs, engineering workstations, SCADA servers, and managed devices.
• Configuration changes: controller program uploads and downloads, setting changes, firmware updates. Vendor tools log these inconsistently - capture what you can and centralize it.
• Operational events: alarm acknowledgments, mode changes (auto/manual), process setpoint changes.
• Network-level events: new devices appearing, unexpected connections, firewall rule hits.

Practical Rules

• Centralize: ship logs to a dedicated collector (syslog or Windows event forwarding) in the DMZ, never inside a device that is also the subject of the audit.
• Sync time: NTP everywhere. An audit trail with unsynchronized clocks is worse than none - it supports every wrong conclusion.
• Immutable retention: write-once storage or strict permissions so operators and engineers cannot edit history. Retention of 12 months is a common baseline; check your industry requirements.
• Keep it boring: alert on the few high-value events (failed admin logins, new device, config change) rather than building a dashboard that screams at everything.

When to Start

Logging does not need a platform project. Start by enabling and centralizing logs from the SCADA servers and network devices you already have, then extend to engineering tools. A partial trail you trust beats a complete trail nobody reads.