7 QSR Records for Device Security Audits

For a device-security audit, I start with 7 linked record categories - not just security test results. Each should help you trace a risk from its first review through testing, release, field response, and closure.

FDA’s QMSR took effect on February 2, 2026. I use QSR only for legacy records and check which QMSR requirements - and Section 524B duties for cyber devices - apply.

Here’s what I include in the audit index:

• Risk-management files: Risks, controls, and approved risk decisions.
• Security test reports: Tested versions, results, failures, and retests.
• Change and release records: Approved changes, release versions, and deployment outcomes.
• Medical device supplier and component files: Supplier reviews, SBOMs, support terms, and fixes.
• Complaint and postmarket records: Field reports, investigations, and reporting decisions.
• CAPA and nonconformance records: Containment, root causes, corrective actions, and effectiveness checks.
• Disclosure and incident-response records: Intake, triage, communications, remediation, and closure.

These are not a universal FDA checklist. I map them to the device’s risks and applicable requirements, then check one thing: <u>Can a reviewer follow the record trail and verify the outcome?</u>

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

sbb-itb-535baee

Determine Which QMSR and Cybersecurity Requirements Apply

Build an applicability matrix for each device or device family. Record the basis for each decision, including any exclusions. Identify whether QMSR and design-and-development controls apply. Then assess Section 524B separately if the device qualifies as a cyber device.^[8][13] Use this matrix to assign each of the seven record categories below.

Section 524B sets binding obligations for qualifying submissions, including 510(k), PMA, De Novo, PDP, and HDE submissions. Required evidence includes a postmarket vulnerability-monitoring plan with coordinated disclosure, cybersecurity processes that provide reasonable assurance, and an SBOM covering commercial, open-source, and off-the-shelf components. Patch processes must address known unacceptable vulnerabilities on a justified regular cycle. They must also address critical vulnerabilities as soon as possible outside that cycle.^[7][8][9]

Separate statutory duties from FDA guidance in the matrix. FDA guidance recommends practices for design, labeling, premarket documentation, and lifecycle cybersecurity management. It does not automatically require a separate mandatory record for every recommendation.^[10][12] Security requirements can go in design inputs, threat analysis in risk records, and penetration-test results in verification reports. Map each requirement to one controlled record, an owner, and an approval path. Keep internal procedures distinct from statutory duties so each requirement links to an audit record you can retrieve.

A manufacturer’s QMS records and an HDO’s assessment serve different purposes. Manufacturer records document device design, testing, production, maintenance, and postmarket controls. An HDO’s questionnaire or deployment approval does not replace required manufacturer records.^[4][7]

Use DHF, DMR, and DHR as search terms only. Map them to the design-and-development file, medical device file, and production/traceability records, respectively.^[11][14] Update the audit index to point to those controlled locations. An old file title is not proof of compliance; auditors will follow the mapped records in the seven categories below.

1. Device Security Risk Management Files

Use this file to show how each cybersecurity risk was identified, controlled, and accepted. Include or link to the risk-management plan, risk analyses, threat models, misuse scenarios, architecture diagrams, security requirements, and design inputs.

Define the device version, intended use, assumptions, connected systems, assessment method, risk criteria, and acceptance criteria. Document how cybersecurity risks that could affect patients feed into the safety-risk assessment.

Lifecycle Coverage

Cover the device from design through deployment, maintenance, updates, and retirement. Reassess the file when architecture changes, new vulnerabilities, supplier changes, complaints, or incidents arise. Keep threat modeling active throughout design and system-wide deployment.

Security Control Evidence

For each control, record why it was selected, where it is implemented, and what limits its effectiveness. Separate implemented controls from planned measures and controls that depend on local configuration. Keep the rationale for any controls that were rejected or deferred.

Residual-risk evaluations should state the post-control risk, acceptance criteria, remaining exposure, and approver.

Record Traceability

Use stable IDs to link each threat, requirement, control, test result, and residual-risk decision. Auditors should also be able to trace each requirement back to its risk.

Check for missing tests, failed tests without follow-up, and risks without owners. Unresolved issues need a status, owner, due date, compensating controls, and escalation path - not just a “low risk” label.

Document Control and Approval

Give each record a title, ID, revision, effective date, owner, and approval status. Keep prior versions and approval history so reviewers can reconstruct release decisions. These records set the baseline for security verification and validation testing.

2. Security Verification and Validation Test Reports

The risk file defines what needs testing. Verification and validation reports show whether the device’s security controls work in the configured system, not just on paper. FDA materials group this evidence into four areas: security requirement testing, threat-mitigation testing, vulnerability testing, and penetration testing.^[7][8]

Security Control Evidence

Test authentication, authorization, access control, and encryption under both permitted and prohibited conditions. Include vulnerability scanning, software composition analysis, static and dynamic analysis, penetration testing, fuzzing, and abuse-case testing.

