What an auditor actually looks for: the SaMD compliance checklist

If you have never been through a medical device audit before, the uncertainty is the worst part. Not the audit itself -- the not knowing exactly what they are going to ask for, and whether what you have will be good enough.

The answer is that auditors are fairly predictable. Whether it is a notified body reviewing your EU MDR technical file, an FDA inspector, or a large enterprise customer doing pre-purchase due diligence, they are looking for the same things. The standards they follow -- ISO 13485, IEC 62304, ISO 14971 -- describe a quality system in some detail, and the people trained to audit against them have a checklist of their own.

This post is a practical version of that checklist. Not the regulatory text, which you can read yourself. A plain-English description of what each item looks like in practice, what the auditor is trying to establish, and the most common reasons teams fall short.

Work through it before your first audit or customer review. If you can answer yes to each item with evidence in hand, you are in good shape.

1. Software safety classification

What they want to see: A declared IEC 62304 safety class for your software -- Class A, B, or C -- based on the severity of harm that could result if the software fails. The classification should be documented and approved, not just an internal assumption.

Why it matters: The safety class determines the entire scope of your compliance obligations under IEC 62304. Class A requires the least documentation; Class C requires the most rigorous development lifecycle evidence. An auditor will establish the classification early because everything else on this list is interpreted in that context. If your class is wrong -- or undeclared -- the rest of your documentation may be assessed against the wrong bar.

What trips teams up: Teams that have done the analysis informally but never recorded it. "We think we are Class A" is not the same as a documented classification rationale signed off by someone with authority.

2. Documented requirements

What they want to see: A list of what your software is supposed to do, written down, version-controlled, and approved by someone with authority to approve it.

Why it matters: IEC 62304 requires that software requirements are established before development and that they are traceable through to verification. Requirements are the foundation of the whole chain. Without them, you have no baseline to verify against and no way to demonstrate that what you built is what you intended to build.

What trips teams up: Requirements stored informally in Jira, Confluence, or user stories that were never formally approved. An auditor wants to see an approval record -- who signed off, when, with what authority. Jira tickets rarely carry that.

QualiHQ stores requirements with versioning, approval records, and display IDs (REQ-001, REQ-002) out of the box. If you are not sure what a compliant requirement register looks like, our QMS guide covers the structure in plain language.

3. Traceability from requirement to test evidence

What they want to see: For every requirement, a clear path to the verification method that covers it, and then to the test evidence showing it passed.

Why it matters: ISO 13485 requires that your product performs as intended. IEC 62304 requires that you verify it. Neither standard accepts "we tested it, trust us." The chain -- requirement, verification method, test result -- is what makes the claim credible.

What trips teams up: Teams that test thoroughly but do not link the tests back to specific requirements. If your test suite passes and your product works, that is excellent. If an auditor asks which test case covers requirement REQ-007 and you cannot answer quickly, it looks like a gap even when it isn't one.

4. Risk analysis

What they want to see: A structured record identifying the hazards your software could create, the probability and severity of harm if each hazard materialises, the controls you have put in place to reduce risk, and the residual risk after those controls are applied.

Why it matters: ISO 14971 is the risk management standard for medical devices and is expected by both the FDA and EU notified bodies. The risk analysis is not a one-off exercise -- it is a living document that should be updated whenever the product changes significantly.

What trips teams up: A risk analysis written at launch and never touched again. Auditors will ask whether it was reviewed before the most recent release and whether the risk items were assessed after any significant changes. A dated, static document with no review records is a finding.

QualiHQ maintains a living risk register per product and requires a formal risk review -- with electronic sign-off -- before any release can be approved. For a broader look at how ISO 14971 fits into your regulatory pathway, the SaMD compliance guide covers it alongside FDA and EU MDR requirements.

5. Release records with approval evidence

What they want to see: For each version of your software, a record of what changed, who reviewed and approved the release, when, and that the approval gate was meaningful -- not just a checkbox.

Why it matters: IEC 62304 requires configuration management and release control. ISO 13485 requires that changes are reviewed and approved. An auditor wants to see that someone with appropriate authority confirmed, for each release, that verification was complete, risk had been reviewed, and the release was fit to go out.

What trips teams up: Releases approved by the person who wrote the code, with no evidence that a checklist was run or that blocking conditions -- incomplete verifications, unreviewed risk items -- were flagged before approval. A strong release record includes electronic sign-off, a timestamp, and evidence that the gate was enforced, not bypassed.

6. Design History File

What they want to see: A structured package, per release, containing the complete design control record: requirements in scope, verification evidence, risk assessment sign-off, open issues, approved SOPs at the time of release, and a completeness summary.

Why it matters: The DHF is what a notified body or FDA reviewer asks to see during an audit for a specific version. It proves the full design control chain existed and was followed for that release. Without a coherent DHF, the rest of your documentation -- however thorough -- is hard to navigate under audit pressure.

