For MedTech companies developing connected devices or software-enabled products, cybersecurity can no longer be treated as a technical add-on, a consultant-owned folder, or a documentation exercise that happens a few months before FDA submission.
That approach was always risky. Now, it is even harder to defend.
With the FDA’s Quality Management System Regulation (QMSR) now in effect (as of February 3, 2026), and cybersecurity expectations continuing to mature, cybersecurity has become inseparable from the way medical devices are designed, developed, documented, changed, and maintained.
The FDA’s companion premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, was also updated and took effect February 3, 2026, superseding the September 2023 version.
For manufacturers, the practical implication is clear: cybersecurity documentation needs to live inside the quality management system, where it can be controlled, connected, reviewed, updated, and traced across the full product lifecycle.
The core shift for MedTech teams is not simply that cybersecurity documentation needs to exist. It is that cybersecurity has become a living quality system responsibility.
That shift matters because cybersecurity is no longer only about protecting data. In medical devices, it is about patient safety, device performance, clinical decision-making, and the manufacturer’s ability to prove that risks have been identified, mitigated, verified, and maintained over time.
The mistake is thinking FDA clearance is the only gate
Many startups understandably focus on regulatory clearance as the primary milestone. But for connected or software-enabled devices, clearance is not the only gate.
Hospitals, health systems, and other buyers may have cybersecurity expectations that go beyond what regulators require. IT departments may ask detailed questions about security controls, software components, update infrastructure, vulnerability response, data protection, or third-party risk before allowing a device into their environment.
That means MedTech teams need to reverse engineer the market they want to sell into. In other words, do not only ask, “What will the FDA expect?” Ask, “What will our intended customers, purchasing teams, IT stakeholders, and clinical environments need to see before they trust this product?”
That makes cybersecurity part of customer discovery as well as regulatory strategy.
A connected device may satisfy the clinical need and receive regulatory clearance, but still face adoption barriers if cybersecurity expectations were not considered early enough. For teams preparing to enter hospital systems or other highly controlled environments, cybersecurity requirements should inform product strategy, design inputs, and go-to-market planning from the beginning.
The core cybersecurity documents teams need to create and maintain
The exact documentation package will depend on the device, its architecture, intended use, connectivity, risk profile, and regulatory pathway. But MedTech teams should generally expect to create and maintain several categories of cybersecurity documents and records, including:
- Threat model
- Cybersecurity risk assessment
- Software bill of materials (SBOM) (statutory requirement under Section 524B for cyber devices)
- Analysis of third-party components
- Cybersecurity management plan
- Postmarket cybersecurity plan
- Vulnerability assessment and penetration testing outputs
- Static application security testing outputs, when applicable
- Documentation of unresolved anomalies
- Cybersecurity labeling or user-facing security information
- Patch, update, and vulnerability response processes
For teams preparing a premarket submission, FDA’s eSTAR v7.0 template includes a dedicated cybersecurity section that maps directly to these document categories. Knowing which template fields correspond to which artifacts helps teams build their documentation package with submission structure in mind from the start.
The important point is not simply that these documents exist. It is that they connect.
The threat model should inform the risk assessment. The SBOM should support third-party component analysis. Testing outputs should feed into risk evaluation. Vulnerability findings should trigger triage, assessment, and, when needed, change control. Postmarket monitoring should connect back to risk management, complaint handling, CAPA, and design changes.
Threat models, risk assessments, and SBOMs are especially common sources of problems. One reason is that teams sometimes apply a traditional IT cybersecurity risk methodology to a medical device context.
In a traditional IT environment, cybersecurity risk may be framed around data protection and likelihood. For medical devices, the assessment must be grounded in patient safety and exploitability.
A related pitfall is applying CVSS scores the same way an IT security team would. A vulnerability rated low or medium severity by CVSS may be critical in a medical device context if it affects a life-sustaining function, a safety-critical alarm, or a diagnostic output. Risk severity in this domain has to account for clinical impact, not just technical exploitability.
A vulnerability is not just a technical issue. The manufacturer has to understand whether it could affect the patient, the device function, the data used to treat the patient, or the information used to make a diagnostic or therapeutic decision.
That distinction changes the way risk needs to be documented and controlled.
Late cybersecurity work can create more than a documentation problem
When cybersecurity documentation is created too late, the problem is rarely limited to the documents themselves.
The cybersecurity risk assessment is often one of the hardest documents to recreate retroactively because it depends on so many inputs. A proper risk assessment may require current penetration testing, static application security testing, SBOM analysis, unresolved anomaly review, and vulnerability assessment.
If those inputs were missing, outdated, or incomplete, the team may need to regenerate them. And once they do, they may uncover real technical issues that need remediation.
That is where the work can become much larger than expected.
Fixing a document may be straightforward. Fixing the software, architecture, update infrastructure, or third-party component risk behind the document can become a major development effort. Remediation can cascade into software changes, software validation, risk file updates, design documentation changes, and additional verification work.
The later those gaps are discovered, the more expensive and disruptive they become.
For this reason, MedTech teams should involve cybersecurity expertise once they have validated the product need, have evidence supporting the product’s claims, and are beginning formal product development.
At that point, the team may not need to complete every cybersecurity activity immediately. But they do need to understand what the device will require, what risks must be addressed, and how cybersecurity will be built into development.
A small amount of early expert guidance can prevent a much larger rework effort later.
Managing cybersecurity in the QMS means maintaining traceability
Once cybersecurity documents exist, managing them properly means they are not treated as static files.
They need revision control. They need review and approval. They need clear ownership. They need to be retrievable. Most importantly, they need to be traceable to the rest of the product development and quality record.
For teams using a Design Control Matrix, this is where cybersecurity needs to be visible alongside the rest of the device’s requirements, risks, controls, and verification activities. That traceability should show how cybersecurity requirements connect to:
- User needs
- Design inputs
- Design outputs
- Risk assessments
- Security controls
- Verification and validation activities
- Testing outputs
- Change records
- Supplier records
- Complaints and CAPA
- Postmarket monitoring
- Regulatory submission documentation
If a document says a cybersecurity risk was mitigated, the next question is: where is the evidence?
Was the risk mitigated by a control? Where was that control implemented? When was it implemented? How was it validated? What testing supports it? How does it connect back to the original requirement or risk?
That evidence trail is the difference between having cybersecurity documents and having a controlled cybersecurity program. In FDA reviews, including IDEs and PMAs, reviewers will trace specific design decisions back through the QMS.
Gaps in that chain are among the most common drivers of Additional Information (AI) requests, and they are almost always avoidable when traceability is built in from the beginning rather than reconstructed before submission.
This is where a connected QMS becomes essential. If cybersecurity documentation sits outside the QMS, teams lose transparency. When a quality event occurs, a complaint comes in, or a design change is needed, it becomes much harder to understand what is affected and what needs to be revised.
It can also create audit risk. If a regulator or notified body asks to see the document trail behind a cybersecurity-related complaint or remediation, teams need to be able to show what happened, what was assessed, what changed, and how the change was controlled.
Cybersecurity should be built into secure product development
Cybersecurity should not wait until the product is complete and ready for a penetration test.
A stronger approach is to use a secure product development framework with security gates built into the software development process. Instead of finishing the software and then testing it all at once, teams should evaluate security iteratively as modules or functions are developed.
That may include static application security testing, SBOM review, vulnerability assessment, or other checks at appropriate points in the development process.
A final penetration test may still uncover issues. But if security has been built into development, the findings are likely to be more manageable than if cybersecurity was addressed only at the end.
From the QMS side, cybersecurity needs to appear in the formal design control process. Cybersecurity-related user needs should inform design inputs. Cybersecurity risks should be captured in the risk assessment. Testing such as penetration testing should connect back to the risks or controls it is intended to evaluate.
This is also where ISO 13485 and ISO 14971 come together in practice.
ISO 13485 provides the quality system structure for planning, controlling, documenting, reviewing, and maintaining design and development activities. ISO 14971 provides the risk management framework for identifying hazards, evaluating risk, implementing controls, and monitoring those risks throughout the device lifecycle.
For connected and software-enabled devices, cybersecurity needs to be managed through both lenses.
In a Design Control Matrix, that means cybersecurity should be visible alongside the rest of the device’s requirements, risks, controls, and verification activities. In other words, the team should be able to say: this cybersecurity risk was identified, this requirement or control was defined, this implementation addressed it, and this test verified it.
Change control is where cybersecurity stays current
Cybersecurity risk changes as the product changes.
A software update, architecture change, authentication change, cloud infrastructure change, third-party component change, or new vulnerability finding may all require cybersecurity review. These changes should be assessed through the lens of whether they could affect the patient, device function, or data used for diagnosis or treatment.
That is true before commercialization and after the product is on the market.
From a QMS perspective, these are technical or design changes. They should be managed through change control in the same disciplined way a company would manage a change to another part of the device design.
A cybersecurity-related change may require updates to documentation, software code, risk management files, design records, testing evidence, and possibly regulatory assessments. Change control helps ensure teams do not fix one issue while creating another.
Regression testing is important for exactly this reason. Software changes can introduce new issues even when they are intended to resolve an existing one.
Suppliers and third-party components expand the cybersecurity burden
Modern software rarely exists in isolation. Devices may rely on open-source components, commercial software, third-party libraries, cloud infrastructure, outsourced development partners, or AI-assisted code development.
Each of those inputs can affect cybersecurity documentation.
Third-party components make up the SBOM. For each component, teams need to assess risk before submission and continue monitoring after commercialization for new vulnerabilities.
That responsibility can grow quickly. AI-assisted development may pull in unnecessary third-party components. Developers may copy and paste code from public sources. Software of unknown provenance (SOUP) may appear in the codebase.
Each of these creates questions the manufacturer needs to answer: where did this component come from, what risk does it introduce, and how will it be monitored or controlled?
The SBOM is not simply a submission artifact. It becomes part of a living cybersecurity management process.
Once the product is on the market, new vulnerabilities may be discovered in third-party components. The manufacturer needs a process to identify those vulnerabilities, assess whether they are exploitable in the device context, determine patient or clinical impact, and decide whether action is needed.
That process should be connected to supplier management, risk management, change control, and postmarket surveillance.
Postmarket cybersecurity requires infrastructure, not just a plan
Cybersecurity does not end when the product is cleared or approved.
One of the biggest postmarket risks is writing a cybersecurity plan for submission without fully understanding the infrastructure needed to execute it.
Postmarket cybersecurity activities may include:
- Coordinated vulnerability disclosure
- A portal or mechanism for reporting vulnerabilities
- Triage of reported vulnerabilities
- True positive / false positive assessment
- Cybersecurity risk assessment
- Ongoing SBOM monitoring
- Penetration testing at defined intervals
- Patch and update planning
- Secure update infrastructure
- Customer communication processes
- Change control and regression testing
A vulnerability disclosure portal is only useful if there is a process behind it. When someone reports a potential vulnerability, the manufacturer needs to know who receives it, who triages it, how it is assessed, how risk is determined, what changes may be required, and how those changes are implemented and documented.
The 2026 guidance also makes clear that the SBOM is a living artifact, not a static submission document. Manufacturers are expected to actively monitor their SBOM components against known vulnerability databases such as the NVD, and to have a defined process for timely assessment and response when new vulnerabilities are identified. This is a postmarket obligation many teams underestimate when they scope their cybersecurity program.
Companies also need to stay current on evolving threats, regulatory expectations, standards, and customer requirements. Cybersecurity changes quickly. A vulnerability that appears low risk today may become higher risk if exploitability changes or new attack methods emerge.
That is why postmarket cybersecurity should connect back to the QMS. A vulnerability may trigger a risk file update, complaint assessment, CAPA, design change, supplier review, field action, or regulatory assessment.
Without a connected QMS process, the company may struggle to keep pace with what the product requires after launch.
The most common mistake: treating cybersecurity as a checkbox
One of the most common cybersecurity documentation mistakes is treating cybersecurity as a checklist.
Too many companies create the expected documents, check the box, and assume they are covered. But when someone asks what inputs support the document, how the controls were implemented, or what evidence proves the risk was mitigated, the story falls apart.
Cybersecurity documentation needs to be part of the design and development file, with traceability to user needs, risks, controls, and verification activities.
The issue is not whether a document exists. The issue is whether the company can prove how that document fits into the broader quality system and device lifecycle.
That is what regulators, auditors, customers, and internal teams need to see.
What cybersecurity best practices look like
A strong cybersecurity documentation program is not defined by a folder full of files. It is defined by a connected evidence trail.
A MedTech company managing cybersecurity well should be able to show:
- What cybersecurity risks were identified
- What requirements or controls were created in response
- Where those controls were implemented
- How they were verified or validated
- What testing supports the conclusion
- How third-party components were assessed
- How vulnerabilities will be monitored after launch
- How changes will be reviewed and controlled
- How postmarket findings will feed back into the QMS
That level of traceability gives teams confidence during submission preparation, audit readiness, customer review, and postmarket operations.
It also helps cybersecurity become part of normal product lifecycle management rather than an isolated specialty function.
QuickVault supports this kind of connected approach by bringing design controls, risk management, document control, change control, quality events, and supplier management into one MedTech-specific platform.
Cybersecurity-related user needs, design inputs, risks, verification activities, controlled documents, and change records can be managed in a connected environment rather than scattered across disconnected tools.
For small and growing MedTech companies, that structure matters. Cybersecurity is complex enough on its own. Managing it across fragmented systems only adds unnecessary risk.
Where startups and growing MedTech companies should start
For teams that know cybersecurity applies to their device but are not sure where to begin, the first step is an honest assessment.
Ask yourself:
- Do we understand the cybersecurity expectations for our device?
- Have we considered customer and hospital IT requirements, not just FDA submission expectations?
- Do we know what cybersecurity documentation we need to create?
- Are those documents connected to our design controls and risk management process?
- Do we have a plan for SBOM monitoring, vulnerability disclosure, patches, and updates after launch?
- Are cybersecurity-related changes managed through formal change control?
- Could we show an auditor, reviewer, or customer the full evidence trail?
If the answer to any of these questions is unclear, do not try to solve it through guesswork.
Start by speaking with a MedTech cybersecurity expert, like those at Blue Goat Cyber, early, before the team is forced into expensive remediation. General IT security expertise may not be enough. Medical device cybersecurity requires an understanding of patient safety, regulatory expectations, product risk, software development, submission documentation, and postmarket obligations.
At the same time, assess your current QMS processes and be honest about your gaps. If you are early in development, build cybersecurity into your product development plan and QMS from the start. If you are already commercial and discover gaps, treat remediation as a technical change project and address it as soon as possible.
The goal is not to make cybersecurity feel bigger or more intimidating than it needs to be. The goal is to make it manageable by bringing it into the same controlled system that already governs the rest of the device lifecycle.
Cybersecurity is a quality system responsibility
Cybersecurity requirements will continue to evolve. Threats will continue to change. Customers will continue to raise the bar. Devices will continue to become more connected, more software-driven, and more dependent on third-party components.
For MedTech teams, that means cybersecurity can no longer live off to the side.
It belongs in design controls. It belongs in risk management. It belongs in change control. It belongs in supplier management. It belongs in postmarket processes. And it belongs in the QMS.
The companies that handle this well will not be the ones that simply create the right documents at submission time. They will be the ones that can show how cybersecurity risks, controls, evidence, and updates are managed across the full lifecycle of the device.
Because in MedTech, cybersecurity is not only about protecting systems. It is about protecting patients, proving control, and building devices that can be trusted long after they reach the market.
Looking to better connect cybersecurity documentation across design controls, risk management, change control, and postmarket processes?
QuickVault by Veeva gives small and growing MedTech teams a connected eQMS built for the full device lifecycle.
Book a personalized demo to see how QuickVault can help your team maintain traceability from development through commercialization.
Article Contributors
Christian Espinosa
CEO, Blue Goat Cyber
Christian Espinosa is the CEO of Blue Goat Cyber, a cybersecurity firm focused on helping medical device companies address cybersecurity across product development, premarket submission, and postmarket management. His work with MedTech innovators includes cybersecurity documentation, risk assessment, penetration testing, SBOM analysis, vulnerability management, and broader cybersecurity strategy for connected and software-enabled medical devices.
Axel Strombergsson
VP of QuickVault, Veeva Systems
Axel brings over 20 years of diverse experience in MedTech, spanning R&D leadership, operations, regulatory strategy, and medical device commercialization. Before joining Veeva, Axel led R&D efforts for a surgical device company and later transitioned to roles focused on scaling operations and bringing medical devices to market. As VP of QuickVault, Axel helps small and growing MedTech companies strengthen quality operations, connect design and risk processes, and build scalable systems for the full product lifecycle
