Logging

What is logging?

Logging is the automatic recording of events in systems, devices and applications to log files, capturing for each event what happened, when, where, and who or what caused it. Logs are the memory of an environment: without them you cannot establish afterwards who changed a configuration, when an attacker got in or why a plant stopped. Logging is therefore the foundation for monitoring, troubleshooting, auditing and cybersecurity, in both IT and OT.

🧠 What does a log entry contain?

A useful log entry answers the questions who, what, when, where and with what result. The standard fields are:

• Timestamp - preferably in UTC and ISO 8601 notation with milliseconds, for example 2026-03-12T08:41:07.215Z
• Source - host name or device ID of the server, PLC, switch or application
• Event type and severity - for example a failed login, a changed configuration or an error message
• Actor - user name, service account or process
• Network details - source and destination IP address, port and protocol
• Outcome - success or failure, with a unique event ID for correlation

The more structured logs are, the more valuable they become. Fields written as key-value pairs or JSON are easy to search and correlate; free text calls for error-prone parsers.

📂 Which events should you log?

Not everything, but the right things. The following categories deliver the most value for security and operations:

IEC 62443-3-3 lists the same core in requirement SR 2.8: access control, request errors, operating system and control system events, backup and restore, configuration changes, potential reconnaissance activity and events concerning the audit log itself.

🏭 Where do logs come from in an OT environment?

In IT, almost every system logs by default. OT is different: many controllers and field devices have little memory and processing power, and an excessive logging load can interfere with control itself. Older PLCs often keep only a diagnostic buffer, without users or security events. The main sources are therefore:

• Engineering stations - where PLC programs are changed and downloaded; Windows logs and the project software show who did what
• HMIs and SCADA servers - operator actions, logins and alarms; the audit trail of the SCADA software is often the richest OT source
• Network equipment - switches, routers and industrial firewalls send their logs via syslog to a central collector
• Network sensors - passive monitoring reads traffic via a SPAN port or TAP and sees program downloads, stop commands and new connections, even for devices that cannot log themselves
• Historians - time series of process data that show during an investigation what physically happened
• Windows servers and domain controllers - for example event IDs 4624 and 4625 (successful and failed logon), 4688 (new process) and 1102 (audit log cleared)

Newer components developed according to IEC 62443-4-2 can generate and forward security events themselves. In existing plants, network-based logging is often the only realistic way to gain visibility of what happens to controllers.

🔧 What are log severity levels?

The syslog protocol (RFC 5424) defines eight severity levels. The lower the number, the more severe the message. Application frameworks often use a simplified scale that maps roughly as follows:

Note that severity describes the technical condition, not the security relevance. A successful login at Informational level may well be the most important line of the day for a security analyst.

🕰️ Why does time synchronisation matter so much?

Logs from different systems can only be correlated if their clocks agree. A drift of a few minutes makes an attack timeline unreadable and can undermine evidential value during an audit.

• NTP typically achieves an accuracy of around one millisecond on a local network and is sufficient for almost all logging.
• PTP (IEEE 1588) reaches sub-microsecond accuracy with hardware timestamping and is used where sequence-of-events recording, motion control or power automation require it.
• One direction only - international guidance advises that OT takes its time from IT and not the other way round, so both domains share one consistent timeline. Do protect the time source itself against tampering: whoever shifts the clock falsifies the timeline.
• UTC - log in UTC and convert to local time only when displaying; this avoids gaps or duplicates when clocks change for daylight saving time.

ISO 27001 (control 8.17) and IEC 62443-3-3 (SR 2.11) both require synchronisation with a reliable time source.

🛠 How do you set up central log management?

Local logs get overwritten, wiped by attackers or lost during a failure. Central log management therefore collects them in one place. A practical approach in five steps:

1. Write a logging policy - which assets, which events, how long to keep them and who reviews them. Start from the risk assessment and the asset inventory.
2. Prioritise sources - the joint guidance of August 2024 from ASD, CISA, NCSC-UK and the Dutch AIVD and MIVD, among others, lists for OT first: devices critical to safety and service delivery, internet-facing devices and devices reachable across network boundaries.
3. Collect per zone - place a log collector in the OT DMZ or in each zone and forward logs upwards in one direction, in line with network segmentation. Use syslog over TLS (RFC 5425, TCP port 6514) rather than unencrypted syslog over UDP port 514.
4. Analyse and alert - a SIEM correlates events and an OT SOC assesses the alerts. Detection rules such as PLC in program mode outside a change window, new engineering connection or cleared log files deliver value quickly in OT, provided they are tied to change management.
5. Test and maintain - periodically check that all sources still deliver; a source that goes silent is an event in itself that deserves an alert, in the spirit of IEC 62443-3-3 SR 2.10 (response to audit processing failures).

