SaMD (Software as a Medical Device) for US Startups: FDA Pathways, 21 CFR Part 11, and Cybersecurity Premarket

In March 2022, a clinical AI startup in New York, Seed stage, $4.8M raised, building a radiology workflow tool, added a feature in sprint seven. The feature analyzed uploaded chest X-ray images and surfaced a probability score: “Findings consistent with pneumoni78%.” The product manager called it a “decision support hint.” The radiologist beta testers called it useful. The regulatory attorney they finally consulted in month nine called it something else.

She called it a medical device.

More specifically, she called it Software as a Medical Device that was intended to be used in the diagnosis of disease, a Class II device under 21 CFR §880.3710, that had been deployed to clinical users without FDA clearance.

The founder had not intended to build a medical device. He had intended to build a workflow efficiency tool with a helpful clinical annotation. The FDA’s classification framework does not care about intent. It cares about intended use and the risk the software poses to patients if it performs incorrectly.

They pulled the feature from production the same week. The 510(k) submission they filed six months later cost $380,000 in regulatory consulting fees, clinical validation study costs, and engineering rework to meet FDA quality system requirements. The feature they had built in one sprint took fourteen months to bring back to market legally.

I have been on 2,000+ calls with US healthcare founders since 2014. The SaMD classification conversation is the one that most founders have too late. Not because they are careless, because the line between “clinical decision support” and “medical device” is genuinely unclear, and the cost of discovering you are on the wrong side of that line after you have shipped is measured in years and hundreds of thousands of dollars.

This guide is the conversation I have with every healthcare founder before they build anything that touches clinical decision-making. It should be the conversation you have before sprint one, not after sprint seven.

Eight Things SaMD Founders Get Wrong Before They Build

• Wrong #1: “We’re decision support, we don’t need FDA clearance.”

The clinical decision support exemption under the 21st Century Cures Act is narrower than most founders believe. The four-part test for CDS exemption requires that the software: (1) is not intended to replace clinical judgment, (2) displays the basis for its recommendation so the clinician can independently review it, (3) targets a condition that is not serious or life-threatening, OR (4) meets specific criteria about the nature of the recommendation. Failing any part of the test means the software is a medical device. Get a regulatory attorney’s opinion before assuming CDS exemption applies.

• Wrong #2: “We’ll get FDA clearance after we validate the product clinically.”

Clinical validation for SaMD is part of the FDA submission, not something you do before the submission and then submit separately. The FDA’s requirements for clinical studies, study design, IRB approval, data collection protocols, statistical analysis plan, must be designed to meet FDA evidentiary standards from the beginning. Clinical data collected before regulatory engagement, using endpoints or methods that do not meet FDA requirements, may not be usable in a submission.

• Wrong #3: “ISO 13485 is optional for software.”

ISO 13485 certification is not legally required for FDA-regulated SaMD, the FDA’s quality system regulation (21 CFR Part 820, now aligned with ISO 13485 through the QMSR) is the regulatory requirement. But the QMSR requires a quality management system that is functionally equivalent to ISO 13485. You are building an ISO 13485-equivalent QMS whether you call it that or not. Calling it ISO 13485 and getting certified is easier than building a bespoke QMS from scratch.

• Wrong #4: “The cybersecurity requirements are about penetration testing.”

The FDA’s 2023 final guidance on cybersecurity in medical devices requires far more than penetration testing. It requires a Cybersecurity Management Plan, a Software Bill of Materials (SBOM), a coordinated vulnerability disclosure policy, postmarket cybersecurity maintenance, and a total product lifecycle approach to cybersecurity that begins in design and continues through the product’s entire market life. The 2023 guidance applies to new submissions, including 510(k) submissions for SaMD.

• Wrong #5: “21 CFR Part 11 means we need digital signatures.”

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated systems. For SaMD, it applies to any electronic records that are required by FDA regulations, audit trails, design history files, device master records, clinical study data. It requires: audit trails for electronic records, access controls, system validation, and, for electronic signatures, specific technical and procedural controls. Most SaMD products need Part 11-compliant audit trails and record management long before they need electronic signatures.

• Wrong #6: “A 510(k) means our product is FDA approved.”

FDA clearance through the 510(k) pathway means the FDA has determined that your device is substantially equivalent to a legally marketed predicate device. It does not mean the FDA has reviewed the clinical evidence for safety and effectiveness in the same way it does for PMA-approved devices. “FDA cleared” and “FDA approved” are legally distinct terms. Marketing your 510(k)-cleared device as “FDA approved” is a regulatory violation.

• Wrong #7: “We can update the algorithm after clearance without re-submitting.”

Changes to a cleared SaMD, algorithm updates, new intended uses, changes to the indications for use, may require a new 510(k) submission or a special 510(k) depending on the nature of the change. The FDA’s guidance on modifications to cleared devices defines when a change requires a new submission. For AI/ML-based SaMD, the FDA’s Predetermined Change Control Plan (PCCP) provides a pathway for pre-approved algorithm updates, but the PCCP must be included in the original submission and approved upfront.

• Wrong #8: “We don’t need a regulatory strategy until we need FDA clearance.”

The regulatory strategy determines the product design. Device classification determines the clinical evidence requirements. The clinical evidence requirements determine the study design. The study design determines the data collection architecture. The data collection architecture is built into the product from sprint one. A founder who decides their regulatory strategy in month twelve of development has already made dozens of design decisions that may need to be reversed.

What SaMD Actually Is, And the Classification Decision That Changes Everything

1. The IMDRF definition:

The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device.

The FDA has adopted the IMDRF SaMD definition and framework. The key elements:

Intended use: What is the software intended to do? The intended use is determined by the manufacturer’s labeling, promotional materials, and the reasonable expectations of the product’s users, not solely by the manufacturer’s internal characterization. A product that markets itself as helping clinicians “identify findings consistent with pneumonia” has an intended use that includes disease diagnosis, regardless of the disclaimer text.

Medical purpose: Does the software serve a medical purpose? Medical purposes include: diagnosis, cure, mitigation, treatment, or prevention of disease; and affecting the structure or function of the body. Software that provides information used to make a clinical decision about a specific patient serves a medical purpose.

Without being part of a hardware medical device: SaMD is standalone software, it runs on general-purpose computing platforms (smartphones, tablets, cloud servers, workstations) rather than being embedded in a hardware medical device. Software that is an integral part of a hardware medical device (the software that controls an infusion pump, for example) is regulated differently.

2. The critical classification question:

Is your software intended to be used in clinical decision-making for a specific patient? If yes, it is almost certainly SaMD or subject to the CDS (Clinical Decision Support) framework analysis. If no, it may be outside FDA jurisdiction.

Software that is outside FDA jurisdiction (generally):

• Software for administrative functions (scheduling, billing, coding)
• Software for general patient communication (appointment reminders, health education)
• Software for maintaining or encouraging a healthy lifestyle (step counters, diet trackers without clinical claims)
• Electronic Health Records (EHR) software that is not intended to diagnose, treat, or prevent disease
• Software that transfers or displays clinical data without interpreting it

Software that is inside FDA jurisdiction (generally):

• Software that analyzes clinical data and provides patient-specific recommendations for diagnosis or treatment
• Software that detects or diagnoses disease, injury, or physiological condition
• Software that suggests a specific treatment or therapy for a patient
• Software that analyzes images, signals, or other clinical data to identify pathology
• Software that predicts a patient’s likelihood of experiencing a specific clinical outcome

3. The intended use statement:

The intended use statement is the most important document in your regulatory strategy. It defines the scope of FDA regulation for your product. Every design decision, what data the software analyzes, what output it provides, how that output is presented to the user, must be consistent with the intended use statement.

Write your intended use statement before you build anything. Get a regulatory attorney to review it. The intended use statement determines your device classification, which determines your regulatory pathway, which determines your clinical evidence requirements, which determines your development timeline and cost.

From a US founder call: “I had twelve engineers building for eight months before I wrote an intended use statement. When I finally did, because my Series A investor required a regulatory memo as a diligence condition, the regulatory attorney told me the intended use I had been building toward was a Class III device requiring PMA, not a Class II device requiring 510(k).

