Computer Software Assurance for a Polarion Deployment

What Computer Software Assurance Is

Computer software assurance (CSA) is FDA's risk-based approach to establishing confidence that software used in medical device production or in the quality system is fit for its intended use. It covers computers and automated data processing systems used as part of production or the quality system, including software used directly in those processes and software that supports them. It does not address software that is itself part of a medical device.

FDA published a draft guidance in September 2022 and issued the final guidance, Computer Software Assurance for Production and Quality System Software, on September 24, 2025. In February 2026 FDA issued a revised version titled Computer Software Assurance for Production and Quality Management System Software, aligning its terminology with the Quality Management System Regulation (QMSR), which took effect on February 2, 2026. The guidance supersedes Section 6 of FDA's 2002 General Principles of Software Validation; the rest of that document still applies. Read the current text on FDA's guidance page.

For a medical device manufacturer, Polarion usually falls within scope. When it holds design inputs, design outputs, verification records, risk analysis links and approvals, it is quality management system software, and the requirement to validate it for its intended use applies.

The Four Steps of the CSA Approach

The guidance organises assurance into four activities. They are easiest to apply feature by feature, so the effort follows the risk of each function.

1. Identify the intended use. State what each feature, function or operation is used for in your processes. The same software can carry very different risk depending on how you use it.
2. Determine the risk-based approach. Decide whether a failure of the function to perform as intended could lead to a quality problem that foreseeably compromises safety. The guidance calls such functions high process risk; everything else is not high process risk.
3. Determine the appropriate assurance activities. Choose testing and other activities in proportion to that risk, and take credit for work the supplier has already done where it is relevant and documented.
4. Establish the appropriate record. Keep a record that shows the intended use, the risk determination, what was done, what was found and the conclusion. Detail scales with risk.

Critical thinking runs through all four steps. The goal is a documented, reasoned decision about how much assurance each function needs, made by people who understand both the process and the software.

Scripted, Unscripted and Supplier-Based Assurance

CSA widens the set of acceptable assurance activities and links each to risk.

• Scripted testing follows written procedures with defined steps and expected results. It suits high process risk functions, either fully scripted or as a hybrid that combines scripted checks with unscripted exploration around them.
• Unscripted testing includes ad-hoc testing, error-guessing and exploratory testing. A tester with knowledge of the process exercises the function, looks for failure modes, and records what was tested and what was found. It suits functions that are not high process risk.
• Supplier activities and documentation can reduce what you repeat. A supplier's development and testing practices, release notes and product documentation, and for hosted deployments the provider's independent assurance reports, can support your assurance case when you have assessed the supplier and the evidence is relevant to your intended use.

Configuration you build on top of the vendor's product, such as workflows, permissions, custom fields, scripts and reports, is yours. Supplier evidence covers the platform; your own assurance covers how you configured and extended it.

How CSA Compares with Traditional CSV Practice

Computer system validation (CSV) as practised under the 2002 guidance often settled into a uniform pattern: detailed scripted protocols for most functions, step-by-step expected results, and screenshots as objective evidence. Documentation effort tended to scale with the number of functions in the system, whatever the risk of each one. For configurable platforms such as Polarion, that meant re-executing large protocols after configuration changes that had little to do with product quality.

CSA keeps the requirement to validate software for its intended use. What changes is how effort is distributed and documented:

• Risk is assessed per feature, function or operation, with the reasoning recorded.
• Scripted testing is concentrated on high process risk functions.
• Unscripted testing is an accepted activity for lower-risk functions, recorded in summary form.
• Supplier evidence and the manufacturer's other quality activities can be credited.
• Records focus on the information that demonstrates assurance; screenshots are used where they add evidence.

For a team maintaining a Polarion deployment through regular configuration changes and upgrades, the practical effect is a smaller regression set that is aimed at the functions that matter, and a clearer argument for an auditor about why each test exists.

Classifying Polarion Features by Risk

Start with an inventory of what your deployment actually uses: workflows, electronic signatures, permissions, custom fields, scripts, reports, baselines, exports and integrations. Then classify each against its intended use. The classes below are typical for a medical device design control deployment; your own intended use decides the result.

Classification follows use. A dashboard is lower risk while it informs a stand-up meeting; when a release review relies on its coverage figures, it becomes part of a quality decision and moves up. Record that reasoning, because the auditor's first question about a lightly tested function is usually why it was judged lower risk.

Custom code deserves particular attention. Workflow scripts and save hooks run on controlled records and are written by your team or your partner, so no supplier evidence covers them. Our guide to Polarion workflow scripts and save hooks describes the version control and regression testing that make them manageable.

What Records to Keep

The guidance describes a record that captures the intended use, the risk determination, a description of the assurance activities performed, any issues found and how they were dispositioned, and a conclusion on whether the results are acceptable. For a Polarion deployment we keep:

• A feature inventory listing each configured feature, script and report with its intended use.
• A risk assessment per item, with the rationale for the class assigned.
• Scripted test protocols and results for higher-risk items, linked to the requirements they verify.
• Unscripted test summaries for lower-risk items: what was exercised, by whom, when, what was found, and the conclusion.
• Supplier assessment and evidence referenced where you take credit for it.
• Issue records with their resolution or justification.
• Change records for each configuration change and upgrade, with the risk-based decision on what to retest.

Polarion can hold most of this itself: requirements, risk items, test cases and test runs as linked work items, with baselines marking each validated state.

Part 11 Still Applies

CSA changes how you plan and document assurance. It leaves 21 CFR Part 11 in place for electronic records and electronic signatures that you use to meet predicate-rule requirements. FDA's 2003 guidance Part 11, Electronic Records; Electronic Signatures — Scope and Application describes where FDA intends to exercise enforcement discretion for certain Part 11 requirements; that discretion does not remove the separate requirement to validate software used in production or the quality system.

In a Polarion deployment, the Part 11 controls map to features that belong in the higher-risk class:

• Audit trails (11.10(e)): history of changes to controlled work items and documents, retained and available for review.
• Access control (11.10(d)): permissions limiting who can create, modify and approve controlled records.
• Signature manifestation (11.50): signed records showing the signer's name, the date and time, and the meaning of the signature.
• Signature and record linking (11.70): signatures bound to the records they apply to.
• Unique identification (11.100 and 11.300): individual user accounts and controls over identification codes and passwords.

Polarion provides the platform capabilities, such as revision history and signatures on workflow transitions; your configuration decides whether they are applied to the right records, with the right meanings and the right people. That configuration is what your assurance activities need to cover.

Getting Started with CSA on Polarion

Teams with an existing CSV package do not need to start again. A practical sequence is to build the feature inventory, classify each item, map existing protocols to the higher-risk items, and retire or summarise tests that cover lower-risk items, recording the reasoning as you go. The next configuration change or upgrade then runs on the new, risk-based regression set.

Our Part 11 and validation service covers risk assessment, protocols and Part 11 configuration for Polarion, and our work with medical device teams covers design controls, risk management and design history file structure in the same platform.