Practical Auditing for Medical-device Development

Start with the decision the audit must support

A useful audit provides evidence about whether agreed requirements are met and whether the processes achieve their intended results. It can also reveal opportunities to improve implementation. A well-written procedure is a starting point; the audit examines what happens in real work.

An audit is a structured sample, with a defined objective, scope and criteria. It is not complete product verification, a design approval or a guarantee that every problem has been found. State the limits of the sample so that management can use the conclusions responsibly.

• Internal audit: examine your organisation’s own processes and their interfaces.
• Supplier audit: examine the activities, outputs and controls entrusted to an external organisation, including the manufacturer–supplier interface.
• Third-party audit: an independent body assesses against a defined certification or audit scheme. Its rules and grading may differ from an internal audit.

A process audit can follow development across several departments. A project-focused audit can follow one product through several processes. Choose the approach that answers the objective, and identify what remains outside scope.

Separate audit criteria from auditing guidance

Criteria are the requirements against which evidence is evaluated: applicable regulations, adopted standards, approved procedures, project plans, specifications and contractual commitments. Identify the actual documents and revisions before the audit. Do not raise a nonconformity against a personal preference.

ISO 19011:2026 provides guidance on managing audit programmes, conducting audits and auditor competence. It is guidance for the audit method, rather than a medical-device QMS certification standard. ISO lists the 2026 edition as replacing the 2018 edition.

ISO 13485:2016 provides medical-device quality-management-system requirements. For development work, build the criteria from the applicable QMS and the organisation’s controlled implementation. Software, risk management and cybersecurity processes may add relevant criteria, depending on the activities and commitments in scope.

Record which editions and market requirements apply to the audit. A new publication does not, by itself, settle a product’s contractual or regulatory transition obligations.

Make auditing a managed activity

The audit programme connects individual audits to organisational priorities. Consider process importance, changes, previous findings, complaints, supplier performance and emerging risks when deciding coverage, frequency and resources. Revisit the programme when significant changes or problems occur.

Assign auditors with sufficient audit skills and technical understanding for the scope. A general QMS auditor may need a software or cybersecurity specialist to evaluate a complex evidence trail. Technical expertise alone does not establish competence in interviewing, sampling or writing findings.

Protect objectivity: avoid auditing your own work, declare conflicts and use an independent reviewer or another auditor where needed. Agree confidentiality, secure evidence access and retention arrangements. For remote audits, test access to repositories, records and participants before the session; record limitations if direct observation is unavailable.

Define who receives the report, who owns corrective actions, who verifies closure and how overdue or serious issues are escalated. Programme reviews should consider recurring findings, coverage gaps and effectiveness of follow-up, rather than only counting completed audits.

Spend time where failure would matter most

Start with the product, process and recent changes. Ask which failures could undermine safety, performance, cybersecurity, regulatory evidence or reliable supply. Then select evidence trails likely to reveal whether the relevant controls work.

• A recent safety-related software change tests risk assessment, requirements, verification and release control together.
• A recurring complaint tests investigation, field impact, corrective action and feedback into development.
• A new critical supplier tests selection, responsibilities, acceptance evidence and ongoing oversight.
• A release with deferred defects tests anomaly evaluation, approval authority and communication.

Request a concise preparation pack: scope and organisation, process map, relevant procedures, one recent release, change and defect lists, earlier findings and relevant performance trends. Select your own samples from these lists; do not rely only on a polished example chosen by the auditee.

Document the sample rationale, the population it comes from and what you intend to establish. A targeted sample is not a statistical estimate of the organisation’s defect rate. Expand it when contradictions or repeated weaknesses appear, and explain any resulting changes to the plan.

Follow a real item through the process

Begin with an open question: “Please show me how this change reached release.” Ask the person who performed the work to explain the sequence, then examine the records. Compare the procedure, the explanation and the actual evidence.

