Audit logging requirements: what your application's audit trail must record
An audit trail is only as good as what the application wrote when it happened. Agnotic Technologies builds audit logging into the product itself, to your requirements, so every sign-in, view, change and export can be traced to a person, a record and a time.
Last reviewed by the Agnotic Technologies engineering team
What must an application's audit trail record?
An application's audit trail must record who did what, to which record, when, from where and with what outcome, for sign-ins, record views, changes, deletions, exports, permission changes and e-signatures. Rules such as 45 CFR 164.312(b) and 21 CFR 11.10(e) set the scope. Agnotic Technologies builds this audit logging into the product itself.
Why do audit trails fail when someone needs them?
Teams usually find the gaps during an incident, an investigation or a customer's security review, when it is too late to log what already happened.
Debug logs used as the audit trail
Application logs written for developers rotate after days, change format with each release and miss the record that was touched.
Views not recorded
Changes are logged but reads are not, so nobody can say who opened a patient's chart or a customer's file.
Changes without the old value
The log says a field changed but not what it was before, which a Part 11 audit trail must not lose.
Logs the admins can edit
Audit rows sit in the same database tables the application and its administrators can update or delete.
Clocks that disagree
Servers in different zones write local times, so the order of events cannot be rebuilt across services.
No answer on retention
Nobody decided how long each kind of record is kept, so logs are either deleted too soon or kept forever at growing cost.
What do we build for audit logging?
Agnotic Technologies builds the application side of audit logging: the events your product writes, the store that keeps them and the screens that read them. These are the parts we typically build.
Audit event library
One shared module every service calls to write an audit event, with a fixed schema, so no feature invents its own format.
Read and export logging
Record views, searches, prints and downloads captured with the record IDs involved, not just the page visited.
Change history with before and after values
Field-level history for regulated records, with the reason for change where your process asks for one.
Append-only audit store
A separate store the application can write to but not update or delete, with its own credentials and access list.
Integrity checks
Hash chaining or signed batches so a missing or altered entry shows up when the trail is verified.
Retention rules by record type
Retention set per event class and linked to the record it describes, with legal holds that pause deletion.
Audit viewer and patient access reports
Search by user, record or time for compliance staff, and reports such as who accessed one patient's chart.
FHIR AuditEvent and SIEM export
Audit records sent to partner systems as FHIR AuditEvent resources, or streamed to your security monitoring platform.
What fields does each audit entry need?
OWASP's logging guidance puts it as when, where, who and what. For regulated records we add the outcome and the values before and after.
When
The event time and the time it was logged, in UTC from a synchronized clock, so events from several services line up.
Where
Application and version, service, endpoint or screen, and the host or device that handled the request.
Who
The unique user ID, the source address or device, and the user or system acted for when one service calls another.
What
The event type, the action and the object: which record, which patient or account, which field.
Outcome
Success or failure, and the reason for a failure such as a denied permission or a failed signature.
Before and after
For changes to regulated records, the earlier value and the new one, so the change never hides what was there.
Which events should the audit trail record?
This event catalogue is where we start an audit logging design. Each row names the fields to capture and the rule or guidance that asks for it.
| Event | Fields to record | Rule or guidance | Retention driver |
|---|---|---|---|
| Sign-in success and failure | User ID, time, source address, method, outcome and reason | 45 CFR 164.312(b) audit controls; OWASP Logging Cheat Sheet | Your security policy and incident review needs |
| Record view or search | User, record or patient ID, time, screen or API call | 45 CFR 164.312(b), activity in systems that contain ePHI | Your policy; HIPAA sets no fixed log period |
| Create or change | User, record ID, field, old and new value, time, reason where required | 21 CFR 11.10(e), changes must not obscure earlier values | At least as long as the electronic record itself |
| Delete | User, record ID, what was removed, time, reason | 21 CFR 11.10(e), entries that delete records | At least as long as the record would have been kept |
| Export, print or download | User, records or data set, format, destination | OWASP Logging Cheat Sheet, data import and export | Your policy and data sharing agreements |
| Role or permission change | Admin, target user, access before and after, approver | OWASP, user administration actions; 45 CFR 164.308(a)(4) | Your access review cycle |
| Electronic signature | Signer's printed name, date and time, meaning of the signature | 21 CFR 11.50 signature manifestations | As long as the signed record |
| Emergency (break-glass) access | User, stated reason, records opened, start and end time | 45 CFR 164.312(a)(2)(ii) emergency access procedure | Your policy and review queue |
How long should audit logs be kept?
It depends on the record the log describes. Under 21 CFR 11.10(e), audit trail documentation for an FDA-regulated electronic record is kept at least as long as the record itself, and must be available for agency review and copying.
The HIPAA Security Rule asks for audit controls but sets no fixed retention period for the logs themselves. It does require that documentation of actions and assessments the rule calls for, such as activity reviews, is kept for 6 years from creation or last effective date (45 CFR 164.316(b)(2)).
State law, payer contracts and customer agreements often set longer periods. We record the retention rule beside each event class, so the period can change without rewriting the logging code.
How do you make an audit trail tamper evident?
Nobody, including the application's own administrators, should be able to change history without it showing.
Running that platform, its detections and its log pipeline is a separate service: see Splunk managed services for healthcare.
Write audit events to a store separate from the application's data, using an account that can insert but not update or delete.
Chain each entry or batch to the one before it with a cryptographic hash, and keep the latest hash somewhere the writer cannot reach.
Synchronize every server clock and record times in UTC, so the order of events holds across services.
Limit read access to the audit trail to named roles, and log every search of the audit trail itself.
Verify the chain on a schedule and alert on gaps, and copy events to your security monitoring platform as they are written.
When should audit records use FHIR AuditEvent?
HL7 FHIR R4 defines the AuditEvent resource as a record of an event made to maintain a security log, based on the IHE ATNA audit record. Use it when audit records leave your product: an EHR or health information exchange that asks for them, a central audit repository, or a partner that reports on access to shared records.
Inside the product, a simpler internal schema is often easier to query. We keep the internal fields mappable to AuditEvent (agent, entity, action, outcome and recorded time), so exporting later is a mapping job rather than a redesign. Our FHIR integration work covers the exchange side.
What should an application never write to its audit log?
An audit trail that holds secrets becomes a target. OWASP lists data that should usually be removed, masked, hashed or encrypted before it is logged.
Encryption of the audit store and key handling follow the same rules as the rest of your data; see PHI data security and encryption.
- Passwords, access tokens and session identifiers (hash a session ID if you need to follow one session).
- Encryption keys, database connection strings and other secrets.
- Full clinical notes, test results or other health details: log the record ID, not its contents.
- Payment card or bank account data.
- Government identifiers such as Social Security numbers.
- Data a user has not consented to have collected.
Which rules set audit trail requirements?
Each fact is from the primary source: the eCFR text of the HIPAA Security Rule and 21 CFR Part 11, HL7 and NIST.
The HIPAA Security Rule audit controls standard requires hardware, software or procedural mechanisms that record and examine activity in information systems that contain or use ePHI (45 CFR 164.312(b)).
Source: 45 CFR 164.312 (eCFR)21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails that record operator entries and actions that create, modify or delete electronic records; record changes must not obscure previously recorded information.
Source: 21 CFR 11.10 (eCFR)Under 21 CFR 11.10(e), audit trail documentation is retained for at least as long as the subject electronic records and is available for FDA review and copying.
Source: 21 CFR 11.10 (eCFR)HL7 FHIR R4 defines the AuditEvent resource as a record of an event made for purposes of maintaining a security log, based on the IHE ATNA audit record definitions.
Source: HL7 FHIR R4, AuditEventNIST SP 800-92, the Guide to Computer Security Log Management, gives guidance on developing, implementing and maintaining log management practices across an organization.
Source: NIST SP 800-92 (CSRC)
Trusted by global innovators
Which standards does Agnotic build healthcare software against?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Where should you go next?
- Splunk managed services for healthcareRunning the logging platform: sources, detections and activity review.
- HIPAA compliant software developmentHow the Security Rule turns into architecture decisions.
- FDA SaMD software developmentSoftware as a medical device, from design controls to submission.
- PHI data security and encryptionEncryption, key management and access controls for PHI.
- Role-based access control designRoles, permission checks and break-glass access for applications.