Record the scope, input types, duration or volume, observed behavior, and safety impacts. A vulnerability scan does not replace penetration testing, which attempts to exploit weaknesses and assess their impact.^[7][16][17] These results should show whether each tested control worked as intended under expected and hostile conditions.

Lifecycle Coverage

Test the release candidate before deployment. After patches or changes, retest installation, vulnerability correction, recovery, and essential performance. Repeat impact-based regression testing when components, threats, or architecture change.^[6][14] This test history feeds the change records in the next section.

Record Traceability

Link each test execution to its requirement, exact hardware and software build, configuration, and component versions. Trace it back to the requirement and forward to the fix, retest, or approved risk acceptance.

Connect each failure to its disposition, including escalation through nonconformance, CAPA, or a release hold. Keep unresolved findings visible. Each needs containment, an owner, remediation timing, and an approved disposition.^[14][18]

Document Control and Approval

Retain approved protocols with predefined acceptance criteria, test steps, results, pass/fail status, dates, tester identity, independence, and reviewer approvals. Preserve tool versions, configurations, scripts, and logs so reviewers can understand or reproduce the results.

Document deviations and how they affect validity. Do not silently revise acceptance criteria after a failure.^[15][16]

3. Design, Configuration, and Release Change Records

Record Traceability

Each ECO should identify the device, affected component, current and proposed versions, reason for the change, and owner. The release manifest should list the exact build, dependencies, security settings, configuration baseline, and release status. It should also link to affected specifications and release notes.^[19][15]

Lifecycle Coverage

Use test results to decide whether a change is routine or needs security review. Classify changes by security impact, not size. For routine maintenance, document why the change does not affect functionality, the attack surface, or controls.

Changes to network interfaces, authentication, encryption, third-party libraries, or update mechanisms need a security-impact assessment. Record affected threats, vulnerabilities, patient-safety risks, threat-model updates, and any required regulatory review.^[4][5][6]

Document Control and Approval

Record who reviewed and approved the change, along with the release decision and supporting regression test evidence. Update affected documents and prevent obsolete binaries and configurations from being used.^[19][21]

Approval isn't the end of the release trail. Verify that the release reached the intended devices. Deployment records should identify which devices received the artifact, the installation date, and the outcome: success, failure, or rollback. Compare the installed state with the release package and test evidence to confirm continued conformity in the field.^[19][15]

Emergency patches must follow the same ECO and release trail. Record the triggering vulnerability or incident, why urgent action was needed, and the initial safety and security risk assessment. Document the decision authority, test scope, deployment population, and rollback plan. Retain post-release monitoring records and a documented post-release review. Expedited handling must preserve traceability; route missing evidence through nonconformance or CAPA.^[4][5]

These records also support supplier review and postmarket complaint tracking.

4. Supplier and Third-Party Component Files

External components and services need the same traceability as internal design changes. Keep records that show how they remain controlled throughout the device lifecycle.

Document Control and Approval

Keep supplier qualifications, assessments, and approval decisions together. Record the supplier’s identity, supplied products or services, risk rating, findings, approver, approval date, and any conditions.

Base assessment depth on the supplier’s effect on device safety and security - not certifications. Keep approval status current, and control revisions to purchasing specifications and agreements.

Security Control Evidence

Purchasing specifications and contracts should spell out:

• Security requirements, SBOM delivery, patch and remediation support, change notification, and audit rights.
• Incident-reporting deadlines, emergency contacts, coordinated vulnerability disclosure terms, and evidence preservation.
• End-of-support notice periods, final patch obligations, and migration support.

A signed contract does not prove its requirements were met. Retain acceptance records showing that delivered products and services meet those requirements.

Record Traceability

Link each component’s name, supplier, version, dependencies, support status, and end-of-support date to the device versions that use it. Keep current and prior SBOMs, and reconcile them against the internal component inventory. Use them as traceability evidence - not proof of security.^[23]

Section 524B(b)(3) requires cyber-device premarket submissions to include an SBOM covering commercial, open-source, and off-the-shelf software.^[6][9]

Lifecycle Coverage

Retain supplier advisories, internal risk decisions, patch notices, remediation commitments, and closure evidence. Monitor supplier notices, the National Vulnerability Database, and CISA’s Known Exploited Vulnerabilities Catalog.

Performance reviews should track notice timeliness, patch response, open findings, and support continuity. Document missed commitments, escalations, interim controls, and decisions to continue approval, suspend use, or replace the supplier.^[7][8]

Auditors should be able to trace a sampled component from supplier approval and purchasing requirements through its assessment, SBOM entry, advisory, and remediation outcome. Connect unresolved supplier issues to nonconformance or CAPA records where appropriate. The manufacturer remains responsible for oversight of external processes, products, and services that affect device security.^[6]

