ISO 13485 for Software Companies: What Healthcare Developers Need to Know

Introduction

ISO 13485 was written for medical device manufacturers. The standard assumes physical products, factory floors, and supply chains. But regulators worldwide now classify software as a medical device in its own right. If your application analyzes diagnostic images, monitors chronic conditions, calculates drug dosages, or guides clinical decisions, it falls under the regulatory definition of Software as a Medical Device (SaMD). And once it does, ISO 13485 becomes the quality management framework you are expected to follow.

We went through ISO 13485 certification at Momentum as a software company. No hardware. No manufacturing line. Our "product" is code, cloud infrastructure, and the development processes around them. Going through certification taught us which parts of the standard translate directly to software work, which parts need reinterpretation, and where software teams tend to get stuck.

This article covers what ISO 13485 certification requires for software teams, based on our direct experience. We will walk through design controls, risk management, validation, documentation, the certification timeline, and what auditors focus on during assessments. The goal is to help you understand the scope of the standard before you decide whether to pursue certification yourself or work with a certified partner.

What ISO 13485 Covers (and What It Does Not)

The Scope of the Standard

ISO 13485 defines requirements for a quality management system (QMS) specific to medical devices. It covers the entire product lifecycle: design inputs, development, verification, validation, production, distribution, installation, servicing, and decommissioning. For software companies, "production" means release management and deployment, and "servicing" means updates, patches, and incident response.

The standard requires organizations to document processes for management responsibility, resource management, product realization, and measurement. Every process that affects product quality needs a defined procedure, records of execution, and evidence of review.

What ISO 13485 Does Not Cover

ISO 13485 does not replace regulatory submissions. It does not grant you FDA 510(k) clearance, CE marking under the EU Medical Device Regulation (MDR), or any market authorization. Those regulatory pathways have their own requirements. ISO 13485 certification demonstrates that your quality management system meets the standard, but you still need to go through the relevant regulatory body for your target market.

The standard also does not address clinical validation. Proving that your software produces clinically accurate results is a separate process, typically governed by clinical evaluation requirements under the MDR or FDA guidance documents.

How ISO 13485 Relates to IEC 62304 and ISO 14971

ISO 13485 is the quality management umbrella. Two companion standards handle software-specific concerns:

• IEC 62304 defines software lifecycle processes for medical device software, including software development planning, architecture, detailed design, unit implementation, integration testing, and maintenance. Where ISO 13485 says "follow design controls," IEC 62304 tells you exactly what those controls look like for code.
• ISO 14971 covers risk management for medical devices. ISO 13485 requires risk management throughout the product lifecycle but does not specify the methodology. ISO 14971 provides that methodology, including hazard identification, risk estimation, risk evaluation, and risk control.

Most certification bodies expect to see evidence of IEC 62304 and ISO 14971 compliance during an ISO 13485 audit, even though they are technically separate standards.

Design Controls for Software

Requirements Traceability

Design controls require a traceable chain from user needs through design inputs, design outputs, verification, and validation. For a software team, this means:

1. Design inputs (requirements) must be documented, reviewed, and approved before development begins.
2. Design outputs (architecture documents, interface specifications, code) must map back to specific inputs.
3. Verification (testing) must demonstrate that each output satisfies its corresponding input.
4. Validation must confirm that the finished product meets user needs in its intended environment.

This traceability chain needs to be maintained through a requirements traceability matrix (RTM). Each requirement gets a unique identifier, and you track it through design, implementation, and test execution. When an auditor asks "show me how this requirement was verified," you need to produce a specific test case, its execution record, and the result.

Design Reviews

ISO 13485 requires formal design reviews at defined stages of development. These are not code reviews or sprint retrospectives. A design review evaluates whether the design outputs at a given stage satisfy the design inputs and whether the project should proceed to the next phase.

For software teams, a practical approach is to align design reviews with development milestones: after requirements finalization, after architecture design, after implementation, and before release. Each review must include participants who are independent of the work being reviewed, and the results must be documented with identified actions and responsible parties.

