SBOM Now Required: SaMD Regulatory Strategy for U.S. Founders

A defensible SaMD regulatory strategy for the U.S. is a risk based, total product lifecycle plan that anchors on FDA classification, an evidence durability strategy, QMSR alignment, cybersecurity readiness, and, where applicable, an authorized Predetermined Change Control Plan. Skip any one of these five components and you build a submission that either stalls in review or breaks the first time you ship an update.

TL;DR:

• The FDA expects a risk-based, lifecycle regulatory strategy that includes classification, evidence durability, quality management, cybersecurity, and change control plans.
• Proper classification relies on intended use, decision impact, and hardware independence to avoid over- or under-classification issues that complicate review.
• Risk categorization determines the evidence depth, validation requirements, and postmarket surveillance level, making early mapping essential for strategy.
• Choosing the right pathway depends on predicate existence, with 510(k) for similar existing devices, De Novo for novel software, and PMA for high-risk, evidence-intensive applications.
• Ongoing lifecycle management, clear documentation, and early regulator engagement are critical to avoiding delays and ensuring smooth review and postmarket compliance.

Table of Contents

• What SaMD Is and How the U.S. Defines Its Scope
• How Risk Categorization Shapes Your Regulatory Burden
• Choosing Your FDA Pathway: 510(k), De Novo, PMA, and When to Ask First
• QMSR and ISO 13485: What Changes Now for Founders
• Cybersecurity and Section 524B: The Deliverables You Cannot Skip
• AI/ML Governance: Using a PCCP to Avoid Repeated Submissions
• Building an Evidence Strategy That Survives Updates
• Computer Software Assurance: Validating at the Speed You Actually Need
• Sequencing U.S. and Global Submissions Without Duplicating Work
• A Time-Aware Roadmap From Pre-Submission to Postmarket
• Why Trust This Guide: Author and The StartUp MD Proof Points
• How U.S. Strategy Differs From EU MDR and Japan's PMDA
• Documentation Practices That Hold Up Under FDA Review
• Regulatory Considerations When Your Software Touches Hardware or Other Systems
• Talking to Regulators Without Losing Time or Trust
• When a Software Update Requires a New Look at Your Clearance
• Regulatory Realities of Cloud-Based SaMD Deployment
• The Part of SaMD Strategy Most Teams Get Backward
• How The StartUp MD Supports Your SaMD Regulatory Strategy
• FAQ

What SaMD Is and How the U.S. Defines Its Scope

Software as a Medical Device is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device, a definition the IMDRF SaMD framework established and that FDA applies in its own oversight of digital health products. The word that matters most is independence. If your software's medical function depends on running as part of a specific piece of hardware, it is likely embedded software governed alongside that hardware, not SaMD.

The practical test founders should run before writing a single line of regulatory strategy has three parts:

• Intended use: does the software's labeling or marketing claim a diagnostic, treatment, or clinical decision function.
• Decision impact: does the output inform, drive, or trigger a clinical action, versus simply organizing or displaying existing data.
• Hardware independence: does the software perform its medical purpose on general purpose computing infrastructure rather than as a control element of a specific device.

Edge cases separate serious regulatory strategy from guesswork. A mobile app that displays glucose readings from a connected meter without interpretation is closer to an accessory. The same app adding a dosing recommendation engine crosses into SaMD territory because it now shapes a clinical decision. Teams that get this wrong tend to either over classify a simple data viewer, wasting time and money, or under classify a decision support tool, which creates far more expensive problems later. Our related guide on avoiding 510(k) through device qualification walks through several of these boundary cases in more detail.

How Risk Categorization Shapes Your Regulatory Burden

IMDRF's risk categorization framework sorts SaMD into four categories by crossing two variables: the significance of the information the software provides to a healthcare decision, and the state of the healthcare situation or condition it addresses, from critical to serious to non-serious. FDA uses this same logic when it evaluates classification requests and 513(g) inquiries, so getting your category right early saves you from a painful reclassification argument mid-review.

