Published: May 22, 2026 · Last reviewed: May 1, 2026
For years, most MedTech teams treated cybersecurity as a submission deliverable. Build the device, hand a binder of documents to a cybersecurity vendor before 510(k), get the premarket package over the line, and move on. That model is over.
With the FDA's QMSR now in effect and the February 2026 Premarket Cybersecurity Guidance setting expectations for the full service life of the device, cybersecurity documentation has to live inside the Quality Management System — controlled, versioned, reviewed, and maintained like every other piece of regulated evidence.
Here's what that actually means in practice.
Why Cybersecurity Belongs in the QMS
Cybersecurity isn't a one-time deliverable. The threat model, the SBOM, the risk assessment, and the architecture diagram are living documents. They change every time the software changes, every time a dependency updates, every time a new vulnerability is disclosed. If they live in a side folder on someone's laptop, they're not living documents — they're snapshots that go stale the day after submission. The QMS is the only place where versioning, change control, and review cadence are already built in. That's where cyber documentation has to live.
When cybersecurity is managed outside the QMS, manufacturers end up with two parallel realities. The QMS says one thing about the device. The cyber binder says another. FDA reviewers notice. Auditors notice. And when something breaks postmarket — a CVE in a third-party library, a deficiency letter, a recall — there's no defensible trail showing the company actually controlled the risk.
What's Actually Changed in the FDA's Expectations
Three things changed at roughly the same time, and together they form a different regime. Section 524B made cybersecurity a statutory premarket requirement, not a guidance suggestion. QMSR aligned the U.S. quality system to ISO 13485 and made lifecycle and risk-based thinking the default. And the February 2026 premarket guidance set explicit expectations for what manufacturers must do across the entire service life of the device — not just at submission. None of those can be satisfied by treating cyber as a separate technical track.
The Documentation MedTech Teams Must Create and Maintain
This is the minimum set the FDA expects, and that we expect to see controlled inside the QMS:
| Document | QMS Process It Lives In | Trigger to Review |
|---|---|---|
| Cybersecurity risk assessment (often per AAMI TIR57/TIR97 or IEC 81001-5-1) | Risk management | Any design change, new vulnerability, postmarket signal |
| Threat model (STRIDE or equivalent) | Design controls / risk | Architecture change, new interface, new data flow |
| Security architecture diagram | Design controls | Any change to trust boundaries or components |
| SBOM (CycloneDX or SPDX) | Configuration management | Every software build released |
| VEX | Vulnerability management | Each new CVE affecting an SBOM component |
| Cybersecurity management plan | QMS / postmarket | At least annually, and on material change |
| Penetration test reports | Design verification | Per release, and after significant change |
| Secure coding & SDLC procedures (SPDF) | QMS procedures | Annual review |
| Supplier cybersecurity agreements & assessments | Purchasing controls | Onboarding and at supplier change |
| Postmarket monitoring & CVD records | Postmarket surveillance | Continuous |
| Patch management & update plan | Change control | Per patch, and on cadence |
The documents most often overlooked or created too late are the cybersecurity management plan, the VEX, and the supplier cybersecurity assessments. Teams build the SBOM because it's obvious. They skip the plan because it feels like paperwork. Then a deficiency letter shows up asking how they'll monitor and patch, and there's nothing to point to.
Connecting Cybersecurity Across the Full Lifecycle
Managing these documents properly inside the QMS means four things. First, design controls — cyber requirements trace to design inputs and outputs like any other requirement. Second, risk management — cyber risk feeds into the same risk file as safety risk, not a parallel one. Third, change control — every software change runs through an impact assessment that explicitly asks the cybersecurity question. Fourth, supplier controls — third-party components and test vendors are part of the quality system, with agreements and oversight to match.
Change control is where most teams fall apart. A product manager approves a "minor" library bump. Engineering ships it. Nobody updates the SBOM, nobody re-runs the threat model, nobody checks whether the new version introduces a known CVE. Six months later the FDA asks why the postmarket monitoring record doesn't match the deployed software. That's a QMS failure, not a cybersecurity failure — and it's exactly why cyber has to be inside the QMS, not next to it.
Suppliers and Third-Party Components
Most of the software in a modern medical device isn't written by the manufacturer. It's open-source libraries, commercial SDKs, OS components, and cloud services. Every one of those is a supplier from a quality standpoint. The SBOM tells you what's in there, the VEX tells you what's exploitable, and the supplier agreement tells you what the vendor will do when something breaks. If your purchasing controls procedure doesn't mention cybersecurity, your QMS has a hole.
What Continues After Market
Postmarket is where the lifecycle framing earns its keep. The activities that have to continue — forever, not just through the warranty — include:
- Monitoring SBOM components for new CVEs and updating the VEX
- Running a coordinated vulnerability disclosure program (CVD)
- Tracking and reporting cybersecurity events per 524B
- Patching on a documented cadence with regression and security testing
- Reassessing the threat model when the threat landscape shifts (new attack classes, new adversary capabilities, post-quantum timelines)
- Keeping cybersecurity labeling and customer guidance current
Companies that handle this well treat the cybersecurity management plan as a real plan — with owners, cadences, and CAPA hooks — not a document they write once and file.
Common Pitfalls
- Cyber binder lives outside the QMS. No version control, no change history, no defensible trail.
- SBOM created for submission, never updated. Stale by the next release.
- No VEX, or a VEX that just says "not affected" for everything. Reviewers see straight through it. (Common VEX mistakes.)
- Change control doesn't ask the cybersecurity question. Library updates slip through without a threat model review.
- Suppliers aren't part of the cybersecurity picture. No agreements, no assessments, no notification expectations.
- Postmarket plan exists on paper but nobody owns it. No cadence, no metrics, no CAPA when something is found.
- Cybersecurity risk file is separate from the safety risk file. Two truths, neither complete.
What "Good" Looks Like
- One risk file. Safety and security risks live together, with shared controls and traceability.
- The SBOM is regenerated on every build and stored as a controlled record.
- The VEX is updated within a defined SLA of each new CVE affecting a listed component.
- Change control templates include a mandatory cybersecurity impact question that routes to a named owner.
- Suppliers have signed cybersecurity terms covering vulnerability notification, SBOM accuracy, and patch support.
- A documented SPDF ties the procedural QMS world to the engineering reality.
- The cybersecurity management plan is reviewed at a stated cadence, with metrics and CAPA triggers.
First Steps for Startups and Growing MedTech Companies
Start before there's a product to ship. Even a pre-seed company can write the cybersecurity management plan, pick the SBOM format, choose the threat modeling methodology, and decide who owns vulnerability triage. None of that requires code. All of it makes the eventual submission and audit dramatically easier.
And put it in the QMS from day one — not in a "we'll move it later" folder. The cost of retrofitting cyber into a mature QMS is much higher than building it in from the start.
If you're standing up cybersecurity inside your quality system — or repairing a system that's been running parallel — our team builds and operates exactly this. The standards are published. The FDA guidance is signed. The QMS is where the work actually lives.
FAQ
Why does cybersecurity documentation need to be managed inside the QMS? Because it has to be controlled, versioned, and maintained across the full device lifecycle. The QMS already provides change control, design controls, supplier oversight, and CAPA — the exact mechanisms cybersecurity documentation needs. Keeping it outside the QMS creates two parallel realities that won't survive an FDA audit or a postmarket incident.
What cybersecurity documents does the FDA expect manufacturers to create and maintain? At minimum: a cybersecurity risk assessment, threat model, security architecture, SBOM, VEX, cybersecurity management plan, penetration test reports, secure development procedures (SPDF), supplier cybersecurity assessments, postmarket monitoring records, and a patch/update plan.
Which cybersecurity documents are most often created too late? The cybersecurity management plan, the VEX, and supplier cybersecurity assessments. Teams produce the SBOM and a threat model for submission, then discover at deficiency-letter time that the lifecycle documents are missing.
What product or software changes should trigger a cybersecurity review? Any change to architecture, trust boundaries, data flows, external interfaces, third-party components (including library version bumps), cryptographic implementations, authentication, or update mechanisms. The change control workflow should force the question for every release.
How should cybersecurity risk connect to product risk management? They belong in the same risk file. Security risks can create safety risks, and safety controls can depend on security controls. Splitting them produces inconsistent mitigations and gaps the FDA will flag.
What cybersecurity activities continue after the device is on the market? SBOM/VEX monitoring, coordinated vulnerability disclosure, 524B event reporting, patching on a defined cadence, threat model reassessment as the landscape changes, and ongoing updates to cybersecurity labeling and customer guidance.
What's the first step for a startup that hasn't built any of this yet? Write the cybersecurity management plan, pick your SBOM format and threat modeling method, and decide who owns vulnerability triage — then put all of it under QMS control before you write more code.