Regression testing for regulated software

What decides which tests a change reopens?

The written analysis of the change decides, and it is read back later as the justification. IEC 62304 Edition 1.1 carries a subclause titled "Retest after changes" at 5.7.3, and Amendment 1 moved it from classes B and C to classes A, B and C, so software at every class owes an answer to the question.

The test the answer has to survive sits one subclause further on. clause 5.7.4, EVALUATE SOFTWARE SYSTEM testing, retitled by Amendment 1 from "Verify SOFTWARE SYSTEM testing", requires the manufacturer to evaluate the appropriateness of the verification strategies and the test procedures, and then to verify three things: that all software requirements have been tested or otherwise verified, that the traceability between software requirements and tests or other verification is recorded, and that test results meet the required pass/fail criteria. It binds at classes A, B and C. A selection argument that cannot be walked back to those three checks is a scheduling decision with no standing in the file.

Which clauses bind at which class is set out on the IEC 62304 testing requirements page.

Which changes count as changes to a safety-related item?

The classification decides, and it was assigned per software item. Clause 4.3 assigns a safety class to the software system and carries the same criteria down to each software item, and where items are grouped, the group is treated at the classification of the highest-classified item in it unless the manufacturer documents a rationale in the risk management file for a lower one.

The item boundary is your own. Definition 3.25 covers "any identifiable part of a computer program, i.e., source code, object code, control code, control data, or a collection of these items", and its note leaves the manufacturer to provide the granularity of software items and software units. A team that never wrote the decomposition down has no unit in which to ask whether a change reopens anything, and the diff becomes the only available unit.

Two consequences follow for release planning. A one-line change inside a class C item reopens the class C clause set, and the size of the diff carries no weight in that. And the movement runs both ways: 4.3 a) permits a software system initially classified B or C to be assigned a new classification after risk control measures external to the software system are implemented, including a revision of the system architecture containing it. A reclassification of that kind is a change to the file with no commit behind it, and it changes what the next release has to show.

Software used to run production or the quality management system is triaged on a different test. FDA's computer software assurance guidance, issued 3 February 2026, considers a software feature, function or operation to pose a high process risk "when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning a medical device risk". The same guidance states that it "does not provide recommendations for the design and development verification or validation requirements for device software functions". One triage rule stretched over both populations ends with a nonbinding process-risk test applied to a device function. What the guidance does reach, and the record it asks for, is set out on the computer software assurance page.

What does the analysis of a change have to record?

Enough to reconstruct the selection without the author. IEC 62304 names the places the record lands in its clause titles: 6.2 Problem and modification analysis, 6.3 Modification implementation, 7.4 RISK MANAGEMENT of software changes, and 8.2 Change control. The substance of what a change does to the risk position comes from ISO 14971:2019, which IEC 62304 carries as its single normative reference, undated.

Step 4 splits along a line ISO/TR 24971:2020 draws in 4.4.7: "The risk management plan specifies how the two verification activities required per 7.2 of ISO 14971:2019 are carried out." The two are verification that a risk control measure was implemented and verification that it is effective. The guidance places the first inside design review, specification approval or design and development verification, and says the second "can require the collection of clinical data, usability studies, etc., as part of design and development validation". A change can leave an implementation untouched and still put its effectiveness in question.

Step 7 is the one a reviewer reads first. The set you ran is a list of activity. The set you excluded is the claim.

Why does a regression set chosen from code coverage lose the argument?

Because coverage and the standard count in different units. A coverage instrument reports which code a run executed. 5.7.4 asks whether every software requirement has been tested or otherwise verified and whether the traceability between requirements and tests is recorded. A suite can raise its coverage figure and leave a requirement with no test traced to it, and the record that has to be produced is the trace.

The risk side has the same mismatch. ISO/TR 24971:2020, 4.5, states that ISO 14971:2019 "requires traceability for each identified hazard to the risk analysis, risk evaluation, implementation and verification of risk control measures, and the evaluation of residual risk", and that traceability "is a requirement to prove that all identified hazards have been completely addressed in the risk management process". The index there is the hazard. A diff cannot be resolved against a hazard without the item-to-requirement-to-hazard chain in between, and a team that has to build that chain during a release is building it under the release date.

