When your Class II medical device includes software, your software vendor’s quality system doesn’t just support your product, it becomes part of your FDA regulatory filing. The difference between a smooth 510(k) clearance and a months-long delay often comes down to whether your partner can prove compliance with two standards that work in tandem: ISO 13485 and IEC 62304.

The Story Behind the Standards

Picture this: you’re six weeks from submitting your 510(k) for a connected patient monitoring system. Your software vendor has delivered on time, the code works, and everyone’s happy, until your regulatory consultant asks for their Design History File. That’s when you discover they’ve never built a DHF before. They have ISO 13485 certification, but their software development process doesn’t align with IEC 62304. Now you’re facing a choice: delay your submission to rebuild documentation from scratch, or find a new vendor and start over.

This scenario plays out more often than you’d think. FDA rejections due to inadequate software documentation rank among the top reasons medical device submissions get delayed. The root cause? A fundamental misunderstanding of how ISO 13485 and IEC 62304 work together and what evidence your vendor must produce before you sign a contract.

Understanding the Relationship

ISO 13485 and IEC 62304 aren’t competitors, they’re complementary layers of the same compliance framework. ISO 13485 defines the quality management system (QMS) that governs your entire medical device operation, design controls, supplier management, risk management, and post-market surveillance. It’s the umbrella under which everything else lives.

IEC 62304, formally titled “Medical device software: Software life cycle processes,” zooms in on the software itself. It specifies how you plan, develop, verify, validate, and maintain medical device software across its entire lifecycle. Think of ISO 13485 as the building code for your entire construction project, while IEC 62304 is the electrical wiring standard that ensures the circuits won’t catch fire.

Critically, IEC 62304 does not cover organizational certification or device validation, those sit squarely under ISO 13485. A vendor can be ISO 13485 certified without having IEC 62304-compliant software processes, and that gap is where submissions stall.

What Documentation to Request Before Signing

Before you execute a contract, require your software vendor to demonstrate they can produce the following artifacts as part of their standard delivery.

Software Requirements Specification (SRS) that captures both functional and non-functional requirements with clear traceability to user needs and system-level hazards.

Software Architecture Description (SAD) showing how the system is partitioned, including safety-critical components, security boundaries, and interfaces with hardware or third-party systems.

Software Design Specification (SDS) with detailed design of software units, especially for Class B or Class C software where failure could cause serious injury.

Risk Management File aligned with ISO 14971, including software-specific hazard analysis, risk control measures, and residual risk evaluation.

Verification and Validation Protocols and Reports demonstrating that every safety requirement was tested and passed, with objective evidence that software performs as intended.

Traceability Matrix linking requirements to design elements to test cases to results, a non-negotiable artifact for FDA review.

Software Bill of Materials (SBOM) for connected devices, listing all third-party and open-source components (required by FDA since 2023).

Cybersecurity Documentation including threat models, vulnerability management plans, and secure development practices.

Design History File (DHF) that consolidates all of the above into a complete, auditable record of the software development lifecycle.

If your vendor hesitates or says they’ll “create it for this project,” that’s a red flag. These artifacts should emerge naturally from an IEC 62304-compliant process, not be bolted on after the fact.

Common Gaps That Delay Submissions

The most frequent compliance failures stem from three patterns:

Treating IEC 62304 as optional because the vendor is ISO 13485 certified. Certification proves they have a QMS, but not that their software development lifecycle meets IEC 62304’s specific requirements for planning, risk management, configuration control, and problem resolution.

Missing or incomplete traceability. FDA reviewers expect to follow a clear line from user need to requirement to design to test to result. When traceability breaks, especially for safety-related requirements, submissions get flagged for Additional Information (AI) letters that add months to clearance timelines.

Inadequate risk documentation. Many vendors perform hazard analysis but fail to connect software hazards to system-level risks, or they don’t document risk control verification. ISO 14971 integration is mandatory, and gaps here trigger deep dives during review.

A related issue: vendors who treat documentation as a post-development activity rather than an integral part of the lifecycle. IEC 62304 requires documentation at each phase, planning, requirements, architecture, detailed design, integration, testing, release, and maintenance. Retroactively creating these artifacts introduces errors and inconsistencies that reviewers spot immediately.

How to Vet a Partner’s Compliance Track Record

Don’t take “we’re compliant” at face value. Ask for evidence:

Request a sample DHF from a previous Class II software project (under NDA). Review it for completeness, traceability, and alignment with IEC 62304 phases.

Ask for their software development procedure and map it against IEC 62304 clauses. Look for explicit coverage of software planning, requirements analysis, architectural design, detailed design, integration, testing, release, and maintenance.

Verify ISO 13485 certification through the issuing body, and ask whether their certificate scope includes software development (not just distribution or consulting).

Interview their quality team about how they handle software problems, configuration changes, and risk updates post-release. IEC 62304 requires problem resolution and configuration management processes that integrate with your post-market surveillance.

Check references from other Class II device manufacturers who’ve successfully cleared products using the vendor’s software. Ask specifically about FDA interactions and whether software documentation caused delays.

The Bottom Line

Your software vendor’s QMS isn’t a back-office detail, it’s a regulatory asset that becomes part of your submission. ISO 13485 certification alone doesn’t guarantee IEC 62304 compliance, and the gap between them is where submissions stall.

Before signing, require proof: sample DHFs, mapped procedures, certified scopes, and references from successful 510(k) clearances. The cost of vetting upfront is negligible compared to the cost of a delayed submission, or worse, a refusal to accept your filing because your vendor’s documentation doesn’t meet FDA expectations.

For Class II devices, there’s no such thing as “basic” software compliance. The FDA expects enhanced documentation for any software function where failure could cause serious injury, and that means your vendor must operate at IEC 62304 Class B or C rigor from day one. Choose accordingly, and your path to clearance becomes significantly smoother.