Audit Trail

The strict regulatory requirements present in many industries (for example, in the Pharmaceutical and food production sectors), necessitate that a full record of any events that involve the creation, modification or deletion of records relating to the manufacturing (or any other closely regulated process) is recorded, maintained and retrievable. This includes any changes made to critical systems within the organization, particularly specific details about the change, the operator or person making the change and any other important details regarding the change.

Providing a full record of every change made to a system that is later able to be recalled in detail, to a standard that meets the scrutiny of industry regulatory bodies, is a challenge for all organizations within these industries. Manually recording and recalling all these changes is a complex, time consuming and error prone activity that requires substantial resources and considerable oversight.

The array of Audit Trail features available in system:inmation offer an automated solution to change management and configuration change tracking, providing a fully digital audit trail. Put briefly, an audit trail is:

  • a secure time stamped record that allows for the reconstruction of events related to the creation, modification or deletion of a record and serve as evidence of actions taken by an individual or computer system or interface.

Or even more briefly:

  • a recorded chronology of the "who, what, when and why?" changes to a record.

Audit Trail is able to provide a full record of all object configuration changes that can be retrieved on demand.

To learn how to enable the Audit Trail features in system:inmation, please visit the DataStudio documentation.

Types of Changes relevant to Audit Trail

The types of changes that are important to be recorded for audit can vary from system to system and depends on the industrial sector and the regulations being followed. The Audit Trail features in system:inmation support the following changes:

  • Configuration changes on a object

  • External writes to the system

  • Connection changes for components

  • Component launch

  • Component update

Control of tracking configuration changes

The Audit Trail configuration tracking can be activated for individual objects in the system by going to the Audit Trail property compound and selecting from the available options.

The options available depend on the type of object that is selected and its function. For example, component objects (Core, Connector etc.) will have options to record component launching and connection events. These will not be present in DataHolder Audit Trail options as they have no component function. However, all objects will offer the option to record all configuration changes and any changes made by external systems.

Profile Audit Trail Roles

Users in the system must be assigned special Audit Trail roles to be able to make any changes to the Audit Trail settings. These roles are assigned in the parent Profile object properties. The different roles available are:

  • Administrator: can enable and disable the Audit Trail across the system and update the Audit Trail strategy.

  • System Wide Reviewer: can view and retrieve all Audit Trail entries.

  • Limited Reviewer: can view and retrieve Audit Trail entries for objects they have Read access to.

Comment upon change

Another important feature is the ability to activate the comment option that requires any configuration change to be accompanied by a comment from the person making the change. When an audit is being conducted it is often necessary to indicate the reason why a particular change was made. In system:inmation, these explanation comments are recorded alongside the other details

In large systems with thousands of objects it can be difficult to selectively turn the tracking on and off for configuration changes on particular objects. In system:inmation, the audit trail feature can be turned on in the settings of node objects, their children will subsequently inherit the same audit trail properties. This allows the user to quickly activate the configuration change tracking for selected sections of the system namespace.

Storing Configuration Changes - Audit Trail Data Store

All Audit Trail data is stored in a separate MongoDB repository called the Audit Trail Data Store. The connection to this can be configured in the System object’s properties.

Audit Trail data is stored in JSON format in the MongoDB repository. In the case of object configuration changes, the data is stored as a JSON representation of the inmation.mass function needed to recreate each config version of the object.

When the Audit Trail records are visualized, the config versions of each change can be compared across all versions.

Audit Trail Visualization options

The Audit Trail records can be visualized in DataStudio in two ways:

Both visualization options present the changes in a tabular format displaying each change record on a different row. The exact details of individual change records can be expanded in a comparable difference dialog box, which will show the exact nature of the differences between config versions for an object.

Please visit the DataStudio Documentation for more details.

Accessing Audit Trail through Lua and Web API

Audit Trail records can also be retrieved through the inmation APIs.

For information and examples of how to use the Lua API to access Audit Trail records, please visit the Lua Audit Trail documentation.

For information and examples of how to use the Web API to access Audit Trail records, please visit the Web API Audit Trail documentation.