What audit trail requirements should regulatory compliance workflows satisfy for FDA submissions

PLM Aras Innovator
, , , , , , ,
1

Our medical device company is preparing for FDA submissions and we need to ensure our Aras workflows meet regulatory compliance requirements. We’re particularly focused on FDA 21 CFR Part 11 for electronic records and signatures, and ISO 13485 audit trail standards.

I’m looking for perspectives on what constitutes adequate audit trail coverage. Should we log every field change, or just critical state transitions? What about data retention policies - how long should audit records be preserved? And how do you implement immutable log design to prevent tampering?

We’re currently capturing basic workflow state changes and approvals, but I’m concerned this might not be sufficient for regulatory audits. What have others implemented for FDA-regulated products?

system 2

Audit Trail Architecture for 21 CFR Part 11 / ISO 13485 in Aras Innovator

Three distinct implementation patterns emerge in regulated Aras deployments. Each satisfies the regulatory floor differently, with meaningful trade-offs across cost, query performance, and audit defensibility.

Regulatory Floor (Non-Negotiable Baselines)

Before weighing approaches, these requirements are structural under 21 CFR Part 11 §11.10 and ISO 13485 §4.2.5:

  • Audit records must capture who, what, when, and previous value — not just “a change occurred”
  • Electronic signatures must be linked and bound to their associated record (Part 11 §11.70)
  • Records must be human-readable and retrievable for the duration of the device’s commercial life plus applicable retention window (typically device lifetime + 2 years under 21 CFR Part 820, but verify against your predicate device classification)
  • Audit records themselves must be protected from modification — not just the item records

Three Architectural Perspectives

Perspective A — Granular Field-Level Audit via Aras Native History

Aras stores item history through the [ItemType]_audit table pattern and the built-in Audit History relationship. Enabling this per-property gives field-level delta records.

<!-- Enable audit on a property in TOC > ItemTypes -->
<Property name="document_status" audit="true" />

Perspective B — Workflow-State-Transition-Only Logging

Capture only Activity completion, Assignment changes, and Vote events via custom server-side Methods on Workflow Activity. Log to a dedicated locked ItemType.

// Server Method on Activity Completion
var auditItem = inn.newItem("Compliance_Audit_Log", "add");
auditItem.setProperty("record_id", this.getID());
auditItem.setProperty("state_from", previousState);
auditItem.setProperty("state_to", newState);
auditItem.setProperty("actor", inn.getUserID());
auditItem.setProperty("timestamp", new Date().toISOString());
auditItem.apply();

Perspective C — External Immutable Log (Database + Append-Only Store)

Write audit events to an external system (e.g., append-only Azure Table Storage, AWS QLDB, or an on-prem write-once schema) via Aras IOM events or an integration layer. Aras becomes the system of record for content; the external store holds tamper-evident audit data.

Trade-offs

Dimension A — Full Field Audit B — State Transitions Only C — External Immutable Store
21 CFR Part 11 coverage High — captures all property changes Medium — may miss field edits outside workflow High — depends on event coverage
ISO 13485 §4.2.5 Strong Marginal (requires gap analysis) Strong if integration is complete
Tamper resistance Weak — same DB, DB admin can modify Weak — same issue Strong — cryptographic or append-only
Query/report performance Degrades at scale (audit tables grow large) Low overhead No Aras query impact
Implementation complexity Low — config-driven Medium — custom Methods High — integration, ops overhead
Retention management Tied to Aras DB lifecycle Same Independent, archival-friendly
E-signature binding (§11.70) Native via Aras signature workflow Requires explicit linkage Requires explicit linkage

Decision Criteria

Your choice should be driven by:

  • Risk classification of your device — Class II/III submissions face stricter scrutiny than Class I; assess whether state-transition-only logging survives a FDA 483 observation
  • Volume of record changes — granular field audit on high-velocity item types creates index and storage pressure (verify in your version for table partitioning options)
  • DB administrator access controls — if DBAs have direct SQL access, in-database audit tables do not satisfy immutability without additional controls
  • Predicate device audit history — if referencing existing 510(k) submissions, your audit depth should be defensibly equivalent
  • Your QMS consultant’s gap analysis against Part 11 §11.10(e) — the requirement is “computer-generated, time-stamped audit trails,” which regulators have interpreted variably across inspection cycles