I had been designing for the wrong regulatory pathway for eight months. The redesign to make the product Class II-eligible cost me four months and $240,000.”, Seed-stage clinical AI founder, SF Bay Area.

The FDA’s SaMD Classification Framework in 2026

The FDA classifies medical devices, including SaMD, into three classes based on the risk the device poses to patients:

• Class I, Low Risk

General controls apply. Most Class I devices are exempt from premarket notification (510(k)). Examples in SaMD: administrative software that crosses into device territory in minor ways, certain electronic health record functions that technically meet the device definition.

In practice: few standalone clinical software products are Class I. If your SaMD is Class I, you have an unusual product. Confirm the classification with a regulatory attorney.

• Class II, Moderate Risk

General controls plus special controls apply. Most Class II SaMD requires 510(k) premarket notification, demonstrating substantial equivalence to a legally marketed predicate device. The majority of digital health SaMD products targeting 510(k) clearance are Class II.

Examples: computer-aided detection (CAD) software for radiology, clinical decision support software for specific conditions, remote patient monitoring software that interprets physiological data, software-based diagnostic aids for dermatology or ophthalmology.

• Class III, High Risk

General controls, special controls, plus Premarket Approval (PMA) required. PMA requires clinical evidence demonstrating reasonable assurance of safety and effectiveness, a much higher evidentiary standard than 510(k). Class III is reserved for devices that support or sustain human life or present a potential unreasonable risk of illness or injury.

Examples: implantable cardiac monitors with software that analyzes arrhythmias, software that controls radiation therapy delivery, certain AI diagnostic tools for life-threatening conditions without adequate predicate devices.

• The IMDRF SaMD risk framework:

The FDA uses the IMDRF SaMD risk categorization framework to assess SaMD risk level within device class. Two dimensions:

Significance of information provided to healthcare decision:

• Treat or diagnose (highest significance)
• Drive clinical management
• Inform clinical management (lowest significance)

Healthcare situation or condition:

• Critical situation or condition (life-threatening, requires immediate intervention)
• Serious situation or condition
• Non-serious situation or condition

Risk increases along both dimensions. SaMD that treats or diagnoses a critical condition is highest risk. SaMD that informs clinical management of a non-serious condition is lowest risk. Your device classification reflects where your software falls in this matrix.

• The De Novo pathway:

When a SaMD is Class II but no legally marketed predicate device exists for 510(k) substantial equivalence, the De Novo pathway allows the FDA to establish new special controls and create a new device classification. De Novo is the pathway for genuinely novel SaMD without a predicate, which includes many AI-native clinical software products in emerging diagnostic categories.

De Novo takes longer than 510(k), typically 12–24 months versus 6–12 months for 510(k), and is more resource-intensive. But once a product receives De Novo authorization, it becomes the predicate device for subsequent 510(k) submissions in that category. Being the first product through De Novo in a category creates a significant competitive moat.

• Determining your device class:

The FDA’s Product Classification Database (accessible at accessdata.fda.gov) lists device classifications by product code and 21 CFR regulation number. For SaMD, relevant product codes include:

• QMF: Software function intended to analyze radiology images for diagnosis or treatment planning
• QNO: Software function intended to analyze physiological signals for diagnosis
• QNR: Computer-aided detection/diagnosis software
• QIH: Software for clinical decision support

Determining device class is not always straightforward, it requires matching your intended use statement to the most appropriate product code, evaluating predicate devices, and assessing special controls applicability. This is a regulatory attorney engagement, not an engineering task.

Compliance trap: The FDA’s device classification database lists historical classifications that may not reflect current regulatory thinking for AI-based SaMD. A product code that was classified as Class II in 2018 based on a non-AI predicate may face Class III reclassification questions if your AI-based implementation significantly expands the risk profile. Work with a regulatory attorney who is current on FDA’s AI/ML guidance, not just one who is familiar with the historical classification.

The 16-Question SaMD Readiness Audit

Work through these sixteen questions before your engineering team writes a line of code intended for clinical use.

• Have you written an intended use statement?

One sentence. What is the software intended to do, for whom, in what clinical context? This statement determines everything that follows.

• Have you had a regulatory attorney review the intended use statement for device classification?

Not a healthcare attorney generalist, a regulatory attorney with FDA SaMD classification experience. Budget $5,000–$15,000 for this engagement. It is the cheapest regulatory investment you will make.

• What is your device classification (Class I, II, or III)?

This determines your regulatory pathway, your clinical evidence requirements, and your development timeline. If you do not know the answer, you are not ready to build.

• What is your regulatory pathway (510(k), De Novo, or PMA)?

Each has different requirements, different timelines, and different costs. Design decisions flow from the regulatory pathway.

• Have you identified a legally marketed predicate device for 510(k) substantial equivalence (if 510(k) is your pathway)?

The predicate device’s intended use, technological characteristics, and performance specifications define the substantial equivalence argument. If you cannot identify a predicate, you may need the De Novo pathway.

• What clinical evidence does your regulatory pathway require?

510(k) substantial equivalence requires performance data demonstrating your device performs at least as well as the predicate. The specific data required, clinical study, bench testing, analytical validation, depends on the device type and the predicate.

• Have you designed your clinical validation study to meet FDA evidentiary standards?

FDA-compliant clinical study design requires: pre-specified primary endpoints, statistical analysis plan, adequate sample size calculation, IRB approval, data collection that produces analyzable data, and results that can be included in a regulatory submission.

• Have you established a Quality Management System?

21 CFR Part 820 (now aligned with ISO 13485 through the QMSR) requires a documented quality management system before you begin design and development of a medical device. The QMS is not post-market infrastructure, it governs the development process itself.

• Have you written a Design History File (DHF)?

The DHF documents the design and development history of the device, design inputs, design outputs, design verification, design validation, design reviews, and design changes. It must be maintained from the beginning of development, not reconstructed after the fact.

• Have you assessed your 21 CFR Part 11 obligations?

Which electronic records in your product are required by FDA regulations? What audit trail requirements apply? What electronic signature requirements apply?

• Have you conducted a cybersecurity risk assessment per the FDA’s 2023 final guidance?

The 2023 guidance requires a cybersecurity risk assessment, a Software Bill of Materials (SBOM), a coordinated vulnerability disclosure policy, and a Cybersecurity Management Plan, all as part of the premarket submission.

• Have you assessed your clinical decision support exemption applicability?

If you believe your product qualifies for the CDS exemption under the 21st Century Cures Act, apply the four-part test from the FDA’s 2022 CDS guidance explicitly. Do not assume exemption, document the analysis.

• What are your postmarket obligations?

Medical Device Reporting (MDR), postmarket surveillance, complaint handling, corrective and preventive action (CAPA), and, for AI/ML SaMD, the Predetermined Change Control Plan. These must be designed into your product and operations from launch.

• Do you have a Software Bill of Materials (SBOM)?

The FDA’s 2023 cybersecurity guidance requires an SBOM listing all software components, including open-source libraries, third-party components, and their versions. The SBOM enables the FDA to assess cybersecurity risk from known vulnerabilities in your software components.

• Have you planned for FDA Pre-Submission (Q-Sub) meetings?

Pre-Submission meetings, formerly called pre-IDE meetings or Q-Sub meetings, allow you to present your proposed regulatory strategy, study design, and device description to the FDA and receive feedback before filing your submission. These meetings are free, they reduce submission uncertainty, and they are underutilized by health tech startups. Budget for at least one Q-Sub meeting before your first regulatory submission.

• What is your regulatory budget and timeline?

SaMD development and FDA submission is a multi-year, multi-hundred-thousand-dollar commitment. Know the numbers before you commit. The cost and timeline for your specific regulatory pathway must be part of your fundraising model, not discovered mid-Series A.

The Three FDA Pathways, 510(k), De Novo, and PMA

• 510(k) Premarket Notification

What it is: A premarket submission to the FDA demonstrating that your SaMD is substantially equivalent to a legally marketed predicate device. Substantial equivalence means the device has the same intended use as the predicate and the same or different technological characteristics, but if different, those differences do not raise new safety and effectiveness questions.