1. Category I covers software providing information to inform clinical management for non-serious conditions, the lightest regulatory footprint and often eligible for enforcement discretion or a straightforward 510(k).
2. Category II covers software that drives clinical management for non-serious conditions or informs management for serious conditions, typically requiring a fuller evidence package and a 510(k) or De Novo pathway.
3. Category III covers software that drives management for serious conditions or informs management for critical conditions, pushing evidence expectations toward robust clinical validation and often a De Novo or PMA track.
4. Category IV covers software that drives clinical management for critical conditions, the highest scrutiny tier, almost always requiring the deepest analytical and clinical validation and close FDA engagement from the earliest pre-submission meeting.

The category you land in determines more than paperwork volume. It sets the depth of analytical and clinical validation FDA will expect, the granularity of your postmarket surveillance plan, and how much documentation your quality system needs to produce on demand during an audit. A symptom checker that only suggests when to see a doctor sits in Category I. A sepsis prediction algorithm that triggers an ICU alert sits in Category III or IV, and no amount of clever engineering changes that classification. Map your category before you build your evidence plan, not after, because the category dictates the plan's shape.

Choosing Your FDA Pathway: 510(k), De Novo, PMA, and When to Ask First

Pathway selection is where regulatory strategy either saves a founder eighteen months or costs them that same amount of time in a rejected submission. The starting question is always whether a predicate device exists.

A 510(k) works when you can identify a legally marketed predicate with the same intended use and similar technological characteristics, and demonstrate substantial equivalence. This is the fastest route for Category I and much of Category II SaMD, particularly software that automates or accelerates a task clinicians already perform manually with an equivalent tool on the market.

A De Novo pathway fits novel software with no suitable predicate but a risk profile FDA can manage through special controls, essentially creating a new device classification. Many first-generation AI/ML diagnostic tools have gone this route because nothing functionally equivalent existed before them. Our breakdown of De Novo versus 510(k) strategy covers the tradeoffs founders weigh most often, particularly around timeline certainty and the strength of evidence required.

A PMA applies to Category III and IV SaMD supporting the highest risk clinical decisions, where FDA requires the most rigorous demonstration of safety and effectiveness, generally including prospective clinical data.

Before committing to any of these, two tools de-risk the decision:

• A 513(g) request gets FDA's written opinion on how your software would be classified, useful when your product sits ambiguously between accessory and standalone SaMD.
• A Q-submission (Q-sub) meeting lets you present your intended use, proposed pathway, and evidence plan to FDA reviewers before you file, catching pathway mismatches while they are still cheap to fix.

If your evidence plan depends on data you have not yet collected, an Investigational Device Exemption (IDE) may be required to legally gather clinical data on human subjects before your marketing submission. IDE review timelines and clinical data collection windows should be built into your product roadmap at the funding and staffing stage, not discovered after a De Novo pre-sub meeting reveals the gap. Teams that treat the Q-sub as optional consistently lose more calendar time than the meeting itself would have cost them.

QMSR and ISO 13485: What Changes Now for Founders

FDA's Quality Management System Regulation became effective February 2, 2026, and it incorporates ISO 13485:2016 by reference, meaning your quality system is now measured against an international standard rather than FDA's legacy 21 CFR 820 framework alone. For SaaS-native teams used to agile sprints and continuous deployment, this is the single biggest operational shift in this article.

Four actions matter immediately:

• Run a gap analysis comparing your current development process against ISO 13485:2016 clauses on design and development, particularly design controls and design history file requirements.
• Build design control evidence into your existing sprint process rather than bolting on documentation after the fact, since retrofitting design history is far more expensive than capturing it as you build.
• Establish supplier and third-party software governance, since QMSR expects documented control over any outsourced component, open source library, or cloud service that touches your device software.
• Create traceability artifacts, linking requirements to design outputs to verification and validation results, in a format an FDA auditor can follow without your engineering team narrating it live.

