ISO 13485 software: what the standard actually asks your tools to do

"ISO 13485 software" is a slightly odd phrase when you think about it, because ISO 13485 does not mention software vendors, does not certify them, and does not require you to use one. You could run a compliant quality management system on paper. People did, for decades, and some still do.

What the standard does is describe records you must be able to produce and processes you must be able to demonstrate. Software is simply the most practical way for a small team to produce those records without a full-time quality department. Which means the useful question is not "which tool is ISO 13485 software" -- most of them will say they are -- but "can this tool produce the specific things clause X asks for, in a form an auditor will accept".

So here is that list. This is ISO 13485:2016, the current edition, and we have kept the clause numbers so you can check us against the actual text rather than taking our word for it.

If you are selling into the US, this list now does double duty. Since February 2026 the FDA's Quality Management System Regulation has amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference, so a tool that can produce what follows is largely answering both frameworks at once rather than two separate ones.

The clauses that translate directly into tooling

4.1.6, validation of QMS software. Start here, because it is the one people miss entirely. If you use computer software as part of your quality system, the standard asks you to validate it for its intended use, proportionate to risk. This applies to the QMS tool itself. When you evaluate a vendor, ask what they provide to support your validation. A vendor who has thought about this will have an answer ready. A vendor who looks surprised by the question is telling you something.

4.2.4, control of documents. Documents reviewed and approved before issue, changes reviewed and approved, current versions available where they are used, obsolete versions prevented from unintended use, and a way to identify changes and current revision status. In tooling terms: versioning, an approval workflow, a visible status on every document, and history you cannot quietly overwrite.

4.2.5, control of records. Records legible, readily identifiable, and retrievable, with defined controls for identification, storage, security and integrity, retrieval, retention time, and disposition. The sentence to hold onto is the standard's own: changes to a record shall remain identifiable. It does not forbid a record being changed. It requires that the change be visible. So if a user can edit a completed record without leaving a trace, the tool is not doing this clause. Ask how the audit trail works and whether administrators can edit it.

7.3, design and development. The largest block, and for software teams the one that carries most of the weight. Planning (7.3.2), inputs (7.3.3), outputs (7.3.4), review (7.3.5), verification (7.3.6), validation (7.3.7), transfer (7.3.8), change control (7.3.9), and design and development files (7.3.10).

The tooling question here is not whether the system can store these. It is whether it maintains the links between them as things change. When a requirement is revised, does its verification evidence get flagged as potentially stale, or does it silently continue to look verified? That single behaviour separates a system that keeps you honest from a filing cabinet with a search box.

7.3.10, the design and development file. Worth pulling out separately. This should be a view assembled from records you already hold, not a document somebody writes at the end from memory. If your tool cannot produce it on demand, you will be producing it manually, in a hurry, at the worst possible moment.

7.4, purchasing. Supplier evaluation criteria, records of evaluation, and defined purchasing information. For a software-only product this is mostly your third-party dependencies, hosting, and any external service that touches user data.

7.5.9, traceability. The requirement to trace, with the extent defined and recorded. In practice: a live matrix linking user needs to requirements to verifications to releases, generated from your actual records rather than maintained by hand.

8.2.2, complaint handling. A documented procedure for receiving, reviewing, and evaluating complaints, with records of the investigation and of any decision not to investigate, including the rationale. That last part catches people out. Deciding a complaint needs no action is fine. Not recording why you decided that is not.

8.2.4, internal audit. Planned audits at defined intervals, with records of the audit, the findings, and the corrections. You audit yourself against the standard, before someone else does.

8.3, control of nonconforming product. Identification, documentation, segregation where relevant, evaluation, and disposition. For software this is your defect and known-issue handling, including what shipped with a known defect and who accepted that.

8.5.2 and 8.5.3, corrective and preventive action. Reviewing nonconformities, determining causes, evaluating whether action is needed, implementing it, and verifying that it worked. That final step, verifying effectiveness, is the one that most homegrown systems skip. A CAPA that was closed without anyone checking whether the fix held is not a closed CAPA.

6.2, competence and training. Records of education, training, skills, and experience, plus evidence that training was effective. Small, but it needs to exist and be current.

5.6, management review. Recorded reviews at planned intervals with defined inputs and outputs and records of the decisions taken.

The evaluation checklist this gives you

Take that into any vendor conversation and it becomes a short set of concrete asks. We would put these to any tool, including ours.

1. Show me a document's full revision history, including who approved each version and when.
2. Change an approved requirement in front of me. What happens to its existing verification evidence?
3. Generate a traceability matrix right now, from live data, without preparation.
4. Show me a completed record and then try to edit it. What does the audit trail capture?
5. Produce the design history for a product as it stands today.
6. Show me a CAPA with its effectiveness check recorded.
7. What do you give me to support validation under 4.1.6?
8. If we leave in two years, what do our records look like on the way out?

Every one of those is answerable in a live demo, and demos are the right place to ask them. Any vendor should be glad to walk you through it, and if you are early in this and would rather be shown than read a feature grid, that is a completely sensible way to evaluate. Ask for the demo.

What none of it requires

Not a single clause above requires an expensive platform, an annual contract, or a consultant to configure it. The standard is specific about outcomes and almost entirely silent about method, which is deliberate. It was written to apply to a two-person software team and a thousand-person manufacturer at the same time.

That silence is good news for you. It means the honest way to shop for ISO 13485 software is to ignore the compliance badges on the homepage and test the eight things above against the tool. The ones that pass are doing the work. The ones that fail are storing your documents, which you could do anyway.

If you are still working out whether you need ISO 13485 at all, we covered that separately, and what it realistically costs a software startup is worth reading before anyone quotes you a number.

Book a demo -- a lean QMS built for small teams.