What trips teams up: Teams with good underlying records but no assembled view. The evidence exists in five different places and assembling it takes days. An auditor does not wait days.

QualiHQ generates the DHF automatically from your existing records -- requirements, verifications, risk sign-off, SOUP review, and documents are assembled into a structured, section-navigable view directly from each release. No manual assembly required.

7. SOUP and dependency review

What they want to see: A list of every third-party software component your product depends on -- open source libraries, SDKs, packages -- with the version in use, the risk level assigned, and evidence that the list was reviewed before each release.

Why it matters: IEC 62304 §8.1 requires that you identify and control software of unknown provenance. In practice this means your npm, pip, or go dependencies. If a library has a known vulnerability and you did not document that you assessed it, that is a finding.

What trips teams up: No SOUP inventory at all, or an inventory that exists but was not updated before the most recent release. The key evidence is a timestamped review record tied to a specific release -- not just a list.

8. Training records

What they want to see: Evidence that everyone working on or with your product has read and acknowledged the relevant procedures. For a software team this typically means SOPs covering change control, non-conformance handling, and any role-specific procedures.

Why it matters: ISO 13485 §6.2 requires that personnel are competent on the basis of appropriate education, training, skills, and experience. Training records are one of the first things an auditor asks for -- they are easy to verify and an obvious indicator of whether a QMS is genuinely being followed.

What trips teams up: SOPs that were written and approved but never formally distributed or acknowledged by the team. Having the document is not enough. The record of who read it and when is what satisfies the requirement.

QualiHQ assigns training automatically when a document is approved and tracks completion per team member. The Team page gives admins a live view of who is outstanding across every required document. If you want to understand what SOPs you actually need, our QMS guide lists the ones that come up most often in audits.

9. Non-conformances, bugs, and CAPA

What they want to see: A process for logging, investigating, and resolving issues when things go wrong -- whether that is a bug found in testing, a complaint from a user, or a deviation from a procedure. CAPAs (Corrective and Preventive Actions) document what was done to fix the root cause, not just the symptom.

Why it matters: ISO 13485 §8.5 requires corrective and preventive action processes. Auditors are not looking for a clean record -- they understand that issues arise. They are looking for evidence that you identified them, investigated root causes, and took action. A QMS with no CAPAs is actually a flag: it suggests issues are not being captured, not that they are not happening.

What trips teams up: Bug trackers that document fixes but not root cause analysis or preventive actions. A CAPA record needs more than "fixed the bug." It needs to show why the bug reached production and what changed to prevent recurrence.

10. Document control

What they want to see: Approved, version-controlled procedures covering the key processes in your QMS -- at minimum, change control, non-conformance and CAPA, document control itself, and a procedure for post-market surveillance. Documents should have approval records, revision histories, and a process for retiring outdated versions.

Why it matters: ISO 13485 §4.2 sets out the document control requirements. SOPs are the evidence that your quality processes are intentional and repeatable, not improvised. The approval record on a SOP is as important as its content.

What trips teams up: Documents that exist but have never been formally approved. A draft SOP sitting in a shared folder does not satisfy the requirement. Approval -- with a named approver and a date -- is what makes it a controlled document.

11. Post-market surveillance

What they want to see: A documented process for monitoring your software after release -- collecting feedback, tracking complaints, reviewing reported issues, and feeding that data back into your risk analysis and improvement process.

Why it matters: ISO 13485 §8.2.1 and EU MDR Article 83 both require active post-market surveillance. For a software team this does not mean a complex monitoring infrastructure -- it means a documented procedure describing how you collect and review feedback, and periodic review records showing you followed it.

What trips teams up: No documented process, or a process document that was never approved or reviewed. The evidence an auditor wants is a PMS SOP plus at least one record showing it has been followed -- a review meeting, a summary of the monitoring data, a note that no significant events occurred in the period.

QualiHQ generates a post-market surveillance SOP automatically when you create your account, with placeholders for your specific monitoring tools, review cadence, and alert thresholds. It surfaces in your onboarding checklist for approval so it does not get forgotten. For more on what compliance actually requires day-to-day, this post on what compliance means in practice is a good grounding.

The honest summary

None of the items on this eleven-point list require a compliance consultant. They require discipline, documentation, and tooling that makes the documentation a natural output of how you work rather than a separate effort.

Most software teams that struggle in audits are not doing bad work. They are doing good work badly documented. The requirements exist somewhere in their heads or their backlog. The risks were considered but never written down. The release was tested carefully but the evidence was not captured in a way that maps back to specific requirements.

The checklist above is not a high bar. It is the table stakes for operating as a medical device company. Getting there before your first audit -- before the notified body submission, before the enterprise customer due diligence call -- means you control the timeline. Getting there after is more expensive, more stressful, and usually means rewriting records that should have been created in real time.

QualiHQ handles the evidence layer for all eleven items on this list. Start free and see how much of this checklist you can tick off before the end of the week.