Unresolved supplier issues often appear first in complaints or field reports; the next section covers those records.

5. Complaint and Postmarket Cybersecurity Records

Complaint files show when problems in the field slip past design and supplier controls.

Document Control and Approval

Record the date the complaint was received, device name and model, applicable UDI or other identifier, and reporter contact information. Keep the original description, affected software or firmware version, serial or lot number, corrections or corrective actions taken, and the reply sent to the reporter.^[22][20] Include the record ID, owner, status, and approval history.

Security Control Evidence

Document who reviewed the report, when they reviewed it, and how they assessed patient-safety impact, exploitability, and which devices were affected. Keep logs, reproduction results, technical findings, and the investigation decision. If a substantially similar complaint was already investigated, link to that investigation and explain why another investigation isn't needed. Keep the review record - a closed ticket isn't enough.^[22]

Treat safety severity and reporting requirements as separate assessments. Evaluate Medical Device Reporting (MDR) under 21 CFR Part 803 and corrections or removals under Part 806.^[4][5] Record MDR and Part 806 decisions separately, including the criteria, facts, decision-maker, date, and approval. When no report is filed, document why.

MDR files must remain readily retrievable. Retain them for two years from the event date or the expected device life, whichever is longer.^[25]

Record Traceability

Link each complaint to the risk assessment, investigation, engineering change, patch validation, customer notice, field correction or recall, and CAPA. Auditors should be able to follow those links through the final action and verify that it addressed the risk.^[4]

Lifecycle Coverage

Track reports from intake through remediation and post-remediation monitoring, including reports involving legacy and end-of-support devices. Track complaint trends by device family, version, severity, recurrence, triage delay, overdue investigation, and repeat failure. Record the review period, thresholds, reviewer, and escalation decisions.^[4][24]

These records feed CAPA decisions in the next section.

6. CAPA and Nonconformance Records

When a security nonconformance points to a process failure, CAPA records show whether the fix addressed the process or just the immediate issue.

Document Control and Approval

Keep the nonconformance report, affected versions, CAPA decision, owner, risk-based priority, due dates, and approvals. Document why the security issue requires CAPA. For nonconforming products, retain records of containment, disposition, use-as-is justification, and rework and retest evidence.^[26][29]

Security Control Evidence

A patch is a correction - not proof of systemic corrective action. Root-cause analysis should identify both the technical defect and the process failure that let it slip through. Corrective actions should remove the cause; preventive actions should address similar potential failures in other products or processes.^[26][28]

Keep correction verification separate from effectiveness checks. Fix verification confirms that the correction works without adding risk. Effectiveness checks confirm that the underlying process prevents recurrence. Define the effectiveness criteria and retain evidence from later release reviews, audit sampling, or recurrence trends. Training completion or patch delivery alone isn't enough.^{[4][26][27][28]}

Record Traceability

Use stable identifiers to link the CAPA to affected devices and versions, complaints, recurring vulnerabilities, supplier corrective actions, risk files, engineering changes, and test reports. These links let auditors compare the affected-product assessment with completed actions and check whether every product using the same vulnerable component was evaluated.^[20][26]

Lifecycle Coverage

Track the CAPA record through containment, investigation, implementation, post-release monitoring, and effectiveness review. Closure requires evidence that actions met their criteria, product disposition was completed, and an approved residual-risk review was documented. Management-review records should include major trends, overdue actions, and applicable closure approvals.^[26][27]

Keep any unresolved vulnerability linked to disclosure and incident-response records.

7. Vulnerability Disclosure and Incident Response Records

Auditors use these records to check that a vulnerability was received, assessed, contained, remediated, reported when required, and closed.

Document Control and Approval

Keep approved, version-controlled CVD and incident response procedures with named owners and review dates. Define the reporting channel, acknowledgment target, escalation path, communication approvals, and closure criteria. Cyber-device submissions must include CVD procedures in the postmarket cybersecurity plan.^[7][8][6]

Lifecycle Coverage

When a vulnerability reaches the field, auditors need a complete response trail from intake through closure. Keep each intake record, including the date received, reporting channel, reporter contact, affected product and version, UDI details, safety impact, owner, case number, triage outcome, and acknowledgment.^[4][5]

Set and document a risk-based remediation timeline for each case. FDA does not set a single deadline that applies to every case.^[7][8][6][4]

Security Control Evidence

Record severity and exploitability based on attack surface, privileges, network exposure, authentication, and patient harm. Keep investigation notes, log reviews, reproduction steps, root-cause findings, and containment actions. Also retain approved decisions about patches, firmware, configuration, monitoring, or compensating controls. Link every response action, remediation decision, and piece of follow-up evidence to the case record.