Who it is for: Class II SaMD with an identifiable predicate device.

What the submission contains:

• Device description and intended use statement
• Substantial equivalence comparison to the predicate device
• Performance data, bench testing, analytical validation, and/or clinical data demonstrating performance at least equivalent to the predicate
• Software documentation, level of concern assessment, software description document, risk analysis, verification and validation testing, cybersecurity documentation
• Labeling

Timeline: The FDA’s review clock for a 510(k) is 90 days from acceptance. In practice, total time from submission to clearance (including submission preparation, FDA review, and any additional information requests) is typically 6–12 months for a well-prepared submission from a first-time submitter.

Cost: FDA submission fee for FY2026: approximately $22,000 for a standard 510(k) from a small business (reduced fee), the full fee is approximately $134,000 for non-small businesses. Regulatory consulting and preparation costs: $150,000-$350,000 depending on complexity, clinical study requirements, and the submitter’s internal regulatory resources.

The level of concern assessment: The FDA’s software guidance requires a software level of concern assessment, Major, Moderate, or Minor, that determines the depth of software documentation required in the submission. Level of concern is based on whether a software failure could result in serious injury or death (Major), non-serious injury (Moderate), or no injury (Minor). Most clinical SaMD is Major or Moderate level of concern. Major level of concern requires the most comprehensive software documentation.

• De Novo Classification Request

What it is: A request to the FDA to establish a new device classification for a novel low-to-moderate risk device that does not have a legally marketed predicate device. A successful De Novo results in a new device type classification and special controls, and the authorized device becomes a predicate for future 510(k) submissions.

Who it is for: Class II SaMD where no legally marketed predicate exists, typically AI-native clinical software in emerging diagnostic or therapeutic categories.

What the submission contains:

• Device description and intended use statement
• Proposed device classification and special controls
• Performance data demonstrating the device is safe and effective, typically more comprehensive than a 510(k) because there is no predicate to establish equivalence against
• Risk analysis
• Software documentation
• Cybersecurity documentation
• Proposed labeling

Timeline: FDA review target is 150 days from acceptance. In practice, 12–24 months from submission start to authorization.

Cost: FDA submission fee: No user fee for De Novo (unlike 510(k) and PMA). Regulatory consulting and clinical study costs: $250,000–$600,000 depending on the novelty of the device and the clinical evidence required.

The competitive moat: A De Novo-authorized device becomes the predicate for all subsequent 510(k) submissions in that device category. The company that goes through De Novo first in a new AI diagnostic category is the company all competitors must use as their predicate, they have defined the performance standard and the special controls for the category. This is a significant first-mover regulatory advantage that is underappreciated by founders.

• Premarket Approval (PMA)

What it is: The most stringent FDA regulatory pathway, required for Class III devices that support or sustain human life or present an unreasonable risk of injury. PMA requires clinical evidence demonstrating reasonable assurance of safety and effectiveness, not just substantial equivalence.

Who it is for: Class III SaMD where the risk is high enough that general and special controls are insufficient to assure safety and effectiveness.

What the submission contains:

• Device description and intended use statement
• Comprehensive clinical study data, typically a pivotal clinical trial with pre-specified endpoints, adequate sample size, and statistical significance
• Preclinical data
• Manufacturing information
• Risk analysis
• Software documentation
• Cybersecurity documentation

Timeline: FDA review target is 180 days from filing. In practice, total time from study initiation to PMA approval is 3–7 years.

Cost: FDA submission fee: approximately $450,000 (full fee, FY2026). Total development and regulatory cost: $5M–$20M+ depending on clinical study requirements.

Who should pursue PM: Very few digital health startups should be pursuing PMA. If your regulatory attorney tells you your product requires PMA, you have one of three options: (1) redesign the product to reduce risk below Class III, (2) raise the capital required for a PMA program with adequate runway, or (3) reconsider the product.

From a US founder call: “I had two regulatory attorneys review my clinical AI product. The first told me 510(k). The second told me De Novo. I hired a third for a tiebreaker. She told me neither, she said the product as designed was Class III requiring PMA, and that the first two attorneys had been wrong. Three regulatory opinions, three different answers. The regulatory attorney you hire for SaMD classification matters enormously. A wrong classification opinion is a multi-year, multi-million-dollar mistake.”, Series A clinical AI founder, Boston.

21 CFR Part 11, Electronic Records and Electronic Signatures

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated environments. For SaMD developers, it applies to the electronic records your product creates, modifies, maintains, archives, retrieves, and transmits, specifically those records that FDA regulations require to be kept.

• The records Part 11 covers for SaMD:

Design History File (DHF): The design and development record for the device. If maintained electronically, Part 11 applies.

Device Master Record (DMR): The compilation of records containing the procedures and specifications for a finished device. If maintained electronically, Part 11 applies.

Device History Record (DHR): The record of activities for the manufacture of each production unit. For software, this includes build records, version control records, and release documentation.

Quality Management System records: CAPA records, audit records, complaint records, management review records, all subject to Part 11 if maintained electronically.

Clinical investigation records: Records from clinical studies used to support FDA submissions, case report forms, data collection records, audit trails. The FDA’s 21 CFR Part 11 requirements for clinical investigation records are among the most stringent.

• The Part 11 technical requirements:

Audit trails: Computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records. The audit trail must include the identity of the operator performing the action, what action was performed, when it was performed, and the original value if a record was modified.

This is the Part 11 requirement most directly relevant to SaMD development: your product’s data records, clinical data, algorithm outputs, user actions, must have an audit trail that meets Part 11 requirements if those records are required by FDA regulations.

Access controls: System access must be limited to authorized individuals. Unique user identification codes combined with passwords, biometrics, or other authentication mechanisms. Access control lists that are maintained and reviewed.

System validation: Computer systems that create, modify, maintain, or transmit electronic records must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

Record security: Electronic records must be protected to enable their accurate and ready retrieval throughout the records retention period. Records must be protected against unauthorized alteration or erasure.

Electronic signatures: When electronic signatures are used in place of handwritten signatures for records required by FDA regulations, they must meet Part 11 requirements: the signature is linked to the record in a way that cannot be excised, copied, or otherwise transferred; the signature includes the printed name of the signer, the date and time when the signature was executed, and the meaning of the signature (e.g., “approved,” “reviewed”).

• The practical Part 11 implementation for SaMD:

For most SaMD products, the practical Part 11 requirements come down to:

Audit log architecture: Every action that creates, modifies, or deletes a FDA-required record must generate an immutable audit log entry. The audit log entry must include: timestamp (UTC, with millisecond precision), user identity (unique user ID), action type (create/modify/delete), record type, record identifier, original value (if modified), and new value (if modified). The audit log must be append-only, no application process can delete or modify audit log entries.

System validation documentation: A validation protocol, execution records, and a validation summary report demonstrating that the system performs as intended. For SaMD, this is part of the Design Verification and Validation (V&V) documentation in the Design History File.

Access control documentation: A documented access control policy, user access lists, and periodic access review records.

Record retention: FDA-required records for medical devices must be retained for a period equivalent to the design and expected life of the device, at minimum two years from the device’s last commercial distribution date under 21 CFR §820.180.

Compliance trap: Many health tech startups implement a general audit log for HIPAA compliance and assume it satisfies Part 11. It does not, necessarily. HIPAA’s audit log requirements and Part 11’s audit log requirements have different specificity, different content requirements, and different retention implications.

A Part 11-compliant audit log must record the original value of a modified record alongside the new value, a requirement that many HIPAA-focused audit log implementations do not include. Evaluate your audit log architecture against both HIPAA and Part 11 requirements explicitly.

FDA Premarket Cybersecurity, The 2023 Guidance That Changed Everything

In September 2023, the FDA finalized its guidance on cybersecurity in medical devices, implementing the cybersecurity requirements of the Consolidated Appropriations Act, 2023 (Section 3305). This guidance applies to premarket submissions, including 510(k) and De Novo, submitted after October 1, 2023.

The 2023 guidance fundamentally changed what SaMD developers must submit to the FDA. Here is what is now required.

The Cybersecurity Management Plan:

A Cybersecurity Management Plan (CMP) must be submitted with any premarket submission for a device with cybersecurity risks. The CMP must describe:

• How the manufacturer will monitor, identify, and address postmarket cybersecurity vulnerabilities
• How the manufacturer will deploy patches and updates to address cybersecurity vulnerabilities in a reasonable time
• How the manufacturer will coordinate vulnerability disclosures with cybersecurity researchers and customers
• The manufacturer’s plan for end-of-life cybersecurity support

The CMP is not a security policy document. It is a specific FDA submission document with specific required content. It must be written by someone with experience in FDA submissions and cybersecurity, not just one or the other.

The Software Bill of Materials (SBOM):

An SBOM listing all software components in the device is required in premarket submissions. The SBOM must include:

• All commercial, open-source, and off-the-shelf software components
• Component name and version
• Component supplier
• Known vulnerabilities (referencing the NIST National Vulnerability Database)

The SBOM format must follow a machine-readable standard, SPDX or CycloneDX are the most commonly used formats that the FDA accepts. Generating an accurate SBOM requires integration with your software build system, not a manual inventory exercise.

For SaMD built on modern technology stacks, Node.js, Python, React, cloud-native services, the number of software components (direct and transitive dependencies) can exceed thousands. The SBOM generation and maintenance process must be automated from the beginning of development.

The Security Architecture Documentation:

The premarket submission must include documentation of the security architecture, how the device is designed to maintain security:

• Threat model: identified threat actors, attack vectors, and assets
• Security controls: how each identified threat is mitigated
• Authentication and authorization design
• Data encryption design (at rest and in transit)
• Audit logging design
• Software update mechanism design
• Network security design (for connected devices)

The threat model must follow a recognized methodology, STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the most commonly used methodology for medical device threat modeling.

Security testing requirements:

The premarket submission must include evidence of security testing:

• Penetration testing results, from a third-party penetration test against the production system
• Vulnerability scanning results
• Static application security testing (SAST) results
• Dynamic application security testing (DAST) results (if applicable for web-based SaMD)

The penetration test must be conducted by a qualified third-party cybersecurity firm, not by your internal engineering team. The test scope must cover the full system as it will be deployed in clinical environments.

The Coordinated Vulnerability Disclosure (CVD) policy:

The FDA requires that SaMD manufacturers have a published Coordinated Vulnerability Disclosure policy, a mechanism through which security researchers can report vulnerabilities to the manufacturer, and the manufacturer commits to a defined process for acknowledging, investigating, and remediating reported vulnerabilities.

The CVD policy must be publicly accessible, typically at security.yourcompany.com or yourcompany.com/security. It must include: how to submit a vulnerability report, what information to include, what the manufacturer’s acknowledgment timeline is, and what the manufacturer’s commitment is for investigation and remediation.

The Total Product Lifecycle (TPLC) cybersecurity approach:

The 2023 guidance emphasizes that cybersecurity cannot be a premarket-only consideration. The FDA expects manufacturers to maintain cybersecurity throughout the product’s lifecycle:

• Premarket: threat modeling, security architecture, security testing, SBOM
• At launch: CVD policy published, postmarket monitoring active, patch deployment capability operational
• Post-market: ongoing vulnerability monitoring (tracking the SBOM components against the NVD), vulnerability remediation and patching, customer notification of critical vulnerabilities, periodic penetration testing

EB Index 2026: Across SaMD-adjacent products we have worked on, the cybersecurity documentation for a 510(k) submission, threat model, security architecture, penetration test, SAST/DAST results, SBOM, CVD policy, and Cybersecurity Management Plan, takes an average of 14 weeks to produce correctly.

Teams that underestimate this timeline delay their submissions by an average of 8 weeks. Start the cybersecurity documentation in parallel with the clinical validation work, not after it.

Red flag: Any SaMD development plan that does not include SBOM generation in the CI/CD pipeline from Day 1 is building technical debt that will be expensive to resolve at submission time. A 12-month-old codebase with thousands of dependencies, none of which have been SBOM-tracked, requires weeks of engineering time to inventory correctly. Generate the SBOM automatically with every build from the first sprint.

The Quality Management System, ISO 13485 and 21 CFR Part 820

The FDA’s Quality System Regulation for medical devices, 21 CFR Part 820, now superseded by the Quality Management System Regulation (QMSR) that became effective February 2026, requires that medical device manufacturers establish and maintain a Quality Management System governing the design, development, production, and post-market activities for their devices.

The QMSR aligns the FDA’s QMS requirements with ISO 13485:2016, making ISO 13485 certification directly relevant to FDA compliance for the first time.

What the QMS requires for SaMD:

Design controls (21 CFR §820.30 / ISO 13485 §7.3): The most critical QMS element for SaMD. Design controls require:

• Design planning: a documented plan for each design and development activity, including responsible parties and review requirements
• Design inputs: documented requirements for the device, intended use, performance requirements, safety requirements, regulatory requirements
• Design outputs: documented outputs of the design process, specifications, source code, build artifacts, labeling, that meet the design inputs
• Design review: formal documented reviews at defined stages of development, with participation of representatives of all functions concerned with the design stage
• Design verification: objective evidence that the design outputs meet the design inputs, testing that confirms the device meets its specifications
• Design validation: objective evidence that the device meets user needs and intended uses, testing that confirms the device meets its clinical requirements, typically including human factors validation
• Design transfer: documented procedures ensuring the design is correctly translated into production specifications
• Design changes: documented process for evaluating, verifying, and validating design changes before implementation

Document control (21 CFR §820.40 / ISO 13485 §4.2.4): All QMS documents must be reviewed, approved, and controlled. Documents must be available at points of use, legible, and identifiable. Obsolete documents must be removed from use. Changes to documents require review and approval.

Risk management (ISO 14971): ISO 14971 is the international standard for medical device risk management. While not directly part of 21 CFR Part 820, ISO 14971 risk management is effectively required for FDA SaMD submissions, it is the methodology the FDA expects to see applied in the risk analysis that is part of every premarket submission.

The ISO 14971 risk management process: hazard identification, risk estimation, risk evaluation, risk control, residual risk evaluation, risk/benefit analysis, risk management report.

For SaMD, the risk analysis must address both software-specific risks (algorithm failure modes, incorrect outputs, user interface errors) and system-level risks (failure of connected systems, cybersecurity threats, misuse by clinicians).

CAPA (Corrective and Preventive Action, 21 CFR §820.100 / ISO 13485 §8.5.2/8.5.3): A documented process for identifying, analyzing, and correcting nonconformities, and preventing their recurrence. For SaMD, CAPA applies to: software defects identified in testing, clinical complaints, adverse events, audit findings, and vulnerability disclosures.

Complaint handling (21 CFR §820.198 / ISO 13485 §8.2.2): A documented process for receiving, reviewing, and evaluating complaints, including medical device reports (MDRs) for adverse events. Every user complaint that may relate to a device malfunction, injury, or death must be reviewed for MDR reportability.

Building the QMS before development starts:

The QMS must be established before design and development begins, not after the product is ready for market. The FDA’s design controls apply from the beginning of the design process.

For an early-stage SaMD startup, the minimum viable QMS includes:

• Quality Manual: one document describing your QMS scope, quality policy, and reference to your QMS procedures
• Design and Development Plan: the roadmap for your device’s design and ML or AI development, with phases, reviews, and responsibilities
• Risk Management Plan: your approach to ISO 14971 risk management for this device
• Document Control Procedure: how your QMS documents are created, reviewed, approved, and controlled
• CAPA Procedure: how you identify, investigate, and resolve nonconformities
• Complaint Handling Procedure: how you receive and evaluate complaints for MDR reportability

Build these six documents before you write the first line of production code. They do not need to be perfect, they need to exist and be followed. The QMS that exists and is followed imperfectly is better than the perfect QMS that is written after the fact.

ISO 13485 certification:

ISO 13485 certification is not legally required for FDA compliance. But it provides several practical benefits:

