Overview
The audit trail is a secure, computer-generated, time-stamped record of user and system actions, as required by 21 CFR 11.10(e). Recording is always active and starts at first startup; it does not depend on the Part 11 compliance mode setting.
Every record stores the UTC timestamp, the user name of the acting person, the origin of the action (GUI, API, MCP, or System), the source IP address, a category, the affected entity, the action, the value before and after the change, an optional reason, a link to the electronic signature when the action was signed, the node that produced the record, and the asset the action concerns. Password and secret fields are masked in the stored values.
What Is Recorded
Records are grouped into categories so they can be filtered on the Audit Trail page.
| Category | Recorded actions |
|---|---|
| Config | Configuration changes: create, update, and delete of configuration records, with the full before and after values of the changed row. |
| Operator | Operator actions: variable writes, alarm and event acknowledgements, loading a recipe to a target, transferring recipes, and removing an active alarm from the Active Alarms view with the Remove button or Remove All. Loading a recipe records one entry naming the recipe and the target, alongside the individual variable write records for each value written. The remove record stores the action RemoveActive with the alarm message as the entity and the alarm id and asset in the value. Screen Notes: adding, editing, removing and the automatic removal of a note, recorded with Entity Type Screen Note and the actions Create, Edit, Remove and Expire. |
| Security | Security events: logins, failed logins, logouts, password changes, denied access attempts such as a configuration change requested without the required rights or with invalid credentials, and electronic signings, including failed signing attempts. |
| Records | Records management events: exports (including recipe exports, audit trail exports, and every run of a report that prints the audit trail), rotation purges, audit trail clearing, and project imports. |
| System | System events written by the application itself, such as chain verification results and detected clock anomalies. |
No rows match the filter.
Asset
Every record stores the asset the action concerns, as the asset was at the moment of the action. Renaming or moving an asset later does not change existing records. Records that concern no equipment, such as logins, exports, and system records, have an empty asset, and so do records written by versions of the application before the asset was recorded.
| Record | Asset |
|---|---|
| Variable write, including select before operate commands | The asset of the variable. |
| Configuration change | The Asset of the changed row. A change that moves the row to another asset records the common parent of the old and the new asset. |
| Alarm acknowledgement, shelve, unshelve, and remove | The asset of the alarm. |
| Event acknowledgement | The asset of the event. |
| Loading a recipe to a target, Transfer Recipe | The common parent of the assets of the target variables. |
| Python script run by an Execute Script action or through its end point | The asset of the Python script. |
| Schedule changes made on a Scheduler | The asset of the schedule. |
| Asset rename or move in the Asset Manager | The new asset path. |
No rows match the filter.
The common parent is the deepest asset that contains every asset involved. Recipe target variables on WTP/Filtration and WTP/Dosing, for example, give WTP.
The asset is part of the record hash, so a changed or removed asset is detected by chain verification like any other field. A record without an asset is hashed exactly as before the asset was recorded, so the chain continues across the upgrade.
To list the records of one asset, filter the Asset column on the Audit Trail page, or set the Asset of an Audit list in the Report Designer, which keeps the asset and everything below it, for example for a batch report.
Audit Trail Page
The Audit Trail page is opened from the Audit Trail entry in the main menu. The page uses the shared configuration table with free-text search, per-column filtering, multi-column sorting, and column management, and loads records in pages as you scroll. See the Configuration Tables article for the table controls.
The toolbar contains a From and To date and time range with an Apply button, an Export button, a Verify Chain button, the search field, and the Columns manager. The initial view shows the last 7 days. For Administrators, a Delete button is added while Part 11 compliance mode is off; see Clearing the Audit Trail below.
Individual records cannot be edited or removed on the page or through the API, so the stored history stays complete.
Records that were authorized by an electronic signature show a Signed indicator in the Signature column. Select the indicator to expand a detail strip beneath the record that lists the signer, the meaning, the signing date and time, the signed action, the identification components used, and any comment. Select it again to collapse the strip. See the Electronic Signatures article. The Audit Trail page is also reachable through the Server section of the configuration side menu, can be selected as a navigation target for buttons and actions, and can be embedded inside a page in the same way as the other viewers.
Access is controlled by the Audit Trail View Right on the User Groups page. Users in a group with this right can open the page; users in the Administrators group always have access. The Asset column shows the asset of each record; its column filter lists the records whose asset contains the entered text. The Columns manager also exposes the technical columns that are hidden by default, including Source IP, Entity ID, Signature ID, Previous Hash, and Record Hash. The Signature ID column shows which electronic signature authorized a signed action; see the Electronic Signatures article.
Chain Verification
Every audit record is cryptographically chained to the previous one: the record hash covers the record content plus the hash of the previous record. Editing or removing any stored record therefore breaks the hashes of every record after it, which makes any modification of the stored history detectable.
The Verify Chain button recomputes the full chain and reports whether it is intact, how many records were checked, and the first record where a mismatch was found. The application also verifies the chain automatically at startup and once per day, and writes the result of every verification into the audit trail itself.
The exported CSV includes the hash columns, so a stored export can be checked against the chain later.
Export
The Export button downloads the records that match the current date range and search as a CSV file, including the hash columns, with the asset of each record as the last column. The export itself is recorded in the audit trail as a records management event, together with the exported row count and the active range and search.
A report can also print the audit trail with the Audit list component of the Report Designer, for example on a schedule. Every run of such a report is recorded the same way, as a records management event with the action Export and the entity type AuditTrail, holding the report name, the produced files, and for each list the period, the filter, and the number of records printed and found. The entry carries the name of the user who started the run, or System for a run started by a schedule, an alarm, or an event. See the Report Designer article.
Storage, Retention, and Rotation
Audit records and electronic signatures are stored in the historian database, next to the historic trend, alarm, and event records. A Data Forwarder with Forward Audit Trail and Forward Signatures enabled replicates both to an external archive database as they are written; see Forwarding to an External Database below.
The audit trail rotates on its own retention setting, Audit Retention Days, in the Historian section on the Parameters page, separate from the Rotation Days setting that governs the historic trend, alarm, and event data. Records older than Audit Retention Days are removed. A value of 0 disables audit trail rotation, so records are kept indefinitely. Rotation removes the oldest records only, so chain verification remains valid across rotations, and every rotation purge is itself recorded in the audit trail as a records management event with the removed row counts. Both settings apply only when Rotate Historian is enabled.
Keeping the two retention periods separate lets you prune the historic trend, alarm, and event data to control disk usage while retaining the audit trail for the full period mandated for the application, which can be multiple years. In a Part 11 deployment, set Audit Retention Days to at least the mandated record retention period, or to 0 to retain the audit trail indefinitely, and size the disk for the audit volume over that period. Alternatively, a Data Forwarder to an external archive database preserves records beyond the local rotation window; see Forwarding to an External Database below.
Rotation exists to bound disk usage so the historian cannot fill the volume and stop the system. It is not the record retention mechanism for a 21 CFR Part 11 deployment. The archive database that a Data Forwarder writes to holds the records for the mandated period.
Size Rotation Days and Audit Retention Days longer than the longest period the archive database can be unavailable. Rotation removes records on age alone and does not check whether a Data Forwarder has already sent them, so a record that ages out while the archive server is unreachable is not recoverable. If the archive server can be offline for two weeks for maintenance or a network fault, set the retention periods well above that.
Setting Audit Retention Days to 0 disables audit trail rotation and keeps the audit records indefinitely, which removes the constraint at the cost of unbounded growth on the local disk. Signature records are never removed by rotation.
Clearing the Audit Trail
While Part 11 compliance mode is off, Administrators see a Delete button in the toolbar of the Audit Trail page. Delete clears the entire audit trail after the Are you sure? confirmation, which supports deployments without regulatory retention requirements, for example after commissioning. The clear operation is itself recorded as the first record of the new chain.
While Part 11 compliance mode is enabled the button is removed and the operation is refused with the message Disabled in Part 11 compliance mode, like every other historic-record deletion.
API Access
The audit trail can be read through the configuration REST API using Basic authentication with an Administrators account. Both endpoints are read-only. The same read-only access is available to MCP clients through the get_audit_trail and verify_audit_trail tools, which mirror these endpoints and are restricted to Administrators. There is no create, update, or delete access to the audit trail through the REST API or MCP.
| Endpoint | Description |
|---|---|
| GET /API/Config/AuditTrail | Returns audit records, including the asset of each record. Supports offset, limit, search, dateFrom, and dateTo query parameters, where search also matches the asset, and returns the total count with the rows. |
| GET /API/Config/AuditTrail/Verify | Runs a full chain verification and returns whether the chain is valid, the number of records checked, and the first invalid record when a mismatch is found. |
No rows match the filter.
GET http://127.0.0.1/API/Config/AuditTrail?offset=0&limit=40&search=PLC1.Pump1_Speed&dateFrom=2026-07-01T00:00&dateTo=2026-07-15T00:00
GET http://127.0.0.1/API/Config/AuditTrail/VerifyForwarding to an External Database
A Data Forwarder can replicate audit records to an external database for long-term archiving or central collection. Enable the Forward Audit Trail option in the Audit Trail section of the Data Forwarder add and edit dialog, and use the Audit Query field to define a custom insert statement when the target table layout differs from the default. The asset of each record is available to the Audit Query as @Asset. The default query does not include it, so an existing archive table keeps receiving the same columns; add an Asset column to the archive table and @Asset to the Audit Query to archive it. See the Data Forwarders article for the forwarder configuration.
Redundancy
In a redundant setup the primary server owns the authoritative audit chain. Actions performed on the standby server are buffered locally and transferred to the primary, where they enter the chain. The node column on the Audit Trail page shows which server produced each record. The asset is buffered and transferred with the record.