1. Need and requirement: what prompted the work, who approved it, and what acceptance criteria were defined?
2. Risk and interfaces: which hazards, security threats, system interfaces or user tasks could be affected?
3. Implementation: which design, code or configuration changed, and how was it reviewed?
4. Verification: which tests or analyses addressed the change, on which baseline, with what results?
5. Release: who accepted unresolved issues, confirmed completion and authorised delivery?
6. Feedback: how were field results, supplier issues or later defects monitored?

Use focused follow-ups: “Which revision did you test?”, “Show me the failed result and its disposition”, “How did you decide what regression testing was needed?” and “What happens when the usual approver is absent?”

Record identifiers, revisions, dates, sample sizes and the relevant observation. Separate what you saw from what someone told you and from your own inference. Interview statements are useful evidence, but important claims should be corroborated where practicable. Keep enough detail for the finding to be understood without unnecessarily copying personal data, source code or confidential product information.

Audit the work and the handover

For outsourced development, establish which activities the supplier performs, whose procedures apply and how the manufacturer accepts the results. A supplier certificate may support an assessment, but its scope and validity do not demonstrate that the particular project’s deliverables are adequate.

• Who owns requirements, architecture, software safety classification and risk decisions?
• Which reviews, test records, anomaly lists, configuration information and release records must be delivered?
• How are subcontractors, third-party software and development tools controlled?
• How are changes, vulnerabilities, incidents and support discontinuation communicated?
• Can the manufacturer obtain the evidence and support needed throughout the product lifecycle?

Sample both sides of the interface: a supplier delivery record and the manufacturer’s acceptance decision. A complete supplier test report may still leave an integration or intended-use validation obligation with the manufacturer. Conversely, a contract that assigns a task to the supplier is not evidence that the task was completed.

Where a supplier has no certified QMS, assess its actual capability and the agreed controls. Identify proportionate additional oversight or support through the manufacturer’s supplier-control process; do not assume either automatic rejection or automatic acceptance.

Make the requirement, evidence and gap explicit

A defensible nonconformity connects an applicable requirement to objective evidence showing that it was not fulfilled. Avoid vague labels such as “poor documentation” or “testing inadequate”. Explain precisely what is missing or inconsistent and the extent observed.

Discuss findings with the auditee to check factual accuracy and resolve misunderstandings. Record unresolved differences. Do not negotiate away evidence. If a potential safety or security issue requires urgent assessment, escalate through the relevant process immediately instead of waiting for the final report.

Worked example: a connected-device software supplier

Fictional scenario: a supplier develops a mobile application that displays injection records from a connected device. The manufacturer owns the system requirements, overall risk management and final release decision. Supplier release 2.4 changes how duplicate records are handled after reconnection. All identifiers below are illustrative.

Objective: determine whether the sampled change was assessed, verified and handed over with sufficient evidence for manufacturer acceptance. Scope: change CR-042, supplier release 2.4 and the associated manufacturer handover. Exclude a full QMS assessment and penetration testing.

Criteria: the agreed quality agreement, approved project plan, change-control procedure SW-P-07 revision 3, release procedure REL-04 revision 2 and the applicable approved requirements. The example findings use these fictional procedures, not invented clauses of a standard.

An eight-hour audit allocation

• 1 hour: preparation, document review and sample selection.
• 30 minutes: opening discussion, responsibilities and scope confirmation.
• 2 hours: trace CR-042 through requirements, risk assessment, code review and verification.
• 1 hour: inspect build identification, unresolved anomalies and release authorisation.
• 1 hour: examine supplier handover, manufacturer acceptance and a previous corrective action.
• 30 minutes: consolidate findings and confirm factual details.
• 30 minutes: closing discussion.
• 1 hour 30 minutes: report and agreed action tracking.

This allocation totals eight hours and includes preparation and reporting. It is a focused audit, not a claim that a complete supplier assessment can always be performed in one day. Adjust the scope when records, participants or technical complexity require more time.

Worked example: what the evidence shows

Requirement REQ-118 requires the application to avoid duplicate injection records after reconnection. Risk control RC-09 addresses misleading treatment history. CR-042 changes record matching; test protocol TP-042 includes interrupted transfer, repeated reconnection and two genuinely separate injections with similar timestamps.

