Since February 2, 2026, the internal audit reports and management review minutes that used to sit outside a U.S. Food and Drug Administration (FDA) inspection have been inspectable. A document revision still waiting for a signature can hold up a European Union Medical Device Regulation (EU MDR) certification. FDA inspections, certification-authority Stage of Involvement reviews on DO-178C programs, and Automotive SPICE (ASPICE) assessments each ask for the same thing in a different format, at a moment we didn’t pick: the link between a requirement and its verification evidence.
Audit readiness changes character once that link lives in project data that is already current, with no folder to reconcile first. This guide covers what five kinds of review actually pull, how to hold the trace structure steady between audits, and what a milestone baseline lets a reviewer confirm about an approval.
How Do We Run an Inspection Response Today?
The war room is how most regulated programs answer a records request today, and it works by separating the investigator-facing workspace from the internal area where we locate and review what was asked for. Communication rules keep unrequested or unvetted documents away from the investigator. Practicing requests before the real inspection tests whether our response process keeps pace.
Prompt record retrieval, and alignment between actual practice and written procedures, are what keep a routine question from becoming an inspection problem. The records-production risk shows up plainly at Kabe Labortechnik GmbH. In Warning Letter 704563 of May 9, 2025, FDA cited the firm under the Quality System Regulation then in force for failing to maintain an adequate design history file (DHF). The file did not contain or refer to the original design inputs, outputs, verification and validation, or design review records. When the inspector asked for them, the quality supervisor said the firm may not have maintained such documents.
The cost of the document-based model becomes clear when a requirement changes mid-program. A significant change reported to a notified body may send the whole documentation set back for reassessment of safety and performance. The Director of Quality and Regulatory at Microsure, whose microsurgical robots go through that notified body review, described what moving the record into Jama Connect changed in that review: “We knew that in the audit process regulating bodies would recognize the level of detail and clarity that the tool gives us.”
FDA’s Quality Management System Regulation (QMSR) is what changed that, by incorporating International Organization for Standardization (ISO) 13485:2016 by reference. Supplier audit records went the same way, and the old exemption is gone.
What Do Auditors Actually Check?
Three links do most of the work across every framework in this article. A requirement traces to its source, to the design that implements it, and to the verification specification that proves it. Aerospace, medical device and automotive programs each ask a team to demonstrate that same connection, in their own artifacts and their own formats. The governing document may be SAE International’s Aerospace Recommended Practice ARP4754B (or ARP4754A on programs still certified to it), ISO 13485, ISO 26262, or Title 21 of the Code of Federal Regulations (21 CFR) Part 820, and the underlying question does not change.
The five review types below each pull something different, and test a different link to get there.
| Evidence dimension | FDA inspection or ISO 13485 audit | EU MDR notified body assessment | DO-178C Stage of Involvement #3 (DO-254 for airborne electronic hardware) | ISO 26262 functional safety assessment | ASPICE assessment |
|---|---|---|---|---|---|
| Evidence pulled | The design history file package as teams still assemble it, verification and validation records, ISO 14971 risk management file | Technical documentation, risk management documentation | Test procedures, test results, structural coverage analysis, traceability data | Safety case work products, hazard analysis, safety requirements at each level, verification results | System and software traceability records |
| Link tested | Design outputs to design inputs, under ISO 13485 Clause 7.3 as incorporated at 21 CFR 820.10(c); each hazard through analysis, control, and residual risk | Whether evidence changed since the prior assessment | Structural coverage evidence to requirements | ASIL determination carried consistently from safety goals through functional safety requirements and technical safety requirements to hardware and software requirements | Bidirectional traceability and consistency across the relevant V-model levels |
| Retrieval output | Design history file export and trace report | Technical documentation and change evidence | Stage of Involvement #3 traceability data | Safety case work products | Bidirectional trace records |
Newer ASPICE versions combine traceability and consistency into a single Base Practice. Assessors can therefore check bidirectional traceability across the V-model at every relevant level together. For medical device software, International Electrotechnical Commission (IEC) 62304 adds traceability at the software level, linking each software requirement to system requirements, risk controls, design outputs, and verification tests. The standard also expects a record of which software requirement implements each risk control measure.
Keeping the Evidence Current Between Audits
Evidence stays current when the trace structure is settled before the first requirement is written and every later change is assessed as it lands. Connected-equipment programs run that same discipline against IEC 61508 and the EU Machinery Regulation, which is the subject of audit-ready documentation starts during engineering. The medical device, aerospace and automotive programs in this article differ in the record each assessor expects at the end of it, and in how much of that record a clause prescribes.
A Traceability Information Model (TIM) specifies which artifact types must connect, which relationship types count, and how changes get recorded, before development begins. A reviewer eventually reads a Requirements Traceability Matrix (RTM), which records what existed at one moment; the TIM is what keeps the RTM honest between those moments.
Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development, holds those relationships as live project data. An upstream change then marks the links to every downstream test case, risk item and design element as suspect, until an engineer assesses each one and either updates the item or clears the suspect link. That turns continuous change control practices into an exception queue with a decision record attached, and it lets approvals run in increments across the project. The Diagnostic Divisions R&D Instruments Senior Manager at Grifols described the effect on her team: “With the Review Center, we review things more incrementally, and we can catch changes, or things to fix, very early in the process. So, the cost at the end is less.” On the project her division reported, review cycles fell from 90 days to fewer than 30, saving more than 80 hours.
What a Reviewer Can Confirm About an Approval
Change and approval records let a reviewer confirm who approved a specific state of the work and when the review occurred. Spreadsheets can store that information but can’t enforce it. Under 21 CFR Part 11, four requirements bear directly on whether an approval record survives a review:
- Associated information: The signed record carries the signer’s printed name, the date and time, and the meaning of the signature (§11.50(a)).
- Record linkage: A link ties the signature to its electronic record (§11.70).
- Single owner: Each electronic signature belongs to one individual and is never reused or reassigned (§11.100(a)).
- Validated system: The system is validated for accuracy, reliability, and consistent intended performance (§11.10(a)).
Part 11 puts the obligation on us, not on our software, which is why these controls have to be enforced where the records actually live and not left to convention. A baseline at each project milestone, compared against the one before, shows an auditor the state of the trace as it stood at any prior point.
The saved state is what removes the pre-audit reconstruction: the reviewer reads the baseline instead of waiting for us to rebuild one. Milestone baselines can help us keep trace records readable and findable for years after the work is finished.
How Jama Connect Supports Audit Readiness
A TIM configured to our own relationship rules turns the five review types above into a reporting problem, when they would otherwise be a research one. For the FDA inspection and the ISO 13485 audit, the design history file package and the risk management file come out of an export against live items, without the compilation step. For the notified body, Baseline Compare helps answer the first critical question in a change assessment: what changed since the last submission. Connected traceability can then help teams evaluate the impact on requirements, risk, verification, and supporting evidence.
Baseline Capture takes a point-in-time snapshot of the selected items and their relationships at each milestone, for comparison and audit reference. Review Center electronic signatures then put an approval record with an audit trail behind it, designed to help us meet FDA 21 CFR Part 11 requirements. The three remaining columns are honest work. Stage of Involvement #3 traceability data, ISO 26262 safety case work products and ASPICE bidirectional trace records are all assembled from the same baselines and trace reports. What shape each submission takes is the assessor’s call, not ours.
Put a Retrieval Target on the Calendar
Set a retrieval time we are willing to be measured against, then run a representative request list and find out whether we hit it. Bring that list to our own project data when we start a free 30-day trial, and time the answer.
Frequently Asked Questions About Audit Readiness
What is the difference between audit readiness and inspection readiness?
The two terms get used interchangeably, and for most purposes that is harmless. A practical distinction is that audit readiness covers the processes, documentation, facilities and personnel we use to demonstrate compliance during an internal or external audit, with readiness maintained as part of normal operations. Inspection readiness applies that focus more specifically to an examination by a regulatory authority such as FDA or an EU national competent authority.
How should we test bidirectional traceability during a mock review?
We should define each required upstream and downstream artifact pair in the audit procedure, including what counts as a valid link and what consistency means after either item changes. During a mock review, we sample in both directions: begin with a requirement and reach its source and verification result, then begin with a test result and identify the requirement it verifies. We record missing links, stale relationships, and unresolved suspect links separately so owners can correct the underlying workflow.
Do engineering tools that produce audit evidence need to be qualified or validated?
The answer depends on the framework, the tool’s intended use, and the consequences of a failure. Aerospace programs may evaluate engineering tools under DO-330. In automotive, the corresponding move is a tool-confidence assessment under ISO 26262, with the qualification evidence retained. Medical device programs can size the validation effort to the consequences of the software failing, under a risk-based software assurance approach.
How fast should we be able to produce a traceability matrix for an auditor?
Fast enough that answering is a report we run, not a project we staff, and the only way to find out is to time it. Run mock requests against real project data, tracking simple evidence separately from requests that span multiple systems, with an evidence owner named for each artifact class and an escalation point when retrieval runs past the target we documented. The times tell us whether the problem is our procedures, our ownership or our integrations.