At the source, Windows Event Log, journald and syslog supply the data; well-known tools for central storage and analysis include Splunk, Microsoft Sentinel, Elastic, Graylog and Wazuh, complemented by OT network monitoring from vendors such as Claroty, Nozomi and Dragos.

🔐 How do you protect logs against tampering?

An attacker who is already inside will often try to cover their tracks. Logs only have evidential value if they remain intact and available:

• Forward immediately - logs leave the source system as soon as possible, so deleting them afterwards has no effect
• Read-only access - IEC 62443-3-3 SR 6.1 requires that authorised people and tools can access logs on a read-only basis; SR 3.9 requires protection against unauthorised access, modification and deletion
• Immutable storage - WORM storage, immutable backups or hash chains make changes visible or impossible
• Separation of duties - administrators of systems do not also administer the logging platform
• Sufficient capacity - full disks lead to overwritten logs; SR 2.9 calls for adequate audit storage capacity

⚖️ Which laws and regulations set logging requirements?

👤 What does the GDPR mean for logging?

Logging user activity is processing of personal data. Security and legal obligations are legitimate grounds, but the purpose must be defined and the retention period may be no longer than necessary. Do not quietly use logs to assess operator performance: in the Netherlands, a system capable of monitoring the behaviour or performance of employees requires the consent of the works council (Article 27(1)(l) of the Works Councils Act, WOR). Pseudonymising user names in reports and strict access to the logging platform help balance security and privacy, in line with privacy by design.

❓ Frequently asked questions

How long should you keep logs?

No single law prescribes one retention period for all security logs; the period follows from risk assessment and sector rules. International guidance points out that discovering an incident can take up to 18 months, so keeping security logs for less than a year is often too short. Interventions on machinery under the Machinery Regulation must remain traceable for five years, and GMP audit trails are kept as long as the records they relate to.

Do PLCs log security events themselves?

Most older PLCs only record diagnostic and fault messages, without users or program changes as security events. Newer controllers developed according to IEC 62443-4-2 can forward audit logs via syslog. For existing PLCs, passive network monitoring fills the gap by recognising program downloads and stop commands in the traffic.

What is the difference between logging and monitoring?

Logging records events and keeps them as evidence; monitoring analyses that data and raises alerts on deviations. Without logging, monitoring has no source, and without monitoring, logs stay unread until after an incident. ISO 27001 therefore treats them as separate controls 8.15 and 8.16.

Is syslog secure enough for security logs?

Classic syslog over UDP port 514 is unencrypted, unauthenticated and can silently lose messages. Syslog over TLS according to RFC 5425 on TCP port 6514 protects confidentiality and integrity in transit and uses more reliable TCP transport. In OT networks, a local collector per zone can receive legacy devices over UDP and forward their logs encrypted.

Do you need a SIEM for logging?

Logging is possible without a SIEM, but a central log server only stores and searches; a SIEM correlates events from multiple sources and generates alerts. Smaller organisations often start with central storage and a limited set of detection rules. In OT, a SIEM is most valuable in combination with network monitoring that understands OT protocols.

Can logging slow down control systems?

Logging must never endanger the availability or timing behaviour of a control system. That is why OT logging focuses on engineering stations, servers and network equipment, and listens passively on the network instead of actively polling controllers. New logging functions on controllers are first tested in a test environment before they go into production.

📌 In summary

Logging records what happens in IT and OT systems, when and by whom, making it indispensable for incident detection, forensic investigation and compliance.

In OT, logging needs extra attention: many controllers barely log, so engineering stations, HMIs, network equipment and passive network sensors fill the gap. Synchronised clocks, central tamper-resistant storage, a deliberate retention period and attention to privacy turn loose log lines into usable evidence for forensic investigation, incident response and compliance audits under NIS2, the Machinery Regulation and GMP.