CSA, Part 11 and QMSR: building a coherent software assurance approach

A coherent assurance argument

Medical device organisations can spend considerable effort proving the same thing more than once. A software function is tested, its approval workflow is tested separately, and another document explains how both sets of evidence meet the quality management system requirements. Each activity has a purpose. The duplication deserves closer examination.

A recent PDA Letter article by NagaPranitha Chodavarapu, Steps to Align FDA CSA With 21 CFR Part 11, ISO 13485, and FDA QMSR, prompted this discussion. Its proposal to coordinate requirements and assurance activities is useful. [1] Taking that idea into practice requires clarity about what each framework does, where it applies, and what evidence remains necessary.

My view is that we should build a coherent assurance argument for each intended use, supported by evidence that can serve several purposes. That argument needs to preserve the differences between functional performance, patient safety, record integrity and regulatory obligations.

One coordinated process can address all of them. One risk label rarely explains all of them.

The discussion below focuses on software used in medical device production and quality management systems, under the US framework.

Four frameworks, different roles

The four names describe different things. CSA is FDA guidance on a risk-based approach to assuring production and QMS software. Part 11 governs applicable electronic records and signatures. ISO 13485 provides QMS requirements. QMSR is the US regulation incorporating ISO 13485:2016 by reference, with FDA-specific provisions. Treating them as four equivalent validation programmes obscures their relationship. [2, 4, 5]

The regulatory dates matter. QMSR became effective on 2 February 2026. FDA’s February 2026 CSA guidance superseded the September 2025 version. References to the former 21 CFR 820.70(i) should therefore be recognised as historical when updating current procedures. [2, 5]

There is a related terminology correction worth making. QMSR did not retain “Design History File” as an additional FDA requirement. FDA removed that terminology while retaining the underlying documentation expectations through the incorporated standard, including the design and development file under clause 7.3.10. A company can retain a familiar internal file name; it needs to demonstrate the required content. [6]

Establish the intended use and scope

Before choosing a testing method, establish what the software actually does. FDA’s CSA guidance covers production and QMS software; it excludes recommendations for design-and-development verification or validation of device software functions. It identifies ISO 13485 clauses 4.1.6, 7.5.6 and 7.6 as relevant software-validation provisions. [3]

A tool supporting manufacture and software performing a device’s medical function can both be important to safety, but they occupy different regulatory roles. Calling either one “supporting software” does not settle its status. The intended use must explain that status before an assurance strategy can be justified.

For a proposed implementation, I would start with a short description covering the function, its users, the decisions it influences, the records it creates, and the consequences of failure. This is more useful than beginning with the vendor’s product category or the organisation’s preferred template.

Assess electronic records explicitly

Part 11 applicability also needs an explicit decision. An electronic record does not become subject to Part 11 merely because it exists. The assessment should identify the applicable underlying FDA recordkeeping requirement and how the electronic record is used. FDA’s scope guidance describes limited enforcement discretion for certain provisions, while maintaining underlying recordkeeping obligations and other controls, including electronic-signature requirements. [4]

The practical implication is straightforward: a process-risk assessment cannot quietly decide that a required record no longer matters.

A worked example: calibration management

Consider a hypothetical system that manages calibration status and prevents production equipment being used after its calibration expires. An effective assessment would examine several failure scenarios together. It would still explain each scenario separately.

These are suggested assessment questions, not a universal list of mandatory tests. The system’s intended use, applicable requirements and existing controls determine what is necessary.

The example shows why integration is valuable. A single scenario can exercise equipment status, user permissions, approval and the resulting record. It also shows why integration needs discipline: a successful expiry check says little about whether an administrator can alter an approval unnoticed.

I would use one coordinated assessment with several explicit dimensions. Where a team assigns an overall risk tier, the reasoning underneath it should remain visible. A reviewer should be able to understand why a particular control needs strong evidence even when another function in the same application needs little additional testing.

Choose testing that answers the questions

Testing should then follow the questions that need answering. FDA allows scripted, unscripted and combined approaches according to risk; the categories are not exclusive to particular risk levels. Its guidance also expects an appropriate record of assurance activities and conclusions. [3]

For the calibration example, a repeatable automated test may efficiently check expiry boundaries. An exploratory session may reveal confusing recovery behaviour after a connection failure. A focused permission test may demonstrate whether an ordinary operator can perform an administrative action. Each method earns its place by producing useful evidence.

“Unscripted” should therefore never become an excuse for an unexplained conclusion. My recommended record would identify the objective, configuration, activities performed, findings, unresolved issues and acceptance decision. An experienced reviewer should be able to follow what was established without having to interview the original tester.

Use supplier evidence with judgement

Supplier evidence can be part of that argument. I would ask what configuration the supplier tested, what the evidence actually covers, and which assumptions differ from our intended use. A certificate or generic validation pack may provide useful context, but a specific claim about our workflow needs relevant support. This is especially important when local permissions, interfaces or custom rules change the behaviour on which we rely.

Six connected decisions

A manageable implementation does not require one enormous document. I would organise the work around six connected decisions:

1. Define the intended use and boundary. Identify the relevant functions, users, interfaces and records.

2. Determine applicability. Record the requirements that apply and the reasoning for exclusions.

3. Assess failure scenarios. Consider process performance, safety, record integrity and authorisation explicitly.

4. Choose controls and evidence. Reuse relevant evidence and identify the gaps requiring additional work.

5. Reach an acceptance decision. Explain results, unresolved issues, limitations and any necessary operating conditions.

6. Maintain the argument through change. Assess whether updates, new interfaces or changed workflows invalidate earlier conclusions.

A concise requirements-to-evidence mapping can connect these decisions. Its purpose is to help someone find the answer, not to repeat the answer in another format.

Keep accountability and assurance current

Ownership also matters. I would give a named process owner responsibility for the intended use and operational acceptance, bring technical specialists into the failure analysis, and involve quality and regulatory colleagues in applicability and evidence expectations. Shared understanding is valuable; clear accountability is equally valuable.

For an existing system, I would begin with one important workflow. Read its assessment and evidence together. Identify duplicated checks, missing scenarios and conclusions that depend on undocumented assumptions. Improve that package before rewriting the entire procedure set. This produces a concrete example that colleagues can challenge and learn from.

The measure of success is whether the organisation can explain, convincingly, why the software is suitable for its intended use and how that conclusion remains valid. Fewer documents may follow. The more valuable result is a clear connection between the requirement, the potential failure, the control and the evidence.

References and context

Regulatory sources checked on 26 September 2026. The implementation approach and hypothetical example above are the author’s recommendations; they are not additional FDA requirements.

1. NagaPranitha Chodavarapu, Steps to Align FDA CSA With 21 CFR Part 11, ISO 13485, and FDA QMSR, PDA Letter, 22 September 2026. Inspiration for this discussion.

2. FDA, Computer Software Assurance for Production and Quality Management System Software, February 2026. Current guidance and supersession notice.

3. FDA, CSA guidance — full text, particularly Sections III, V.A and V.B. Scope, assurance methods, evidence and electronic records.

4. FDA, Part 11, Electronic Records; Electronic Signatures — Scope and Application, September 2003, particularly Section III.

5. FDA, Quality Management System Regulation — Frequently Asked Questions, updated 2 February 2026.

6. FDA, Medical Devices; Quality System Regulation Amendments, final rule, 89 FR 7496, particularly the response to Comment 31 on record terminology.