Audit Trail Requirements: 3 Layers Regulators Expect for Compliance

Audit trail requirements: what regulators expect you to log, protect and produce

An audit trail has one job: when someone asks "who changed this record, and when?", it answers with a name, a timestamp and the old value, and nobody could have edited that answer since. FDA, HHS, the IRS and the SEC phrase it differently. Underneath, they all want the same thing. Log the action, lock the log, and hand it over when asked.

Below: what each regulator actually says (with links to the rule text), the fields worth logging, how to stop logs being edited, retention periods, review cadence, and a checklist for this week.

One practical note before we start. A lot of audit pain isn't about logs at all. It's the quarterly access review nobody did, or the certificate that lapsed in May. ExpiryEdge tracks those dates, chases the owner and keeps an exportable record of what was done.

What counts as an audit trail (and why you probably need three of them)

Think of it as the system's diary, written by the system rather than the user. NIST's bulletin on audit trails says it should hold enough detail to reconstruct a sequence of events: the login at 08:02, the edit at 08:05, the file deleted at 08:06.

In practice you'll usually run three kinds side by side.

• System logs, from Windows, Linux or your cloud console: logins, permission changes, file access, accounts created or removed.
• Application logs, from the software itself. A lab value edited in an eCRF. A contract approved in a workflow tool.
• Session logs, which stitch everything one person did between login and logoff into a single story.

Each has a blind spot. Operating system logs will show an admin quietly granting themselves rights, but they won't tell you that the record they then opened was a patient's chart. Application logs know about the chart and miss the privilege escalation. So you need both, on a shared clock.

Next decision: where do you keep before and after values? In a clinical trial database, always. One altered lab result can flip a safety finding. Same for ledger adjustments. A shared-drive access log usually just needs the fact of access. Get this wrong one way and reviewers drown. Get it wrong the other way and you can't tell an auditor what the record used to say.

What each regulation actually requires

No single audit trail rule exists. You get a handful of sector rules that agree on the goal and quibble over details. Here's the short version of each, with the source.

• FDA 21 CFR Part 11. The key line is section 11.10(e). Audit trails must be secure, computer-generated and time-stamped, and they must record on their own when someone creates, changes or deletes an electronic record. A correction can't overwrite the original. Keep the trail as long as the record, and let FDA copy it. This bites anywhere an electronic record replaces paper in regulated work, from HPLC results to batch records.
• HIPAA Security Rule. 45 CFR 164.312(b) is one sentence long. You need mechanisms that "record and examine activity" in systems holding electronic protected health information. It doesn't list fields, so your risk analysis has to. Most practices log logins, chart access and edits, then review them on a schedule. HHS's Security Rule pages cover the rest of the rule.
• IRS Publication 1075. If you handle Federal Tax Information, this is the most prescriptive list you'll meet. Exhibit 9 wants successful and failed logins, privileged actions, changes to access rights, and every object or account created, changed or deleted. And you keep audit information for six years.
• SEC Rule 17a-4. For decades, broker-dealers had to keep records on WORM (write once, read many) media. The 2022 amendments opened a second route. Your system can instead keep a complete, time-stamped audit trail of every change and deletion, note who made it, and be able to rebuild the original. You still owe the regulator records in a format it can actually use.
• PCI DSS Requirement 10. Take card payments and store or process the data yourself? Then you log every access to the cardholder data environment and review security logs for critical systems daily. Version 4.0 adds a retention rule: a year of history, with the last three months on hand.

Read them side by side and one thing jumps out. Not one of them names a product or a storage technology. They ask whether the log can be trusted, whether you can get at it, and whether it leads back to a person. How you get there is up to you.

The fields every audit log entry needs

The fields that satisfy an auditor barely change between regulations. Get these right and you've covered most of what FDA, HIPAA, IRS and SEC examiners ask for.

• A timestamp with time zone, synchronized across systems so events from different sources line up.
• The user or system account, which should be unique to one person. Shared logins wreck attribution.
• The action: create, read, update, delete, export, print or approve.
• The object: the specific record, file or field that was touched.
• The outcome: success, failure or an error code.
• Source context such as IP address, device, application and a session or correlation ID that links related events.
• Before and after values, where the rule or the risk calls for them.

Don't try to log everything at full detail on day one. Start with these fields on your highest-risk system. Then check you can rebuild a real incident using only those fields, and expand from there.

Here's a quick test. Take one real change, say a dosage edited in a trial record last March. Can you say who made it, from which account, at what minute, what the old value was and whether anyone approved it? If any of those is a shrug, that field is missing.

