What ‘software validated’ has to specify before the claim means anything

“Software validated: yes” is one of the most common single-line answers in a quality system, and one of the least specific. ISO 13485:2016 doesn't ask that question once — it asks it three times, in three clauses scoped to three different kinds of software: the QMS itself under Clause 4.1.6, the software driving production and service provision under Clause 7.5.6, and the software inside the equipment that measures the result under Clause 7.6. All three share the same underlying shape — validate before first use, revalidate after a change, scale the rigor to risk, keep the record — but each runs on its own evidence. A program that validates the QMS platform, calls the requirement satisfied, and never asks the other two clauses' question has covered one-third of what the standard is actually asking for.

The clause most programs actually answer: the system that runs the paperwork

Clause 4.1.6 requires the organization to document procedures for validating the application of computer software used in the quality management system — the electronic document-control platform, the CAPA tracker, the complaint database, or a spreadsheet standing in for any of them. It's the clause most quality teams reach for first, because it's the software they touch daily and the one an auditor is most likely to ask about by name. It also names four things the record has to show, not one: validation before initial use, revalidation as appropriate after a change to the software or its application, an approach and rigor scaled to the risk the software's use carries, and records of the activity. A file with a single “validated at go-live” entry and no trigger tied to later changes has answered the first of those four things and left the rest assumed.

The clause most programs miss: the software running the process

Clause 7.5.6, validation of processes for production and service provision, carries the same software-validation requirement scoped differently — to computer software used in production or service provision, not the QMS. A PLC controlling a sterilization cycle, software driving an automated test fixture, firmware sequencing an assembly step: this is software whose failure changes what actually gets built or done to the device, not what gets recorded about it afterward. It sits inside 7.5.6's broader logic, which requires process validation wherever a process's output can't be fully verified by later monitoring or measurement — the software controlling such a process is validated for the same reason the process itself is, because inspecting the result afterward can't substitute for confidence in how it was made. A validation program built only around 4.1.6 has no separate record for this software at all, which means the process most likely to carry safety consequences if it's wrong is the one least likely to have a dedicated file.

The clause almost nobody thinks to check: the software measuring the outcome

Clause 7.6, control of monitoring and measuring equipment, carries its own version of the same requirement for computer software used in that equipment — the calibration software behind a gauge, the firmware in a test instrument reporting pass or fail, the software translating a sensor's raw signal into the number written on a record. If that software is wrong, every verification and inspection result downstream of it is wrong in a way nothing else in the quality system is positioned to catch, because the measurement itself is the thing being trusted. A software validation matrix that lists the QMS platform and the production line's control software, with no row for the equipment doing the actual measuring, has left out the layer the rest of the system depends on to know whether anything else passed.

None of the three clauses says how — that part is yours to justify

Across all three clauses, ISO 13485 doesn't prescribe a fixed methodology: no mandated IQ/OQ/PQ structure, no required test-case count. What it fixes is the shape of the record — validated before first use, revalidated when the software or its application changes, rigor proportionate to risk, evidence kept. A program that can show which of the three clauses each piece of software falls under, and can point to a record matching that shape for each one, has actually answered whether its software is validated instead of restating the question. It's the same discipline a document-control SOP owes its own retention rules, and the same gap a CAPA tracker's verification-of-effectiveness field exposes when it's left as a checkbox instead of a record: three clauses asking the same shape of question, and a program only gets credit for the ones it can actually show.

A software validation matrix built around this three-clause structure — QMS, production and service provision, and monitoring and measuring equipment, each with its own trigger and record — is previewed in the launch catalog. If your program has found a fourth scope this split is missing, the shelf takes that correction directly.