Your spectroscopy software generates electronic records. Maybe it is an FTIR system running raw material identification in a pharma QC lab. Maybe it is a Raman device classifying tissue samples in a clinical diagnostic setting. Maybe it is an NIR instrument verifying incoming materials against a spectral library. If any of those records are generated in a GMP or clinical environment regulated by the FDA, you need to comply with 21 CFR Part 11.

This is not a theoretical risk. FDA issued 303 drug warning letters in FY2025 - a 59% increase over FY2024. Data integrity violations appear in approximately 15% of all warning letters and roughly 60% of warning letters issued to Indian manufacturing sites. The agency is not backing off. It is accelerating enforcement.

Shimadzu, Malvern Panalytical, and Mettler Toledo all publish Part 11 compliance documentation for their spectroscopy instruments, confirming FDA expects spectroscopy software to maintain compliant audit trails and preserve data integrity. If the instrument vendors take this seriously, your workflow software must too.

This article covers what Part 11 actually requires, what FDA inspectors look for when they walk into your lab, and a minimum viable compliance checklist you can hand to your development team.

This article is educational and does not constitute legal or regulatory advice - consult qualified regulatory professionals for your specific situation.

The actual requirements

Part 11 was published in 1997 and has not been substantively revised since. The regulation is short - about 15 pages - but those pages have generated thousands of warning letters and 483 observations. The core requirements break into six areas.

Audit trails

Section 11.10(e) requires computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records. The audit trail must be retained for a period at least as long as the subject electronic records.

In practice, this means:

Every action timestamped. Not "sometime this morning" - ISO 8601 UTC timestamps with sufficient precision to establish the sequence of events.

Attributed to a specific user. Every audit trail entry must identify who performed the action. "Lab Tech" is not a user. "System Administrator" is not a user. Jane Smith, user ID JSMITH042, is a user. No shared accounts. Period.

Reason for change recorded. When someone modifies a record, the system must capture why. This is a required field, not an optional comment box. "Correcting transcription error" is a reason. A blank field is a finding.

Tamper-evident. The audit trail cannot be modified or disabled by users, including administrators. If an administrator can delete audit trail entries, you do not have an audit trail - you have a log file that happens to exist until someone decides it should not.

Retained for the full record lifecycle. If your spectroscopy records must be retained for seven years, your audit trail must be retained for seven years. The audit trail is not a temporary debugging tool. It is a permanent regulatory record.

Here is what a compliant audit trail entry looks like as a data structure:

interface AuditTrailEntry {
  id: string;
  timestamp: string;           // ISO 8601, UTC
  userId: string;              // Unique user identifier
  userName: string;            // Display name
  action: 'CREATE' | 'READ' | 'UPDATE' | 'DELETE' | 'APPROVE' | 'REJECT' | 'SIGN';
  resourceType: string;        // e.g., 'spectrum', 'classification_result', 'method'
  resourceId: string;
  previousValue?: unknown;     // For updates: what was there before
  newValue?: unknown;          // For updates: what it changed to
  reason?: string;             // Required for modifications
  ipAddress: string;
  sessionId: string;
  checksum: string;            // SHA-256 hash including previous entry's checksum (chain)
}

The checksum field is critical. Each entry's checksum is computed from the entry's data plus the previous entry's checksum, creating a hash chain. If someone modifies or deletes any entry in the middle of the chain, every subsequent checksum becomes invalid. This is the same principle behind blockchain - not because you need a blockchain, but because cryptographic hash chaining is the simplest way to make tampering detectable. An auditor can verify the entire audit trail by recomputing the chain from the first entry forward. Any break proves the trail was altered.

Electronic signatures

Sections 11.50, 11.100, and 11.200 govern electronic signatures - the requirements that apply when someone "signs" an electronic record to approve a result, release a batch, or authorize a method change.

Linked to a unique user. The signature must be attributable to one specific individual. No shared accounts - this comes up again because it is the single most common Part 11 violation.

Two distinct identification components. The signature must require at least two components - typically username and password. A single-click "Approve" button is not an electronic signature. The user must re-authenticate at the time of signing. Saved passwords and auto-fill defeat this requirement entirely.

Signature meaning recorded. The system must capture what the signature means: reviewed, approved, rejected, verified. "Signed" is not sufficient. The meaning must be unambiguous.

Linked to the specific record. The signature must be bound to the exact record being signed, not to a batch of records or a general approval. If a reviewer approves a spectral classification result, the signature is linked to that specific result ID, not to "Tuesday's results."

