MDS2 Forms and HDO Questionnaires: A Practical Guide for Small Med-Device Firms
- May 18
- 5 min read
By Jonathon Carlson | Atlas Thread Digital
You finally get the call from a regional health system. They love your device, the clinical champion has been pushing for it, and procurement is ready to move. Then their security team sends over a 60-page questionnaire and asks for your MDS2, your SBOM, your vulnerability disclosure policy, and a list of every third-party library you've shipped in the last three years. The deal stalls. You spend the next four weeks chasing PDFs across Slack and your contract engineer's inbox.
This is the part of medical device cybersecurity nobody warned you about. The FDA premarket guidance gets the headlines, but for small device manufacturers the bigger surprise is what happens after clearance, when a hospital's information security office picks up the phone. In a recent industry survey, 35% of healthcare delivery organizations said they will not even consider a device without a software bill of materials (SBOM), and missing SBOMs account for 34% of procurement rejections. The procurement gate has moved. If you're a 30-person device firm and you can't produce these documents in a week, you're competing with one hand tied behind your back.
The documents the hospital buyers want are not mysterious, and they don't require a six-figure compliance program to produce well. They just require knowing what each one is, who reads it, and how they connect. The MDS2, the SBOM, the vendor questionnaire, and the contract addendum are four artifacts that look unrelated on the org chart and are tightly coupled in practice. Once you see how they fit, the conversation with a hospital's security team gets much shorter.
What an MDS2 actually is
The Manufacturer Disclosure Statement for Medical Device Security, or MDS2, is a standardized form created by HIMSS and NEMA so that hospitals can ask every device vendor the same security questions and get answers in the same format. Think of it as a nutrition label for medical device security. The hospital's biomedical engineering team uses it to figure out how your device behaves on their network: what ports it opens, what protocols it speaks, whether it stores PHI, how it handles authentication, whether it can be patched, and what happens to data when the device is decommissioned.
An MDS2 is not a regulatory submission. The FDA does not require it. But almost every health system in the United States now asks for one before they will let a device touch their network, and many will refuse to escalate a purchase order without it. The form is roughly 200 questions and is updated periodically by HIMSS. If you don't have one filled out, that's where to start.
The 2026 regulatory shift makes this harder to ignore
The regulatory baseline shifted underneath device makers this year. The FDA's Quality Management System Regulation took effect in February 2026, aligning the agency's quality system requirements with ISO 13485:2016. A month later, FDA issued an updated premarket cybersecurity guidance that maps cybersecurity risk management directly into the QMSR framework. The practical effect for manufacturers is that cybersecurity documentation is no longer a parallel workstream you bolt onto your 510(k) submission. It now has to live inside your quality management system, with the same controls, traceability, and audit trail as the rest of your design history file.
The most consequential piece is the SBOM. FDA now expects machine-readable bills of materials in SPDX or CycloneDX format, covering every commercial, open-source, and off-the-shelf component, with version numbers, supplier information, and support windows. You're expected to keep it current across the device lifecycle, not just at submission. For a small firm running a CI pipeline, this is doable: tools like Syft can generate an SBOM at build time and link it cryptographically to the release. For a firm shipping a binary that was last touched in 2019, it's painful.
HDO questionnaires go further than the MDS2
Here's where it gets interesting. Most hospitals will not accept the MDS2 as the end of the conversation. They send a second document, their own vendor security questionnaire, and the two overlap maybe 70%. The hospital's questionnaire usually asks about your secure software development lifecycle, your incident response process, your support windows for end-of-life software, how you handle coordinated vulnerability disclosure, and whether you'll sign the Health Sector Coordinating Council's Model Contract Language for MedTech Cybersecurity. HSCC updated that template in late 2025, and large health systems are increasingly insisting on it as a precondition for purchase.
The reason hospitals push harder than FDA is simple math. The average healthcare data breach cost $10.9 million in 2025 and is projected to clear $11.5 million in 2026. Ransomware attacks on healthcare jumped 30% last year, and 80% of attacks that touch a medical device disrupt patient care. When PIH Health in California was hit in 2025, more than 3 million patients lost access to services for days. UMMC cancelled appointments for nine. Hospitals are not asking you for an SBOM because the FDA told them to. They're asking because their CFO told them to.
A practical sequence for small firms
If you're starting from zero, you don't need to solve everything at once. Build the documents in the order a hospital will read them, and let each one carry weight for the next conversation. The point is to make the security packet boring: predictable, complete, and obviously the product of an engineering team that thought about this before the request hit their inbox.
First, fill out the MDS2. The form is free, the template is public, and the questions are not subjective. Treat it like a tax form: pull the answers from your existing engineering docs, get one person to own it, version it, and ship it. Second, automate your SBOM. Pick a generator (CycloneDX or SPDX), wire it into your build pipeline, and store the output as a release artifact. The first SBOM is the hard one; subsequent ones are free. Third, write a one-page vulnerability disclosure policy and put it on your website with an email address that goes to a monitored inbox. Hospitals look for this and many will reject vendors without one. Fourth, draft a postmarket monitoring plan that describes how you'll watch for vulnerabilities in your dependencies, how fast you'll patch, and how you'll notify customers. Fifth, get comfortable with the HSCC Model Contract Language so you're not negotiating it from scratch on every deal.
At Atlas Thread, we've been working with med-device firms on exactly this sequence. The pattern is consistent: the documents are not the bottleneck — the ownership is. Most small firms have the information; it lives in tribal knowledge, design history files, and Confluence pages. The fix is structural, not technical.
Where this is heading
Two-week security review windows are becoming standard procurement language. Health systems are formalizing what was previously a back-channel process into a gate with SLAs, scorecards, and named owners. Vendor security questionnaire fatigue is real on the hospital side too, which is why standardized templates like the MDS2 and HSCC contract language keep gaining ground. The firms that will win the next three years of hospital business are not the ones with the prettiest device. They're the ones whose security packet shows up complete on day one.
For a small device firm, that's actually a fair fight. You don't need a CISO and a 12-person AppSec team to produce a clean MDS2 and a current SBOM. You need a process, a couple of well-chosen tools, and a willingness to treat the security packet as a product deliverable rather than an afterthought. The hospitals on the other side of the questionnaire are not trying to fail you. They're trying to find a vendor who makes their job easier than the last one did.
Jonathon Carlson is the founder of Atlas Thread Digital, where he builds custom AI solutions, MCP servers, and intelligent automation systems for organizations ready to move beyond the chatbot. Reach him at jcarlson@atlasthreaddigital.com.
Comments