• The QMSR aligns with ISO 13485, so ISO 13485 compliance is effectively equivalent to QMSR compliance
• ISO 13485 certification is required by many international regulatory bodies (EU MDR, Health Canada, TGA) if you plan to market internationally
• Enterprise health system customers and large payers increasingly request ISO 13485 certification as part of vendor qualification
• ISO 13485 certification provides independent third-party validation of your QMS that is useful in fundraising and sales

For a SaMD startup targeting FDA clearance and enterprise health system customers: pursue ISO 13485 certification alongside your FDA submission preparation. The QMS you build for FDA compliance is 90% of what you need for ISO 13485 certification. Add the certification audit ($15,000–$40,000 for a notified body audit) and it becomes a meaningful credential that differentiates you from competitors.

Clinical Decision Support, The Exemption That Is Not What Founders Think

The 21st Century Cures Act created a carve-out for Clinical Decision Support (CDS) software, software that assists clinicians in making decisions but meets specific criteria that remove it from FDA device regulation. This exemption is the most misunderstood provision in health tech regulatory law.

The four-part CDS exemption test:

Under 21 CFR §880.3310 and the FDA’s 2022 CDS guidance, software qualifies for the CDS exemption if it:

1. Is not intended to replace clinical judgment of a healthcare professional. The software provides information; the clinician makes the decision.
2. Displays the basis for its recommendations so that the clinician can independently review the basis and is not dependent on the software’s conclusions.
3. Is not intended to acquire, process, or analyze a medical image, signal from an in vitro diagnostic device, or signal acquisition system. Software that analyzes medical images or diagnostic signals, regardless of how the output is framed, is a medical device.
4. Meets one of the following:
   • Intended to identify, treat, or prevent a condition or disease based on the patient’s current medical information, and the basis for the recommendation can be reviewed by a clinician without extensive specialized training
   • OR any other criteria the FDA may establish by regulation

The practical interpretation:

Condition 3 eliminates most AI diagnostic software from CDS exemption. Any software that:

• Analyzes medical images (X-rays, CT scans, MRI, pathology slides, dermoscopy images, fundus photos, ECG waveforms)
• Analyzes signals from in vitro diagnostic devices (glucose readings, troponin levels, other lab analyzer outputs)
• Analyzes physiological signals (EEG, EMG, spirometry, pulse oximetry waveforms)

…is NOT eligible for the CDS exemption, regardless of whether it “merely” provides decision support rather than a definitive diagnosis.

Condition 2 eliminates software that uses black-box AI without explainability. If the clinician cannot independently review the basis for the software’s recommendation, because the recommendation is produced by a neural network whose internal workings are not accessible, the software does not meet the CDS exemption criteria.

What the CDS exemption actually covers:

Software that is genuinely exempt from FDA regulation under the CDS framework includes:

• Drug-drug interaction checkers that flag potential interactions based on a formulary database
• Dosing calculators that compute medication doses from patient weight and renal function
• Evidence-based clinical guideline recommendations that surface relevant guidelines based on a patient’s documented diagnosis
• Risk calculators that compute clinical risk scores (CHADS2, Wells criteria, Framingham) from patient-entered data without analyzing physiological signals

For most AI-native clinical software, the CDS exemption does not apply. If you are building anything that analyzes images, signals, or diagnostic data, or that produces patient-specific recommendations using ML models, assume you are building a medical device until a regulatory attorney tells you otherwise.

The “not intended to replace clinical judgment” requirement:

This requirement is about more than a disclaimer in the user interface. The FDA evaluates the product’s design holistically, does the workflow enable and encourage independent clinician review, or does the workflow make the clinician’s independent review impractical?

A product that presents an AI-generated recommendation prominently and buries the supporting data where a clinician would need to take multiple steps to access it may fail this criterion even if a disclaimer states the software is not intended to replace clinical judgment.

Design your clinical workflow with the CDS exemption criteria in mind from the beginning, if CDS exemption is your regulatory strategy, the design must support it.

Compliance trap: Many health tech startups cite the CDS exemption in their investor materials and marketing copy before their regulatory attorney has formally analyzed whether the exemption applies.

If the FDA subsequently determines that your product is a medical device that has been marketed without clearance, the fact that you claimed CDS exemption in your investor deck is documented evidence of an intended use that you should have submitted for FDA review. Do not claim CDS exemption publicly until a regulatory attorney has documented the exemption analysis in writing.

The SaMD Software Development Lifecycle

SaMD development is not standard Agile software development. The FDA’s design controls require a structured development lifecycle that produces specific documentation artifacts, and that lifecycle is incompatible with shipping-first, documenting-later development practices.

The SaMD-compatible development model:

The challenge for health tech startups is reconciling the FDA’s design control requirements with the speed and iteration pace that venture-funded startups need. The solution is not to choose between regulatory compliance and development speed, it is to build regulatory compliance into the development process from the beginning, so it does not slow you down retrospectively.

The key insight: the FDA’s design controls document what you are doing anyway, planning, reviewing, testing, validating. The compliance cost is in the documentation, not in the activities. Building documentation habits from Day 1 costs less than reconstructing documentation for a 510(k) submission from a codebase and development history that was never documented with regulatory intent.

The Design History File (DHF) architecture:

The DHF is the central document of your SaMD development record. For a 510(k) submission, the FDA does not require you to submit the DHF, but it must exist and be producible for a FDA inspection. The DHF contains:

Design and Development Plan: Updated at each design phase. Defines phases, deliverables, responsibilities, and review requirements.

Design Inputs: The documented requirements for the device. For SaMD, this includes: intended use statement, indications for use, user needs, functional requirements, performance requirements, safety requirements, cybersecurity requirements, regulatory requirements.

Design Outputs: The documented outputs of each design phase. For SaMD: software architecture document, software design specification, source code (in version control), build artifacts, labeling drafts.

Design Review Records: Records of formal design reviews at each phase. Attendees, agenda, findings, action items, approval signatures.

Design Verification Records: Testing records demonstrating that design outputs meet design inputs. For SaMD: unit test results, integration test results, system test results, performance test results.

Design Validation Records: Evidence that the device meets user needs and intended uses. For SaMD: usability testing records, clinical validation study results, human factors validation.

Risk Management File: ISO 14971 risk analysis, risk control measures, residual risk evaluation, risk management report.

Cybersecurity Documentation: Threat model, security architecture, SBOM, penetration test report, SAST/DAST results.

Design Change Records: Documentation of design changes, change description, risk assessment of the change, verification/validation of the change, approval.

Version control as regulatory infrastructure:

For SaMD, version control is not just a development tool, it is regulatory infrastructure. The version control history is part of your design history. The FDA expects to be able to trace from a released software version back to the specific design inputs, design outputs, and verification/validation records that apply to that version.

Requirements:

• Every commit tagged with the developer’s identity and the change description
• Tagged releases with immutable version identifiers
• Branch protection, no direct commits to main/release branches
• Pull request reviews with documented approvals, who reviewed what, when, and their approval
• Links between version control commits/releases and requirements, defects, and test results

Tools we use for SaMD-compliant version control: GitHub or GitLab with branch protection rules, required pull request approvals, and integration with requirements management tools (Jira, Polarion, or Jama Connect for regulated environments).

The requirements traceability matrix:

A requirements traceability matrix (RTM) links every design input (requirement) to the design output that implements it, and to the verification or validation test that confirms it is correctly implemented. For a 510(k) submission, the RTM demonstrates to the FDA that every requirement has been implemented and tested.

Building the RTM from the beginning, linking requirements to code, linking code to tests, linking tests to results, is far less expensive than reconstructing it from a completed codebase. Build the RTM in parallel with development, not after.

Agile development within design control constraints:

Most SaMD startups use Agile development, sprints, backlog refinement, continuous integration. Agile is compatible with FDA design controls if the design control documentation is built into the sprint process:

• Sprint planning produces updated design outputs and updated test plans
• Sprint review includes design review documentation
• Every merged pull request updates the RTM (requirement → code → test linkage)
• Sprint retrospectives that identify process improvements feed the CAPA process
• Each sprint produces an updated SBOM

The documentation overhead per sprint is real, typically 15–20% of sprint capacity for a team that is doing it correctly. This is not optional overhead. It is the cost of building a device rather than software.