Change Management

Any change to requirements, design, or implementation after approval requires a formal change request. The change request must include the rationale for the change, impact analysis (including risk assessment), approval, and verification that the change was implemented correctly.

This is where software teams used to "just fix it and push" feel the friction most. Every change that affects the medical device needs a documented trail. This does not mean you cannot iterate. It means every iteration needs a record.

Agile and Design Controls

Agile workflows and ISO 13485 are not mutually exclusive, but they require adaptation. The standard does not prescribe waterfall development. It requires traceability, reviews, and change control. You can run sprints, maintain a backlog, and release incrementally as long as each increment has traceable requirements, verified outputs, and documented review points.

At Momentum, we map design control activities to our sprint cadence. Requirements go through formal review before entering a sprint. Each sprint produces verified outputs. Design reviews happen at release milestones. The key is distinguishing between exploratory work (which does not need full design controls) and work that will be part of a released medical device (which does).

Risk Management and ISO 14971

The Risk Management File

ISO 14971 requires a risk management file that persists throughout the product lifecycle. This file contains your risk management plan, hazard identification, risk analysis, risk evaluation, risk control measures, and residual risk evaluation. For software, the file also needs to cover risks introduced by software architecture decisions, third-party dependencies, data handling, and deployment environments.

Software-Specific Risks

Hardware risk categories (electrical shock, mechanical failure, biocompatibility) do not apply to standalone software. Software risk analysis focuses on different hazard categories:

• Incorrect output: the algorithm produces a wrong result that leads to clinical harm (e.g., a miscalculated dosage recommendation)
• Data integrity failures: patient data is corrupted, lost, or mixed between patients
• Availability: the system is unavailable when a clinician needs it for a time-sensitive decision
• Unauthorized access: protected health information is exposed or modified by unauthorized users
• Usability errors: the interface misleads a clinician into taking an incorrect action

Severity and Probability Matrices

Risk evaluation uses a matrix that maps severity of harm against probability of occurrence. Severity categories typically range from negligible to catastrophic. Probability ranges from improbable to frequent. Each identified risk is plotted on the matrix, and risks above an acceptable threshold require risk control measures.

For healthcare software, severity assessment should consider the clinical context. A miscalculated wellness metric in a consumer app has different severity than a miscalculated drug interaction alert in a prescribing system. Your severity definitions need to reflect the actual clinical scenarios your software supports.

Connecting Risk to Testing

Risk controls often take the form of design decisions, input validation, algorithmic checks, or user interface safeguards. Each risk control measure needs verification, which means a test case tied to the specific risk. High-severity risks should have more rigorous verification, including edge case testing, boundary testing, and failure mode testing. This creates a direct link between your risk management file and your test strategy.

Software Validation and Verification

Validation vs. Verification

These terms have specific meanings under ISO 13485 that differ from casual usage:

• Verification answers: "Did we build the product correctly?" It confirms that design outputs meet design inputs through testing, inspection, or analysis.
• Validation answers: "Did we build the correct product?" It confirms that the final product meets user needs and intended uses under actual or simulated conditions of use.

Both are required. Verification happens throughout development. Validation happens on the finished product before release.

Testing Mapped to ISO Requirements

ISO 13485 and IEC 62304 expect a testing hierarchy:

• Unit testing verifies individual software units against their detailed design specifications.
• Integration testing verifies that software units work together and that the software integrates correctly with hardware or external systems.
• System testing verifies that the complete software system meets its software requirements specification.
• Acceptance testing (validation) confirms the product meets user needs in its intended use environment.

Each level needs a test plan (what will be tested, acceptance criteria, test environment) and test reports (what was tested, results, deviations, conclusions).

Automated Testing as Evidence

Automated tests are valid evidence for ISO 13485 audits, and auditors increasingly expect to see them. The key requirement is that automated test results are recorded, timestamped, and linked to specific software versions. A CI/CD pipeline that runs unit tests on every commit and stores results with build identifiers provides continuous verification evidence.