Our detailed walkthrough of QMSR alignment steps under 21 CFR 820 covers the traceability matrix format auditors expect most often. For design control specifics, the guide to 21 CFR 820.30 and IEC 62304 is worth reviewing before your next major release.

Pro Tip: Treat your design history file as a living artifact updated every sprint, not a document assembled the week before an audit.

Cybersecurity and Section 524B: The Deliverables You Cannot Skip

Section 524B of the FD&C Act, reinforced by FDA cybersecurity guidance updated in February 2026, requires manufacturers of what FDA calls "cyber devices" to build a documented cybersecurity plan into their premarket submission, not treat it as a postmarket afterthought. If your SaMD connects to the internet, exchanges data with another system, or contains software components that could be exploited, you are almost certainly in scope.

A Software Bill of Materials, or SBOM, is now a required premarket artifact under Section 524B for cyber devices, meaning your release pipeline needs to generate and maintain one automatically rather than reconstruct it manually before each submission, according to FDA's cybersecurity guidance. That SBOM becomes the backbone of your ongoing vulnerability monitoring, since you cannot track third-party component risk you have not inventoried.

The core deliverables your submission needs:

• A postmarket monitoring plan describing how you will identify and assess new vulnerabilities across the product's commercial life.
• A patching and update timeline committing to defined response windows for critical versus low-severity findings.
• A coordinated vulnerability disclosure process, typically including participation in an Information Sharing and Analysis Organization, per FDA's postmarket cybersecurity guidance.
• Design evidence mapping to the five widely used security objectives: authenticity, authorization, availability, confidentiality, and updatability.

Practically, this means your QMS needs a cybersecurity risk management file that sits alongside your clinical risk file, not buried inside general engineering documentation. Our FDA cybersecurity checklist breaks these deliverables into developer-level tasks your engineering team can action directly, and a partner resource on AI transformation and lifecycle governance is useful if your cybersecurity monitoring itself relies on automated or AI-assisted tooling.

AI/ML Governance: Using a PCCP to Avoid Repeated Submissions

A Predetermined Change Control Plan lets you specify, in advance, the modifications you plan to make to an AI/ML enabled device and gain FDA authorization to implement those changes without filing a new marketing submission each time, according to FDA's PCCP guidance. For any SaMD that retrains or updates its model on a regular cadence, this is the difference between shipping improvements monthly and shipping them once every regulatory cycle.

A complete PCCP has three required components:

1. A description of the modifications, stating precisely what will change, such as retraining on new data or adjusting a decision threshold.
2. A modification protocol, detailing the verification and validation methods and acceptance criteria FDA expects to see spelled out with enough specificity to permit authorization without ambiguity.
3. An impact assessment, analyzing the benefits and risks of the planned changes and how they will be monitored postmarket.

PCCPs make the most sense when your model genuinely needs to evolve, retraining pipelines, threshold recalibration, expanding to a new population subset within the same intended use. Traditional change control, filing a new submission for each modification, remains the right call when changes are infrequent, unpredictable, or would alter the fundamental intended use, since a PCCP cannot authorize changes it did not anticipate.

Pro Tip: Draft your PCCP's acceptance criteria as if a reviewer with no context on your model will read only that document, because that is functionally what happens.

FDA's AI/ML and total product lifecycle guidance recommends an early Q-sub specifically to discuss your PCCP structure before your primary submission, giving reviewers a chance to flag ambiguity in your modification protocol while it is still easy to revise.

Building an Evidence Strategy That Survives Updates

Every SaMD submission rests on three evidence pillars, and conflating them is one of the most common mistakes founders make. Analytical validation demonstrates that your software's output is technically accurate, that it measures or computes what it claims to measure. Clinical validation demonstrates that the output is clinically meaningful, that acting on it actually improves or informs patient outcomes in the intended population. Human factors and usability testing demonstrate that real users, under real conditions, can operate the software as intended without introducing new risk.

