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 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 inmation, please visit the DataStudio documentation.

As the Audit Trail is meant to provide a complete record of all changes made to a system, Audit Trail data can not be purged.

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 inmation support the following changes:

  • Configuration changes on a object

  • External writes to the system

  • Datastore Purges

  • Connection changes for components

  • Component launch

  • Component update

  • File transfer

The system can be configured to track all these types of change or just selected types in the Audit Trail Strategy property of the Root object. They are listed in the Audit Trail Types flag group.

Control of tracking configuration changes

When activated, the audit trail will record configuration changes to objects that increase the Config Version of the object. This includes all property changes that are NOT dynamic properties, volatile properties or performance counters (visit the individual property pages in the system-model to get more information on the attributes).

Config Version changes may appear more than once in the Audit Trail records if configuration changes occur on objects whilst components are disconnected. For example, if configuration changes to an object are made simultaneously on a Master Core and Local Core during a disconnection, then upon reconnection both changes will appear in the record with the same config version.

The Audit Trail configuration tracking can be activated for the system in the Root object by clicking on Admin in the DataStudio menu bar and selecting "Edit Root Object…​" from the menu. This opens the Edit Root dialog where the Audit Trail settings can be configured. This is described in more detail in the DataStudio docs here.

Access to the Root object is only possible when logged into DataStudio with a User/Profile that has Administrator privileges

Datastore Purge

The system can be configured to add Audit Trail entries whenever the system automatically purges any data from any System or Custom data store. Data purging is configured in the Data Store objects themselves (or the System object for System Data stores) on either a time basis or when objects in the system are deleted (the Time Series and Event purge options are by default set to not purge).

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 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 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.

In the Security Config Display or in the MassConfig Display an update comment for the Audit Trail is only requested for the first time that Apply is clicked for a display. For all following changes made in the same open display, the same comment is entered automatically into the Audit Trail whenever Apply is clicked.

To enter a different comment, click on the 'speech bubble' icon in the display’s menu bar and enter the new comment before clicking Apply.

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 syslib.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.

The schema used by inmation to store Audit Trail documents is documented here.

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 Docs 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 page.

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