audit logging

Audit logging is the systematic recording of events and activities in a system so that actions affecting security, data integrity, or compliance can be reconstructed and reviewed later. In industrial and manufacturing environments, audit logging typically captures who did what, when, where, and, when possible, from which system or device.

What audit logging includes

In regulated operations and OT/IT systems, audit logging commonly refers to recording events such as:

• User authentication, logon, and logoff attempts
• Changes to configurations, recipes, and control logic
• Modifications to electronic records, quality data, and master data
• Creation, approval, or deletion of documents and workflows
• Privilege or role changes, account provisioning, and deprovisioning
• Security-relevant events such as access denials, failed logins, or policy violations

Each audit log entry typically contains a timestamp, actor (user ID, service account, or device), action performed, target object (file, record, recipe, configuration item), source (workstation, IP, component), and result (success or failure).

How audit logging is used operationally

Audit logs are used to support:

• Traceability: Showing who changed parameters, records, or configurations in MES, SCADA, historians, or ERP systems.
• Incident investigation: Reconstructing events after cybersecurity incidents, data integrity concerns, or process deviations.
• Access oversight: Reviewing privileged access usage and detecting unusual patterns.
• Compliance evidence: Providing documented history of changes for audits and inspections, especially in regulated industries.

In practice, audit logging may be implemented natively within applications (for example, a MES audit trail), at the operating system level, or via centralized logging services and security information and event management (SIEM) tools that collect logs from multiple OT and IT components.

Relationship to controls and standards

Security and control catalogs, such as NIST SP 800-53 or similar frameworks, commonly reference audit logging as a technical safeguard. Organizations may use these catalogs as a vocabulary to describe their audit logging expectations, such as which events must be logged, how long logs are retained, and how they are reviewed. Using these frameworks as references does not in itself imply compliance; they provide structure for defining and mapping local logging practices.

What audit logging is not

• It is not the same as process data logging (such as continuous sensor data in a historian) unless that data specifically serves as an auditable record of user or system actions.
• It is not a guarantee of security or compliance; it is one element of a broader control environment.
• It is not only log file storage; it also involves consistent event selection, formatting, retention, and access controls.

Common confusion

• Audit logs vs. application logs: Application logs may include general operational messages and diagnostics. Audit logs focus on events relevant to accountability, data integrity, and compliance, and are often subject to stricter protection and retention.
• Audit logging vs. electronic signatures: An audit log records actions; an electronic signature asserts a person's review or approval of a specific record or action. The two are related but not interchangeable.
• Audit trail vs. audit logging: "Audit trail" often refers to the complete, reviewable history for a record or process. "Audit logging" is the underlying activity of capturing the events that make such trails possible.