• Analytical validation scales with algorithmic complexity: a rules-based calculator needs less than a deep learning model trained on a shifting data distribution.
• Clinical validation scales with the healthcare situation's criticality, meaning Category III and IV SaMD generally needs prospective clinical data, while Category I often relies on literature-supported clinical validity.
• Human factors testing scales with the consequence of user error, so a dosing tool warrants formal simulated use testing that a passive data dashboard may not need.

The durability question matters as much as the initial evidence package. Software changes constantly, and re-running a full clinical validation study for every minor release is neither realistic nor what FDA expects. The practical approach is to design your validation studies around the underlying claim, not the specific software version, so that a UI update or performance optimization does not automatically invalidate your evidence base. Document exactly which inputs, outputs, and clinical claims your validation covers, so your team can quickly assess whether a planned change falls inside or outside that evidence's boundary.

Computer Software Assurance: Validating at the Speed You Actually Need

FDA's Computer Software Assurance guidance recommends a risk-based approach to validating production and quality system software, replacing blanket, document-heavy validation with assurance activities scaled to actual patient risk. For SaMD teams shipping frequent releases, this is the guidance that keeps a rigorous QMS compatible with an agile development cadence.

The practical decision flow looks like this: for any planned change, first ask whether it affects the device's intended use, its safety profile, or a claim already covered by your existing clinical evidence. If yes, treat it as requiring a new or supplemental submission and full verification and validation. If no, and the change is a low-risk enhancement such as a UI refinement or a performance fix that does not touch clinical logic, CSA supports lighter-touch assurance activities, potentially unscripted testing with documented rationale rather than exhaustive scripted test cases.

Three practices reduce regulatory friction without cutting corners:

• Automated regression testing tied directly to your traceability matrix, so every code change maps back to the requirement and risk it touches.
• Change-impact classification built into your pull request process, forcing engineers to tag whether a change is clinical-logic-affecting before it merges.
• Version-controlled validation records stored alongside the code they validate, not in a separate document repository your QA team maintains by hand.

Our CSA and software validation checklist gives engineering leads a concrete template for this classification step, which is usually the single highest-leverage process change a SaaS-native team can make.

Sequencing U.S. and Global Submissions Without Duplicating Work

A U.S.-first strategy does not mean ignoring global markets. It means building what is best thought of as a "global core," a set of artifacts written once and reused across jurisdictions: your intended use statement, your tiered evidence package, and your lifecycle documentation.

• Write your intended use language broadly enough to support both FDA and international submissions without requiring a rewrite for each market.
• Build your evidence tiers (analytical, clinical, usability) to a standard rigorous enough to satisfy FDA's Category III or IV expectations even if your initial classification is lower, since stronger evidence transfers more easily than it can be retrofitted.
• Maintain your lifecycle artifacts, design history file, risk management file, cybersecurity documentation, in formats that map cleanly to both QMSR/ISO 13485 and international quality standards, since the underlying technical content rarely differs.

For most SaaS-native health companies, sequencing rather than parallelizing U.S. and EU submissions makes financial and operational sense in the first product cycle: nail your FDA pathway and QMS, then adapt the same evidence core for the EU's requirements once you understand exactly what a reviewer wanted to see. Parallelizing only makes sense when a large existing EU customer base or investor timeline demands simultaneous market entry, and even then, the underlying evidence should be built once.

A Time-Aware Roadmap From Pre-Submission to Postmarket

Turning this strategy into an execution plan means sequencing work into three phases with realistic internal deadlines.

1. Pre-submission: lock your intended use statement, confirm your IMDRF category, draft your evidence plan, run your QMSR gap analysis, and build your cybersecurity plan in parallel, not sequentially.
2. Submission: select your pathway (510(k), De Novo, or PMA), use a Q-sub to pressure-test your evidence package and PCCP if applicable, and assemble your submission documentation with traceability built in from day one.
3. Postmarket: activate your postmarket surveillance plan, maintain continuous vulnerability monitoring against your SBOM, and run a documented change-governance cadence for every release.

