My first step for QMSR readiness: link each device version to its risks, tests, release approval, and field history. Since February 2, 2026, FDA’s CP 7382.850 has replaced QSIT, shifting inspection preparation toward linked lifecycle records - not just files in separate folders.

I focus on five checks:

  • Trace each release: Connect hardware, software, cloud services, suppliers, and changes to the approved configuration.
  • Document security decisions: Keep vulnerability reviews, patch testing, incident responses, and end-of-support plans. Section 524B duties apply only to products that meet the definition of a cyber device.
  • Separate software uses: Device-software validation and production or QMS software assurance serve different purposes.
  • Keep older records accessible: Preserve records that support current compliance, including those from before QMSR took effect.
  • Keep responsibilities clear: Manufacturers maintain QMS records; healthcare delivery organizations manage deployment, local security, and vendor coordination.

I use a 15-minute retrieval drill as a readiness check - not an FDA deadline. My priority is <u>patient safety first</u>: assign each gap an owner, a due date, interim controls, and a check that the fix worked. Vendor-risk tools can help track that work, but they do not replace manufacturer records or FDA duties.

The New FDA Inspection Reality: The Shift from QSIT to QMSR & Section 524B Cybersecurity Audits

Quality Records for Connected Devices

Inspectors now expect a controlled set of records that links each connected-device decision to a specific version.

Required records are not an inspection package. QMSR, ISO 13485, FDA requirements, device commitments, and internal procedures define the evidence you need. Use a lifecycle index or version registry to help inspectors move from the current release to historical evidence. Give each record an owner, approver, backup, primary record location, retention rule, and escalation path.

Trace intended use and foreseeable misuse through hazards, threats, requirements, controls, verification, validation, and residual-risk review. Release approval should state exactly what was approved: the configuration, evidence reviewed, decision-maker, and any monitoring commitments.

Record category Connected-device evidence Inspection question Accountable owner
Design and risk management Design inputs, threat model, risk-management file, design reviews, residual-risk approval How did risks shape requirements and controls? Engineering and cybersecurity
Verification and validation Test protocols, results, security testing, clinical and usability validation Does evidence cover the released configuration and intended use? Verification/validation lead; clinical or usability lead
Production and release Build records, production controls, device or batch records, release approval What was built, verified, and released? Operations and quality
Supplier controls Qualification, audit reports, agreements, change notifications How were supplier risks and changes controlled? Supplier quality
Complaints and CAPA Investigations, root-cause analysis, corrective actions, effectiveness checks Did field evidence lead to effective action? Postmarket quality and CAPA owner
Regulatory decisions Submission commitments, change assessments, reporting decisions Were regulatory obligations assessed and met? Regulatory affairs

Track Versions, Dependencies, and Suppliers

Maintain a controlled baseline for hardware, firmware, software, OS, cloud, network, and third-party dependencies. This lets inspectors match an installed system to the approved release. Link the software bill of materials to its release. FDA’s cybersecurity requirements and guidance address commercial, open-source, and off-the-shelf software components.[6][7] Record release identifiers, dates, test status, approvals, and recovery instructions so teams can tell an approved configuration from an installed one.

Link supplier qualification, audits, change notices, and vulnerability notifications to affected configurations. This data supports real-time portfolio risk management across the device lifecycle. Each change-impact assessment should document safety and security effects, required testing, regulatory review, customer communication, and the disposition: patch, compensating controls, field correction, or justified no action. Include deployment dependencies such as identity services, remote access, and network settings.

Retain Historical and Postmarket Records

Treat complaints, service reports, cybersecurity incidents, surveillance, field actions, internal audits, and management reviews as lifecycle inputs - not separate archives. Link them by device ID, software build, complaint number, vulnerability ID, and CAPA number.

Preserve pre-effective-date records and use a crosswalk to map them to current terminology. Inspectors should be able to trace how historical decisions explain current controls.[2] Apply the relevant regulatory and procedural retention requirements and any holds - not one universal retention period.

