Audit Trail Requirements for Clinic Software (2026 Checklist)

Audit Trail Requirements for Clinic Software: Compliance Checklist (2026)

An audit trail in clinic software is not a reporting feature — it is a risk control system. The difference is significant. A reporting feature tells you what happened in aggregate (this week's invoices, this month's appointments). An audit trail tells you who did what, to which record, when, and from what state it changed — with a level of evidence integrity that can withstand regulatory review, internal investigation, and legal discovery.

For a clinic, audit trails serve three simultaneous purposes: GDPR accountability (Article 5(2) requires demonstrating compliance), operational integrity (detecting and investigating billing errors, access abuse, and data modifications), and clinical governance (confirming that documentation standards are being followed). A system without adequate audit trails fails on all three dimensions.

This guide covers the minimum audit trail requirements for clinic software — what events must be logged, how logs must be structured, what makes a log immutable, and how long logs must be retained.

Why Clinic Audit Trails Must Be Stronger Than General Business Audit Trails

Standard business software often logs the most recent state of a record: "this invoice was last modified on this date." This is inadequate for a clinical environment for two reasons.

First, clinical records have a legal completeness requirement. A clinical note that was modified after the fact — to add information that changes the clinical picture — must be distinguishable from a note that was completed correctly at the time of the appointment. The modification must be logged with: who made it, when, what the original value was, what the new value is, and why the change was made. A system that overwrites the original without preserving the previous state has destroyed legally relevant clinical evidence.

Second, the data subjects (patients) have GDPR access rights. Under Article 15 and Article 20, a patient can request all personal data held about them — including a log of who has accessed their records. If the system cannot produce this log, the clinic is unable to comply with a legitimate DSAR (Data Subject Access Request). Under GDPR Article 83, the fine for failure to maintain adequate accountability records can reach EUR 10 million or 2% of global annual turnover — whichever is higher.

Non-Negotiable Audit Log Controls

Immutability

Audit log records must be immutable — they cannot be edited, deleted, or overwritten by any user, including system administrators. This is the foundational control that makes an audit trail trustworthy. An audit log that a senior administrator can edit is not evidence; it is a document with a claimed history.

Immutability is typically implemented at the database level:

• Audit log records are appended only — the log table has no UPDATE or DELETE permissions, only INSERT
• Audit log access is restricted to read-only for all application users
• Any attempt to modify or delete an audit log record generates an alert

Test immutability before selecting a platform: ask the vendor whether administrators can delete audit log entries. If the answer is yes, the log is not a genuine audit trail.

User attribution

Every logged event must identify the user who performed the action. The identity should be:

• The individual user's account (not a shared role account, not "system")
• The role the user held at the time of the action (a user whose role has since been changed should still show the role they had when they took the action)
• Where applicable: the IP address or device from which the action was taken (for access events)

Automated system actions (scheduled tasks, batch operations, notification sends) should be attributed to a named system actor — "Tregovia Automation" or "Scheduled Task: vaccination-reminders" — not to a blank user field. An event log with blank user attribution is not usable for investigation.

Timestamp with timezone

All event timestamps must:

• Include the full date and time (not just the date)
• Include the timezone (UTC is the standard; local timezone is acceptable if clearly labelled)
• Be generated by the server, not the client (client-generated timestamps can be manipulated)

For clinical events where the exact timing is clinically significant (medication administration time, emergency response time), the timestamp precision should be to the second — not just the minute.

Before/after value capture for edits

When a data record is modified, the audit log must capture:

• The field that was changed
• The value before the change
• The value after the change
• The reason for the change (reason code or free-text, depending on the event type)

"Invoice modified" is an inadequate audit entry. "Invoice #2026-4821 line item 'Consultation fee' changed from EUR 85.00 to EUR 65.00 by [user] at [timestamp]. Reason: 'Agreed discount for returning client'" is a complete audit entry.

Exportable evidence

The audit log must be exportable in a format that can be shared with a regulator, a legal team, or an auditor. The export should be:

• Complete for the requested date range (no truncation)
• In a readable format (CSV at minimum; PDF for formatted reports)
• Reproducible: the same query run twice should produce the same result

High-Risk Events That Must Be Logged

Not all events carry the same risk. The following events are mandatory for clinical software audit logging:

Clinical record events

• Clinical note created (with author and timestamp)
• Clinical note edited (before/after values, author, reason)
• Clinical note accessed (for sensitive patient data — read events, not just write events)
• Clinical document attached or removed
• Clinical record accessed and exported (for DSAR)

Financial events

• Invoice created (line items, total, author)
• Invoice edited (before/after values, author, reason)
• Invoice deleted or voided (reason required)
• Payment recorded (amount, method, author)
• Refund approved (amount, approver, reason)
• Discount applied (type, amount, approver)
• Credit note issued (original invoice reference, amount)

Access and permission events

• User login (success and failure)
• Failed login attempts (for brute-force detection)
• User role change (who changed it, from what role, to what role)
• User account created or deactivated
• Access to restricted record types (clinical notes, controlled drug records)
• Data export events (who exported, what data, to where)

Configuration events

• Tax rate changes (before/after values, author)
• Service catalogue changes (new services, price changes, retired services)
• Permission configuration changes
• System integration configuration changes

