ISO 14971:2019 Audit-Readiness Rubric — Risk Management for Medical Devices
What this is: Medical devices — Application of risk management to medical devices. ISO 13485 (see iso13485-rubric.md, §7.1/§7.3.9/§8.2.1) references this standard as the risk-management engine threaded through design, production, and post-market feedback, but ISO 14971 is itself a standalone, independently certifiable/auditable body of requirements with its own clause structure, its own file (the Risk Management File, distinct from the Medical Device File and Design History File), and its own compliance status under EU MDR and FDA review. This rubric scores the risk-management process on its own terms — deeper than the one-paragraph cross-reference the ISO 13485 rubric gives it (its own §127/gap 5 explicitly flags ISO 14971 as warranting a standalone rubric; this is that follow-up).
Companion document: ISO/TR 24971:2020 ("Guidance on the application of ISO 14971") is a non-normative technical report that mirrors ISO 14971:2019's clause/sub-clause numbering exactly and gives worked explanations, examples, and interpretation guidance for each clause — it's the practitioner's companion to the normative standard, comparable in role to how FDA guidance documents interpret a CFR requirement. Referenced below wherever it adds interpretive detail beyond the base standard's structure.
Sourcing note: ISO 14971's and ISO/TR 24971's full clause text are copyrighted and sold by ISO (iso.org's own preview pages returned HTTP 403 to automated fetch this session, consistent with the ISO 13485 rubric's experience). No verbatim clause text is used below — this is structure and paraphrase built from secondary sources: Greenlight Guru, SimplerQMS, TS Quality & Engineering, Oriel STAT A MATRIX/ELIQUENT Life Sciences, Key to Compliance, and AchieveXL — cross-checked across multiple independent sources for clause numbering and the six/seven-step process description. Two of these sources (Greenlight Guru's dedicated "risk management file" article, and a guessed FDA-consensus-standards URL) returned HTTP 404 and were not used. Where only one or two sources confirmed a specific point, that's noted inline. This session's web-search tool quota was exhausted before this document was drafted (hit mid-research, budget shared across the whole session) — all research after that point used direct-fetch (WebFetch) against URLs already surfaced by the earlier searches, not fresh searches. This means some threads that a fresh search likely would have resolved (see Gaps section) were left open rather than chased further.
Rubric legend
Each row: Requirement (plain language) → Citation → Evidence that demonstrates compliance → Common failure pattern
Failure patterns are drawn from consultancy write-ups (Greenlight Guru, AchieveXL) describing patterns observed across risk-management audits — not a named, quantified Notified Body or FDA deficiency database, the same sourcing gap flagged in the ISO 13485 rubric. One specific, well-corroborated qualitative claim recurs across sources and is used repeatedly below: risk management files are commonly built rigorously pre-launch and then go static, failing to absorb post-market signals — one source states plainly that "very few companies have figured out how to ensure [the] RMF is living after product development."
Clause 1–3 (not auditable — reference only)
Clause 1 Scope, Clause 2 Normative References, Clause 3 Terms and Definitions. The 2019 edition (third edition) restructured from 9 clauses in the 2007 edition to 10 clauses, adding three informative annexes: Annex A (rationale for requirements), Annex B (risk management process flow diagram / correspondence to the prior edition), and Annex C (fundamental risk concepts — hazard/hazardous-situation/harm relationships). Clause 3 introduced several new or sharpened definitions worth flagging because they change what "compliant" documentation must show: benefit (positive impact/desirable outcome on an individual's health, extended in practice to public-health benefit), reasonably foreseeable misuse (use not intended by the manufacturer but resulting from readily predictable human behavior, covering both intentional and unintentional misuse by lay and professional users), and state of the art (developed state of technical capability at a given time — current accepted good practice, not necessarily the most advanced solution available). Clauses 4–10 are the auditable requirements.
Clause 4 — General requirements for risk management system
| # | Requirement (plain language) | Citation | Evidence of compliance | Common failure pattern |
|---|---|---|---|---|
| 1 | A risk management process must be established, documented, and maintained across the entire device lifecycle, with top management providing evidence of commitment and ensuring adequate resources and competent personnel are assigned. | ISO 14971:2019, §4.1–4.3 | Risk management procedure/SOP; management commitment records (resourcing, sign-off); personnel competency records for risk-management roles (education/training/experience relevant to the device type and risk methodology used) | Risk management treated as a document-production exercise owned solely by a regulatory-affairs or quality function, with no visible engineering/clinical/management involvement or resourcing decision behind it |
| 2 | A device-specific (or device-family-specific) risk management plan must be established, covering: scope of activities across the full lifecycle; assignment of responsibilities and authorities; requirements for review of risk management activities; criteria for risk acceptability including a defined method for evaluating overall residual risk and (new in 2019) explicit criteria for acceptability of overall risk; verification activities; and activities for collecting/reviewing production and post-production information. | ISO 14971:2019, §4.4 | Approved, version-controlled risk management plan naming all mandated elements, established at/near project start and kept current | Plan drafted once at project kickoff, listing only risk-acceptability criteria for individual risks and omitting the (2019-new) overall-residual-risk acceptability criteria and the post-production information-collection commitment |
| 3 | A risk management file (RMF) must be established and maintained, referencing or containing records for every risk management activity performed, for each device or device family, and must provide traceability for each identified hazard through risk analysis, risk evaluation, implementation/verification of risk control measures, and evaluation of residual risk. | ISO 14971:2019, §4.5 | Risk management file (or index/master record referencing constituent records) per device/device family, with a traceability matrix or equivalent linking each hazard to its analysis, evaluation, control, and residual-risk-evaluation records | RMF exists as a static binder assembled once for initial certification/clearance rather than a living, indexed, continuously-updated record; traceability breaks between a hazard identified early and the eventual control/verification evidence, especially after design changes |
Clause 5 — Risk analysis
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 4 | Intended use and reasonably foreseeable misuse must be documented, including characteristics relevant to safety (per Annex C-style hazard/harm reasoning) — covering both correct-use and foreseeably-incorrect-use scenarios by both lay and professional users. | ISO 14971:2019, §5.1–5.3 | Intended-use statement and foreseeable-misuse analysis, explicitly distinguishing lay-user vs. professional-user contexts where applicable | Foreseeable-misuse analysis limited to "user error" in the abstract rather than concrete, evidence-based misuse scenarios (e.g. drawn from similar-device complaint history or usability studies) |
| 5 | Hazards and hazardous situations must be systematically identified — both known and foreseeable, across normal use, fault conditions, and reasonably foreseeable misuse — using a documented, repeatable method (e.g. a standards-based hazard table, preliminary hazard analysis, or equivalent). | ISO 14971:2019, §5.4 | Hazard identification records (hazard tables, PHA) covering normal/fault/misuse conditions, referencing a defined identification methodology | Hazard identification limited to the device's own historical hazard list, not extended to newly foreseeable hazards from indication/design changes, connectivity, or software additions |
| 6 | For each identified hazardous situation, risk must be estimated using severity and probability of occurrence of harm, per a documented, consistently-applied estimation methodology; where probability of occurrence of harm cannot be estimated, the plan's methodology for handling that case (per §4.4) must be applied and documented. | ISO 14971:2019, §5.5 | Risk estimation records (e.g. risk matrices, FMEA probability/severity scoring) applying a consistent, pre-defined scale; documented rationale where probability could not be estimated | Severity/probability scoring applied inconsistently across hazards or across product lines, undermining comparability of risk-acceptability decisions; FMEA/FTA records treated as the risk analysis itself rather than feeding a distinct risk-estimation step — a distinction ISO/TR 24971 draws explicitly (FMEA/FTA are failure-analysis tools that inform, but are not equivalent to, the hazard/harm-based risk analysis ISO 14971 requires) |
Clause 6 — Risk evaluation
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 7 | Each estimated risk must be evaluated against the pre-defined acceptability criteria from the risk management plan to determine whether risk reduction is required. | ISO 14971:2019, §6 | Risk evaluation records showing each risk scored and explicitly compared against the plan's acceptability criteria, with an accept/reduce decision recorded | Acceptability criteria applied retroactively/inconsistently to justify a device that's already been designed, rather than driving design decisions prospectively |
Clause 7 — Risk control
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 8 | Risk control options must be identified and selected in the mandated priority order: inherently safe design and manufacture first, then protective measures (in the device itself or the manufacturing process), then information for safety (labeling/warnings/training) last and only as a supplement, not a substitute, for the first two. | ISO 14971:2019, §7.1 | Risk control option analysis explicitly documenting why higher-priority options (design, protective measures) were or weren't feasible before falling back to labeling/warnings | Labeling/warnings used as the primary or sole control for a risk that a design change could have addressed — a pattern regulators and Notified Bodies specifically scrutinize because it shifts risk-management burden onto the user |
| 9 | Selected risk control measures must be implemented and their implementation verified, and their effectiveness verified (i.e., confirming the measure actually achieves the intended risk reduction, not just that it was built). | ISO 14971:2019, §7.2 | Implementation records (design/process change records) plus separate verification records confirming both "was it built" and "does it work as intended" | Verification records confirming the control measure was implemented (e.g. a design change shipped) without separate evidence the measure actually reduces the risk as estimated |
| 10 | Residual risk after each control measure must be evaluated using the same criteria as the original risk evaluation; where residual risk isn't acceptable, further control options must be considered, iterating until acceptable or until further control isn't practicable — at which point a benefit-risk analysis is required. | ISO 14971:2019, §7.3–7.4 | Residual-risk evaluation records per control measure; benefit-risk analysis records (clinical/functional benefit vs. residual risk) wherever residual risk remains above the acceptability threshold | Benefit-risk analysis skipped or treated as a formality when residual risk is above threshold, rather than a substantive, evidence-based justification |
| 11 | Risk control measures must themselves be evaluated for new risks they might introduce (a control measure that solves one hazard but creates another), and the overall completeness of risk control implementation across all identified risks must be confirmed. | ISO 14971:2019, §7.5–7.6 | Records showing each control measure assessed for newly-introduced risk; a completeness check/sign-off confirming no identified risk was left without a documented control decision | New risks introduced by a control measure (e.g. a software mitigation that adds a new failure mode) not looped back into the hazard identification/risk analysis records as a new entry |
Clause 8 — Evaluation of overall residual risk
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 12 | The cumulative residual risk of the device as a whole (not just risk-by-risk) must be evaluated against the plan's overall-residual-risk acceptability criteria; where the cumulative residual risk isn't acceptable, an overall benefit-risk analysis must be performed and, if the device is to proceed, information necessary to disclose that residual risk (e.g. to users/clinicians) must be identified. | ISO 14971:2019, §8 | Overall residual risk evaluation record distinct from the per-risk residual evaluations in Clause 7; overall benefit-risk analysis and disclosure-information records where applicable | Overall residual risk evaluation omitted entirely — manufacturers commonly do the per-hazard residual risk evaluation (Clause 7) but skip the separate cumulative, whole-device evaluation this clause specifically requires; this is one of the more consultancy-cited gaps introduced by the 2019 restructuring, since the 2007 edition didn't isolate this as its own clause |
Clause 9 — Risk management review
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 13 | Before commercial release, a risk management review must confirm the risk management plan has been appropriately implemented, overall residual risk is acceptable, and appropriate methods are in place to collect and review production/post-production information — reviewed and signed off by someone with the appropriate authority. | ISO 14971:2019, §9 | Risk management review record with a named authority sign-off, explicitly confirming plan execution, overall residual risk acceptability, and the post-production information system's readiness | Review conducted as a checkbox exercise referencing the plan generically, without evidencing that the specific mandated post-production collection mechanisms (Clause 10) are actually operational at launch, not just planned |
Clause 10 — Production and post-production activities (the post-market feedback loop)
| # | Requirement | Citation | Evidence | Common failure pattern |
|---|---|---|---|---|
| 14 | A system must be established for actively and systematically collecting production and post-production information relevant to the device — sources include production/process data, user/customer feedback, service/installation/maintenance personnel, supply-chain sources, complaints, adverse-event/vigilance reports, publicly available information (literature, competitor/similar-device incident data), and state-of-the-art developments. | ISO 14971:2019, §10.1–10.2 | Documented post-production information collection procedure naming each mandated source category; evidence the sources are actually monitored (e.g. literature-search records, complaint-database extracts, service-report logs), not just named in a procedure | Procedure names the mandated sources on paper, but only complaints/vigilance data is actually and routinely reviewed — literature/state-of-the-art monitoring and service/installation feedback are the categories most often only nominally covered |
| 15 | Collected information must be reviewed for relevance to risk management — specifically: previously unrecognized hazards or hazardous situations; whether an estimated risk is no longer acceptable; whether the overall benefit-risk conclusion still holds; and whether the state of the art has advanced such that a previously-acceptable control is no longer adequate. Where review identifies an issue, it must feed back into a re-evaluation of the risk management file (potentially reopening risk analysis, evaluation, or control), and corrective action considered — at both the device-specific level (e.g. reassessment, control changes, field action/recall) and process/systemic level (e.g. procedure updates, broader management review) — a bifurcation ISO 14971:2019 made explicit that the 2007 edition did not draw as sharply. | ISO 14971:2019, §10.2–10.3 | Post-production information review records explicitly evaluating each of the four review questions above; RMF update records showing re-opened hazard/risk entries where review triggered them; CAPA or field-action records cross-referenced to the specific RMF entry they affect | This is the single most commonly cited weak point in risk management systems across sources used for this rubric. The RMF is built rigorously pre-launch, then treated as closed once the device ships — post-market signals (complaints, vigilance data, literature) are handled through the complaint-handling/CAPA process in isolation, without a documented loop back into the risk management file itself. One source states plainly that "very few companies have figured out how to ensure [the] RMF is living after product development." |
The Risk Management File — what it must contain, and how it differs from the Medical Device File and Design History File
ISO 14971:2019 §4.5 defines the Risk Management File (RMF) as containing or referencing, per device or device family, records demonstrating: risk analysis; risk evaluation; risk control implementation and verification; residual risk evaluation (per-risk and overall); benefit-risk analysis where triggered; the risk management report; and post-production information review outcomes — with traceability as the unifying requirement (§4.5 explicitly requires each identified hazard be traceable through analysis → evaluation → control implementation/verification → residual-risk result). One consultancy source (AchieveXL) frames this as a four-level documentation stack worth using as a mental model even though it isn't itself an ISO 14971 clause structure:
- Foundational reference records — standard hazard tables, preliminary hazard analysis, standard harms tables (reusable across a device portfolio, not device-specific).
- Failure-analysis records — design/process/software/use-error FMEA, fault tree analysis — these analyze potential failures, which is a narrower and different thing from ISO 14971's hazard/harm-based risk analysis; FMEA/FTA feed the risk analysis, they aren't a substitute for it.
- Risk assessment records — design/process/software/use-error risk assessments that compile the failure-analysis data into actual hazard-harm risk estimates, including residual risk.
- Risk trace matrix — the single cumulative record tying every risk to its hazard, control, verification, and residual-risk outcome; this is functionally what §4.5's traceability requirement is asking for, whether or not a manufacturer literally calls it that.
Relationship to the ISO 13485 Medical Device File (§4.2.3) and Design History File (§7.3.10) — flagged as reasoned synthesis rather than a directly-sourced comparison: no source fetched this session explicitly contrasted these three files side by side, so the following is built by cross-referencing the ISO 13485 rubric's own clause descriptions against ISO 14971's §4.5 definition, not lifted from a secondary source that already did this comparison.
| File | Owning standard | Scope | Primary content | Relationship to the RMF |
|---|---|---|---|---|
| Risk Management File (RMF) | ISO 14971 §4.5 | Per device/device family | Risk management plan execution record: hazards, risk analysis/evaluation/control/verification, residual risk, benefit-risk analysis, risk management report, post-production review outcomes | The source-of-truth for risk; the other two files reference into it rather than duplicating it |
| Design History File (DHF) | ISO 13485 §7.3.10 | Per device type/family | Design-control traceability: design inputs → outputs → reviews → verification → validation → transfer → change control | Overlaps with the RMF specifically where a design input/output is a risk control measure (e.g. a design verification test that is simultaneously the risk-control-verification evidence for a specific hazard) — the same underlying test/record can and typically should be cross-referenced from both files rather than duplicated, but the DHF's organizing principle is input/output traceability, while the RMF's is hazard/risk traceability |
| Medical Device File (MDF) | ISO 13485 §4.2.3 | Per device type/family | Running operational record: device description/intended use, specifications, manufacturing/packaging procedures, measuring/monitoring procedures, installation/servicing requirements | Narrower operational focus (how the device is made and maintained) rather than why it's safe; the MDF's device-description and intended-use content should be consistent with, and is a natural cross-reference point for, the RMF's §5.1 intended-use/foreseeable-misuse documentation, but the MDF does not itself carry risk-evaluation content |
Practical implication: none of these three files should be built or scored as fully independent silos — a gap-analysis tool should specifically check that the RMF's intended-use statement matches the MDF's, that design verification records cited as risk-control verification in the RMF are the same records (not just similarly-named ones) as those in the DHF, and that a design change logged in the DHF's change-control record (ISO 13485 §7.3.9, which itself mandates assessing effect on risk management) has a corresponding RMF update — this cross-file consistency check is exactly the kind of gap an AI document-analysis tool is well suited to catch that a manual audit sampling a single file might miss.
Relationship to ISO 13485 and EU MDR/FDA — confirmed status
- ISO 13485 relationship: ISO 14971 is not a sub-requirement of ISO 13485 in the sense of being optional without it — ISO 13485 §7.1 requires "a" risk management process be documented throughout product realization but does not itself specify the process's content; ISO 14971 is the universally-adopted standard manufacturers point to when satisfying that requirement, and ISO 13485's own post-2016 restructuring (particularly its §8.2.1 production/post-production feedback clause) was explicitly aligned to mirror ISO 14971:2019's Clause 10 requirements (confirmed, multiple sources). ISO 14971 is therefore best understood as a parallel, independently-scoped standard that ISO 13485 leans on, not a subordinate appendix to it — which is exactly why this rubric treats it as standalone rather than folding it into the ISO 13485 rubric's Clause 7 row.
- EU MDR: ISO 14971:2019 (as EN ISO 14971:2019, later amended by A11:2021) is the harmonized standard cited for demonstrating conformity with EU MDR's General Safety and Performance Requirements (GSPRs) on risk management. Multiple sources confirm EU MDR imposes a stricter risk-reduction standard than the ISO base text alone: MDR requires manufacturers to reduce risks "as far as possible" without the cost/practicability trade-off language that a pure ISO 14971 reading might otherwise allow — meaning EU-market compliance is not simply "follow ISO 14971," it's "follow ISO 14971 as interpreted through MDR's stricter GSPR risk-reduction language," typically implemented via the EN-harmonized version's Annex ZA-style deviations. Flagged for follow-up: this session did not directly fetch the Annex ZA/A11:2021 deviation text itself (only secondary characterizations of it converging on the same "as far as possible" point) — worth a direct-source pass before this is used as a customer-facing compliance claim, same caveat pattern as the ISO 13485 rubric's FDA QMSR section.
- FDA: ISO 14971 is recognized by FDA as a consensus standard applicable to device risk-management documentation supporting 510(k)/PMA submissions, and is referenced in FDA's own guidance and expectations under 21 CFR 820 (now QMSR, per the ISO 13485 rubric's findings). Not independently re-verified against a direct fda.gov consensus-standards-database page this session (a guessed URL for this returned HTTP 404, and the search-tool quota was exhausted before a corrected URL could be found) — flagged as a gap, same caveat strength as the ISO 13485 rubric's FDA-snippet-only sourcing.
- Net for Regscribe's positioning: ISO 14971 compliance is effectively mandatory for EU MDR conformity assessment (via the harmonized-standard route) and is expected, though not itself a discrete regulatory submission requirement, for FDA submissions — a customer cannot treat "we have ISO 13485 certification" as proof of adequate risk management; the RMF is scored/reviewed as its own artifact by Notified Bodies and FDA reviewers.
Documents/evidence needed for an ISO 14971 risk-management audit
Clause 4: risk management procedure/SOP; management commitment and resourcing records; personnel competency records for risk-management roles; risk management plan (scope, responsibilities, review requirements, acceptability criteria incl. overall-residual-risk criteria, verification activities, post-production information plan); risk management file (or index referencing constituent records) per device/device family with a traceability matrix.
Clause 5: intended-use and reasonably-foreseeable-misuse documentation; hazard/hazardous-situation identification records (hazard tables, PHA); risk estimation records (risk matrices; FMEA/FTA as supporting failure-analysis input, not a substitute for the risk analysis itself).
Clause 6: risk evaluation records showing each risk compared against the plan's acceptability criteria.
Clause 7: risk control option analysis (showing the inherent-safety → protective-measure → information-for-safety priority order was actually applied, not just labeling used by default); implementation records; risk control verification records (both "was it built" and "does it work"); residual risk evaluation per control measure; benefit-risk analysis records where residual risk exceeds threshold; new-risk-from-control-measure assessments; completeness/sign-off confirming every identified risk has a documented control decision.
Clause 8: overall (cumulative, whole-device) residual risk evaluation record, distinct from per-risk residual evaluations; overall benefit-risk analysis and risk-disclosure-information records where applicable.
Clause 9: risk management report — the authority-signed record confirming plan execution, overall residual risk acceptability, and operational readiness of the post-production information system, produced before commercial release.
Clause 10: post-production information collection procedure and evidence of active monitoring across all mandated source categories (production data, complaints, vigilance/adverse-event reports, service/installation feedback, literature/state-of-the-art, supply-chain input); PMS-to-risk-file feedback records — review records explicitly evaluating new-hazard/no-longer-acceptable-risk/benefit-risk-still-holds/state-of-the-art-advanced questions, with RMF re-opening/update records and CAPA/field-action records cross-referenced to the specific RMF entry affected.
Cross-file: consistency checks between the RMF's intended-use statement and the ISO 13485 Medical Device File's device description; consistency checks between DHF verification/validation records cited as risk-control verification and the actual RMF entries they support; RMF update evidence tied to each ISO 13485 §7.3.9 design-change risk-impact assessment.
Common failure patterns (cross-clause summary)
Same sourcing caveat as the ISO 13485 rubric: no named, quantified Notified Body or FDA deficiency database specific to ISO 14971 risk-management findings was located this session (and the search-tool quota was exhausted before a targeted follow-up search for one — e.g. against FDA's Form 483/Warning Letter database filtered to risk-management citations — could be run). The patterns below are qualitative, drawn from convergent consultancy sourcing (Greenlight Guru, AchieveXL):
- The RMF goes static after launch (Clause 10) — by far the most consistently and strongly stated pattern across sources. Rigorous pre-launch risk analysis/control/verification work is not matched by an equally rigorous, operational post-production information review loop; complaints and vigilance data get handled through complaint-handling/CAPA in isolation from the RMF rather than looping back into it. This is the same underlying gap the ISO 13485 rubric's §8.2.1 row and its own failure-pattern #3 already flag from the ISO 13485 side — this rubric's Clause 10 treatment goes deeper into why it happens (informal feedback channels like service/literature monitoring are the categories most often only nominally covered) rather than repeating the ISO 13485 rubric's one-line version of the same finding.
- Overall residual risk evaluation (Clause 8) skipped or conflated with per-risk residual evaluation (Clause 7) — a 2019-restructuring-specific gap: manufacturers whose risk process predates the 2019 edition, or who adapted a 2007-edition-era template, commonly do the per-hazard residual risk step but never perform the separate, cumulative, whole-device evaluation the current edition isolates as its own clause.
- Labeling/warnings used as a first-resort control rather than last-resort (Clause 7.1) — the mandated inherent-safety → protective-measure → information priority order is not evidenced; a risk gets a labeling-only control without a documented rationale for why design or protective measures weren't feasible.
- FMEA/FTA treated as equivalent to the ISO 14971 risk analysis rather than as a supporting failure-analysis input to it — a structural/terminology confusion ISO/TR 24971's aligned-numbering guidance is specifically meant to help manufacturers avoid, per the AchieveXL four-level framing above.
- Traceability breaks after design changes — a hazard identified and controlled at initial development doesn't get re-traced through the RMF when the design, manufacturing process, or intended use later changes, echoing the identical pattern the ISO 13485 rubric found for its own §7.1/§7.3.9 rows (this rubric's version is more granular: it's specifically the hazard→analysis→control→verification→residual-risk chain in the RMF that breaks, not just "the risk file wasn't updated" generically).
Gaps / follow-ups
- iso.org OBP/standard pages returned HTTP 403 to automated fetch for both ISO 14971 and ISO/TR 24971 — clause numbering above is cross-checked across 5+ independent secondary sources but never verified against ISO's own (even preview-level) page directly, same caveat as the ISO 13485 rubric.
- This session's WebSearch quota was exhausted mid-research (200/200 used session-wide, not specific to this task) — all research after that point relied on WebFetch against URLs already in hand. Two follow-up searches that would likely have closed real gaps and were not run: (a) a targeted search for the EN ISO 14971:2019/A11:2021 Annex ZA deviation text itself (currently only characterized via secondary sources' "reduce risk as far as possible" framing, not read directly); (b) a targeted search of FDA's Form 483/Warning Letter database filtered to risk-management/ISO 14971 citations, to see whether a named, quantified deficiency pattern exists the way MHRA's GMP/GDP data does for the sibling rubric.
- RMF vs. Design History File vs. Medical Device File comparison (the dedicated section above) is reasoned synthesis, not a directly-sourced comparison — no fetched source explicitly contrasted the three files; it was built by cross-referencing this rubric's ISO 14971 §4.5 findings against the ISO 13485 rubric's own §4.2.3/§7.3.10 descriptions. Worth a follow-up direct-source pass (e.g. a consultancy article specifically titled around "RMF vs DHF") before treating the comparison table as anything more than a reasonable, internally-consistent inference.
- FDA consensus-standard recognition status for ISO 14971 was not independently re-verified against a direct fda.gov page this session (a guessed URL 404'd, and the search quota was gone before a corrected query could be run) — same sourcing-strength caveat as the ISO 13485 rubric's FDA QMSR section; treat as reasonable industry-standard fact pending a direct-source check.
- IEC 62304 / IEC 62366 (usability engineering) overlap — ISO 14971's use-error and reasonably-foreseeable-misuse content interacts closely with IEC 62366-1's usability engineering process and with IEC 62304's software risk management for SaMD, both directly relevant to Regscribe's own software/SaMD-adjacent customer base; not researched this session, flagged as a candidate follow-up rubric or cross-reference, same pattern as the ISO 13485 rubric's IEC 62304 gap note.
- Cybersecurity risk annex — one source noted ISO 14971:2019 carries an informative cybersecurity-aware annex (referred to as "Annex F" in that source) addressing internet-connected device vulnerabilities; this wasn't independently corroborated by a second source this session and isn't reflected as its own scored row above — flagged rather than asserted as confirmed structure.
Suggested integration note (not implemented — flagging for a decision, not doing it unasked)
Same pattern as the ISO 13485 rubric: this document is not wired into lib/rubrics.ts (the RUBRICS registry currently lists part11 and gmp-gdp; iso13485-rubric.md and iso27001-checklist.md are also reference-only docs not yet wired in). If ISO 14971 is meant to become a selectable rubric in the product, the follow-up is: add an iso14971 entry to RUBRICS in /Users/khando/Khando/Dev/Projects/regscribe/lib/rubrics.ts pointing at iso14971-rubric.md, plus whatever test coverage lib/__tests__/rubrics.test.ts expects for a new rubric ID. Flagging rather than doing it, since it touches app code/tests and wasn't asked for.