Periodically reconcile quality, service, and cybersecurity records. Document discrepancies, owners, due dates, and resolutions. These records also support cybersecurity and software-validation reviews.

Cybersecurity Records and Software Validation

Connected-Device Cybersecurity Records Across the Lifecycle

Connected-Device Cybersecurity Records Across the Lifecycle

CP 7382.850 is not a separate cybersecurity rule. Still, inspectors can review cybersecurity evidence across design, change control, production, suppliers, and postmarket monitoring. For connected devices, records must show how vulnerabilities, patches, supplier changes, and incidents were assessed and resolved. Inspectors follow that evidence through the full lifecycle, rather than treating it as a separate set of files.[4][8]

Maintain Cybersecurity Records Through Retirement

Apply section 524B obligations only to products that meet the statutory definition of a cyber device. For these products, submit an SBOM identifying commercial, open-source, and off-the-shelf software components. Also maintain processes to monitor and address postmarket vulnerabilities and keep the device and related systems secure. These obligations come from section 524B - not QMSR - and apply only to cyber devices.[6][10][11]

Use the table below to organize threat models, SBOMs, vulnerability monitoring, patch decisions, and retirement records. Together, these records should show controlled security decisions from design through end-of-support.

Lifecycle stage Evidence to maintain Accountable owners Review triggers
Design Threat model, cybersecurity risk assessment, security architecture, cybersecurity requirements, data-flow diagrams Product cybersecurity and systems-engineering leads New threat, architecture change, new interface, or changed intended use
Release Security verification and validation reports, unresolved security-anomaly assessment, SBOM where applicable, security release approval, residual-risk assessment Quality, regulatory, engineering, and cybersecurity leads Major software release, failed security test, new vulnerability, or submission change
Deployment Secure configuration baseline, access controls, network assumptions, security installation and service instructions Field service, clinical engineering, and customer-success teams Installation deviation, network change, new integration, or security incident
Maintenance Vulnerability-monitoring records, coordinated-disclosure intake, patch assessment, security regression testing, cybersecurity incident and CAPA records, updated SBOM where applicable Postmarket surveillance, cybersecurity, quality, and supplier-management teams New CVE, exploit activity, supplier advisory, security incident, or patch
Retirement End-of-support notice, residual-security-risk communication, secure decommissioning procedure, data-retention and deletion records, customer notification Product management, quality, service, and regulatory teams End-of-support date, replacement availability, or inability to provide security maintenance

Use supplier advisories, the National Vulnerability Database, and CISA’s Known Exploited Vulnerabilities Catalog as monitoring inputs. Document why each vulnerability calls for a patch, interim controls, deferred action, or no action. At retirement, record remaining vulnerabilities, replacement or compensating-control guidance, and secure decommissioning or data-handling steps. Ending support does not eliminate remaining risk.[6][13]

Distinguish Device Validation From QMS Software Assurance

Cybersecurity records and software validation are linked, but they answer different inspection questions. Classify software by intended use, not where it runs. Device software, firmware, clinical interfaces, mobile apps, and device-related cloud functions require validation tied to their effect on safety and effectiveness.

FDA’s Computer Software Assurance (CSA) guidance addresses software used in medical-device production or the quality system. It recommends risk-based assurance that software is fit for its intended use. CSA does not replace device-software design verification and validation. If one platform serves both as a device function and a QMS tool, document both roles so inspectors can tell which evidence supports each use.[9][12]