Effectiveness evidence is the part a code-driven selection can never reach, because the evidence it rests on was not produced by executing the changed code in the first place. Where verification of effectiveness rested on a usability study or on clinical data, no instrument watching the build will raise a hand when the change invalidates it. That decision is made by a person reading the risk management file, and the fuller account of the file and what testing feeds into it is on the ISO 14971 page.

What does a reviewer look for when the release notes say "no impact"?

Whether the evidence being relied on still describes the thing being shipped. A claim of no impact points backwards at test results produced for an earlier build, so the reviewer opens those results.

clause 5.7.5, SOFTWARE SYSTEM test record contents was rewritten by Amendment 1, and its stated purpose is to support the repeatability of tests. It lists seven items every system test record has to document, and three of them decide whether an old result can be carried into a new release: the version of the software tested, the relevant hardware and software test configurations, and the relevant test tools. A result whose record leaves any of those three blank cannot be attached to a build, so it cannot stand for a different one.

Questions a reviewer asks of a no-impact release claim under IEC 62304, each matched to the record that answers it.

The reviewer's question	What answers it
Which requirements does this change touch?	The requirements-to-test traceability required by 5.7.4, updated for this release
Which items did it touch, and at what class?	The change analysis, with the class of each item from 4.3
Which risk control measures sit in those items?	Hazard traceability in the risk management file, per ISO/TR 24971:2020, 4.5
Which build produced the evidence you are re-using?	"The version of the software tested" in each 5.7.5 record
Was it produced on this configuration and these tools?	The test configuration and test tool entries in the same record
What did you decide not to re-run?	The exclusion list from the change analysis
Which anomalies are still open at release?	The residual anomaly record under 5.8.2

For software used in production or in the quality management system, FDA names the record shape directly: the intended use of the feature, function or operation; the result of the risk-based analysis; and documentation of the assurance activities, comprising a description of the testing conducted, the issues found, a conclusion statement declaring acceptability including the resolution of any issues, a record of who performed the testing and the date, and review and approval where appropriate. The guidance adds that documentation "need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified". That sentence sizes the record. It does not remove it.

What does the set run against?

A regression suite is executed more often than any other suite you own, so whatever seeds it gets copied and restored for longer than any other data in the project. We do not need production PHI to test. Environments run on synthetic and de-identified data. The rest of the terms, including what is signed and where project data sits, are written out under how we work with protected health information, and the corpus itself is built by the method in testing with synthetic PHI data.

The record side of a release, including how the traceability and the test records are assembled into something an auditor reads unaided, is the work described at validation documentation. Where the selection has to run inside a pipeline on every merge, the constraints that adds are covered at CI/CD for medical device software.

Where does a regression argument fail?

• The selection is defended by the coverage figure of the run, and no document says which tests were excluded or why.
• Retesting after a change is treated as a class B and C activity, although Edition 1.1 binds 5.7.3 at class A as well.
• The change analysis names files instead of software items, so it cannot be joined to the classification or to the risk management file.
• Evidence is re-used from a run whose 5.7.5 record gives a version string that no longer resolves to a build.
• The suite is re-run in full to avoid the analysis, and the traceability required by 5.7.4 is still missing at release.
• A risk control measure was verified for effectiveness by a usability study, and the release that changed the workflow around it reopened only the code tests.
• A dependency upgrade is logged as maintenance and never reaches the anomaly evaluation that clause 7.1 heads.
• The exclusion list exists, and nobody with authority over the risk management file has signed it.

Clause numbers, titles and quotations from IEC 62304 Edition 1.1 and ISO 14971:2019 on this page were read on 2 September 2026 against the IEC and ISO catalogue entries and preview texts, and against ISO/TR 24971:2020. The FDA material comes from Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026.