At Momentum, our automated test suites generate reports that map to requirements identifiers. When we need to demonstrate verification for a specific requirement, we can pull the test execution history for that requirement across all builds. This is significantly more efficient than maintaining manual test protocols, and auditors have responded positively to this approach.

Documentation Requirements

Core Documents

ISO 13485 requires several categories of documentation:

• Quality manual: describes your QMS scope, processes, and their interactions.
• Quality policy and objectives: management's commitment to quality and measurable quality goals.
• Documented procedures: ISO 13485 specifies about 15 mandatory procedures, including document control, record control, internal audits, CAPA, and management review.
• Records: evidence that processes were followed, including training records, design review records, test records, and audit records.

Design History File (DHF) and Device Master Record (DMR)

Each medical device needs two key files:

The Design History File (DHF) contains the complete design and development history: requirements, design documents, risk management file, verification and validation records, and design review records. Think of it as proof that you followed your design control process.

The Device Master Record (DMR) contains everything needed to produce the device: specifications, manufacturing (build and deployment) procedures, quality assurance procedures, and labeling. For software, the DMR includes your release build process, deployment procedures, installation instructions, and product labeling (including intended use statements and user documentation).

What "Documented Procedure" Means in Practice

A common misconception is that every documented procedure requires a lengthy standalone document. In practice, a documented procedure needs to define who does what, when, and how, with enough detail that a trained person could follow it and an auditor could verify compliance. For software teams, many procedures can live in your existing tools: wiki pages, repository READMEs, pipeline configurations, or issue tracker workflows.

The requirement is that procedures are controlled (version-managed, reviewed, approved) and accessible to the people who need them. A well-maintained Confluence page with version history and approval records satisfies the standard just as well as a traditional Word document with signature blocks.

Document Control and Version Control

Software teams already practice version control for code. ISO 13485 extends that discipline to all quality documents. Every document needs a unique identifier, version number, approval record, and distribution control. Changes to controlled documents require review and approval before implementation.

If you already use Git for code and a wiki with version history for documentation, you are halfway there. The gap is usually in formal approval workflows and ensuring that obsolete versions are identified and removed from use.

The Certification Process

Gap Analysis

Before building a QMS, conduct a gap analysis against ISO 13485 requirements. This assessment compares your current processes and documentation to what the standard requires. For most software companies, common gaps include lack of formal design controls, no risk management file, limited document control, and no internal audit program.

A gap analysis typically takes 2 to 4 weeks and produces a prioritized action plan. You can do this internally if you have someone who understands the standard, or engage a consultant for an independent assessment.

Building the QMS

Developing a compliant QMS from scratch takes 6 to 18 months, depending on your starting point. A startup with minimal documentation will need longer than an established company with existing quality processes.

The work includes writing your quality manual, establishing procedures for all required processes, creating templates for records and forms, training staff on the QMS, and executing the processes long enough to generate audit evidence. Auditors want to see that your system has been operational for several months, not that you created documentation the week before the audit.

Internal Audits and Management Reviews

Before your certification audit, you need to conduct at least one full cycle of internal audits covering all QMS processes and at least one management review. Internal audits verify that your processes work as documented. Management reviews evaluate QMS effectiveness using data (audit results, customer complaints, process performance, CAPA status).

These are not formalities. Auditors will review your internal audit records and management review minutes closely. Findings from internal audits that were identified and corrected demonstrate a mature quality system.

Stage 1 and Stage 2 Audits

Certification involves two stages:

Stage 1 (documentation review): The certification body reviews your QMS documentation to confirm it meets ISO 13485 requirements. This is primarily a desk review, though it may include a brief site visit. The auditor identifies any documentation gaps that must be resolved before Stage 2.

Stage 2 (implementation audit): The certification body audits your facility (or, for remote teams, your development environment and processes) to verify that your QMS is implemented and effective. Auditors interview staff, review records, observe processes, and sample evidence across all QMS requirements. Stage 2 typically takes 2 to 5 days depending on organization size.