Each phase feeds the next. A weak pre-submission evidence plan produces a Q-sub meeting full of unresolved questions, and a postmarket surveillance plan built as an afterthought produces exactly the audit findings QMSR was designed to catch.

Why Trust This Guide: Author and The StartUp MD Proof Points

This guide reflects the perspective of Paul Bergeron, MD, MBA, who brings over 25 years of experience across medicine and business into advising healthcare SaaS companies on regulatory and clinical strategy. Consultants with clinical and regulatory expertise may support product evaluation, regulatory guidance, and clinical operations decisions relevant to healthcare SaaS companies. That dual grounding in clinical practice and startup operations shapes the practical, lifecycle-first framing used throughout this piece, rather than a purely legal or purely engineering lens.

How U.S. Strategy Differs From EU MDR and Japan's PMDA

FDA's SaMD framework shares its conceptual foundation with IMDRF, but the practical requirements diverge once you leave the U.S. The European Union's Medical Device Regulation classifies software using its own risk-based rule set and requires a Notified Body review for most SaMD above the lowest risk class, a structurally different process from FDA's predicate-based 510(k) or the De Novo pathway. Japan's Pharmaceuticals and Medical Devices Agency applies its own classification and review process, often requiring a Japan-specific clinical evaluation even when equivalent data exists from a U.S. or EU submission.

The instinct to treat these as three parallel checkboxes is what drives founders to duplicate work unnecessarily. A more efficient approach recognizes that the underlying clinical and analytical evidence, if built to a sufficiently rigorous standard, can often satisfy multiple regulators with jurisdiction-specific packaging rather than jurisdiction-specific studies. Where the frameworks genuinely diverge, usually in postmarket reporting timelines, quality system audit cadence, or specific labeling requirements, treat those as localization tasks layered onto a shared evidentiary core rather than reasons to rebuild your evidence strategy from scratch for each market. Founders who plan U.S. first typically find their FDA-grade evidence package needs targeted, not wholesale, revision when adapting for the EU or Japan.

Documentation Practices That Hold Up Under FDA Review

Regulatory submissions live or die on traceability. Every claim your labeling makes needs a documented line back to the evidence that supports it, and every design decision needs a documented line back to the requirement and risk it addresses. Reviewers spend far more time following these threads than reading prose summaries.

Three documentation habits separate submissions that move smoothly through review from ones that generate repeated information requests. First, maintain a single traceability matrix connecting requirements, design outputs, verification results, and risk controls, updated continuously rather than reconstructed before filing. Second, write your intended use statement with the same precision you would want in a legal contract, since ambiguity here creates downstream disagreement about classification and evidence sufficiency. Third, keep your risk management file, cybersecurity file, and design history file cross-referenced rather than siloed, since a reviewer evaluating your cybersecurity plan will often need to see how a specific vulnerability maps to a specific design control.

The teams that struggle most with FDA review are rarely the ones with weak science. They are the ones whose documentation cannot answer a reviewer's follow-up question without a week of internal archaeology. Build your documentation system to answer that question in an afternoon.

Regulatory Considerations When Your Software Touches Hardware or Other Systems

Interoperability introduces a regulatory question many SaaS teams underestimate: once your software integrates with a connected device, an electronic health record, or another vendor's software, your risk analysis has to account for failure modes that originate outside your own codebase. FDA expects manufacturers to document interface specifications, data validation logic, and failure handling for every external system their SaMD depends on.

Practically, this means your risk management file needs a section addressing what happens when an upstream data source sends malformed, delayed, or unexpected data, and how your software detects and responds to that condition rather than silently propagating an error into a clinical decision. If your SaMD pulls data from a connected glucose meter, an imaging system, or an EHR via an interface like HL7 or FHIR, your verification testing needs to include scenarios where that upstream system behaves outside its expected parameters.