Make logs tamper-evident, or they aren't evidence

A log someone can edit after the fact proves nothing. If your database admin can open the audit table and delete Tuesday's rows, an inspector has no reason to believe Wednesday's. Tamper evidence is what turns a log into evidence.

WORM storage writes a record once and blocks any later change or deletion. It was the traditional answer for broker-dealers. The SEC's audit trail option shows regulators will accept other designs, as long as the system can show the same integrity through a complete, time-stamped trail instead of the storage medium.

• Append-only logs accept new entries and refuse edits to old ones. They're lighter than full WORM.
• Cryptographic hashes give each entry or batch a fingerprint, so any later change is detectable.
• Digital signatures bind an identity to each record, which adds non-repudiation on top of tamper detection.
• Hash-chained (ledger-style) logs store the previous entry's hash in each new one. Insert or delete a line and the chain breaks.

Access control matters as much as storage. The people whose actions get logged shouldn't be able to edit the log, and almost nobody should be able to delete entries. That separation is what stops an insider rewriting history. Encrypt logs at rest and in transit too, especially when you copy them to backup or send them to an auditor.

How long to keep audit logs, and how to hand them over

Retention can go wrong in both directions. Too short and you're out of compliance. Too long and you're holding sensitive data you no longer need.

The IRS sets a six-year floor for audit information tied to Federal Tax Information. HIPAA doesn't name a period for logs themselves, but 45 CFR 164.316(b)(2) requires Security Rule documentation to be kept six years from creation or from when it was last in effect, whichever is later. Part 11 ties the audit trail to the record: it lives as long as the record it describes.

• Map each system to the strictest rule that applies to it, not the shortest.
• Size log storage with headroom. Full disks cause silent overwrites of old records before their retention period ends.
• Alert when storage hits 70 to 80 percent, well before rollover becomes an emergency.
• Move aging logs to cheaper storage that's still searchable instead of deleting them early.

Format matters as much as length. The SEC rule expects records in a human-readable, reasonably usable electronic format, not a proprietary export only your vendor's software can open. Build that in from the start. Retrofitting it during your first real request is miserable.

How often to review audit trails

Match the review cadence to the risk of what's being logged. One calendar habit applied to every system wastes time on the boring logs and misses the dangerous ones.

Routine access to low-risk systems can be reviewed weekly or monthly, looking for patterns rather than single events. High-risk activity needs an alert the moment it happens. That covers:

• Privileged actions such as admin logins, permission grants and configuration changes.
• A burst of failed logins in a short window, which often means someone is trying stolen credentials.
• Bulk exports or downloads outside normal working patterns.
• Access to records outside someone's normal job, like a billing clerk opening clinical notes.

Picture a pharmacy technician exporting 4,000 patient records at 11pm on a Sunday. A monthly review finds that weeks later. A real-time alert finds it before the file leaves the building.

Larger organizations usually feed logs into a SIEM (security information and event management) tool to correlate events and tune alerts. Whatever you use, write down every review, including the ones where you found nothing. That note is evidence too. And agree the escalation path in advance, so nobody is deciding who to call in the middle of an incident.

Build the program in four steps

You won't get from "we have some logs" to "we'd pass an inspection" in one project. Do it in this order.

1. Policy before tools. Decide which events you log, how long each system keeps them, who reviews them and how often, and who gets called when something looks wrong. One or two pages is fine.
2. Separate the people. Whoever configures logging shouldn't be the one reviewing it, and neither should control access to the archive. In a ten-person team that might be the IT lead, the compliance manager and the finance director.
3. Start where the regulated data lives. The EHR, the trial database, the general ledger. Operating system and database logs come second, to plug specific gaps.
4. Prove it works. Pick an event from last month and rebuild it from the logs alone. Complete? Readable? Provably untouched?

Run your first reconstruction test on a system you know well. If you can't rebuild a known event from your own logs, an auditor won't manage it either, and you'd rather find that out first.

Don't switch on verbose logging everywhere. Nobody reads it, and the storage bill grows every month. Log deeply where the regulated data lives and lightly elsewhere.

Four audit trail mistakes that surface during audits

The failures auditors find are rarely dramatic. They're boring gaps that sat there for a year.

• The log disk filled up in February and the oldest entries were overwritten. Nobody noticed.
• Only screen activity was logged, so a nightly script that rewrote prices left no trace.
• The DBA whose actions are logged can also delete log rows.
• The logs exist. Nobody has opened them since go-live.