The Real Cost Stack for SaMD Development in 2026

• Engineering (what you pay us):

SaMD-compliant software development with QMS documentation, design controls, cybersecurity documentation, Part 11-compliant audit trail, and SBOM generation:

Class II SaMD MVP development (single indication, non-image-based, 510(k) pathway with predicate): $180K–$290K / 16–24 weeks (engineering + QMS documentation)

Class II SaMD MVP (image-based, AI/ML algorithm, 510(k) or De Novo pathway): $240K–$400K / 22–32 weeks

Dedicated SaMD pod post-submission: $32K–$52K/month

• Regulatory consulting:

Regulatory attorney for classification opinion and regulatory strategy: $8K–$20K 510(k) submission preparation (regulatory consulting firm): $120K–$280K De Novo submission preparation: $200K–$450K PMA submission preparation: $800K–$3M+ FDA Pre-Submission (Q-Sub) meeting preparation: $15K–$35K ISO 13485 gap assessment: $8K–$20K ISO 13485 certification (notified body audit): $15K–$40K

• Clinical validation:

Clinical study design and IRB submission: $25K–$60K Clinical study conduct (site costs, data collection, monitoring): $150K–$500K+ depending on sample size, number of sites, and study design Clinical study analysis and reporting: $30K–$80K Biostatistics consulting: $20K–$60K

• Cybersecurity:

Third-party penetration test: $15K–$40K (medical device penetration testing is more comprehensive than standard web application testing) SBOM tooling (commercial): $10K–$30K/year (Anchore, Snyk, Black Duck) Cybersecurity consulting for threat model and CMP: $20K–$50K

• FDA submission fees (FY2026):

510(k) small business fee: approximately $22,000 510(k) standard fee: approximately $134,000 De Novo: No user fee PMA small business fee: approximately $225,000 PMA standard fee: approximately $450,000

• Post-market obligations (ongoing):

MDR system and complaint handling infrastructure: $15K–$30K/year (tooling + staff time) Postmarket surveillance activities: $20K–$60K/year SBOM maintenance and vulnerability monitoring: $10K–$25K/year Annual penetration testing: $15K–$40K/year ISO 13485 surveillance audits: $8K–$20K/year

EB Index 2026: The median total cost for a US health tech startup to achieve FDA 510(k) clearance for a Class II SaMD product, from regulatory strategy engagement through clearance receipt, was $1.2M. The median timeline was 22 months from regulatory strategy engagement to clearance. The largest single cost component was clinical study conduct at $320,000 (median). The largest timeline driver was clinical study execution at 11 months (median from study start to final data lock).

What we’d cut: For a pre-Series A SaMD founder with under $5M raised: pursue the De Novo pathway only if you have a genuinely novel product in an emerging category with no predicate. The De Novo pathway’s lack of user fee does not offset its greater regulatory complexity and longer timeline for most products. For most Class II SaMD, find the predicate first, then design to 510(k).

The 16-Week SaMD MVP Sprint

This timeline covers building a SaMD-compliant engineering foundation, QMS establishment, design controls implementation, SaMD-compliant development environment, and core product build with regulatory documentation, for a Class II non-image-based SaMD targeting 510(k) clearance.

This is the engineering sprint. The regulatory submission preparation, clinical study conduct, submission document preparation, runs in parallel and extends well beyond 16 weeks.

• Week 1: Regulatory Strategy and QMS Establishment

Regulatory attorney engagement. Intended use statement drafted. Device classification confirmed. Regulatory pathway selected (510(k), De Novo). Predicate device identified (if 510(k)). QMS established: Quality Manual, Design and Development Plan, Risk Management Plan, Document Control Procedure, CAPA Procedure, Complaint Handling Procedure. Quality management tooling selected (MasterControl, Veeva Vault, Greenlight Guru, or similar). FDA Pre-Submission (Q-Sub) meeting request filed.

• Week 2: Design Inputs and Risk Management Foundation

Design inputs documented: intended use, indications for use, user needs, functional requirements, performance requirements, safety requirements, cybersecurity requirements, regulatory requirements. ISO 14971 risk management process started: hazard identification, risk estimation methodology defined. Design and Development Plan updated with phase structure and review schedule.

• Week 3: Architecture and Security Design

Software architecture designed with regulatory documentation: system components, interfaces, data flows, deployment architecture. Threat model produced using STRIDE methodology. Security architecture documented: authentication, authorization, encryption, audit logging, update mechanism. SBOM generation integrated into CI/CD pipeline from this week forward. Cybersecurity requirements documented in design inputs.

• Week 4: Development Environment and Part 11 Infrastructure

Version control configured with branch protection, required pull request approvals, and identity-linked commits. Part 11-compliant audit trail service deployed, immutable, append-only, with original value capture for modifications. Requirements traceability matrix structure established, requirements management tool configured. SBOM tooling operational in CI/CD pipeline. Design output: Software Architecture Document.

• Weeks 5–10: Core Feature Build with Design Control Documentation

Feature development in sprints. Each sprint produces: updated design outputs (code, specifications), updated RTM entries (requirement → code → test linkage), sprint design review record, updated SBOM (generated automatically). Every pull request: peer-reviewed with documented approval, linked to requirement in RTM, triggers SAST scan (Semgrep, SonarQube). No feature merges without SAST review. Each sprint ends with a formal design review record.

• Week 11: Design Verification Testing

Systematic verification testing against every design input requirement. Unit tests, integration tests, system tests. Performance tests against specified performance requirements. Test results documented in the DHF with traceability to requirements. Any verification failures: change request opened, design change evaluated for risk impact, design change implemented and re-verified.

• Week 12: Cybersecurity Testing

SAST results reviewed and findings addressed. DAST testing if applicable. Third-party penetration test scoped and initiated (may extend into Week 13–14). Vulnerability scanning against SBOM components using NVD database. Cybersecurity findings triaged and addressed. Cybersecurity documentation package assembled: threat model, security architecture, SBOM, testing results.

• Week 13: Human Factors Validation Planning and Usability Testing

Human factors validation study designed, per FDA human factors guidance and IEC 62366. Use-related risk analysis completed. Summative usability testing conducted with representative users in simulated use environment. Human factors validation report drafted. Any use errors identified in usability testing: design modifications, retest.

• Week 14: Clinical Validation Study Setup (Parallel Workstream)

Clinical study protocol finalized with biostatistics input. IRB submission prepared and submitted. Clinical study sites identified and contracted. Clinical data collection infrastructure built in the product (with Part 11-compliant records). Clinical study data management plan documented. Note: IRB review typically takes 4–8 weeks, this workstream started earlier in parallel.

• Week 15: Pre-Submission Meeting with FDA

Pre-Submission (Q-Sub) meeting with FDA conducted (if scheduled, timeline depends on FDA scheduling, typically 60–90 days from request). FDA feedback on proposed regulatory strategy, clinical study design, and performance testing approach incorporated. Any required design or study changes initiated.

• Week 16: DHF Review and Regulatory Submission Preparation

Complete Design History File reviewed against 510(k) submission requirements. Gaps in documentation identified and addressed. Submission strategy finalized with regulatory consulting firm. 510(k) submission preparation initiated, this extends well beyond Week 16. Software documentation section of 510(k) (software description document, level of concern assessment, software architecture, hazard analysis, V&V testing summary) drafted.

AI/ML-Based SaMD, The Most Complex Regulatory Category in Digital Health

AI/ML-based SaMD is the most rapidly growing and most regulatory-complex category of medical device in 2026. The FDA has been actively developing its regulatory framework for AI/ML-based SaMD since 2019, and that framework continues to evolve.

• The unique regulatory challenge of AI/ML-based SaMD:

Traditional medical device regulatory pathways were designed for devices with fixed, predetermined software functions. A 510(k)-cleared algorithm does the same thing in version 1.0 as it does in version 1.1, the only change is bug fixes, not algorithmic behavior. The substantial equivalence argument holds because the device’s function is stable.

AI/ML models are different. They can be retrained on new data, their internal weights change with training, and their output behavior can change in ways that are not fully predictable from their architecture. A retrained AI/ML model that nominally performs the same function as the cleared version may behave differently on patient populations, image acquisition conditions, or clinical contexts that were not represented in the training data.