Surveillance and Recertification

After initial certification, you undergo surveillance audits annually. These cover a subset of QMS requirements each year, with full coverage over the 3-year certification cycle. Recertification audits occur every 3 years and cover the full scope of the standard.

Cost Considerations

Certification Body Fees

External audit costs depend on organization size, scope, and the certification body you choose. For a small to mid-size software company (20 to 100 employees), expect:

• Stage 1 and Stage 2 audit: $10,000 to $25,000
• Annual surveillance audits: $5,000 to $12,000
• Recertification audit (every 3 years): $8,000 to $20,000

These ranges vary by geography and certification body. BSI, TUV, SGS, and Dekra are among the common choices for ISO 13485 certification.

Internal Effort

The larger cost is internal. Building a QMS requires dedicated effort from engineering leadership, quality personnel, and development teams. Depending on whether you hire a quality manager, engage consultants, or both, internal costs during the initial build phase range from $50,000 to $200,000+ in staff time and consulting fees.

Ongoing maintenance includes document updates, internal audits, management reviews, CAPA management, and training. Plan for 10% to 20% of a full-time quality role for ongoing QMS maintenance in a small company, or a full-time quality manager in a larger organization.

Working with a Certified Partner

For companies whose primary business is not medical device manufacturing, building and maintaining a full ISO 13485 QMS may not be the most efficient path. Working with a certified development partner means your software is built under an existing certified quality system. You benefit from established design controls, risk management processes, and documentation practices without the overhead of running your own QMS.

This approach is particularly relevant for healthcare startups building their first SaMD product, established companies adding a healthcare software component to their portfolio, or organizations that need to reach market quickly within a certified framework.

What Auditors Actually Look For

Documentation vs. Practice Alignment

The most common source of nonconformities is a gap between what your documented procedures say and what your team actually does. Auditors test this by interviewing developers, reviewing recent project records, and checking whether the evidence matches the procedure. If your design control procedure requires a design review with specific roles but your last three projects skipped that step, that is a nonconformity.

The fix is not to write more detailed procedures. It is to write procedures that reflect your actual workflow and then follow them consistently.

Common Nonconformities in Software Companies

Based on our experience and observations across the industry, software companies frequently receive nonconformities in these areas:

• Incomplete traceability: requirements exist, tests exist, but the link between them is missing or inconsistent.
• Risk management gaps: the risk management file was created during development but not updated when the design changed.
• Training records: staff performing quality-relevant activities do not have documented evidence of training on applicable procedures.
• CAPA effectiveness: corrective actions were taken but there is no evidence that they were verified for effectiveness.
• Supplier controls: third-party libraries or cloud services used in the medical device were not evaluated as suppliers.

Corrective and Preventive Actions (CAPA)

CAPA is the backbone of continuous improvement in ISO 13485. When a problem is identified (through audits, complaints, or process monitoring), the CAPA process requires root cause analysis, corrective action to address the specific problem, preventive action to prevent recurrence, and verification that the actions were effective.

Auditors pay close attention to CAPA because it reveals how your organization responds to problems. A well-maintained CAPA log with closed-loop actions demonstrates an active quality culture. An empty CAPA log is a red flag, because it suggests either that problems are not being identified or that the process is not being used.

Start Building on a Certified Foundation

ISO 13485 certification is a significant investment in process maturity. For software companies entering the medical device space, it requires rethinking how you manage requirements, control changes, document decisions, and verify outputs. The standard is achievable for software organizations of any size, but the timeline and effort should not be underestimated.

If you are building healthcare software and need ISO 13485-compliant processes without the 12+ month certification journey, working with a certified partner gives you access to an established QMS from day one. Momentum is ISO 13485 certified, and our development teams operate under that quality system for every healthcare engagement.

See how other healthtech companies approach ISO 13485 certification

‍