None of these need a big budget. Make the log store append-only, run an integrity check each month, alert on disk space early, and test a restore at least once. Short on time? Start with the highest-risk data. A beautifully logged staff wiki won't help if the patient records database has holes.

Your audit trail checklist

Three buckets: things to fix now, things to check every quarter, and things to have ready on the day.

1. This week: switch on timestamps in every regulated system, take write access to the logs away from everyone who doesn't need it, and alert on privileged actions.
2. This quarter: rebuild one real event from the logs, check that archiving and retention actually ran, and read through privileged user activity.
3. On audit day: export readable copies, note who handled each record you hand over, and have your integrity checks ready to show.

Treat audit trails as an operating tool, not a checkbox

Regulations set the floor. A good audit trail pays for itself the first time something goes wrong inside the business. A supplier's bank details change the day before a payment run. Who changed them, from which laptop, and who approved it? With decent logs, that's a ten-minute query. Without them, it's two weeks of interviews.

Too many teams treat the audit trail as a box tied to a rule number. Flip it. Build logs you'd want for your own investigations, and Part 11 or HIPAA compliance mostly comes along for free. The weak link is usually human, not technical: the review scheduled for March that slid to June, with nothing written down to show it ever happened.

Keep recurring reviews and renewals on a schedule

That's how audit readiness usually slips. Not a missing policy. A missed date. The vendor's SOC 2 report expired, the quarterly access review was skipped, and nobody noticed until the auditor's request list arrived.

ExpiryEdge handles that part. You load the dates (a quarterly access review, an annual PCI assessment, a staff certification), assign an owner, and it reminds them by email, SMS, WhatsApp, Slack or Teams. Overdue items escalate to a manager, renewed documents are collected against the record, and the whole history exports as an audit trail. Try it free for 14 days, no credit card needed, with your own compliance calendar.

Check the requirements at the source

Primary sources beat summaries, especially when your auditor quotes the regulation back to you.

• 21 CFR 11.10 sets the controls for closed systems, including audit trails, under FDA Part 11.
• HHS HIPAA Security Rule resources explain audit control obligations for ePHI.
• IRS Safeguards audit requirements list auditable events and retention for Federal Tax Information.
• SEC final rule 34-96034 sets out the audit trail alternative to WORM for broker-dealers.
• NIST's audit trail bulletin covers what an audit trail should contain and how to implement one.

Kuldeep writes about compliance operations and workflow automation, with a focus on how deadline tracking and structured reminders cut audit prep time for regulated teams.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Meeting IRS Safeguards audit requirements | Internal Revenue Service
• NIST ITL Bulletin: Audit Trails
• Final Rule: Electronic Recordkeeping Requirements for Broker-Dealers, Security-Based Swap Dealers, and Major Security-Based Swap Participants
• HIPAA Security Rule | HHS
• 21 CFR 11.10, Controls for closed systems | eCFR
• 45 CFR 164.312, Technical safeguards | eCFR
• 45 CFR 164.316, Policies and procedures and documentation requirements | eCFR

FAQ

What are the audit trail requirements under 21 CFR Part 11?

Section 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record when operators create, modify or delete electronic records. A change can't hide what was there before. You keep the trail at least as long as the record it covers, and FDA must be able to review and copy it during an inspection.

What are the FDA guidelines for audit trails?

FDA wants the system to write the trail itself. Users shouldn't be able to type into it, edit it or switch it off, and under 21 CFR 11.10(e) it must last as long as the record it covers. Inspectors look for gaps, deleted entries and shared logins. Check yours for those three before an inspection, not after.

What should an audit trail contain?

At minimum: a synchronized timestamp with time zone, the unique user or system account, the action (create, read, update, delete, export, approve), the exact record or field touched, and whether it succeeded. Add before and after values for regulated data such as lab results or ledger entries, plus IP address or session ID where you need to trace a sequence.

What is the new rule on audit trails?

In 2022 the SEC amended Rule 17a-4 (Release 34-96034) so broker-dealers no longer have to use WORM storage. They can instead keep records in a system with a complete, time-stamped audit trail that logs every modification and deletion, records who made it, and can re-create the original record. Firms still have to produce records in a usable electronic format on request.

Recommended

• Benefits of Automated Compliance Tracking for Teams
• What Approval Workflow Compliance Actually Requires
• Certification Expiration Tracking Checklist for Compliance Teams
• How Clinical Staff License Monitoring Works: Compliance Guide