The FDA’s traditional 510(k) pathway, which would require a new submission for every algorithm update, is not designed for the iteration pace of AI/ML development. This tension is at the center of the FDA’s AI/ML regulatory framework.

• The Predetermined Change Control Plan (PCCP):

The FDA’s response to the AI/ML iteration challenge is the Predetermined Change Control Plan, introduced in draft guidance in 2019 and finalized in guidance in 2023. The PCCP allows a SaMD manufacturer to describe, in the original submission, the types of algorithm modifications they plan to make post-clearance, and to receive FDA pre-approval for those changes.

If the PCCP is approved in the original submission, the manufacturer can make PCCP-specified algorithm changes without a new 510(k) submission, as long as the changes remain within the boundaries described in the PCCP and the manufacturer follows the change control procedures specified in the PCCP.

What a PCCP covers:

Description of anticipated modifications: Specific types of algorithm changes, retraining on expanded datasets, updating preprocessing pipelines, adjusting decision thresholds, described precisely enough that the FDA can evaluate whether each change remains within the cleared device’s risk profile.

Performance monitoring: How the manufacturer will monitor the algorithm’s performance post-deployment, what metrics are tracked, what thresholds trigger a review or a modification, how monitoring data is collected.

Methodology for making modifications: How algorithm updates are validated before deployment, what testing is performed, what performance benchmarks must be met, what documentation is produced.

Transparency: How changes are communicated to users and clinical customers, labeling updates, customer notifications, update documentation.

The PCCP is a complex regulatory document that requires collaboration between your regulatory attorney and your ML engineering team. It must be specific enough to give the FDA confidence in your change control process and flexible enough to accommodate the algorithm development you actually plan to do.

• AI/ML algorithm documentation for FDA submissions:

The FDA expects specific documentation of AI/ML algorithms in SaMD submissions:

Algorithm description: The type of algorithm (supervised learning, deep learning, reinforcement learning), the model architecture (CNN, transformer, ensemble, etc.), the training approach, the inference mechanism.

Training data description: The source of training data, the size and demographics of the training dataset, how the dataset was curated and labeled, how data quality was assessed, how class imbalance was handled. The FDA will scrutinize training data for potential biases that could lead to disparate performance across patient subgroups.

Performance testing: Training and validation performance (accuracy, sensitivity, specificity, AUC-ROC as appropriate), test set performance on a held-out dataset not used in training or validation, performance across clinically relevant subgroups (age, sex, race/ethnicity, clinical site, imaging equipment, for image-based algorithms).

Subgroup analysis: The FDA requires subgroup performance analysis demonstrating that the algorithm performs equitably across demographically and clinically diverse patient populations. Algorithms that perform well overall but perform poorly for specific demographic subgroups (a documented problem in many medical AI algorithms) face additional regulatory scrutiny.

Algorithm transparency and explainability: For clinical decision support AI, the FDA expects that clinicians can understand the basis for the algorithm’s outputs. For deep learning algorithms, this typically means: attention maps, saliency maps, or similar explainability mechanisms that show the clinician which features of the input drove the algorithm’s output.

• The real-world performance monitoring obligation:

Once an AI/ML SaMD is cleared, the manufacturer is expected to monitor real-world performance, how the algorithm performs on actual patient populations, in actual clinical environments, on actual imaging equipment, and compare it to the performance demonstrated in the premarket submission.

Real-world performance monitoring requires: a defined performance metric, a data collection mechanism (which may require IRB approval if new clinical data is collected for monitoring purposes), a performance threshold that triggers investigation or corrective action, and a reporting mechanism for significant performance deviations.

Build real-world performance monitoring into the product architecture from the beginning, collect the performance data, store it, analyze it, and report on it. This infrastructure is required by the PCCP and expected by the FDA; it is also clinically valuable for demonstrating your algorithm’s real-world impact to health system customers.

From a US founder call: “We built a radiology AI product and went through the 510(k) process. The performance data from our submission looked great. Six months after clearance, our real-world performance monitoring showed the algorithm was performing 12 points lower on sensitivity at one of our six clinical sites.

The difference traced to a difference in X-ray machine manufacturer, our training data was dominated by one manufacturer’s equipment and the algorithm had not generalized to a different manufacturer’s outputs. We had to retrain, validate, and, because this was outside our PCCP, submit a new 510(k) for the updated algorithm.

If we had included ‘retraining on expanded equipment diversity data’ in the PCCP, we would have avoided a new submission. Include everything you might want to change in the PCCP. Everything.”, Series A radiology AI founder, Chicago.

Post-Market Surveillance and the Predetermined Change Control Plan

• Medical Device Reporting (MDR):

FDA regulation 21 CFR Part 803 requires manufacturers to report to the FDA within specific timelines when they become aware that a device may have caused or contributed to a serious injury or death, or when a device malfunctions and would be likely to cause or contribute to a serious injury or death if the malfunction were to recur.

For SaMD, MDR-reportable events include: algorithm outputs that contributed to a clinical decision that resulted in patient harm, software failures that prevented clinical staff from accessing critical patient information, and cybersecurity incidents that compromised device function.

MDR timelines: 30-calendar-day report for deaths and serious injuries. 5-calendar-day report for events that require remedial action to prevent unreasonable risk of substantial harm to public health.

MDR infrastructure: a complaint handling system that captures all user complaints, a process for evaluating each complaint for MDR reportability, a documented decision record for each complaint (reportable or not reportable, with rationale), and a mechanism for filing MDR reports electronically through the FDA’s MedWatch Plus system.

• Postmarket surveillance (21 CFR Part 822):

The FDA may require postmarket surveillance studies for Class II or Class III devices where the FDA determines that postmarket surveillance is necessary to protect public health or to provide safety and effectiveness data. For AI/ML SaMD, the FDA is increasingly requiring postmarket surveillance commitments as a condition of clearance.

Postmarket surveillance for AI/ML SaMD typically involves: prospective collection of real-world performance data, analysis of algorithm performance across clinical sites and patient subgroups, reporting to the FDA at defined intervals, and investigation of any significant performance deviations.

• The recall and field safety corrective action:

If a SaMD has a defect that presents a risk to health, the manufacturer must initiate a recall or field safety corrective action (FSCA). For software, this typically means deploying a software update that corrects the defect and notifying affected customers.

The recall process: health hazard evaluation, recall strategy, recall communications to affected customers, FDA notification (within 10 working days of initiating a Class I or Class II recall), recall effectiveness checks, and recall termination.

Software recalls for SaMD are less operationally complex than hardware recalls, deploying a software update does not require retrieving a physical device. But the regulatory process is identical. Build your update deployment infrastructure, and your customer notification mechanism, to support a rapid recall response before you go to market.

When an Indian Engineering Partner Is Wrong for Your SaMD Build

An Indian engineering partner is the wrong call for your SaMD build if: your regulatory strategy requires that all software development be performed by staff with specific FDA-regulated environment training and located in the US, some federal health system procurement contracts and some Defense Health Agency programs include this requirement.

If your QMS requires that design review meetings be conducted in person, increasingly uncommon, but some notified body auditors have expressed preference for in-person design review records.

If your clinical study conduct requires engineering team members to be physically present at clinical sites for system integration, more relevant for hardware-adjacent SaMD than for pure software.

If your regulatory attorney or investor diligence team has raised a specific concern about offshore SaMD development that has not been resolved with evidence of process maturity.

For the vast majority of SaMD startups building Class II 510(k) or De Novo products: the structured collaboration model, US-based regulatory consulting firm, US-based clinical study management, Indore-based engineering team with SaMD-compliant development practices and US-overlap window for design review meetings, is viable.

We have supported SaMD-compliant development from Indore, with US-based regulatory consulting partners handling the FDA-facing submission work. The engineering, building the Part 11-compliant audit trail, generating the SBOM, implementing the security architecture, running SAST in the CI/CD pipeline, documenting the DHF, is engineering work. It does not require a US location.

