Designing an Audit Trail for 21 CFR Part 11 Compliance

Major Projects

Client

Formulatrix

Service

UI/UX

Year

2025

Context

As part of our work toward 21 CFR Part 11 compliance, we needed to implement an Audit Trail in our software. This feature is critical for regulated industries, ensuring every action within the system is recorded and traceable. Without it, users could not fully trust the system to meet compliance requirements, which limited adoption in regulated environments.

My role as UX/UI Designer was to translate compliance rules into practical design, ensuring the audit trail was not only secure and compliant but also usable and accessible for everyday users.

Understanding the Problems

From discussions with customers and internal teams, the key problems were clear:

  • No way to trace who made changes, what was changed, or when it happened.

  • Lack of visibility increased the risk of unauthorized or incorrect modifications.

  • Users needed to export logs for internal reviews and regulatory audits.

  • The system had no plan for long-term retention or storage management.

These gaps made compliance and accountability impossible in its current state.

CFR Clauses and Design Considerations

CFR Clause

Point

Consideration

§ 11.10 (e)

Audit trails must be secure, computer-generated, and time-stamped. Changes must not obscure previous data.

  • Log all user actions (create, modify, delete)

  • Include timestamps and user identification

  • Retain audit trails as long as the associated records

  • Make audit data available for review and inspection


Discussion with Internal Team

I facilitated technical discussions with engineers and QA to determine what was feasible for the first release. Together we defined the following objectives:

  • Ensure records cannot be changed without leaving a trace.

  • Track who made changes, what was changed, and when.

  • Provide a way to export audit trail logs when needed.

We also raised open questions for the PM:

  • Should users be required to give a reason when modifying data?

  • How should the system handle retention periods for audit logs to avoid memory issues?

These points needed clarification to finalize the release scope.

PM Alignment

With the internal objectives defined, I brought the open questions to the PM to confirm scope and priorities for the first release.

The PM confirmed:

  • Reason for modification – not required for now. As long as the system tracked actions before and after a change, compliance would be satisfied.

  • Retention period – memory analysis showed no immediate risk. Retention and memory management would be added in a later iteration, possibly with limits and warnings when storage approached capacity.

This alignment allowed us to focus version one on core compliance while planning ahead for scalability.

Designing the Solution

Based on the discussions and alignment, I prepared all necessary design outputs for handover:

  • User workflows covering positive, negative, and edge cases.

  • High-fidelity mockups and prototypes for the audit trail view and export function.

  • Design documentation detailing system behavior and compliance alignment.

These artifacts ensured clarity for developers and consistency for stakeholders.


The Outcome

The first release of the audit trail delivered:

  • A secure, computer-generated log of all user actions, complete with timestamps and user IDs.

  • The ability to export audit logs for review and audit purposes.

  • Increased trust and transparency, ensuring customers could rely on the system in regulated environments.

  • A roadmap for future iterations, including reasons for modification, log retention management, and storage monitoring.

This feature reinforced data integrity and accountability, helping the product move closer to full 21 CFR Part 11 compliance and strengthening customer confidence.

Create a free website with Framer, the website builder loved by startups, designers and agencies.