What Clinics Often Miss

Logging only successful actions, not denied attempts. A staff member who repeatedly attempts to access a restricted record — and is denied — is a security signal. The denied attempts must be logged as clearly as the successful access events. If only successes are logged, attempted privilege escalation is invisible.

Missing actor context on automated jobs. When the system sends automated vaccination reminders or generates scheduled reports, these actions should be attributed to a named system actor, not left with a blank or generic "system" label. An audit trail that cannot distinguish between a human action and a system action is incomplete.

No documented retention policy. The log must be retained for a defined period — not indefinitely (storage cost and privacy minimisation principles) and not deleted prematurely (legal retention requirements). The retention schedule should be documented explicitly: clinical access logs retained for the duration of the clinical record retention period; financial event logs retained for the statutory financial records period (typically 7 years in most EU jurisdictions); security event logs retained for 12 to 24 months.

Implementation Checklist

Before go-live with any clinic software, verify:

• Audit log is immutable (administrators cannot delete or edit log entries)
• All events attributed to a named user or system actor
• Timestamps are server-generated and timezone-included
• Before/after values captured for all edits to clinical and financial records
• Read events logged for sensitive data access (clinical notes, exports)
• Denied access attempts logged
• Automated actions attributed to named system actors
• Log export available in CSV and/or PDF format
• Retention schedule documented and configured
• Regular audit log review scheduled (operational owners weekly; compliance monthly)

Setting Up in Tregovia

Tregovia's audit trail covers all clinical, financial, and access events across all modules:

Immutable log: Audit events are append-only at the database level. No user — including platform administrators — can delete or modify an audit event.

User attribution: Every event records the user ID, display name, role at time of action, and session identifier. System actions attributed to named system actors.

Timestamps: UTC timestamps at second precision, server-generated.

Edit capture: Before/after values recorded for all edits to clinical notes, invoices, payments, refunds, and permissions. Reason code field available for edits to financial records.

Read logging: Access to clinical records, controlled drug records, and data export events logged as read events.

High-risk event coverage: Full coverage of the mandatory event list above (clinical, financial, access, configuration events).

Export: Full log export by date range in CSV format. Filtered export by user, event type, or record.

Retention: Configurable retention per event category. Default: clinical events retained for 10 years; financial events for 7 years; security events for 24 months.

Privacy controls: Configure access roles, consent records, exports, deletion requests, and retention rules before publishing this workflow.

Pricing: Audit trail included in all Tregovia plans — base plan EUR 47/month flat rate. 14-day free trial.

FAQ

Should read actions be logged in clinic software?

Yes, for sensitive data — particularly clinical records, controlled drug records, and bulk data exports. A write event (creating or editing a record) changes the data and is clearly significant. A read event does not change the data — but it does evidence who accessed what. For clinical records, this is a GDPR accountability requirement: if a patient asks who has accessed their records (Article 15), the clinic must be able to answer from the audit log. For controlled drug records, many EU jurisdictions require access logging as part of the controlled substance framework. For bulk data exports, access logging detects potential data exfiltration — an employee who exports the entire patient database before leaving the practice is generating read events that should be visible.

Can audit logs ever be corrected?

Not directly. Corrections are appended as new events, with a reference to the original event being corrected. If an audit event was logged with an incorrect user attribution (a shared login was used, for example), the correction record notes the original event ID, explains why it is inaccurate, and records the correct attribution in a new event. The original (incorrect) event remains in the log — because removing it would destroy the immutability of the log. This append-only correction model is standard practice in compliant audit systems.

How long should clinic audit logs be retained?

By jurisdiction and event type — define the retention schedule explicitly in the practice's data protection policy. The general principle: retain as long as the underlying record is retained, plus the applicable statute of limitations for disputes about that record type. For clinical access logs: as long as the clinical record (typically 8 to 10 years post-last visit). For financial event logs: as long as the financial records (typically 7 years in most EU jurisdictions). For security event logs (login attempts, permission changes): 24 months is a common minimum; longer if there is a known security incident under investigation. Never delete audit logs before the applicable retention period without explicit sign-off from the compliance owner.

Who should review audit trails and how often?

Operational owners (billing manager, clinical lead, practice manager) should review anomalies weekly — specifically: denied access attempts above a threshold, after-hours access to sensitive records, high-volume data exports, and invoice edit rates above the baseline. The compliance owner (typically the practice manager or principal) should review the full audit log monthly for patterns: are specific staff members accessing records outside their normal workflow? Are there repeated denied access attempts indicating someone is testing permission boundaries? Is the log complete (no gaps in the event stream)? Quarterly, the compliance owner should confirm that the retention schedule is being applied and that no log records have been inappropriately deleted.

What is the difference between an audit trail and a system log?

An audit trail records who did what to which business record, with enough context to support investigation and accountability. A system log records technical events: server errors, process starts and stops, API calls, performance metrics. Both are useful, but they serve different purposes. A system log that shows "invoice service called at 14:32:07" is not an audit trail. An audit trail that shows "Invoice #2026-4821 line item changed from EUR 85.00 to EUR 65.00 by Reception User J. Smith at 14:32:07, reason: agreed discount" is. Clinical software must have both: system logs for technical operations and infrastructure, and audit trails for business record events.