Software category Intended use Applicable validation or assurance approach Evidence Accountable owner
Device firmware or embedded software Controls or monitors a device function Device software design controls, verification, validation, cybersecurity testing, and risk management Requirements traceability, test protocols and results, anomaly assessments, release approval Software engineering, systems engineering, quality, and regulatory
Clinical interface or interoperability module Exchanges data with an EHR, monitor, imaging system, or clinical workflow Device software validation plus interface, data-integrity, interoperability, and cybersecurity testing Interface specifications, mapping tests, negative tests, workflow validation, defect disposition Systems engineering, clinical engineering, quality, and clinical subject-matter experts
Patient or clinician mobile application Displays, collects, or controls device-related information or functions Device software validation based on intended use, supported platforms, usability, security, and performance Platform matrix, use-case tests, permissions review, usability evidence, release records Mobile engineering, clinical, cybersecurity, and quality
Cloud service Stores, analyzes, transmits, or presents device data or provides a device function Device software validation for device functions, with service-change control and cybersecurity verification Cloud architecture, availability and recovery tests, access-control tests, data-integrity tests, change records Cloud engineering, product, cybersecurity, and quality
Manufacturing or QMS application Supports production, inspection, release, CAPA, complaint handling, or records Risk-based CSA for production or quality-system software; validation for intended use remains required under QMSR Intended-use assessment, risk assessment, assurance activities, test evidence, access and audit-trail review Process owner, quality, IT, and validation lead

When these systems change, inspectors will look for evidence that the update was tested against its intended use.

Test Patches and Connected-Service Changes

Retain a change-impact assessment for affected configurations when making OS updates, firmware patches, cloud changes, third-party library changes, interface changes, database migrations, authentication updates, network-protocol changes, or emergency remediations. Assess the effects on clinical workflows, cybersecurity threats, safety hazards, performance, data integrity, interoperability, and continuity of care.

Where relevant, test normal operation, degraded connectivity, recovery, failover, backward compatibility, alarm behavior, access control, logging, and data synchronization. Keep failed tests and unresolved anomalies alongside passing results. The approval should explain why the remediation does not introduce unacceptable risk to patients, performance, data integrity, or continuity of care. Even urgent remediation needs documented risk controls, release authorization, deployment instructions, and follow-up effectiveness checks.[4][6][9]

Inspection Readiness in Healthcare Settings

For HDOs, inspection readiness means using records to prove control over deployment, monitoring, incident response, and vendor coordination - not recreating manufacturer-controlled QMS evidence.[4][2]

Organize Records for Inspection

Build an evidence index, not a shared source of truth. Manufacturer entries should link to controlled originals. HDO entries should identify supporting records from their own activities. Keep older records needed to verify the installed version and deployment history, and use a crosswalk to map those records to QMSR requirements.[2]

Use this readiness matrix to connect each installed device version to evidence of deployment, monitoring, remediation, and current risk status.

Evidence area Specific record Accountable owner Record location Last review date Affected device or version Open gap Remediation owner Target completion date Remediation status
Device/software inventory Current and historical inventories; approved configurations HDO biomedical engineering and IT CMMS/asset repository Date Device/version Unmapped legacy devices Owner Date In progress
Risk assessments and threat models Risk-management files, threat models, applicable SBOMs Manufacturer cybersecurity and quality; HDO security liaison Controlled QMS and vendor-risk repository Date Device/version Missing SBOM for field version Owner Date Open
Validation and change history Software-validation summaries; change and release approvals Manufacturer engineering and quality; HDO clinical engineering QMS/change-control system Date Device/version Deployment evidence incomplete Owner Date Planned
Supplier and vendor oversight Supplier qualification and monitoring records Manufacturer purchasing and quality; HDO procurement/security Supplier repository Date Device/version Expired assessment Owner Date Remediation due
Incidents, complaints, and CAPA Complaint, incident, and CAPA records Manufacturer quality; HDO patient safety/security Complaint, incident, and CAPA systems Date Device/version CAPA linkage under review Owner Date Open
Audits and management reviews Internal audit reports and management review minutes Manufacturer quality/management; HDO governance Audit and governance repository Date Device/version Evidence retrieval test pending Owner Date Scheduled

Test whether teams can retrieve records within 15 minutes. Check permissions, timestamps, approval signatures, controlled history, backup availability, and links to deployed device versions. Record failed retrievals, missing approvals, and release-to-installation mismatches as gaps. Reconcile inventory monthly and keep dated reviews.[4][5]

