Software is transforming the medical device industry, and the rules that govern it haven't always kept pace. Apps that update weekly, cloud-based platforms that evolve in real time, and AI-driven diagnostics have all arrived in a regulatory environment built largely around physical hardware.

So where does that leave software as a medical device (SaMD) when it comes to ISO 13485's production controls?

To answer that question, Greenlight Guru’s Etienne Nichols sat down with Adnan Ashfaq, Founder Director of Simplimedica and a quality and regulatory expert with more than 25 years of experience spanning startups and global medtech companies. Over the past decade, Adnan has deepened his focus on medical device software, implementing ISO 13485, validating SaMD under IEC 62304 (the international standard for medical device software lifecycle processes), and remediating FDA design history files. During their discussion on the Global Medical Device Podcast, Adnan was clear that for SaMD, ISO 13485 is not optional. Applying its clauses to software just requires creative thinking.

Here's where he landed on some of the most consequential clauses in ISO 13485.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

1. Adopt a "virtual manufacturing space" mindset

The foundational point Adnan makes is that ISO 13485 was never written to separate hardware from software. The standard simply doesn't draw that line. Companies developing SaMD must apply it anyway, and that requires a shift in mindset.

Instead of thinking about a factory floor with physical machines and clean rooms, SaMD teams need to think about a "virtual manufacturing space." The development environment, whether that's GitHub, GitLab, a cloud platform, or a continuous integration and continuous delivery (CI/CD) pipeline, is, in effect, the production floor. It must be validated, controlled, and documented with the same rigor you'd apply to physical manufacturing equipment, satisfying Clause 7.5 (Production and Service Provision).

This also means resisting the urge to mark production clauses as non-applicable simply because you're building software rather than hardware. Some clauses genuinely don't apply, with sterilization requirements (7.5.5, 7.5.7) being the obvious example. But others are more nuanced than they first appear, and Adnan notes that auditors are becoming more sophisticated about SaMD as AI and machine learning grow more prevalent, and that clauses previously accepted as non-applicable may start to draw more scrutiny.

2. Validate SOUP as purchased products

One consequential application of the virtual manufacturing mindset involves Software of Unknown Provenance (SOUP), meaning the open-source libraries, third-party modules, and commercial components that most SaMD products are built on top of.

Adnan explains that SOUP items should be treated as purchased products under Clause 7.4 (Purchasing Processes). Just as a hardware manufacturer is responsible for validating and evaluating the components it sources from suppliers, SaMD developers must verify and, where appropriate, validate the building blocks they incorporate into their software. That means documented supplier verification, impact assessment, and either a completed validation or a clear rationale for why one wasn't required.

In practice, this often means reviewing certifications and quality attestations from major platform providers like AWS or Microsoft rather than conducting a full supplier audit. Adnan also connects SOUP management to Clause 4.1.6 (Software Validation), noting that a Master Validation Plan should account for all SOUP items within the development environment. The FDA's Computer Software Assurance (CSA) guidance offers a useful risk-based framework, weighing high risk against low risk, for deciding how rigorously each item needs to be validated.

3. Contamination control is cybersecurity

One of the more unexpected connections Adnan draws is between Clause 6.4.2 (Contamination Control) and cybersecurity. In a hardware context, contamination control means managing particulates, chemicals, and sterile barriers. In a software context, it means something very different.

According to Adnan, contamination in SaMD includes data corruption, unauthorized code, malware, and ransomware, the digital contaminants that can compromise the integrity of a medical software product. These need to be addressed within the Quality Management System (QMS) just as physical contamination would be, making cybersecurity controls a non-negotiable part of your quality system.

This connects directly to Clause 6.3 (Infrastructure), which Adnan maps to computing environments, secure hosting platforms, access controls, backup procedures, encryption, and disaster recovery capabilities. An auditor reviewing a SaMD QMS will want to see evidence that the work environment itself has been properly addressed, not just the software running within it.

4. Formalize the software bill of materials (SBOM)

When most people think about the Medical Device File (Clause 4.2.3), they picture a bill of materials, assembly drawings, and labeling. For SaMD, the equivalent documentation looks quite different, and the Software Bill of Materials (SBOM) sits at the center of it.

Adnan describes the SBOM as the digital equivalent of a hardware BOM. It is a complete inventory of all software components, libraries, dependencies, and their version histories. The SBOM is a key deliverable under Clause 4.2.3 and plays a critical role in Design Transfer to Production (Clause 7.3.8). Regulators and auditors increasingly expect to see a well-maintained SBOM as evidence that a manufacturer has control over what's actually running in their product.

The broader software release package required for Clause 7.3.8 should also include validated design outputs, code and configuration documentation, evidence of all verification activities, and a Software Design Trace Matrix linking user requirements through to software units. Adnan notes that through his own practice he has developed 16 individual documents that together meet IEC 62304's requirements, from the Software Requirements Specification and SOUP declarations to systems testing and problem resolution.

5. Bridge agile with documentation

SaMD teams frequently use agile methodologies, with iterative, fast-moving development cycles that don't map neatly onto ISO 13485's waterfall-oriented design control framework (Clause 7.3). The core issue there, Adnan says, is documentation.

During an ISO 13485 Stage 2 audit, he observed auditors specifically asking whether risk assessments had been documented for each version control entry. In agile environments, the work often happens, but the paper trail frequently doesn't. Every iteration, bug fix, or patch needs a documented risk assessment and a clear change history, or it becomes an open non-conformance.

AAMI TIR 45 (the Association for the Advancement of Medical Instrumentation's Technical Information Report on agile practices in medical device software development) can help teams structure this in a compliant way. And the quality assurance function needs to stay closely engaged throughout. Just as quality engineers in hardware manufacturing maintain oversight of the production floor, someone in a SaMD organization needs to be monitoring the virtual manufacturing space for changes that could introduce compliance risk.

Keep in mind, these are just a handful of the most important clauses for SaMD manufacturers to know about. Etienne and Adnan discussed many more of ISO 13485’s clauses and how they relate to SaMD over the course of the full episode, and I encourage you to listen to the whole thing.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

Want to see what a SaMD-ready eQMS looks like?

Software bills of materials, agile-aligned risk documentation, and audit-ready evidence across continuous releases require a QMS built for how software teams actually work. Greenlight Guru's eQMS connects with Jira and GitHub, supports IEC 62304 alignment natively, and gives QA and engineering one source of truth, without the parallel tools or compliance add-ons that traceability layers force teams into.

If you’re ready to see what a SaMD-ready eQMS can do for your team, get your free demo of Greenlight Guru today.

Adnan Ashfaq is the Founder Director of Simplimedica. Connect with him on LinkedIn.