Interoperability also affects classification conversations. Software that merely displays data from a connected device without added interpretation sits in a lighter regulatory position than software that combines multiple data streams into a new clinical output, since the combination itself becomes a new intended use requiring its own evidence.

Talking to Regulators Without Losing Time or Trust

The Q-sub process exists precisely so that regulatory disagreements surface early, when they cost a meeting instead of a rejected submission. Teams that treat FDA interactions as adversarial rather than collaborative consistently take longer to reach clearance. The more useful posture is to bring a specific, well-reasoned proposal to every interaction rather than an open-ended question, since reviewers respond faster and more substantively to a defined position they can agree with, modify, or push back on.

When FDA raises a concern, the strongest response documents your reasoning rather than simply complying to move forward. If a reviewer questions your evidence scope, a written rationale explaining why your validation boundary matches your intended use claim builds a stronger long-term relationship than an immediate, unexplained expansion of scope. That same documented reasoning becomes valuable again at your next submission, when a new reviewer asks a similar question about a related product.

Internally, designate one person, usually your regulatory lead or fractional CMO, as the single voice communicating with FDA, so your positions stay consistent across meetings and submissions. Fragmented communication, where different team members answer similar reviewer questions differently, is one of the most common and avoidable causes of delay in SaMD review.

When a Software Update Requires a New Look at Your Clearance

Not every release requires FDA's attention, but every release requires you to ask the question. The determining factor is whether the change affects the device's intended use, alters its risk profile, or falls outside the boundary of your existing clinical evidence, the same test that governs your CSA-based change-impact decisions.

Real-world evidence, data collected from your SaMD's actual postmarket use rather than a controlled study, is increasingly valuable here. A well-designed postmarket surveillance plan that captures performance data across your real user population can support both safety monitoring and, in some cases, evidence for future labeling expansions or PCCP-authorized changes. The catch is that real-world evidence only strengthens your regulatory position when it is collected systematically, with defined metrics and a documented analysis plan, not as an unstructured byproduct of customer support logs.

Founders sometimes treat "update" and "new submission" as a binary decision made by gut feel. It should instead be a documented decision, run against your CSA change-impact criteria and your PCCP if you have one, with the rationale recorded regardless of which way the decision goes. That record is exactly what a reviewer or auditor will ask to see if your update history is ever questioned.

Regulatory Realities of Cloud-Based SaMD Deployment

Deploying SaMD as a cloud-hosted service changes where regulatory responsibility sits, but it does not reduce it. FDA treats the software's intended medical function as the regulated article regardless of whether it runs on a hospital's on-premises server or your own cloud infrastructure, which means your quality system needs to account for cloud-specific risks: multi-tenant data segregation, service availability commitments, and the security posture of your cloud provider as part of your own risk management file.

Availability becomes a formal design consideration rather than an operational nicety. If a clinical decision depends on your software being reachable at the moment of need, your risk analysis has to address what happens during an outage, and your cybersecurity plan under Section 524B needs to speak directly to availability as one of its core objectives.

Version control also looks different in a cloud-deployed model, since you can push updates continuously rather than through discrete, user-installed releases. That capability is powerful, but it raises the stakes on your change-impact classification process, since a single backend update can instantly affect every user rather than rolling out gradually. Teams running SaMD as a service should treat their deployment pipeline itself as part of their regulated quality system, with the same change control rigor applied to infrastructure changes as to application code.

The Part of SaMD Strategy Most Teams Get Backward

Most SaMD founders treat regulatory strategy as a gate to clear before launch, something you finish once and move past. That framing is the single biggest strategic error in this space. FDA's own shift toward lifecycle-based tools, QMSR, CSA, and PCCPs, all say the same thing: regulation is no longer a one-time hurdle, it is an operating discipline you either build into your product process or fight against for the life of the product.

