Audit Trail Principles
This page describes the rules by which LiteLog sets up and operates an account, and how the audit trail secures these rules. It is written for quality managers, administrators and auditors. The rules are the same for every account. Which of them are active in your account is decided by the switches under Settings → Policies.
:::info Scope LiteLog documents according to the ALCOA+ principles and thereby supports GMP-compliant documentation. Validating the use of the system remains the task of your quality system. The mapping of the individual requirements of 21 CFR Part 11 and EU GMP Annex 11 is on Conformance Part 11 & Annex 11. :::
What every entry in the audit trail contains
| Item | How it is implemented |
|---|---|
| Who | Name, username and role of the person. All of it is recorded at write time. For completions and signatures also the personnel number. |
| When | With seconds, in local time and in UTC. Settings, access events and account changes carry the server time. For signatures, device time and the server's time of receipt stand side by side. For completions, the phone's clock applies if it is at most one hour behind the server time and at most five minutes ahead of it, otherwise the server time. |
| What | The area, the record and the event, for example created, changed, archived, cancelled. |
| Old value, new value | One row per changed field. |
| Reason | Reason code and text. The system demands them on save (principle 3). |
The fourteen principles
1. Every entry belongs to a person
There are only personal accounts, no shared accounts. Name, username, role and personnel number are recorded in every row. Sign-in is by password, QR code, NFC chip or Microsoft account. Which methods an account may use is set per account.
2. The time comes from the server
Settings, access events and account changes carry the server time, in local time and in UTC. For signatures, device time and the server's time of receipt stand side by side, so it stays visible when a device was offline. For completions, the phone's clock applies if it is at most one hour behind the server time and at most five minutes ahead of it. Otherwise the server time counts.
3. No reason on creation, a reason on every change
Creating, completing, submitting and reporting are the recording itself. They need no reason. Every later change, every cancellation, every archiving and every change to the configuration needs a reason. The reason consists of a code and a text. The system demands it on save and stores it with the old and the new value. This applies equally in the portal, in the app, via the API and via the AI integration.
You switch on the mandatory reason for settings changes under Settings → Policies (see Change Control). The reason codes are Correction, New requirement, Customer request, Bug fix, Periodic review and Other.
4. Nothing is deleted
Tasks are archived. Completions are cancelled. Reports and incidents are corrected or cancelled. The original remains visible with its signature, in the export and in the PDF as well.
5. Signing happens where the process demands it
The personal signature PIN is a second factor next to the sign-in. Completion, submission, incident, "not feasible" and cancellation are signed. Every signature carries a meaning, the time and a checksum over the record. After that the record is locked. Every later change is detected and displayed. The system shows the status per signature: signed, modified after signature, superseded or cancelled. You set the signature requirement per property, per template and per task (see Digital Signature).
6. The evidence is the signed whole
A form is recorded as a whole and fixed in time by the signature. LiteLog does not log when individual fields were filled in or boxes were ticked. The reason is simple: staff document at the end of a work step, not after every action. A timeline per field would feign a simultaneity that does not exist. What counts is the time of the signature, the arrival on the server and the content, which cannot be changed afterwards. Drafts before the signature are not evidence.
The time of completion is the time of the signature, provided the phone clock is plausible (principle 2). Otherwise the arrival on the server counts. Offline recording remains recognisable by the gap between signature and server arrival.
7. Four eyes for configuration
Changes to templates, roles, rhythms and property settings can be submitted as a request with a reason. A second administrator decides and signs. Nobody can approve their own request. The approval requirement can only be switched on if there are at least two approvers. Which areas are under approval is set per area (see Change Control).
8. The audit trail is immutable
The logs are locked in the database against change and deletion. The application itself cannot change an entry either. There is no function for it. If an entry cannot be written, the change is rejected.
9. Vendor access is recognisable
If LiteLog accesses the account for support, this appears in the activity log as "Platform admin" with its own name. Never under the customer's account. Configuration on behalf of the customer runs through an administrator account of the account and is visible as such in the activity log. Test data of the vendor is marked as "Test" and is archived before regular operation.
10. Templates are versioned
Every change to the content of a form template increases the version. A submitted form carries the version it was filled in with. Changes are logged per check item. Older versions remain traceable.
11. Evidence can be exported and cross-checked
Exports as CSV, Excel and PDF carry username, role and UTC time. The checksum of a signature is the same in the completion, in the signature log and in the PDF. The same log is available to auditors via the API. Which exports exist and how they fit together is described in the Evidence package.
12. Access is limited to what is needed and is logged
Every role has only the permissions it needs. Every sign-in, every sign-out, every failed attempt, every PIN check and every change of password or PIN is logged with time, device and method. Sessions expire. The access log is in the Activity log under the source Sessions and in the activity export.
13. Limits are named
What LiteLog does not record and what is still in progress is stated in the handbook. Not between the lines. The open conformance items are listed under Conformance Part 11 & Annex 11, the limits of change control under What the workflow does not cover.
14. Updates are planned and follow the hosting model
Every change to the system is a release with a version number and release notes. Updates do not change the audit trail. How often updates arrive depends on the hosting model (see Hosting models).
When a reason is mandatory
| Kind of action | Examples | Reason |
|---|---|---|
| Initial recording | Create task, create incident, submit form, complete task, create account | Not needed. The record is the recording. Who and when are recorded. |
| Deviation from the intended process | Task "not feasible" | Reason code is mandatory. For "Other" a text as well. |
| Subsequent change | Correct incident, correct report, change master data or account, reset status | Mandatory. With old and new value per field. |
| Cancellation, archiving, deletion | Cancel completion, cancel report, archive task, delete incident | Mandatory. The record remains visible. |
| Configuration | Templates, roles, rhythms, property settings, company settings | Mandatory. For changes under approval additionally the decision of a second administrator with signature. |
| Access management | Reset password or signature PIN | Not needed. Who, when and how are in the access log. |
:::tip Switching on the mandatory reason The requirement for configuration changes is a switch under Settings → Policies. While it is off, the reason for settings changes remains optional. The requirement for corrections, cancellations and "not feasible" always applies. :::
Who does what during configuration
| Role | Task |
|---|---|
| Customer administrators | Make the functional settings themselves. Every change carries their name, their role and their reason. |
| Second administrator | Decides on requests for areas under approval, for example templates and roles, and signs the decision. |
| LiteLog (vendor) | Changes the account only on the customer's instruction. Vendor interventions are marked and visible in the activity log. |
Before regular operation, test properties, test forms and test accounts are archived. The activity log is retained.