Printed name, date/time, and meaning included. Every electronic signature must display the printed name of the signer, the date and time the signature was executed, and the meaning of the signature. This information must be part of any human-readable display or printout of the signed record.

Biometric signatures (fingerprint, retinal scan) are permitted under Part 11 but rarely implemented in laboratory software. The username-and-password approach is simpler and universally supported.

System access controls

Sections 11.10(d) and 11.10(g) require controls to limit system access to authorized individuals and to enforce authority checks on specific operations.

Unique user IDs. Every person who accesses the system must have a unique identifier that is never reused, even after an employee departs. User IDs are permanent records.

Password policies. Minimum length (8 characters is the practical floor), complexity requirements, expiration intervals (90 days is standard), and password history (cannot reuse the last 12 passwords). These are auditable requirements, not suggestions.

Session timeouts. Automatic logout after a defined period of inactivity - fifteen minutes is the most common implementation. If a lab technician walks away from their workstation, the system must not remain accessible indefinitely.

Role-based access control. At minimum: operator (run tests, enter data), reviewer (approve or reject results), and administrator (manage users and configuration). The critical principle is separation of duties - the person who generates a result should not be the same person who approves it.

Authority checks. The system must verify that the user is authorized for the specific operation they are attempting. These checks must be enforced at the system level, not by policy or training.

Record retention

Section 11.10(c) requires the ability to generate accurate and complete copies of records in both human-readable and electronic form suitable for inspection, review, and copying by the agency.

Human-readable output. Raw database records are not sufficient. If an FDA inspector asks to see the audit trail for a specific result, you must be able to produce a readable document - typically PDF/A - that shows the complete chain of events. "Let me write a SQL query" is not an acceptable response during an inspection.

Content and meaning preserved. Copies must preserve the content and meaning of the original record. A CSV export that strips context and relationships does not meet this requirement.

Retrievable throughout the retention period. If your records have a seven-year retention requirement, you must be able to retrieve those records seven years from now. Your retention strategy must account for technology changes - the system that created the records may not exist in seven years, but the records must still be accessible.

System validation

Section 11.10(a) requires that systems used to generate, modify, maintain, or transmit electronic records be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

In practice, this means IQ/OQ/PQ:

Installation Qualification (IQ). Documented evidence that the software was installed correctly on the intended hardware, in the intended environment, with all dependencies satisfied. A protocol, execution record, and documented results.

Operational Qualification (OQ). Documented evidence that the software functions according to its specifications. Every feature that touches electronic records or electronic signatures must be tested and the results recorded.

Performance Qualification (PQ). Documented evidence that the software performs as intended in the actual production environment, with real data volumes, real network conditions, and real user workflows.

Revalidation. System validation is not a one-time event. Any significant change - software update, database migration, infrastructure change - requires an impact assessment and potentially a revalidation.

For spectroscopy software, validation must cover the end-to-end data pipeline: from spectrum acquisition through classification, result generation, and HL7 message transmission. If your software is classified as SaMD, validation requirements compound with IEC 62304 lifecycle requirements.

Backup and recovery

Section 11.10(c) also addresses the protection of records to enable their accurate and ready retrieval throughout the records retention period.

Regular automated backups. Manual backup procedures fail. Backups must be automated, scheduled, and monitored.

Documented recovery procedures. A backup that cannot be restored is not a backup. You need written procedures describing exactly how to restore the system, who is authorized to initiate a restore, and how to verify completeness after restoration.

Tested recovery. This is where most organizations fail. "We have backups" is not compliance. "We have verified that we can restore from backups" is. Recovery testing should be performed quarterly, documented with results, and any failures addressed with corrective actions. "We have never tested it" is a finding.

What FDA inspectors actually look for

The requirements above are the regulation. What follows is what happens when an FDA investigator walks into your facility and starts asking questions. These findings are drawn from actual warning letters and 483 observations.

Shared user accounts

This is the number one finding. It appears in warning letters with predictable regularity.

Person & Covey, Inc. (Glendale, CA) - Warning letter 711191, September 23, 2025. "System Administrator" was the only user type. All lab personnel shared a single common password. The firm admitted during the inspection: "There was never a formal procedure for Data Integrity." One user type. One password. No individual accountability. No audit trail attribution. This is not a subtle technical violation - it is a complete absence of the most basic Part 11 control.

The fix is straightforward: every person who touches the system gets a unique account. No exceptions for small teams. No exceptions for shared shifts.

Audit trails that can be modified or disabled

