ISO 13485 Internal Audit Checklist for Software Companies

Introduction

ISO 13485 Clause 8.2.2 requires organizations to conduct internal audits at planned intervals. The purpose is to verify that your quality management system conforms to planned arrangements, the requirements of the standard, and the QMS requirements you have established. For software companies building medical devices, these audits are both a certification requirement and an operational tool for catching process drift before it becomes a compliance problem.

Internal audits function as a rehearsal for your certification body's external assessment. The auditor assigned to your certification audit will follow a similar structure: reviewing documentation, interviewing team members, tracing product records, and evaluating whether your processes match what your QMS describes. The difference is that internal audits give you the opportunity to find and fix gaps on your own timeline.

At Momentum, we maintain ISO 13485 certification for our medical device software (SaMD) development. We conduct internal audits as part of that maintenance, and we have been through the external audit cycle multiple times. This article shares the checklist we use, the nonconformities we have encountered in software organizations, and practical guidance for preparing your team for both internal and external assessments. The focus is on areas where software companies differ from traditional medical device manufacturers.

Disclaimer: This article provides engineering and quality management guidance based on our experience. It is not legal or regulatory advice. Consult a qualified regulatory professional for decisions specific to your organization.

What ISO 13485 Internal Audits Cover

Audit Scope

An internal audit program must cover every QMS process over a defined cycle. Most organizations use 12 months, meaning every process gets audited at least once per year. You can audit everything in a single comprehensive session or spread focused audits throughout the year.

The scope includes:

• QMS documentation (Clause 4): quality manual, document control, record management
• Management responsibility (Clause 5): management reviews, quality policy, organizational roles
• Resource management (Clause 6): personnel competence, training, infrastructure
• Product realization (Clause 7): design controls, purchasing, production and service
• Measurement, analysis, and improvement (Clause 8): monitoring, CAPA, data analysis

For software companies, Clause 7 is where most audit effort concentrates. Design controls (7.3), risk management (ISO 14971), and supplier management for third-party components (7.4) require detailed review.

Audit Frequency and Planning

Your audit schedule should reflect the importance and status of each process area. High-risk areas or processes with previous nonconformities may warrant more frequent auditing. Document your schedule in an annual audit plan defining scope, audit criteria, team, and timeline for each planned audit.

Internal Audit Checklist: QMS Documentation (Clause 4)

This section covers the foundation of your quality management system: the documents that define what you do and the records that prove you did it.

Software-specific note: Most software companies manage documents and records in tools like Confluence, Notion, SharePoint, or specialized QMS software. Your document control procedure needs to address how version control, access control, and approval workflows function in these digital tools. If your team uses Git for code, your procedure should explain how Git's version history satisfies document control requirements for code-as-documentation.

Internal Audit Checklist: Management Responsibility (Clause 5)

Internal Audit Checklist: Resource Management (Clause 6)

Software-specific note: Training records are a frequent audit finding in software companies. When a new developer joins the team, you need documented evidence that they have been trained on your QMS procedures, design control process, change management workflow, and any role-specific regulatory requirements. Onboarding checklists with sign-off records work well here.

Internal Audit Checklist: Design Controls (Clause 7.3)

Design controls are the most scrutinized area for software companies. This is where auditors spend the most time, and where the majority of nonconformities occur. Every item below should be verified against actual product records, not just procedure documents.

Internal Audit Checklist: Risk Management (ISO 14971 Integration)

ISO 13485 requires risk management throughout the product lifecycle. Most organizations implement this through ISO 14971. During an internal audit, verify the following for each product:

Software-specific note: Software risk management needs to address cybersecurity risks, data integrity risks, interoperability failures, and algorithmic errors alongside traditional use-related hazards. Risk management files should reference IEC 62304 software safety classifications.

Internal Audit Checklist: Purchasing and Supplier Controls (Clause 7.4)

For software companies, this section extends beyond traditional hardware suppliers to include every external component in your software stack.

Software-specific note: If your application uses 200 npm packages or Python libraries, your QMS needs a defined approach for evaluating these as supplied materials. You do not need a full supplier audit for each package, but you do need documented acceptance criteria, a process for monitoring security advisories, and a re-evaluation method when vulnerabilities are disclosed.

