Obligation to validate computer software used in QMS functions before use and after changes, with documented validation records — 820.70(i)'s core requirement continues under ISO 13485 §4.1.6.
A documented procedure is now required (not just per-application protocols). Validation depth must be explicitly proportionate to risk — requiring a risk assessment to justify the approach chosen for each application.
Auditors will look for the documented procedure, a complete software inventory, risk assessments justifying validation depth for each application, and revalidation records for any software that has changed since initial validation.
Maps to
QMSR / ISO 13485: §820.70(i) Automated processes.
ISO 13485: §4.1.6 Validation of computer software used in the QMS
Requirement text
The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained (see 4.2.5).
Why this clause exists
Computer software used in a quality management system is not passive infrastructure — it is a process control mechanism. When an electronic document management system routes approvals, when a calibration management system triggers maintenance reminders, when a complaint management database generates trend analyses, the software is performing quality system functions that directly affect the integrity of the QMS and the reliability of quality data. If that software is not validated for its intended use, there is no objective evidence that it is performing those functions correctly — and errors in QMS software can systematically corrupt the records and data upon which regulatory decisions are made.
ISO 13485:2016 §4.1.6 imposes three substantive obligations that address this risk. First, a documented procedure for software validation — not ad hoc validation but a systematic, proceduralized approach. Second, validation prior to initial use and as appropriate after changes — closing the gap where software is deployed without validation, or where changes are made to validated software without revalidation. Third, and significantly, the approach and activities must be proportionate to the risk associated with the use of the software. This proportionality principle means that a spreadsheet used to track office supply inventory does not require the same validation rigor as an electronic batch record system whose data forms the basis for product release decisions. Organizations must make an explicit risk-based judgment about validation depth — and that judgment itself must be documented.
FDA enforcement under both Part 820.70(i) and the QMSR has consistently cited failures in this area: software used in production or the quality system without documented validation, changes to validated software deployed without revalidation, and validation records that are incomplete or cannot be retrieved during inspection.
What changed
§820.70(i) — Part 820 (legacy)
"Automated processes. When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented."
§4.1.6 — ISO 13485:2016 (current)
"The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained (see 4.2.5)."
Δ Adds requirement for a documented procedure (vs. an established protocol per application). Introduces explicit proportionality-to-risk principle for validation depth — requires a risk assessment to justify the approach chosen for each application, absent from Part 820.70(i).
Common gaps (what we see in audits)
- No Documented Software Validation Procedure — The organization validates software on a case-by-case basis using individual validation plans or protocols, but has no documented procedure that governs the software validation process itself — including how applications are identified, risk-classified, and validated. ISO 13485 §4.1.6 requires a documented procedure, not just case-by-case validation records.
- Software Inventory Incomplete — Informal Applications Not Captured — The organization maintains validation records for formally deployed enterprise software (e.g., EQMS, ERP) but has not inventoried and validated software applications that were informally adopted for QMS functions — shared spreadsheets used for tracking, cloud-based tools added by individual departments, or legacy applications whose original validation documentation is lost.
- No Risk Assessment to Justify Validation Depth — Software is either fully validated using the same depth regardless of risk, or low-risk applications are not validated at all without a documented risk justification. ISO 13485 §4.1.6 requires that the approach be proportionate to risk — which requires an explicit risk assessment for each application to justify the validation approach chosen.
- Software Changes Not Evaluated for Revalidation Need — When validated software receives vendor updates, configuration changes, or is used in new QMS functions, the changes are deployed without a documented evaluation of whether revalidation is required. ISO 13485 §4.1.6 requires revalidation 'as appropriate' after changes — which implies a documented evaluation for each change.
- Validation Records Not Maintained as Quality Records — Software validation activities were performed but records are retained in IT project folders, email threads, or individual team drives rather than in the controlled quality records system. ISO 13485 §4.1.6 requires records of validation activities to be maintained per §4.2.5.