Rehearse a Vulnerability-to-CAPA Review

Once the records are indexed, put them to the test. Rehearse how one vulnerability moves from detection through triage, escalation, and closure.

Use a tabletop exercise on unauthorized access to a network-connected infusion pump. Name one incident lead and alternates. Manufacturer cybersecurity triages the exposure; engineering traces affected versions through change requirements, design controls, testing, and release approval; quality documents complaint handling and whether CAPA is warranted; regulatory assesses applicable reporting duties. HDO biomedical engineering confirms installations and installed-device monitoring, cybersecurity checks segmentation and remote access, and clinical operations checks downtime procedures and patient-safety escalation. Vendor management confirms support contacts; leadership approves resources and risk decisions. Preserve a timeline through incident handling and effectiveness checks, including the rationale if CAPA is not opened. A vulnerability alone does not trigger CAPA.[4][14]

Coordinate HDO and Vendor Risk Assessments

Use shared vendor assessments to close evidence gaps and assign responsibility for mitigation. Keep HDO records separate from manufacturer QMS files.

Censinet RiskOps™ can support HDO and vendor risk assessments for medical devices, PHI, and supply chains. It can help teams request missing evidence and track unresolved mitigation tasks. These coordination records do not replace manufacturer QMS records, software validation, or FDA compliance duties.

Conclusion: Keep Records Ready for Inspection

For connected devices, inspection readiness starts with traceability across the lifecycle. Link every risk decision to its control, test evidence, residual-risk approval, and release decision. Use the same identifier scheme for cybersecurity, software, supplier, and postmarket records, all within one controlled record set.

Keep device validation separate from QMS software assurance. Keep historical records available, including evidence from before February 2, 2026, when it still supports current compliance. Retain management reviews and quality and supplier audits.[2][1] Map older records to the device or software version under review. If an inspector can't retrieve a record quickly, the control isn't inspection-ready.

Assign primary and backup owners. In the record index, keep manufacturer and HDO responsibilities separate. During periodic reviews, check retrieval drills, overdue risk reviews, and cybersecurity benchmarks for unresolved supplier issues - not just whether files exist. Then check whether those records support fast action on active risks.

Address patient-safety gaps first: unsafe therapy, lost monitoring, connectivity failures, and uncontrolled remote access. Give each action an owner, deadline, interim control, and effectiveness check. Records should show how decisions remain controlled as devices, software, and clinical workflows change.

FAQs

How do I prioritize connected-device QMSR readiness gaps?

Take a risk-based approach that focuses on exploitability and potential patient harm - not standard probability calculations. Rank threats using CVSS, check the CISA Known Exploited Vulnerabilities (KEV) Catalog, and prioritize devices based on their clinical importance and network exposure.

Bring vulnerabilities into the Corrective and Preventive Action (CAPA) process under ISO 13485 Clause 8.5. This keeps the quality system closed-loop and supports inspection readiness.

How can I tell whether my device qualifies as a cyber device?

Under Section 524B of the FD&C Act, your device qualifies as a cyber device if it includes sponsor-validated software and can connect to the internet or other networks [1][2][3].

That connectivity includes Wi-Fi, cellular, Bluetooth, RF, USB, Ethernet, and serial ports - even if internet use isn’t intended [1][4]. Check FDA guidance for details that apply to your device’s architecture and software [3].

What should my hospital do if a vendor withholds compliance records?

If a vendor withholds required compliance records, use your Corrective and Preventive Action (CAPA) process to document the issue, identify root causes, and put system-level fixes in place. Record which documents are unavailable, the justification for their absence, and any compensating controls.

Include documentation requirements in procurement contracts. Censinet RiskOps™ centralizes vendor disclosures and tracks remediation through collaborative Corrective Action Plans. If noncompliance persists, you may need to apply contractual penalties or end the vendor relationship.

Related Blog Posts