FDA · QMSR · ISO 13485
Medical Device Cybersecurity Is No Longer a Security Problem. It Is a Quality System Problem.
Design. Document. Defend.
Medical device cybersecurity stopped being a specialty discipline on February 3, 2026, and became an ordinary obligation of your quality management system. On that date the U.S. Food and Drug Administration issued a revised final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, superseding the version issued on June 27, 2025. The technical expectations barely moved. The regulatory address moved entirely.
Here is what happened, in one sentence: the FDA deleted its citations to the old Quality System Regulation and replaced them with citations to specific subclauses of ISO 13485:2016. Your threat model, your software bill of materials, your penetration test report, your coordinated vulnerability disclosure plan — none of those documents changed. What changed is where they live. They now live inside your quality management system, where a registrar audits them and an FDA investigator inspects them, in the same breath as your design history file and your corrective action records.
Most device organizations have not absorbed the consequence. They read the guidance update, saw “primarily a terminology alignment,” and moved on. That is a mistake, and it is the kind of mistake that surfaces at the worst possible moment — when an investigator asks a security question in quality-system language and nobody in the room knows which procedure to point at.
Direct Answer
Medical device cybersecurity is the discipline of designing, documenting, and maintaining a device so that it remains safe and effective in the presence of cybersecurity threats — and, as of the FDA's February 3, 2026 final guidance, of proving that work through the quality management system. The guidance ties cybersecurity activity directly to ISO 13485:2016 subclauses now incorporated by reference into 21 CFR Part 820 under the Quality Management System Regulation. In practice, medical device cybersecurity evidence is quality system evidence: it is planned, controlled, reviewed, and inspected like every other record in your QMS.
The Regulatory Shift
What Changed in Medical Device Cybersecurity on February 3, 2026?
Same rules. New home.
The change to medical device cybersecurity is best understood as a two-day sequence, and the order matters.
February 2, 2026
The FDA's Quality Management System Regulation (QMSR) takes effect. Published at 89 FR 7496, it amends 21 CFR Part 820 and incorporates ISO 13485:2016 by reference. ISO 13485 becomes the operative regulatory text for finished devices marketed in the United States.
February 3, 2026 — One Day Later
The FDA reissues its medical device cybersecurity guidance to match. Every reference to the old Quality System Regulation is replaced with a reference to the QMSR — and, where the FDA previously cited a subsection of Part 820, it now cites the corresponding subclause of ISO 13485:2016.
A one-day turnaround is not a coincidence. The FDA issued the revised guidance as a Level 2 guidance under 21 CFR Part 10 — the category reserved for minor policy changes and technical clarifications — precisely because the agency did not intend to change what it expects of a medical device cybersecurity program. It intended to change the vocabulary in which that expectation is written, so that the guidance and the regulation would speak the same language from the first day the QMSR was law.
The technical core is untouched. The Secure Product Development Framework is still the operational mechanism. Threat modeling, software bill of materials, vulnerability management, penetration testing, and secure architecture are all still expected across the total product lifecycle. Section 524B of the Federal Food, Drug, and Cosmetic Act still governs cyber devices and is now explicitly connected to quality management processes rather than sitting alongside them. We covered the underlying regulation itself in our breakdown of the FDA QMSR rule and its 21 CFR Part 820 / ISO 13485 alignment.
Direct Answer
The February 3, 2026 update to the FDA's medical device cybersecurity guidance replaced Quality System Regulation citations with Quality Management System Regulation citations, mapping cybersecurity expectations onto ISO 13485:2016 subclauses. It superseded the June 27, 2025 edition. The technical requirements — SPDF, threat modeling, SBOM, vulnerability management, secure architecture — were not overhauled. What changed is that medical device cybersecurity is now formally described as a component of quality management rather than a parallel discipline.
The Consequence
Why Medical Device Cybersecurity Moving Into ISO 13485 Changes Everything
Inspectable. Auditable. Traceable.
“Just a terminology alignment” is how the trade press summarized it. That framing is accurate about the text and badly wrong about the consequences. Three things change the moment medical device cybersecurity is described in quality-system language.
1. Your security artifacts became quality records.
A threat model produced by a security engineer and stored in a wiki is a document. A threat model referenced by a design and development plan, reviewed at a design review, approved by an authorized person, and retained under document control is a record — and records carry obligations. They must be legible, identifiable, retrievable, and retained for a defined period. They must be controlled through change. When the security team updates the threat model after a new vulnerability disclosure, that update now flows through your change control process, not through a pull request nobody outside engineering ever sees.
2. The people who ask the questions changed.
Before, medical device cybersecurity questions came from reviewers assessing a premarket submission. Now they also come from a registrar auditing your ISO 13485 system and from an FDA investigator running an inspection under Compliance Program 7382.850. Those two audiences do not read a penetration test report the way a submission reviewer does. They ask whether the process that produced it was defined, whether the person who performed it was competent, whether the result fed a documented decision, and whether that decision was verified. That is a quality auditor's mind, applied to a security artifact — and most device organizations have never rehearsed the conversation.
3. Cybersecurity gained a management review seat.
Under the QMSR, management review records and internal audit records are FDA-inspectable. If postmarket vulnerability data, patch cadence, and coordinated disclosure activity are part of your quality system's performance, they belong in front of top management at planned intervals. Most first-time reviews leave them out entirely. We walk through what a defensible review looks like in our ISO 13485 management review playbook — and cybersecurity inputs are the newest thing missing from most agendas.
“The FDA did not add a single cybersecurity requirement in February. It simply moved the filing cabinet into a room where auditors and investigators already have a key.”
Direct Answer
A terminology change matters because it changes who audits medical device cybersecurity and how. Once cybersecurity is expressed in ISO 13485 subclauses, security artifacts become controlled quality records, registrars and FDA investigators evaluate them with quality-audit logic, and cybersecurity performance becomes a legitimate management review input. Medical device cybersecurity stops being something the engineering team owns privately and becomes something the quality system must be able to demonstrate on demand.
Design Objectives
What Does the FDA Expect a Medical Device Cybersecurity Program to Deliver?
Five objectives. One design.
The FDA frames medical device cybersecurity around designing for security, and it names five security objectives that a premarket submission should demonstrate are addressed by and integrated into the device design. They are not a checklist to satisfy at the end. They are design inputs, and treating them as anything else is the single most expensive mistake a device team can make.
1. Authenticity, including integrity
The device can establish that data, code, and commands are genuine and unaltered. Signed firmware. Verified update packages. Tamper-evident logging.
2. Authorization
Only permitted actors can perform permitted actions. Role separation between clinician, service technician, and administrator is a design decision, not a configuration afterthought.
3. Availability
The device continues to deliver its essential performance under attack or under degraded network conditions. For a therapeutic device, availability is patient safety by another name.
4. Confidentiality
Sensitive data — clinical, personal, and cryptographic — is protected in transit, at rest, and in use.
5. Secure and timely updatability and patchability
The device can be fixed in the field, safely, without a new submission for every patch — because the update mechanism itself was designed, validated, and documented up front.
Notice what the fifth objective implies. A device that cannot be patched safely is a device that will eventually be unsafe, and the FDA has said so plainly. Updatability is now a design requirement, which means it is a design input under ISO 13485 Clause 7.3.3, which means it is verified and validated like any other design input. A medical device cybersecurity program that treats patching as an IT problem rather than a design problem has already failed the guidance.
The scope is broader than most teams assume. The guidance applies to devices containing software, firmware, or programmable logic — including devices that are not network-enabled — and it applies across the premarket pathways: 510(k), De Novo, PMA, Product Development Protocol, Investigational Device Exemption, Humanitarian Device Exemption, and Biologics License Application. It reaches devices containing artificial intelligence and devices relying on cloud services. If your device has code in it, medical device cybersecurity is your problem, whether or not it touches a network.
Direct Answer
The FDA expects a medical device cybersecurity program to address five security objectives in the device design: authenticity including integrity, authorization, availability, confidentiality, and secure and timely updatability and patchability. Premarket submissions should describe how the design achieves them. Because these are design objectives rather than post-hoc controls, medical device cybersecurity belongs in design inputs, design review, and design verification — the ISO 13485 Clause 7.3 machinery you already run.
The Evidence
The Medical Device Cybersecurity Evidence Package: SPDF, SBOM, and the CVD Plan
Build. Bill. Disclose.
Section 524B of the FD&C Act was added by Congress in December 2022 and has applied to premarket submissions since March 29, 2023. It is the statutory floor beneath the guidance, and it is worth being precise about what it actually obligates a sponsor of a cyber device to do.
Section 524B — What a Cyber Device Sponsor Must Submit
A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure and related procedures. Design, development, and maintenance processes that provide reasonable assurance the device and related systems are cybersecure. Postmarket updates and patches made available on a schedule, and out of cycle for critical vulnerabilities. A software bill of materials listing commercial, open-source, and off-the-shelf components.
The Secure Product Development Framework (SPDF) is the FDA's recommended way to satisfy those obligations. It is a set of processes that reduce the number and severity of vulnerabilities in a product across the total product lifecycle — and in the 2026 guidance it is presented as one way to satisfy the QMSR. That phrasing is the whole story in five words. The SPDF is not a parallel program bolted onto the quality system. It is quality system work, expressed in security vocabulary.
The software bill of materials is the artifact everyone remembers, and the one most often misunderstood as sufficient on its own. An SBOM is an inventory, not a risk assessment. What the FDA wants is the inventory plus the assessment of known vulnerabilities in those components as reasonably foreseeable risks — which is exactly the language of ISO 14971 risk management, applied to software provenance. An SBOM delivered without a linked risk analysis answers a question nobody asked.
The coordinated vulnerability disclosure plan is the requirement most often documented and least often operational. A CVD plan that exists as a PDF in a submission and has never been exercised is a finding waiting to happen. Somebody outside your organization must be able to report a vulnerability to you, reach a human, and receive a response on a defined timeline. If your plan names a security@ address that forwards to a mailbox nobody monitors, your medical device cybersecurity program has a hole in it that no amount of penetration testing will find.
Threat modeling ties the package together. It is the activity that explains why the controls you chose are the right controls — the reasoning that connects the architecture to the risk. Without it, a submission reviewer sees a list of security features with no argument behind them, and an auditor sees controls with no documented rationale. Threat modeling is the design rationale of medical device cybersecurity, and like every design rationale in a device quality system, it must be recorded.
Direct Answer
The core medical device cybersecurity evidence package is the Secure Product Development Framework, a threat model, a software bill of materials covering commercial, open-source, and off-the-shelf components, security testing including penetration testing, and an operational coordinated vulnerability disclosure plan with a postmarket patch commitment. Section 524B makes these statutory for cyber devices. Under the QMSR, each artifact is also a controlled quality record — which is why medical device cybersecurity now fails audits, not just submissions.
The Clause Map
Where Medical Device Cybersecurity Lives in Your ISO 13485 Quality System
Map it. Own it. Prove it.
This is the practical work the February 2026 guidance created, and almost nobody has done it yet. Every cybersecurity activity in your program now needs a home in a clause of ISO 13485. The FDA's revised guidance points to the framework directly — noting, for example, that to satisfy the software validation and risk management requirements of Subclauses 7.3.7 and 7.1, software developers may need to establish cybersecurity risk management and validation processes.
Here is the mapping that MSI builds with device clients. It is not the only defensible map, but it is one that has survived contact with auditors — and having a map is what separates an organization that can answer an investigator from one that improvises.
Clause 4.2.3 — Medical Device File
The SBOM, the threat model, the security architecture description, and the cybersecurity labeling all become part of the documented device file. This is the folder an investigator opens first.
Clause 6.2 — Competence
Who is qualified to perform threat modeling? To review a penetration test? To triage a disclosed vulnerability? Competence must be defined per role and evidenced. A contractor's résumé in an email thread is not evidence.
Clause 7.1 — Planning of Product Realization
Risk management planning across realization. This is where the cybersecurity risk process is declared and connected to ISO 14971.
Clause 7.3 — Design and Development
The five security objectives enter as design inputs (7.3.3), are examined at design review (7.3.5), are proven at verification (7.3.6), are confirmed in the intended-use environment at validation (7.3.7), and are governed through change control (7.3.9). The SPDF maps almost one-for-one onto this subclause family.
Clause 7.4 — Purchasing
Third-party and open-source software components are purchased product in every sense that matters. Supplier evaluation now has a software-provenance dimension, and your SBOM is the register.
Clause 8.2 — Feedback and Complaint Handling
A reported vulnerability arriving through your coordinated disclosure channel is feedback. Sometimes it is a complaint. Sometimes it triggers regulatory reporting. Your intake process must be able to tell the difference — and prove it did.
Clause 8.5 — Corrective and Preventive Action
A patch is a correction. The process improvement that stops the class of vulnerability recurring is the corrective action. Confusing the two is the most common finding MSI sees when security work meets a quality auditor.
Two supporting standards do heavy lifting inside this map. IEC 62304 governs the medical device software lifecycle and gives the SPDF a software-engineering spine. ISO 14971 governs risk management and is the mechanism by which a known vulnerability in a third-party library becomes a documented, evaluated, and controlled risk of patient harm rather than a ticket in a backlog. Neither is optional in practice, and neither is a substitute for the other.
Direct Answer
Medical device cybersecurity maps onto ISO 13485 as follows: security documentation into the Medical Device File (4.2.3), qualified personnel into competence (6.2), the cybersecurity risk process into product realization planning (7.1) linked to ISO 14971, the five security objectives into design and development (7.3.3 through 7.3.9), software component provenance into purchasing (7.4), vulnerability reports into feedback and complaints (8.2), and patches and process fixes into CAPA (8.5). Building this map is the first practical step in bringing medical device cybersecurity under QMSR control.
Scope
Which Products Are In Scope for Medical Device Cybersecurity Requirements?
Three tests. One answer.
Section 524B defines a cyber device with a three-part test, and all three parts must be true. The device includes software validated, installed, or authorized by the sponsor as a device or in a device. It has the ability to connect to the internet. And it contains technological characteristics, validated or installed or authorized by the sponsor, that could be vulnerable to cybersecurity threats.
Read the test carefully and two things become obvious. First, “cyber device” is narrower than “device with software” — an implantable with firmware and no connectivity may not meet the statutory definition. Second, and more importantly, the guidance is broader than the statute. The FDA recommends addressing medical device cybersecurity in a premarket submission for any device with cybersecurity risk, connected or not — because a device that does not connect to the internet can still be compromised through a service laptop, a USB port, or a maintenance interface. The statutory floor and the guidance ceiling are not the same height.
Legacy devices sit in the most uncomfortable position. A device cleared before March 29, 2023 may fall outside Section 524B's premarket obligations entirely — and yet the FDA expects ongoing cybersecurity risk management for connected devices already on the market. “We are not in scope” is a statement about a submission, not a statement about your postmarket obligations, and organizations that conflate the two are carrying risk they have not written down anywhere.
And then there is the boundary that is moving fastest: connected health products that may or may not be regulated devices at all. On January 6, 2026 — four weeks before the cybersecurity guidance — the FDA issued its General Wellness policy for low-risk devices, signaling that it does not intend to enforce traditional device requirements for general wellness products, including many wearables and apps. Which side of that line a product lands on determines whether any of this article applies to it. We take that question apart in detail in our companion guide to digital health FDA compliance for wearables and health apps, because a single feature release can move a product from one side of the line to the other.
Direct Answer
Section 524B's “cyber device” test has three parts, all of which must be met: sponsor-validated software in or as the device, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. But medical device cybersecurity expectations reach further than the statute — the FDA recommends addressing cybersecurity for any device with software or programmable logic that carries cybersecurity risk, including devices that are not network-connected. Assume medical device cybersecurity applies if your device contains code.
From 200+ Audits
How Medical Device Cybersecurity Actually Fails in the Audit Room
Observed. Repeated. Preventable.
Across 28 years and 200+ certification audits attended alongside clients, MSI has watched the same failure modes repeat whenever a technical discipline meets a quality auditor for the first time. Medical device cybersecurity is following the identical pattern that software validation followed a decade ago, and design controls followed before that. The technology is new. The failure is not.
MSI client experience suggests these are the medical device cybersecurity patterns most likely to generate a finding.
The orphaned artifact
A beautifully executed threat model that no procedure requires, no plan references, and no record of review accompanies. The work is excellent. The system cannot prove it happened. To an auditor, an artifact with no process behind it is indistinguishable from an artifact created the night before the audit.
The stale bill of materials
An SBOM generated once for the submission and never regenerated. Three releases later it describes a product that no longer exists. Because it is now a controlled document within the Medical Device File, its obsolescence is a document control failure as well as a security failure — two findings from one omission.
The disclosure channel nobody answers
A coordinated vulnerability disclosure plan is documented, submitted, and accepted — and then no one tests it. Ask the quality manager who receives a report at the disclosure address and how long they have to respond. If the answer takes more than five seconds, the plan is decorative. An auditor will ask that question, and increasingly, so will an investigator.
The patch that was never a change
Security patches shipped through the engineering release process without passing through design change control under Clause 7.3.9 — no impact assessment, no verification record, no regulatory notification decision. This is where medical device cybersecurity and change management collide, and it is the reason we wrote about change management automation and about change management as a proven system. A patch is a design change. Treat it as one.
The competence nobody documented
The penetration test was performed by a firm whose qualifications live in a procurement email. Clause 6.2 asks who is competent and how you know. If the answer is “they came recommended,” the medical device cybersecurity program has a supplier-control problem that is also a competence problem.
The management review that never mentions it
Twelve required inputs are covered. Cybersecurity posture is not among them, because nobody added it. Under the QMSR those minutes are FDA-inspectable, and their silence on medical device cybersecurity is itself a data point about how seriously top management takes it.
“In every audit I have attended where a technical discipline failed, it failed the same way: the work was done, and the system could not prove it. Medical device cybersecurity is about to teach that lesson to a new generation of engineers.” — Diana Lynn, President, Management Systems International
Direct Answer
The most common medical device cybersecurity audit failures are structural, not technical: security artifacts with no procedure behind them, an SBOM that was never regenerated, a disclosure channel that has never been exercised, security patches that bypassed design change control, uncredentialed testers, and management reviews that never discuss cybersecurity at all. Organizations typically report that the security work itself was competent — what failed was the quality system's ability to demonstrate that medical device cybersecurity is a controlled, repeatable process.
The Build
Building a Medical Device Cybersecurity Program Inside the Quality System
Sequence. Structure. Sustain.
The organizations that will handle this well are not the ones with the best security team. They are the ones whose quality system was already load-bearing before cybersecurity arrived. A strong ISO 13485 system absorbs a new discipline the way a good foundation absorbs a new floor. A weak one buckles, and the crack shows up somewhere you were not looking.
The sequence that works is unglamorous. First, score where your quality system actually stands — MSI's self-scoring ISO 13485 Gap Analysis covers every clause of the standard, including design controls, and returns a readiness percentage plus a recommended next step for each item. No consultant required. Second, map every cybersecurity activity you already perform to the ISO 13485 clause that governs it — the map above is a starting point, not a finished artifact. Third, find the activities that have no owner, no procedure, or no record, because those are your real exposure. Fourth, write the procedures that make those activities repeatable, and write them with the engineers who will follow them rather than handing down a template they will quietly ignore. Fifth, train the people. Sixth, audit it internally before a registrar or an investigator does it for you.
That fifth step is the one most organizations skip and the one that pays for itself fastest. An internal audit that puts a trained auditor in front of your threat model, your SBOM, and your disclosure log will find in an afternoon what an FDA investigator would find in a morning — with the difference that you get to fix it first. Building genuine internal audit capability is not a nice-to-have in a device company; it is the difference between owning your quality system and renting it.
This is precisely the terrain where experienced ISO consulting earns its keep. Translating a technical discipline into clause-mapped, auditable procedure is not a security skill and it is not an engineering skill — it is a management-system skill. Management Systems International (MSI) has spent 28 years doing exactly that translation in regulated environments where evidence has to survive contact with an investigator: 80+ certifications supported, 200+ audits attended, and 600+ professionals trained across manufacturing, technology, medical device, government, healthcare, and other regulated industries. ISO consulting for a device company is not about handing over a binder. It is about leaving behind a system your team can run without you.
Three things distinguish MSI's approach for device organizations, and they matter more than usual here. MSI writes the actual procedures alongside your engineers rather than issuing templates — which is decisive in design controls, where a generic procedure is worse than no procedure. MSI trains your staff to run internal audits, because a device company that depends permanently on an external auditor has not built a quality system. And MSI attends the certification audit. Being in the room on audit day is a commitment most consultants will not make, and it is where 200+ audits of pattern recognition actually gets spent.
For organizations that want the whole path run for them, SurePath is MSI's turnkey route from decision to certificate — procedures written with your engineers, staff trained, internal audit program built from day one. For organizations already certified, SureResults keeps the system audit-ready year-round, which is the only realistic way to keep a medical device cybersecurity program from decaying between surveillance visits. And because much of this work becomes unmanageable on spreadsheets at scale, MSI's alliance with CAQ AG Factory Systems supports the platform side — we describe how to sequence that decision in our guide to procedure-first ISO compliance automation.
Your Next Step
Map Your Cybersecurity Evidence to ISO 13485 Clauses — Before an Investigator Does
Bring your threat model, your SBOM, and your disclosure plan to a planning session with MSI. In one working conversation you will leave with a clause-by-clause map of where each artifact lives in your ISO 13485 system, an honest list of what has no procedure behind it yet, and a sequence for fixing it — what to do first, what can wait, and what a realistic timeline looks like given the staff you actually have. MSI has attended 200+ certification audits and knows which controls a registrar tests hardest in a device company.
Call 760-434-9141 to book a planning session.
Want a score before you call? Run MSI's self-scoring ISO 13485 Gap Analysis first — every clause of the standard, an instant readiness percentage, and a recommended next step for each item. Bring the scored results to the planning session and you skip straight to sequencing.
Need the system itself, not just the map? SurePath builds a QMSR-ready ISO 13485 quality system around how your team actually designs and ships — and MSI is in the room on audit day.
Still deciding whether to commit? Watch the ISO Executive Decision Briefs — short leadership videos on what an ISO program really costs, how long it takes, and what it returns, so you can make the call with numbers instead of guesses.
Questions
Medical Device Cybersecurity: Frequently Asked Questions
Ask. Answer. Act.
Do I need to redo my submission because of the February 2026 guidance update?
Probably not, if you were already following the June 2025 edition. The technical medical device cybersecurity expectations did not change — the regulatory citations did. What does need attention is your internal documentation: procedures, templates, and submission language that reference 21 CFR Part 820 subsections should be re-mapped to the corresponding ISO 13485:2016 subclauses, and your cybersecurity processes should be traceable under the QMSR framework.
Is an SBOM enough to satisfy the FDA?
No. A software bill of materials is one required element of medical device cybersecurity, not the whole of it. Section 524B also requires a postmarket vulnerability monitoring plan with coordinated vulnerability disclosure, processes providing reasonable assurance the device is cybersecure, and a commitment to make updates and patches available. And the SBOM itself is only useful when paired with an assessment of known vulnerabilities in the listed components as reasonably foreseeable risks — an inventory without a risk analysis answers a question nobody asked.
My device does not connect to the internet. Am I exempt?
You may fall outside the statutory “cyber device” definition in Section 524B, which requires the ability to connect to the internet. You are not outside medical device cybersecurity expectations. The FDA's guidance applies to devices with software, firmware, or programmable logic that carry cybersecurity risk — including devices that are not network-enabled — because service laptops, USB ports, and maintenance interfaces are all attack surfaces. Treat the statute as a floor, not a ceiling.
Who owns medical device cybersecurity — the security team or the quality team?
Both, and the split is the point. Security engineers perform the technical work — threat modeling, testing, architecture. The quality system makes that work provable: defined procedures, competent people, controlled records, design reviews, change control, CAPA, and management review. Medical device cybersecurity fails in audits not because the engineering was weak but because the quality system could not demonstrate it. Assign the activity to security and the evidence to quality, and make one person accountable for the seam between them.
Does ISO 13485 certification prove my cybersecurity is adequate?
No, but it is now the framework in which adequacy is assessed. A certificate says a registrar found your quality management system conforming at a point in time. Medical device cybersecurity conformity depends on whether the specific processes — design inputs, risk management, software provenance, vulnerability handling, patch change control — were actually built into that system and are actually running. A certified system with no cybersecurity procedures is certified and exposed at the same time.
How long does it take to bring a cybersecurity program under QMSR control?
It depends on what already exists. Organizations typically report that mapping existing medical device cybersecurity activities to ISO 13485 clauses takes weeks, while writing and implementing the missing procedures — and training people to follow them — takes months. Companies with a mature quality system and immature security work move faster than the reverse, because procedure discipline is harder to install than a threat modeling habit. Book a planning session at 760-434-9141 for a timeline based on your actual staffing.
Related Reading
Keep Going
- Digital Health FDA Compliance — the companion guide: are your wearable and app regulated devices, or general wellness products?
- The FDA QMSR Rule — how 21 CFR Part 820 and ISO 13485 became one regulation.
- ISO 13485 Management Review — the twelve Clause 5.6.2 inputs, and where cybersecurity now belongs among them.
- ISO 13485 Gap Analysis — score every clause of the standard yourself and get an instant readiness percentage.
- The FDA Voluntary Improvement Program — measuring how maturely your device quality system actually operates.
- The ISO Consulting Decoder Ring — why ISO 13485 keeps its own clause architecture, and what that means for you.
- Design and Development Process — the Clause 7.3 discipline that cybersecurity now depends on.
- Five ISO Maintenance Risks — how certified systems quietly decay between audits.
- Multi-Site ISO Certification — when design happens in more than one place.
- ISO 13485 QMS Overview Course — get the whole team operating to the documented system.
References & Further Reading
- U.S. FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final guidance, February 3, 2026).
- U.S. FDA. Digital Health Center of Excellence — Cybersecurity.
- U.S. FDA. General Wellness: Policy for Low Risk Devices (January 6, 2026).
- Federal Register. Medical Devices; Quality System Regulation Amendments — 89 FR 7496.
- eCFR. 21 CFR Part 820 — Quality Management System Regulation.
- eCFR. 21 CFR Part 10 — Administrative Practices and Procedures (guidance levels).
- ISO. ISO 13485:2016 — Medical devices, quality management systems.
- ISO. ISO 14971:2019 — Application of risk management to medical devices.
- IEC. IEC 62304 — Medical device software lifecycle processes.
- U.S. FDA. Medical Device Single Audit Program (MDSAP).
- NIST. Cybersecurity Framework.
- CISA. Cybersecurity and Infrastructure Security Agency — advisories and coordinated disclosure.
- AAMI. Association for the Advancement of Medical Instrumentation.
- IMDRF. International Medical Device Regulators Forum.
- ASQ. Quality Auditing Resources.
About the Author
About Management Systems International (MSI)
Diana Lynn is President and Principal ISO Consultant at Management Systems International (MSI), a veteran-owned, female-owned ISO consulting firm she co-founded in 1998. With 28 years of experience including extensive AS9100 work in MSI's early years, MSI's track record includes 80+ certifications supported, 200+ audits attended, and 600+ professionals trained across manufacturing, technology, medical device, government, healthcare, and other regulated industries.
Today MSI implements ISO 9001, ISO 13485, ISO 14001, and ISO 45001, with an expanding focus on ISO 7101 healthcare quality.
msi-international.com · 760-434-9141