Shiva Analyticals Private Limited (Bangalore, India) - Warning letter 707857, July 23, 2025. FDA inspected January 20-24, 2025. Investigators found that analysts had performed hundreds of "Add/Modify/Delete peaks" and "Alter existing file on disk" entries in MassLynx audit trails between January 2022 and January 2025. Torn and discarded original CGMP documents were found in the waste disposal area.

This warning letter illustrates two failures. First, the software allowed users to alter data files on disk - the audit trail recorded the alteration, but the system did not prevent it. Second, the volume of modifications (hundreds over three years) suggests routine data manipulation rather than legitimate corrections. A compliant system would require a documented reason for every modification and flag unusual patterns for quality review.

No documented system validation

This finding appears in two forms. The obvious form: no validation documentation at all. The subtle form: using Microsoft Excel for critical GMP calculations - concentration calculations, acceptance criteria, trending - with no validation of spreadsheet formulas, no protection against accidental modification, and no audit trail on changes.

Unvalidated spreadsheets are one of the most common Part 11 findings. Excel is not inherently non-compliant, but using it for regulated calculations without validation, cell protection, and audit trails is a violation that investigators know to look for.

Inadequate backup and recovery

Investigators ask two questions: "Show me your backup procedures" and "When did you last test a restore?" If the answer to the second question is "we have not," that is a finding.

Electronic signatures failing the two-component requirement

Single-click approvals without re-authentication. Saved passwords enabling auto-fill at the signature step. Shared reviewer accounts. These are all findings, and they are all detectable in minutes during an inspection.

Updated guidance: October 2024

In October 2024, FDA finalized updated guidance titled "Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers" (Revision 1). The key clarification for software developers: once data enters a sponsor's electronic data capture system, Part 11 applies fully. This guidance reinforced that the scope of Part 11 is not limited to the point of data generation - it extends to every system in the chain that stores, processes, or transmits the electronic record.

For spectroscopy software that feeds results into downstream systems, this means your data pipeline architecture must maintain Part 11 compliance at every handoff point, not just within your application boundary.

How this applies to spectroscopy specifically

Here is what Part 11 compliance looks like for the operations your spectroscopy software performs every day.

An FTIR measurement

Every FTIR measurement in a regulated environment must be traceable. That means the audit trail captures:

Who ran it. Operator ID - "JSMITH042," not "Lab Tech." The operator must have authenticated with their unique credentials before the measurement started.
When. ISO 8601 UTC timestamp. Not "Tuesday afternoon." Not a timestamp that can be modified after the fact.
What instrument. Serial number of the spectrometer, its current calibration status, and the date of last calibration verification. If the instrument was out of calibration, the measurement should be flagged or prevented.
What parameters. Resolution (4 cm-1), scan count (32 scans), aperture setting, background reference timestamp. These parameters must be recorded automatically by the software, not entered manually by the operator.
What result. The classification output (e.g., "Acetaminophen, confidence 0.97, hit quality index 0.94"), the model version that produced it, and the spectral library version used for comparison.
Who reviewed it. Reviewer ID, timestamp of review, and the reviewer's disposition: approved, rejected, or flagged for further investigation, with a documented reason.
Full chain to delivery. If the result generates an HL7 message to a downstream system, the audit trail records the message ID, destination, transmission timestamp, and acknowledgment status.

Every field is captured automatically. Nothing is left to manual entry where automatic capture is feasible. The clinical workflow architecture must be designed to generate these records as a natural byproduct of operation, not as an afterthought bolted on later.

A classification model update

When you deploy a new version of a spectral classification model, the audit trail must capture:

Who deployed the new model version, authenticated with their unique credentials
The previous model version identifier and the new model version identifier
Validation results for the new model: sensitivity, specificity, accuracy on the validation dataset, compared against the previous version
The approval workflow: who requested the change, who performed the impact assessment, who authorized deployment, and with what justification
Documented rollback capability: evidence that the previous model version can be restored if needed

Model updates in SaMD systems may also trigger revalidation requirements under IEC 62304. Your change control procedure must account for both Part 11 audit trail requirements and device lifecycle requirements.

A result correction

Results in a Part 11-compliant system are never overwritten. When a correction is necessary, the system must:

Preserve the original value in its entirety - the original record is never modified or deleted
Record the new (corrected) value alongside the original
Require a documented reason for the change - this is a mandatory field, not an optional comment
Record who made the change and who approved the change (separation of duties - the corrector and the approver should be different people)
Display both values in the audit trail so that any reviewer can see what was changed, when, by whom, and why

The principle is simple: the history of a record is as important as its current state. An investigator should be able to reconstruct exactly what happened, in what order, and with what justification, by reading the audit trail alone.

Implementation checklist