The auditor examines code-review record REV-042, test report TR-042, the delivered binary manifest and release approval RA-24. The supplier explains that all tests passed. The report, however, identifies build 2.4.0-rc2, while the delivery manifest identifies build 2.4.0. A later matching-logic change is recorded between those builds.

Why this is defensible: the finding names the requirement, records, change and missing evidence. It does not claim that the application necessarily produces duplicate records. That product impact requires assessment.

Next actions: the responsible teams assess affected deliveries and potential product impact promptly, establish appropriate containment, complete the required verification or justified evidence assessment and investigate why release controls failed. The auditor records the finding and escalation; the product and quality authorities own release and field-action decisions.

Example strength: the build manifest makes the baseline mismatch visible and enables identification of affected deliveries. Example improvement: once conformity is established, linking release manifests directly to approved evidence could reduce manual reconciliation. Automation would be an option, not the audit criterion.

Close the loop on effectiveness

The report should state the objective, scope, criteria, method, participants, dates, samples and limitations. Summarise effective practices, findings and conclusions, and distinguish observed facts from unresolved questions. Provide action owners, due dates and escalation arrangements through the organisation’s established process.

A suitable conclusion for the worked example is: “The sampled change had documented requirements, code review and verification activities. The release evidence did not establish coverage of the delivered matching-logic baseline. Release control effectiveness could therefore not be confirmed for this sample. Product impact and corrective action require follow-up.” Avoid extrapolating one sample to every release without supporting evidence.

• Correction: resolve the specific detected issue, including assessing affected product and evidence.
• Cause analysis: determine why the process allowed the issue and whether similar releases are affected.
• Corrective action: change the process or controls to address the cause and prevent recurrence.
• Effectiveness verification: examine later evidence to establish whether the action worked.

For the baseline mismatch, updating a procedure and recording training may demonstrate implementation of an action. Effectiveness could be checked by sampling subsequent releases and confirming that every post-test change has an approved evidence disposition before authorisation. Define the period, sample rationale, acceptance criteria and reviewer in advance. Do not close solely because the action owner says “done”.

Feed recurring weaknesses and overdue actions into management review, supplier monitoring and the future audit programme as appropriate.

Practise selecting evidence and writing a finding

Scenario: a supplier’s approved procedure requires a documented impact assessment for every software change before implementation. From 12 recent changes, you select three affecting alarm presentation. Two have approved assessments. CH-19 changes alarm priority colours but has no assessment record. The engineer says it was “only cosmetic”. Functional tests passed, and the release is already in customer use.

1. Which additional records and people would you sample, and why?
2. Write a finding using the criterion, evidence and gap.
3. Separate the established process failure from the product-risk questions.
4. Propose a proportionate follow-up and an effectiveness check.

Keep this output: a one-page audit plan, evidence log, one finding and a proposed effectiveness check. Compare these with your organisation’s approved audit and corrective-action processes.

Check your audit is useful and defensible

• The objective, scope and criteria are clear and agreed.
• The auditor has suitable competence and objectivity.
• Sampling follows important risks, changes and prior issues.
• Evidence identifies the actual records, revisions and product baselines examined.
• Conclusions distinguish requirements, facts, inference and unresolved questions.
• Findings describe a demonstrated gap without prescribing an unnecessary solution.
• Significant product or security concerns are escalated promptly.
• The report records limitations and avoids claims beyond the sample.
• Action owners, deadlines and effectiveness checks are defined.
• Lessons influence supplier oversight and the next audit programme.

Authoritative references and related learning

References checked on 15 October 2026. Consult controlled copies and the requirements applicable to your organisation and audit scope. The plans, scenarios and sample findings in this module are original teaching examples.

• ISO 19011:2026 — Guidelines for auditing management systems
• ISO 13485:2016 — Medical-device quality management systems
• FDA — QMSR frequently asked questions
• MTL-123 — Supplier and outsourced-process control
• MTL-108 — Software lifecycle
• MTL-116 — Verification and validation
• MTL-129 — Configuration and change management