The conventional advice, hire a regulatory consultant right before your submission, undervalues how much classification and evidence-planning mistakes made at the design stage cost to unwind later. By the time a submission is being drafted, the product's core clinical claims and evidence boundaries are usually already locked in, for better or worse.

If there is one priority I would put ahead of everything else in this article, it is this: get your IMDRF classification and evidence plan reviewed by someone with both clinical and regulatory judgment before your engineering roadmap solidifies, not after. Everything downstream, your QMS design, your cybersecurity architecture, your PCCP strategy, is easier and cheaper when the foundation is right from the start.

— Paul Bergeron MD, MBA

How The StartUp MD Supports Your SaMD Regulatory Strategy

Building the strategy this article describes is straightforward to outline and genuinely difficult to execute without someone who has sat on both the clinical and the operational side of a healthcare SaaS company. That is the gap a fractional Chief Medical Officer is built to close.

Specialized consultancies can assist healthcare SaaS founders and executives through fractional Chief Medical Officer engagements and project-based advisory work, applying clinical and business experience to regulatory and clinical decisions.

• Regulatory roadmap facilitation, mapping your IMDRF classification and pathway decision against your actual product timeline.
• Pre-submission meeting preparation, helping you walk into a Q-sub with a defensible, well-documented position.
• Fractional CMO retainer support, giving you ongoing clinical and regulatory judgment without a full-time executive hire.

Pro Tip: Bring a fractional CMO into the conversation before your classification decision is finalized, not after your engineering team has already built around it.

Engagements typically begin with a scoping conversation about where your product sits today and what decision you are trying to make next. Visit the services page to see the full scope of fractional CMO and advisory offerings and start a conversation about your SaMD regulatory strategy.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

FAQ

What makes software qualify as SaMD under FDA rules?

Software qualifies as SaMD when it performs a medical purpose, such as diagnosis, treatment guidance, or clinical decision support, independently of any specific hardware device, following the definition IMDRF established and FDA applies. Software that merely displays or transmits data from a connected device without adding clinical interpretation generally falls outside SaMD.

How do I know whether to file a 510(k) or a De Novo?

File a 510(k) when a legally marketed predicate device exists with the same intended use and similar technology, since that lets you argue substantial equivalence. File a De Novo when your software is genuinely novel with no suitable predicate, which is common for first-generation AI/ML diagnostic tools. A 513(g) request or Q-sub meeting can confirm the right choice before you commit to either path.

What does the QMSR change mean for a small SaMD startup?

The QMSR became effective February 2, 2026 and incorporates ISO 13485:2016 by reference, meaning your quality system now needs to align with that international standard rather than the older 21 CFR 820 structure alone. Small teams should run a gap analysis and build design control documentation into their existing development sprints rather than treating it as a separate compliance project.

Is a PCCP required for every AI-enabled SaMD?

No. A Predetermined Change Control Plan is optional and most valuable when your AI/ML model will undergo planned, iterative updates such as retraining or threshold recalibration, since FDA's PCCP guidance lets manufacturers implement authorized changes without a new submission each time. Products with infrequent or unpredictable changes can rely on traditional change control instead.

What cybersecurity documents does FDA require for a cyber device submission?

Under Section 524B, manufacturers of cyber devices need a Software Bill of Materials, a postmarket vulnerability monitoring plan, a patching and update timeline, and a coordinated vulnerability disclosure process, as described in FDA's cybersecurity guidance. These documents need to be built into your premarket submission, not added after clearance.

Recommended

• Avoid These 7 FDA SaMD Guidance Submission Gaps for U.S. Startups
• Avoid Months of Delay: De Novo vs 510(k) Strategy for U.S. SaMD Founders
• QMSR 21 CFR 820: 4 Immediate Steps for U.S. Healthtech Startups
• U.S. Startups: 7-Item FDA Cybersecurity Checklist for Devices