A minimum viable compliance checklist. Not exhaustive, but if your spectroscopy software does not implement every item on this list, you have a gap that an FDA inspector can find.

Unique user accounts for every person. No shared logins. No generic "admin" accounts used by multiple people. User IDs are never reused, even after an employee departs.
Password policy enforcement. Minimum 8 characters, complexity requirements (uppercase, lowercase, numeric, special character), 90-day expiration, cannot reuse the last 12 passwords. Enforced by the system, not by policy alone.
Session timeout. 15-minute inactivity auto-logout. The timeout must log the user out of the application, not just lock the screen. Re-authentication required to resume.
Role-based access control. At minimum: operator (run tests, enter data), reviewer (approve or reject results), administrator (manage users and configuration). Separation of duties enforced - operators cannot approve their own results.
Immutable audit trail on every write operation. Create, update, delete, approve, reject - every action that modifies the state of an electronic record generates an audit trail entry. No exceptions.
Audit trail entries include: timestamp (ISO 8601, UTC), user ID, action type, resource type, resource ID, previous value, new value, and reason for change (required for modifications). These fields are populated automatically by the system.
Checksum chaining for audit trail tamper-evidence. Each entry's SHA-256 hash incorporates the previous entry's hash. Chain integrity is verifiable independently of the application.
Electronic signatures require re-authentication. Username and password entered at the time of signing. No saved credentials. No single-click approvals. No auto-fill.
Signature records include: signer's unique user ID, printed name, date and time of signature, and the meaning of the signature (approved, rejected, reviewed). Linked to the specific record being signed.
All records exportable in human-readable format. PDF/A or equivalent that preserves content, context, and meaning. Available on demand during an inspection without requiring technical intervention.
Automated daily backups with documented recovery procedures. Backup jobs monitored for success and failure. Backup storage physically or logically separated from the production system.
Backup recovery tested quarterly. Documented with test date, personnel involved, recovery time, data completeness verification, and any issues encountered. Findings addressed with corrective actions.
System validation protocol (IQ/OQ/PQ) documented and executed. Protocols approved before execution. Results documented. Deviations investigated and resolved. Validation summary report approved by quality.
Change control procedure. Any system change - software update, configuration change, infrastructure modification - requires a documented impact assessment, testing plan, test execution and results, and approval before deployment to production.
Periodic audit trail review by the quality unit. Monthly at minimum. Review should look for unusual patterns: excessive deletions, modifications without adequate reasons, after-hours activity, and any evidence of data manipulation.

These fifteen items are the floor. An FDA investigator who finds gaps in any of these areas has a potential 483 observation.

How SpectraDx handles Part 11

Part 11 compliance is built into the SpectraDx platform architecture from the first line of code. The audit trail is a core database construct that every write operation touches - spectrum acquisition, classification, result review, method changes, user management. Every entry is SHA-256 checksum-chained and independently verifiable. No user, including administrators, can modify or delete audit trail entries through any application interface.

Electronic signatures are integrated into the result release workflow. When a reviewer approves or rejects a classification result, the system requires re-authentication with both username and password, records the signer's identity and disposition, and binds the signature to the specific record. Role-based access control is enforced at the API layer. All electronic records are exportable as PDF/A documents that preserve the complete context of the record, including its full audit trail history.

Every SpectraDx deployment includes IQ/OQ/PQ documentation tailored to the customer's environment, change control procedure templates, and backup and recovery documentation. The platform is designed so that passing an FDA inspection is a predictable outcome of normal operation, not a special preparation event. For more on how compliance integrates with the broader platform, see our solutions overview.

The bottom line

21 CFR Part 11 is not complicated. It is detailed, but the core requirements are straightforward: know who did what, when, and why. Prevent unauthorized access and modifications. Keep records retrievable. Validate that your system works. Test your backups.

The organizations that receive warning letters are not struggling with exotic edge cases. They are failing at fundamentals: shared accounts, modifiable audit trails, no validation documentation, untested backups. These are problems solved at the architecture level, not the policy level. If your software does not enforce unique user accounts, no amount of SOPs will make you compliant.

If your spectroscopy software is generating electronic records in a regulated environment, Part 11 compliance is not optional and it is not something you can defer to "version 2." The time to build it in is now - at the architecture level, before the first record is generated. Retrofitting compliance onto an existing system is always more expensive and more error-prone than building it in from the start.

Start with the fifteen-item checklist above. Implement every item. Validate the implementation. Document the validation. Then maintain it - because compliance is not a milestone, it is an ongoing operational commitment.

21 CFR Part 11 for Spectroscopy: Audit Trails and Compliance