Keep dated communications with researchers, customers, suppliers, providers, and regulators. Include communications about interim safeguards and remediation availability.

Document the reporting assessment for every significant case. Include the applicable pathway, facts considered, deadlines, legal or regulatory review, and final approval. Retain any submitted reports, acknowledgments, follow-up correspondence, and closure records.^[4][5]

Record Traceability

Use the case ID to link the disclosure record to related complaint, risk, nonconformance, supplier, change, V&V, and CAPA records. Show how the case updated the risk file, led to a remediation change and retest, and informed the CAPA referral decision. Auditors should be able to follow these links through the full response history and map disclosure and incident response records to QMSR controls.

Keep lessons learned, CAPA referral decisions, procedure-review records, and exercise results. Include response times, communication gaps, assigned actions, and records showing that identified gaps were closed.

How the 7 Record Categories Connect to QMSR

Link these seven record categories to the QMSR processes they support, rather than keeping them in a separate cybersecurity archive. The table shows where each record type fits.

Treat this table as a process crosswalk, not a filing checklist. Use legacy QSR labels only to index older files, and cross-reference pre-2026 QSR files to current QMSR/ISO 13485 records and controlled locations.^[3] These process links should let you retrieve records and trace them through the audit trail.

Link Records to Build a Retrievable Audit Trail

Once you’ve mapped the seven record categories, connect them with one master case ID. Assign it at intake and use it on every related record. Include the device model, UDI or other product identifier, software version, and affected component. Link records in both directions so auditors can move from complaint to test - and back.

Each case should connect complaint, risk, supplier, change, test, and CAPA records.

Hypothetical investigation: An authenticated user with overbroad privileges accesses configuration data through a device’s remote-support service. Link Complaint CMP-2026-014 → Vulnerability Record VUL-2026-003 → Risk Assessment RA-2026-022 → Supplier Action SCAR-2026-006, if applicable → Engineering Change Order ECO-2026-041 → Validation Report V&V-2026-019. Open CAPA-2026-008 only when documented CAPA criteria are met, such as recurrence or systemic failure.

Keep the rationale, not just the remediation. Document the patient-safety assessment, affected versions, supplier response, release approval, notification and field-action decisions, and closure rationale. If no further investigation or CAPA is warranted, keep the evidence and approved justification. Complaint investigation decisions must remain documented.^[27][20][2]

Store records in controlled systems with revision status, access controls, retention rules, and backups. Keep originals and log every change, its date, and the reason for it.^[30]

Test whether the audit trail can be rebuilt from identifiers alone. Have an independent reviewer reconstruct a closed case using the same case chain. Track retrieval time and missing links, then fix those gaps before the final review.

Conclusion: Check Record Completeness and Traceability

Before closing the audit file, link the seven categories to risks, tests, changes, suppliers, complaints, CAPA, and vulnerability response. Confirm that evidence and approvals are complete, failed tests have documented dispositions, and CAPA effectiveness checks are recorded. Check that record revisions and device versions are correct.

Log each unresolved finding with its owner, risk rating, interim control, and target date. A remediation ticket is not proof. Keep evidence of both implementation and verification. Auditors will check that closure can be traced to those records.

For the final review, map every record to QMSR and retain legacy QSR evidence that still supports current compliance.^[2][3]

FAQs

How can I identify gaps in legacy QSR records?

Check that version details match across current risk reports, SBOMs, and test evidence ^[1]. Follow one threat from its model through mitigation, testing, and results to the final residual-risk or labeling statement. Any break in that chain points to a documentation gap ^[1].

Audit your Design History File (DHF) regularly to verify that SBOMs and threat models match the actual software configuration. Outdated records are a frequent cause of FDA observations ^[2].

When does a cybersecurity issue require CAPA?

A cybersecurity issue requires a Corrective and Preventive Action (CAPA) record when a systemic risk or nonconformance calls for root-cause analysis and a documented fix. This includes systemic complaints, supplier failures, and findings from vulnerability assessments or penetration tests that need remediation ^[1][2][3].

Under QMSR and ISO 13485, route third-party cybersecurity findings to CAPA - not IT tickets. Each record should document the CVSS score, clinical impact, owner, and closure evidence ^[1].

How should I audit unsupported medical devices?

Record the decision in your risk management files. For each unsupported or abandoned component, include a formal risk assessment that explains why it can’t be updated, which compensating controls you’ve put in place to reduce hazards, and how you’ll monitor it without vendor patches.

If the end-of-support date is unclear, document your review of the project’s commit history or community activity. This gives the FDA a record of your due diligence.

Related Blog Posts

• Checklist for Pre-Market Medical Device Cybersecurity
• FDA IoT Cybersecurity: 2026 Updates Explained
• Medical Device Cybersecurity: Required Risk Assessment Docs
• Checklist for Post-Market Cybersecurity Transparency