FDA Computer Software Assurance

CSA focuses effort where software failure could affect product quality

FDA's February 2026 final guidance describes computer software assurance for computers and automated data-processing systems used in medical-device production or the quality management system. It promotes a risk-based approach that establishes confidence in intended use while directing additional rigour to higher-risk functions.

The guidance supports the FDA Quality Management System Regulation, which became effective on 2 February 2026. It is intended to encourage appropriate use of automation and modern assurance methods—not to remove control of software-dependent processes.

Production and QMS software is not device software

CSA applies to software used to support manufacturing or quality activities: examples include manufacturing execution, electronic QMS, laboratory systems, automated inspection, calibration management, electronic records and production equipment software.

Device software performs a function of the medical device and requires product-development evidence. A software tool can fall into both contexts only if it genuinely performs both roles; classify functions carefully rather than applying one label to an entire platform.

Use MTL-309 — FDA Device Software Functions — Premarket Submissions for device-software evidence and MTL-126 — Production-process Validation for the process context.

Define the software's intended use before selecting tests

Describe the business or production process, users, decisions, data, interfaces, records and outputs supported by the software. Identify configured functions, automated actions and any manual checks or downstream controls.

• What quality or production activity does the software perform?
• What data does it receive, transform, store or transmit?
• Which decisions or product dispositions depend on its output?
• What configuration, workflow or electronic-record controls are used?
• What failures could be detected before affecting product or the quality system?
• Who owns the process and who administers the system?

Assurance scope should follow actual intended use. A broad software platform may contain many functions that do not all need the same evidence.

Assess process risk, then scale assurance

Consider whether failure of the software function could create or fail to prevent a quality problem that may foreseeably compromise device safety or quality. Distinguish direct process risk from general business inconvenience and consider existing controls, detectability and the effect of incorrect records or decisions.

Document the rationale. Labelling every function “high risk” defeats prioritisation, while treating all commercial off-the-shelf software as low risk ignores how it is configured and used.

Use supplier evidence intelligently

Supplier documentation, development practices, testing, service history, certifications and release information can support assurance. Evaluate whether the evidence is relevant to the version, configuration and intended use in your process.

The manufacturer remains responsible for establishing confidence. Supplier qualification does not prove every configured workflow works correctly, and repeating all supplier tests may add little value. Focus internal work on configuration, interfaces, data migration, critical functions and process-specific risks.

MTL-125 — Supplier and Outsourced-process Control explains proportionate supplier governance.

Use the assurance method that best reveals meaningful failures

FDA describes scripted and unscripted testing approaches. Unscripted methods can include scenario testing, error guessing and exploratory testing performed by knowledgeable people. Scripted testing may be appropriate where repeatability, objective acceptance criteria or high process risk requires it.

Choose a combination that establishes confidence efficiently. Method choice should follow risk and uncertainty, not an organisational preference for screenshots and step-by-step scripts.

Retain sufficient objective evidence

Records should identify the intended use, risk rationale, functions assessed, methods, personnel, date, version or configuration, results, issues and conclusion. Evidence can be captured digitally and may include automated logs or other reliable records.

FDA does not require a particular document template. Records must nevertheless be attributable, legible, contemporaneous, original or accurate copies and complete enough to reconstruct the assurance decision. Failed checks, deviations and corrective actions should remain visible.

Assurance continues through change and operation

Evaluate supplier releases, configuration changes, workflow updates, infrastructure changes, data migration, integrations, security patches and process changes. Determine what existing evidence remains valid and target regression to affected functions and risks.

Monitor incidents, user problems, access events, data-quality issues and process performance. Feed significant failures into nonconformity, CAPA, supplier and risk processes. Maintain configuration and change records through MTL-127 — Configuration and Change Management.

Process owners and system owners share accountability

The process owner understands the quality or production consequence; the system owner understands configuration, operation, support and technical controls. Quality provides assurance and regulatory interpretation, while IT or suppliers may provide platform expertise.

Define ownership for intended use, risk assessment, assurance, access, changes, incident response, backups, continuity and retirement. Approval should come from people competent to understand both the process and the software evidence.

Example: automated acceptance-test software

Software receives measurements from production equipment, compares them with limits and records a pass or fail result used for release. An incorrect calculation or mismatched limit could allow nonconforming product to proceed.

• Define approved measurement inputs, units, limits, rounding and decision logic.
• Control product-specific configuration and user privileges.
• Challenge boundary values, invalid inputs, communication loss and record integrity.
• Verify interfaces and traceability to calibrated equipment.
• Use automated regression for calculations and targeted scenarios for workflows and recovery.
• Record the released configuration and monitor failures in operation.

The assurance is focused and rigorous because the function directly affects product acceptance; unrelated administrative features need not receive identical testing.

Common misconceptions

Practical assurance checklist

• Is each software function's intended use defined?
• Is the boundary between device software and production or QMS software clear?
• Does the risk analysis address process and product-quality consequences?
• Has relevant supplier evidence been evaluated?
• Are assurance methods suited to risk and uncertainty?
• Are critical configurations, interfaces and data migrations covered?
• Do records identify versions, testers, results and conclusions?
• Are failures and deviations resolved visibly?
• Are changes and operational issues assessed through the lifecycle?
• Are process-owner and system-owner responsibilities explicit?