This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

For FDA 21 CFR Part 11 compliance, you need comprehensive audit trails that capture who, what, when, and why for every modification. This includes field-level changes, not just state transitions. The regulation specifically requires that audit trails are computer-generated, time-stamped, and include operator identification. You also need to log failed access attempts and invalid signature attempts. Partial logging won’t pass FDA inspection.

4

From an ISO 13485 perspective, your audit trail must demonstrate traceability throughout the product lifecycle. We log all changes to device master records, design documents, risk assessments, and validation records. Data retention policies should align with your device’s expected lifetime plus regulatory requirements - typically 10-15 years minimum. But check your specific regulatory jurisdiction as requirements vary by region.

5

Immutable log design is critical and often overlooked. In Aras, we implement this by writing audit events to a separate database schema with restricted permissions - only the system account can write, no user can modify or delete. Each audit record includes a cryptographic hash of the previous record, creating a tamper-evident chain. We also implement log verification routines that run daily to detect any unauthorized modifications. This architecture has withstood multiple FDA audits without issues.

6

Don’t forget about electronic signatures! FDA 21 CFR Part 11 has specific requirements for signature manifestations and meaning. Your audit trail must capture the signed data, signature timestamp, and the meaning of the signature (e.g., “Approved for Release” vs “Reviewed”). We also maintain a separate signature log that links to the audit trail but provides additional context about signature authority and delegation chains.

7

For data retention policies, consider both regulatory minimums and practical storage constraints. We implement tiered storage: hot storage for active records (0-2 years), warm storage for recent historical data (2-7 years), and cold archival storage for long-term retention (7-15 years). Make sure your retention policy is documented and validated as part of your quality management system. Also implement automated retention enforcement - don’t rely on manual processes.

8

I’ve been through numerous FDA audits and here’s what actually gets scrutinized: evidence of who made changes, when they were made, what the old and new values were, and whether the person had authority to make that change. Your basic workflow state logging is insufficient - you need field-level audit trails for all controlled documents and records. Also critical: your audit system itself must be validated per your organization’s validation procedures.

9

After researching and discussing with our quality team, here’s the comprehensive approach we’re implementing:

FDA 21 CFR Part 11 Requirements: We’re implementing field-level audit trails that capture every modification to controlled records. This includes: user identity (authenticated via our validated system), timestamp (server-synchronized to prevent manipulation), action performed (create/modify/delete/approve/reject), old and new values for all fields, reason for change (required comment field), and electronic signature details when applicable. We’re also logging failed login attempts and invalid signature attempts as required by the regulation.

ISO 13485 Audit Trail Standards: For medical device quality management, we’re ensuring traceability across the entire product lifecycle. Our audit trails cover: design history files, device master records, risk management files, validation and verification records, complaint handling, and CAPA records. Each audit event links to the specific requirement being satisfied (e.g., “Change per ECO-2024-1234 for Design Control requirement”).

Data Retention Policies: We’ve established a 15-year retention policy for all audit records related to Class II and Class III devices, aligning with FDA guidance and our device lifetime expectations. The policy includes: automated enforcement through system rules, tiered storage strategy (hot/warm/cold), annual verification of data integrity, and documented procedures for emergency data recovery. We’re also maintaining metadata about the retention policy itself in the audit system.

Immutable Log Design: This was our biggest gap. We’re implementing a blockchain-inspired approach where each audit record contains a cryptographic hash of the previous record, creating a tamper-evident chain. Technical implementation includes: separate audit database with write-only permissions for system account, cryptographic signing of each audit entry using SHA-256, daily verification jobs that validate the hash chain integrity, and quarterly external verification by our quality assurance team. Any break in the chain triggers immediate investigation and incident reporting.

Additional considerations we’re addressing: Our audit system itself is being validated per our software validation procedures (IQ/OQ/PQ). We’re implementing automated reports that auditors can run to verify compliance. We’re also creating a signature manifestation system that clearly displays what was signed, by whom, when, and the meaning of the signature.

The key insight from all this research: regulatory compliance isn’t just about technology - it’s about demonstrable processes. Your audit trail must prove you have control over your data and can detect unauthorized changes. This requires both technical controls (immutable logs, cryptographic verification) and procedural controls (validation, periodic review, incident response).