Internal Audit Checklist: CAPA (Clause 8.5)

Corrective and Preventive Action is the second area (after design controls) where auditors concentrate their review. CAPA is the mechanism that proves your QMS can self-correct.

Common Nonconformities in Software Companies

These are the nonconformities we see most frequently in software company audits:

1. Incomplete Requirements Traceability

Requirements exist in Jira. Tests exist in a test management system. But the link between a specific requirement and its verification tests is missing, incomplete, or outdated. Auditors select requirements at random and ask for verification evidence. If you cannot trace from requirement to test result in a few minutes, this becomes a finding.

2. Risk Management Files Not Updated After Design Changes

The initial risk management file is thorough. But six months and 40 pull requests later, features have changed and the risk file still reflects the original design. Clause 7.1 requires risk management throughout product realization. A stale risk file is one of the easiest nonconformities for an auditor to identify.

3. Missing Training Records

A developer has been contributing for eight months but has no training record for the CAPA procedure or design review process. Without documented evidence, there is no way to demonstrate compliance. This finding is avoidable with a structured onboarding checklist.

4. CAPA Effectiveness Not Verified

A nonconformity was identified, root cause analysis completed, corrective action implemented. The CAPA record stops there. Clause 8.5.2 requires verification that the corrective action was effective, meaning checking whether the nonconformity has recurred. Many organizations implement the fix but skip follow-up verification.

5. Third-Party Libraries Not Managed as Suppliers

Your application depends on 150 external packages. Your approved supplier list has 4 entries. Open-source libraries and third-party SDKs are supplied materials under Clause 7.4. Your QMS needs a documented process for evaluating, accepting, and monitoring these dependencies.

6. Design Review Records Missing Required Content

Design reviews happened, but the records do not include all required elements. Common omissions: the list of participants does not identify who was independent of the design work, action items are not recorded, or the review conclusion (proceed, proceed with actions, do not proceed) is absent.

7. Document Control Gaps

A procedure was updated six months ago, but the previous version is still accessible on the shared drive alongside the current version. Or a procedure references a form template that no longer exists. Document control in digital environments requires the same rigor as paper-based systems, with the added challenge of multiple storage locations, local copies, and cached versions.

How to Prepare for an External Audit

External audits follow a predictable structure. Your internal audit program should mirror it.

• Conduct internal audits with external rigor. Your internal auditors should review documentation beforehand, prepare an audit plan with specific clauses, interview personnel, review records, and document findings formally. Casual walkthroughs will not prepare your team for the formality of a certification assessment.
• Use independent auditors. The person who wrote the CAPA procedure should not audit the CAPA process. In small teams, cross-train members to audit areas outside their responsibility, or engage external consultants for high-risk process areas.
• Review previous findings. Before any audit, verify that corrective actions from prior nonconformities have been implemented and that effectiveness verification is documented. External auditors check previous findings as part of their assessment.
• Prepare your team. Every team member should be able to explain their role in the QMS. Developers should know where to find the design control procedure. QA personnel should be able to walk through the traceability matrix. Auditors interview multiple people, and responses that contradict documented procedures create findings.
• Organize design history files. For each product in scope, verify the DHF contains all design inputs, outputs, review records, verification evidence, validation reports, and change records. If your DHF spans multiple tools, prepare an index mapping each element to its location.
• Prepare a CAPA summary. Have a current summary showing open items, status, target closure dates, and overdue items. Include recently closed CAPAs with effectiveness verification results.

Working with a Certified Partner

Building and maintaining an ISO 13485-compliant QMS is a significant investment for any software company. The quality management system requires dedicated personnel, ongoing training, regular internal audits, and continuous documentation maintenance. For organizations that need compliant medical device software but do not want to establish their own QMS, working with a certified development partner is an alternative.

Momentum holds ISO 13485 certification and develops medical device software under IEC 62304 and ISO 14971. We have completed over 100 healthcare deployments and maintain the audit-ready documentation, design control processes, and CAPA systems described in this article. If your product requires ISO 13485-compliant development, learn more about our compliance capabilities

‍