What does require US presence: FDA Pre-Submission meetings, clinical investigator meetings, FDA inspections, and regulatory attorney client meetings. These are not engineering activities.

The SaMD Development Scorecard

Score each row 0 (absent), 1 (partial), or 2 (fully present). Maximum score: 70.

#	Criterion	Weight	Your Score
1	Intended use statement written and reviewed by regulatory attorney before development	2×	/4
2	Device classification confirmed with regulatory attorney (Class I, II, or III)	2×	/4
3	Regulatory pathway selected (510(k), De Novo, PMA) with predicate identified if 510(k)	2×	/4
4	Quality Management System established before design and development began	2×	/4
5	Design History File maintained from first sprint	2×	/4
6	Design inputs documented (intended use, performance requirements, safety requirements)	2×	/4
7	Requirements Traceability Matrix maintained (requirement → code → test)	2×	/4
8	ISO 14971 risk management process active with risk management file	2×	/4
9	SBOM generated automatically in CI/CD pipeline from project start	2×	/4
10	Part 11-compliant audit trail with original value capture for modifications	2×	/4
11	Threat model produced using STRIDE or equivalent methodology	1×	/2
12	Third-party penetration test completed before submission	1×	/2
13	Cybersecurity Management Plan drafted	1×	/2
14	Coordinated Vulnerability Disclosure policy published	1×	/2
15	SAST integrated into CI/CD pipeline with blocking on critical findings	1×	/2
16	Human factors validation study conducted with representative users	2×	/4
17	Clinical validation study designed to FDA evidentiary standards	2×	/4
18	FDA Pre-Submission (Q-Sub) meeting requested or completed	1×	/2
19	CDS exemption analysis documented if CDS exemption is claimed	2×	/4
20	PCCP included in submission (if AI/ML SaMD with planned algorithm updates)	1×	/2
21	MDR complaint handling system operational	1×	/2
22	Real-world performance monitoring infrastructure built (if AI/ML SaMD)	1×	/2
23	ISO 13485 certification obtained or in progress	1×	/2
24	Postmarket surveillance plan documented	1×	/2
25	Version control with immutable release history and identity-linked commits	1×	/2

Score interpretation:

• 55–70: Strong SaMD regulatory posture, ready for FDA submission preparation
• 40–54: Proceed with identified gaps remediated, regulatory 2× items are submission-critical
• Under 40: Significant regulatory exposure, do not deploy clinically or market as a medical device until gaps are closed

Conclusion

SaMD development is the most regulated, most expensive, and most consequential category of health tech product to build. The clinical AI feature that took one sprint to add takes fourteen months and $380,000 to bring back to market after it is discovered to be a medical device that was shipped without FDA clearance.

The founders who navigate this correctly, who write the intended use statement in Week 1, who get the device classification opinion before sprint one, who build the QMS before they write the first line of production code, who include the PCCP in the original submission for their AI/ML algorithm, are the ones who reach the market on the timeline they planned.

The founders who discover their regulatory obligations in month nine are the ones who rebuild, retest, and revalidate on the investor’s clock.

The regulatory conversation is not the most exciting conversation in health tech product development. It is also the most consequential. Get it right before you build. Everything that follows is easier when the foundation is correct.

If you want 30 minutes to talk through your SaMD product, what your intended use is, what your device classification likely is, what your regulatory pathway should be, and what the build needs to look like to support a 510(k) submission, book a call with me or Aditi. No slides. No pitch. Just the regulatory conversation.

FAQ

• What is the difference between SaMD and regular healthcare software?

SaMD is software intended to be used for one or more medical purposes, diagnosis, treatment, cure, mitigation, or prevention of disease, without being part of a hardware medical device. Regular healthcare software (EHR administrative functions, billing software, appointment scheduling) is not intended for medical purposes and is not subject to FDA regulation as a medical device. The distinction is the intended use and the risk to patients if the software performs incorrectly.

• Does the clinical decision support exemption apply to my AI diagnostic tool?

Probably not. The CDS exemption under the 21st Century Cures Act does not apply to software that acquires, processes, or analyzes a medical image, signal from an in vitro diagnostic device, or physiological signal. Most AI diagnostic tools analyze one of these input types. Additionally, the exemption requires that the basis for recommendations be displayable for independent clinician review, which is challenging for deep learning models without explainability mechanisms. Get a regulatory attorney’s written CDS exemption analysis before claiming exemption.

• What is a 510(k) and how long does it take?

A 510(k) is a premarket notification to the FDA demonstrating that your SaMD is substantially equivalent to a legally marketed predicate device. The FDA’s review target is 90 days from acceptance. In practice, total time from submission start to clearance, including submission preparation, any FDA additional information requests, and the review period, is typically 6–12 months for a well-prepared submission. For first-time submitters in novel categories, 12–18 months is common.

• What does 21 CFR Part 11 require for SaMD?

Part 11 requires that electronic records required by FDA regulations be maintained with: computer-generated time-stamped audit trails recording who created, modified, or deleted each record and what the original value was; access controls limiting system access to authorized individuals; system validation; and record security ensuring accurate retrieval throughout the retention period. For SaMD, the most relevant Part 11 requirement is the audit trail for design history records, clinical study records, and any product records that FDA regulations require.

• What is an SBOM and why does the FDA require it?

A Software Bill of Materials is a comprehensive inventory of all software components in your device, commercial software, open-source libraries, third-party components, with their versions and known vulnerabilities. The FDA’s 2023 cybersecurity guidance requires an SBOM in premarket submissions because software component vulnerabilities are a significant cybersecurity risk in medical devices. The SBOM allows the FDA to assess whether known vulnerabilities in your software components have been addressed or accepted with documented rationale.

• What is the Predetermined Change Control Plan for AI/ML SaMD?

The PCCP is a document submitted with the original 510(k) that describes the types of algorithm modifications the manufacturer anticipates making post-clearance and the validation methodology for those modifications. FDA pre-approval of the PCCP allows specified algorithm changes to be made without a new 510(k) submission, provided the changes remain within the PCCP’s boundaries and follow the specified change control procedures. The PCCP addresses the fundamental tension between AI/ML’s iterative development nature and the FDA’s traditional device clearance framework.

• How much does FDA 510(k) clearance cost for a SaMD product?

Total cost from regulatory strategy engagement through 510(k) clearance, including regulatory consulting, clinical study conduct, cybersecurity testing, and FDA submission fees, averages $1.2M based on the 2026 EngineerBabu Healthcare Build Report. The largest cost component is clinical study conduct at a median of $320,000. The FDA submission fee for small businesses is approximately $22,000. Timeline: median 22 months from regulatory strategy engagement to clearance.

• What is De Novo classification and when should I use it?

De Novo is an FDA pathway for novel low-to-moderate risk devices that do not have a legally marketed predicate for 510(k) substantial equivalence. A successful De Novo results in a new device classification and special controls, and the authorized device becomes a predicate for future 510(k) submissions. Use De Novo when your AI/ML SaMD is genuinely novel in its diagnostic category with no comparable predicate device. De Novo takes 12–24 months and requires more comprehensive clinical evidence than a typical 510(k), but it creates a regulatory first-mover advantage in the device category.

• Do I need ISO 13485 for FDA SaMD clearance?

ISO 13485 certification is not legally required for FDA SaMD clearance, the FDA’s Quality Management System Regulation (QMSR) is the legal requirement, and it is now aligned with ISO 13485:2016. In practice, building a QMSR-compliant QMS is equivalent to building an ISO 13485-compliant QMS. Pursuing ISO 13485 certification alongside FDA submission preparation adds the notified body audit cost ($15,000–$40,000) but provides third-party validation of your QMS and is required for international market access (EU MDR, Health Canada, TGA).

• What triggers a new FDA submission after my device is cleared?

Changes to a cleared device that require a new 510(k) include: changes to the intended use, changes to indications for use, changes to the fundamental technology that introduce new safety questions, and changes that could significantly affect safety or effectiveness. Minor bug fixes, UI changes that do not affect functionality, and security patches typically do not require a new submission. For AI/ML SaMD, algorithm retraining that changes performance beyond the cleared specifications typically requires a new submission unless covered by an approved PCCP.