Traceability

Traceability for FDA submissions: from RTM to submission evidence

How to use live requirements traceability for FDA submissions — what reviewers expect, how baselines and coverage reports fit, and how to avoid the pre-submission matrix scramble.

By traceunified ·

FDA submissions (and the design-control / software documentation that supports them) keep asking the same underlying question: can you show a complete, current thread from need → requirement → design → verification? The requirements traceability matrix is the classic artifact. Submission-ready teams treat it as an output of the system of record, not a project that starts when the submission calendar turns red.

What submission-oriented traceability looks like

  1. Stable IDs for requirements and tests that survive across baselines
  2. Forward and backward links with clear link types (derive, satisfy, verify, mitigate)
  3. Coverage views that expose gaps before quality freezes the package
  4. Named baselines that match the revision you are filing against
  5. Signatures / approvals where your predicate rules and SOPs require them
  6. Exportable reports (Word/PDF/Excel/ReqIF as needed) that match the live data at freeze time

See Design controls evidence package for how this sits inside a broader DHF/DDF story, and IEC 62304 verification coverage for software-heavy devices.

The pre-submission scramble (and how to avoid it)

Typical failure pattern:

  1. Requirements in one tool, tests in another, risk in a third
  2. Two weeks before filing, someone builds an RTM in Excel
  3. Engineering keeps changing; the matrix is wrong the next morning
  4. Quality and RA reconcile IDs by hand under time pressure

Avoidance pattern:

  1. Author and verify on one thread all year (hub vs system of record)
  2. Run coverage continuously; treat gaps as backlog, not a surprise
  3. Freeze a baseline; generate the RTM and verification reports from that baseline
  4. Use suspect links so late changes produce a re-verification list instead of silent drift

Practical freeze checklist

  • Gap report clean (or waivers documented)
  • Baseline name/version recorded in the submission narrative
  • Risk file aligned to the same revision
  • SBOM/cyber documentation included when 524B / cybersecurity applies
  • Export retained with the submission archive
  • Outbound path tested (Export) so you are not stuck

Evaluation questions for ALM buyers

  1. Generate an RTM for last quarter’s release from current tooling in one sitting.
  2. Show the baseline that matches a prior submission and its signature history.
  3. Demonstrate a late requirement change and the suspect worklist it creates.

See traceability work as one connected system.

Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.

Try for free Tour the platform →