ISO 14971 Risk Files: Evidence and Review

A risk management file should let a reviewer reconstruct why a particular device configuration was considered acceptable, which evidence supported that decision, and what new information would change it. A spreadsheet of scored hazards needs links to evidence and decisions to answer those questions.

Research reviewed: September 18, 2026. This report addresses medical-device manufacturers preparing or maintaining EU and US evidence. The worked examples are hypothetical engineering reviews, not findings about a customer's device. Product-specific requirements and an organization's controlled procedures still determine the actual work.

TL;DR

• Acceptance criteria need a rationale. ISO 14971:2019 describes a lifecycle process and requires objective risk-acceptability criteria; the acceptable levels and the chosen presentation require a device-specific rationale. Establish the criteria before applying scores. ISO/TR 24971:2020 provides application guidance rather than an additional certification requirement. ^{1 2}
• Recall counts identify review questions, not a device's failure probability. Our pinned export contains 58,785 distinct FDA product recall numbers. Device Design accounts for 7,621 and Process control for 6,494. Another 16,709 records fall into broad, unresolved or missing categories. Use that distribution to challenge evidence coverage, not to rank products or claim that a risk file prevents a measured percentage of recalls. Pure Global — Reproducible recall aggregates, methods and scoped pricing extract for this report
• The release decision needs connected evidence. For each important harm scenario, connect the relevant configuration, control, verification result, residual-risk rationale and post-market review trigger. Distinguish statutory requirements from standards and guidance, and distinguish professional review fees from the cost of creating missing engineering evidence.

What did we actually count in the recall export?

The analysis began with the shared data catalog and a pinned FDA medical-device recall export dated August 24, 2026. We counted every row, checked the uniqueness of product_res_number, and grouped the exact text in root_cause_description. There are 58,785 rows and 58,785 unique product recall numbers, with 44 categories including an empty value. The calculation supplement preserves the input checksum, category counts, date-quality checks and grouping definitions. The denominator is the entire exported snapshot, not devices sold, patients treated, inspections conducted or manufacturers operating. Pure Global — Reproducible recall aggregates, methods and scoped pricing extract for this report

This distinction is material. A single corrective action can cover several catalog products and generate several product recall numbers. Conversely, a recall record can describe a large quantity of affected units. Without a defensible event linkage and an exposure denominator, dividing records by records produces a share of records. Estimating the chance of harm requires additional evidence about exposure and outcomes. We retained product recall numbers as the unit throughout the analysis and kept event frequency, patient exposure and comparative product safety outside its scope.

The relevant openFDA resource is the device recall dataset, not a generic adverse-event collection or an undifferentiated enforcement feed. Its documentation identifies the FDA medical-device recall database as the source and explains that data may be corrected. FDA's published ingestion code maps root_cause_description from the database's FDA-determined-cause field. Some category labels contain the words “by firm,” but describing the entire column as a set of manufacturer-assigned root causes would misstate its provenance. ^{3 4}

The prominent categories include Device Design, 7,621 records or 13.0%; Process control, 6,494 or 11.0%; Nonconforming Material/Component, 5,863 or 10.0%; and Software design, 3,449 or 5.9%. These are labels at the recall-record level. The export leaves the pre-release risk-management method, completeness of testing and effect of alternative designs unresolved. Such questions require the individual record, subsequent communications and product-specific evidence.

A second calculation changes the interpretation of the first. Other contributes 8,928 records; Under Investigation by firm contributes 6,777; Unknown/Undetermined by firm contributes 647; Pending contributes 344; and 13 records are blank. Together those categories contain 16,709 records, or 28.4% of the export. This is an analyst-defined group of nonspecific, unresolved or absent labels. “Other” can include completed investigations whose specific causal mechanism remains unavailable in this coded field.

The useful management decision is therefore narrow: reserve review effort for the design-to-production transition, incoming material assumptions, software behavior and evidence that controls remain effective. Manufacturers of a simple sterile consumable and a connected infusion device need separate, product-specific testing priorities. Their hazards, users, exposure patterns and applicable evidence differ.

How much does the taxonomy change the apparent priority?

Category grouping can create an apparently precise finding that depends on an unstated choice. Consider packaging. Adding only Packaging and Packaging process control gives 3,117 records, or 5.3% of the export. Adding Package design/selection and Packaging change control produces 4,268, or 7.3%. Both sums are reproducible; they answer different questions. Neither is a direct count of sterile-barrier failures. A packaging-related recall could concern identification, protection or another function. Pure Global — Reproducible recall aggregates, methods and scoped pricing extract for this report

The difference is 1,151 records. It is large enough to make a “top risk” ranking look different, yet nothing about the underlying devices changed. The analyst changed the basket. The supplement therefore retains the complete original labels, allowing readers to inspect the categories behind any proposed grouping. A quality lead can select a narrower product population and read its actual notices, but should document that selection before interpreting the outcome.

The same problem appears in software. Software design is a distinct label from Software change control, Software Design Change, Software Manufacturing/Software Deployment, Software in the Use Environment, and Software design (manufacturing process). Combining them may be useful for a software-governance question. Label it explicitly as an analyst-defined group and publish its component categories. Keeping the original field and a separate analyst group allows another reviewer to reproduce or challenge the grouping without losing provenance.

Date quality also matters. A plausibility check flags 21 initiation dates outside the chosen 1976–2026 bounds, including a value with year 0010. We retain such records in the all-record category denominator, disclose the date issue and avoid deriving a historical trend from unreviewed dates. Excluding a suspicious date from a trend would require a stated rule; rewriting it to a guessed year would create unsupported data. This report makes no claim that the observed proportions rose or fell over a specified period.

For an internal review, turn each relevant record into a question with an answer location. If a comparable device had a material problem, the useful question is which material attribute matters for the intended function and how the current product demonstrates control of that attribute. A supplier certificate may answer an identity question while leaving a performance question unresolved. If a comparable product had a software update problem, ask which versions, interfaces and installation states are covered by the current regression evidence.

A recall search can also return counterevidence to a team's preferred story. A design-focused group may discover that a production change invalidated its assumptions. A manufacturing-focused group may discover that an unchanged process consistently produces a design with inadequate margins. Neither discovery proves that the company has the same problem. It identifies a plausible challenge that should be accepted, rejected or investigated with product evidence. Record that disposition instead of copying competitors' recall narratives into a hazard table as if they were verified events for your own device.

Which requirements control an EU or US risk file?

Start with a short applicability record. Identify the product, intended purpose, markets, classification, lifecycle stage and submission or conformity-assessment route. Then identify each relevant legal requirement, standard edition, guidance and product-specific evidence expectation. The important distinction is between an obligation and one possible method of satisfying it. Verify the edition and jurisdictional status even when a standard's title is familiar. ¹

For the EU, MDR Annex I requires a documented, iterative risk-management system and an ordered approach to risk controls. Annex II addresses technical documentation, including benefit-risk analysis and risk management. Annex III addresses post-market surveillance documentation. These connections mean that changing the clinical claims, production process or available safety information may affect more than one document. The organization still needs to choose a usable layout for those connections. ⁵

The European Commission explains that using harmonised standards is voluntary and that a cited standard supports presumption of conformity within its relevant coverage. A team should record the applicable European edition, amendment and Official Journal status, together with any limits, rather than assuming that the international title alone resolves every MDR requirement. A standards matrix is useful only if it records what the evidence actually covers. A copied list of standards with no applicability reasoning is difficult to maintain when the product changes. ⁶

In the United States, QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference, with additional FDA requirements. ISO 14971 has a separate standards-recognition role. FDA inspection requirements continue to apply to manufacturers holding an ISO 13485 certificate. Separately, FDA's recognized-standards database lists ISO 14971 Third Edition 2019-12 under recognition number 5-125, with complete recognition and a specific cybersecurity qualification in its explanatory text. ^{7 8}

The practical output is a controlled requirements map with a reason for every inclusion. Suppose a company has one product family sold in both markets. It can maintain a common engineering risk analysis while linking market-specific evidence and decisions. That avoids two independently edited hazard inventories drifting apart. The EU declaration, US submission and internal release review retain their distinct purposes.

Assign ownership of that map. Regulatory affairs can identify the applicable route and documentary expectations; engineering can explain which configuration and tests support the technical claims; quality can connect production and change controls; clinical expertise can assess the relevance of the harms and benefits. One coordinator should reconcile disagreements into an approved decision record. Record the specific conclusion from each function: testing of the relevant software configuration, for example, or assessment of the applicable market obligations.

What should the file let another person reconstruct?

Think of the file as an index to controlled evidence, with enough explanation to follow a decision. It can reference records held in several systems if those records remain identifiable, accessible and under appropriate control. The following organization is a recommended working structure, not a claim that ISO requires these exact folder names. It implements the lifecycle purpose described by ISO 14971 and uses ISO/TR 24971 as guidance for application. ^{1 2}

First, establish the assessed configuration. Include the product or family boundary, intended users and use environments, accessories, important software versions, manufacturing assumptions and supported combinations. Explain why variants belong together. If a family shares an analysis but differs in patient contact, energy delivery, materials or operator interaction, identify which assumptions and evidence need separate treatment. The file should make it possible to tell whether a newly proposed variant is inside the assessed boundary.

Second, identify the plan and decision rules. Name responsibilities, review points, acceptance criteria, verification approach and the method for collecting production and post-production information. Explain how the team will handle uncertainty and conflicting evidence. A plan that simply says “all risks will be reduced to green” leaves the reviewer without a reason to trust the colors. The criteria should make sense for the intended purpose and the nature of the harm, rather than appearing only after test results are known.

Third, record harm scenarios and control decisions. Preserve the connection between a source of potential harm, a foreseeable sequence of events, a hazardous situation and the resulting harm. A failure mode can contribute to that chain without being identical to the harm. For example, an incomplete package seal is a failure condition; exposure of a vulnerable patient to microorganisms during use is a different part of the scenario; infection is a possible harm. Keeping the distinctions clear helps identify which control addresses which step.

Fourth, link each selected control to its implementation evidence and effectiveness evidence. A drawing revision can show that a connector was redesigned. Demonstrating prevention of the intended misconnections requires evidence of performance under relevant conditions. A test report may support effectiveness, but only for its tested samples, configurations, conditions and acceptance criteria. Include those boundaries in the linkage so a later reader can assess applicability without searching through unrelated attachments.

Fifth, preserve the residual-risk and overall decision. Explain why remaining risks meet the defined criteria, identify unresolved questions, and document the authority for release or further work. The aggregate decision should consider the device as used, including interactions between controls. Finally, connect that decision to the information monitored after release and the changes that reopen the assessment. An identifiable current conclusion makes a file usable for a submission or engineering change even when it also contains a substantial historical record.

How do you test whether a control has enough evidence?

Use a hypothetical sterile, single-use device to separate evidence types. Assume that the proposed control is a sealed package intended to protect the device through its claimed storage and distribution conditions. The review should establish whether the report supports the material, sealing process, device geometry, aging claim and distribution conditions that define the offered configuration. The manufacturer would need a device-specific testing plan to apply this review method. ²

Begin with the claim. If the commercial team promises a particular shelf life while the evidence covers a shorter interval, a risk-table statement that packaging has been “validated” conceals the mismatch. If the manufacturing team changes a pouch supplier, confirm which attributes and process assumptions can reasonably be bridged to the existing evidence. Review the earlier study against the new material and the assumptions being carried forward. Record the rationale for bridging or for obtaining additional evidence.

Next, distinguish the control's presence from its performance. A purchase specification and released bill of materials may establish which pouch should be used. Production records and incoming checks can help establish what was actually used. A relevant test program can address performance under stated conditions. These pieces answer different questions. Selecting one as a substitute for all the others leaves a gap that a document-completeness dashboard may fail to expose.

Consider a second hypothetical example: a home-use device has a warning intended to prevent an unsafe setup. The team should ask whether intended users can notice, understand and act on the information at the point of use. FDA's human-factors guidance addresses users, use environments and user interfaces in evaluating use-related risk. It supports examining the actual interaction, rather than treating the existence of a warning sentence as proof that the scenario has been controlled. ⁹

Now consider a software limit designed to prevent an out-of-range output. Requirements, implementation review and verification results should refer to the same version and boundary conditions. Include what happens during missing input, interrupted operation, recovery and relevant combinations with other functions. FDA's 2023 software-submission guidance connects software documentation with safety and effectiveness evaluation; the documentation level and submission content require their own applicability decision. A generic statement that software was “fully validated” provides little information about which behavior was evaluated. ¹⁰

For connected products, add a deliberate cybersecurity interface. FDA's February 3, 2026 guidance superseded the June 2025 document. It distinguishes security risk assessment from estimating the probability of an ordinary accidental event, and addresses matters such as threat modeling, architecture and lifecycle controls. The recognized ISO 14971 entry now explicitly points to exploitability for cybersecurity risk estimation. Do not force an attacker-driven scenario into an unsupported numerical occurrence estimate merely to fit an existing spreadsheet. Connect the security analysis to potential safety consequences while retaining the security-specific reasoning. ^{11 8}

How can a team expose uncertainty before approving the file?

An evidence review becomes more useful when it distinguishes an observed result from an inferred conclusion. Consider a hypothetical bench study in which no failures occur among 100 tested units. The directly supported observation is zero observed failures under those test conditions. Field performance remains subject to sampling uncertainty and differences in use conditions. If the samples were independent and representative of a defined binomial process, the one-sided 95% upper confidence bound would be approximately 3%, calculated as one minus 0.05 raised to the power of one divided by 100. Those assumptions may not describe an accelerated test, a selected worst-case sample or clinical use. The calculation illustrates uncertainty; the acceptance criterion requires a separate justification. ¹

The next question is whether the test is connected to the harm scenario. A component failure may or may not lead to a hazardous situation, and a hazardous situation may or may not lead to a particular harm. Moving from a bench study of component behavior to patient-harm probability requires evidence for the intervening steps. Document the intervening assumptions. Where the evidence supports only a qualitative estimate, a justified qualitative assessment may communicate the uncertainty more honestly than several decimal places copied into a risk matrix.

Separate independence from sample count as well. Repeated readings from one unit and observations across one hundred units support different inferences about between-unit variability. Several lots made with one unchanged material batch may not explore the variability that a supplier change introduces. These are questions about the study design and the inference being made, not reasons to demand a particular sample size in every project. The file should identify which sources of variability matter and explain how the available evidence addresses them.

For each important assumption, create a short record containing the assumption, supporting evidence, applicability boundary and consequence if it is wrong. A shelf-life assumption might depend on a specified material and storage condition. A human-factors assumption might depend on the intended user group and training. A software assumption might depend on an interface remaining available during recovery. This record is an editorially proposed working aid. It helps make the control-evidence connections discussed in FDA's human-factors and software guidance reviewable across functions. ^{9 10}

Now distinguish disagreement about facts from disagreement about criteria. Two reviewers may agree on the test result but disagree on whether the sample represents the offered configuration. They may agree on applicability but disagree on the acceptable residual risk. Resolving the first disagreement requires an evidence or applicability decision; resolving the second requires use of the organization's approved criteria and decision authority. A meeting note saying that the team reached consensus is incomplete unless it records which issue was resolved and the basis for resolving it.

Use explicit dispositions for evidence gaps. “Report unavailable” means a retrieval or ownership problem until the report's existence and relevance are confirmed. “Test not performed” identifies a different gap. “Test performed on an earlier configuration” requires an applicability assessment. “Test failed” requires investigation and a decision on its implications. “Criterion changed after results were reviewed” requires transparent justification and review of potential bias. Combining these states into one amber status deprives decision makers of the information needed to choose the next action.

The review record can end with a small decision table: evidence accepted with its boundary, additional analysis required, additional testing required, claim or configuration changed, or release decision deferred. These are proposed administrative dispositions, not replacements for the organization's formal procedures. Each one should identify an owner and the configuration affected. Where a conclusion depends on later information, state whether that dependency permits release under the applicable criteria or prevents a decision. This is more informative than labeling the entire file “complete” while leaving its most consequential assumptions unresolved.

What can a real enforcement example add?

Public enforcement material provides a different evidence lane from an aggregate recall chart. FDA's September 9, 2025 warning letter to Royal Philips discusses observations arising from inspections of ultrasound-related facilities and the agency's assessment of submitted responses. It includes issues involving corrective action, complaints and device evidence. It is a dated account of FDA's findings and concerns, not a general estimate of industry performance or a statement about every Philips product. ¹²

The value for a different manufacturer is to extract a review question, not copy a conclusion. When a corrective action is supported by a test, what shows that the test addresses the identified failure mechanism? When a complaint is closed, what connects the closure rationale to the available evidence? When a device has a useful-life or maintenance assumption, where is the supporting information and how is the assumption communicated? These questions can expose missing links even when the company's own records have different products, different causes and different outcomes.

A useful review exercise starts with one significant harm scenario and follows it in both directions. Forward, inspect how the analysis led to a control and how the control was implemented and checked. Backward, start with a complaint, failed test or changed component and determine which risk assumptions it could affect. The two paths should converge on an identifiable configuration and decision. If they end in different versions of the analysis, reconcile the assumptions and evidence before approving the current conclusion.

Record the review's evidence boundaries. A public warning letter may omit confidential technical details. A response described as inadequate at one date may later be supplemented. A statement about current compliance status requires a separate check of later public information. Likewise, a recall notice can identify an action without providing enough evidence to reconstruct the manufacturer's entire risk decision. Public evidence supports targeted questions; it rarely supports a complete external audit.

For a management review, the resulting action can be concrete. Select a small, justified sample across a severe-harm scenario, a recent design change, a production change and a post-market signal. Record the sampling rationale. Ask different functions to demonstrate the evidence path rather than merely report that a document is approved. Any gaps become assigned investigations with a scope, owner, due date and disposition. This is an editorially proposed review exercise, not an FDA-mandated sample size or a promised method of passing inspection.

Its success measure should also be concrete. The team should be able to identify the affected configuration, locate applicable evidence, explain its limitations and state the decision still required. Faster retrieval can be useful operationally, but no arbitrary ninety-second retrieval target establishes regulatory adequacy. A readily accessible unsupported conclusion is still unsupported. A slower but well-evidenced conclusion may instead reveal an indexing problem that deserves a different corrective action.

How should residual risk and post-market information connect?

A residual-risk decision should expose the reasoning that remains after controls are considered. Separate the severity of a possible harm from the estimate of its probability, the confidence in that estimate and the evidence supporting both. If the available information is sparse, state the uncertainty and determine what decision it permits. Replacing missing information with a convenient low score can create false precision. ISO's public description explicitly leaves acceptable risk levels to device context and manufacturer criteria. ¹

A benefit-risk discussion needs to address unresolved control questions explicitly. Identify the intended benefit, the population, available alternatives where relevant, the remaining harm scenarios and the quality of supporting information. FDA's guidance on benefit-risk factors in product-availability, compliance and enforcement decisions shows that such judgments are contextual. Premarket acceptance requires a separate decision in the applicable submission context. ¹³

The whole-device view can reveal interactions missed by separate rows. For example, a proposed alarm could address delayed recognition of a fault but introduce distraction or a confusing recovery task. A tighter limit could reduce one unsafe output while increasing interruptions during intended use. These hypothetical tradeoffs require a coherent decision about the device's actual use, not a contest to achieve the lowest sum of ordinal scores. Where the team's matrix is ordinal, its multiplied or averaged scores remain ordinal scoring constructs rather than measured probabilities.

Post-market monitoring should test the assumptions on which release depended. Define which complaint patterns, service findings, nonconformities, literature findings or changes would challenge the analysis. Identify who evaluates them and where the resulting decision is recorded. A trend is useful only when the numerator, denominator, time period and data quality fit the question. “Complaints decreased” may reflect fewer devices in service, a reporting delay or a changed coding practice rather than an effective control.

For the EU, the MDR distinguishes the post-market surveillance report from the periodic safety update report, or PSUR. Under Article 86, Class IIa PSURs are updated when necessary and at least every two years; Class IIb and III PSURs at least annually. MDCG 2022-21 provides guidance on PSUR preparation. Urgent risk assessments need attention when the information arises, independently of the scheduled reporting cycle. ^{5 14}

US medical-device reporting and correction/removal assessment are separate obligations with their own criteria. Risk-file updates, reporting decisions and engineering investigations each need their own documented disposition. FDA's reporting and recall guidance pages provide the starting points for identifying the applicable process. Build a connection between those processes so that a safety signal reaches the responsible decision makers without relying on an annual document refresh. ^{15 16}

What should happen when the device changes?

A change record should begin with the proposed difference and the assumptions it could invalidate. “Equivalent supplier” or “minor software update” is a proposed conclusion, not the starting evidence. Identify affected materials, manufacturing parameters, interfaces, performance claims, users and configurations. Then determine which existing evidence remains applicable, which needs a documented bridge and which must be replaced. FDA's guidance on deciding whether a change requires a new 510(k) provides a separate US submission decision framework; it depends on a sound underlying technical assessment. ¹⁷

Consider a hypothetical component substitution. The new component meets a headline specification, but its tolerance distribution, aging behavior or interaction with another part may differ. An appropriate review starts with the attributes that matter to the device's function. It then asks whether supplier information, engineering analysis, verification or other evidence adequately addresses the change. The purchasing decision should use the resulting technical assessment alongside commercial considerations. Equally, a full retest of every unrelated characteristic may consume resources without addressing the changed assumption.

For software, identify the deployed versions and the transition states as well as the final version. A change can affect installation, data migration, compatibility, rollback or recovery even when its new function behaves correctly. The risk file should point to the evidence for those relevant states and to the decision on unresolved anomalies. If the change alters a security control or a dependency, connect the security review rather than treating cybersecurity as a document produced once for an earlier submission. ^{10 11}

A release checklist can then ask four specific questions. Which configurations are covered by the revised conclusion? Which linked records changed? Which claims or instructions must change with them? What needs to happen to products already distributed? The answers may lead to several different processes, including updated documentation, new testing, a market-specific submission assessment or a post-market action assessment. The checklist should make those decisions visible without preselecting the outcome.

The record also needs a clean boundary between open work and accepted limitations. An unresolved test result, an unreviewed supplier change and a documented limitation supported by an approved rationale are different states. Labeling all three “acceptable with monitoring” prevents management from seeing what remains undecided. If monitoring is part of a justified decision, specify the question being monitored, the evidence to collect, the escalation condition and the person responsible for acting on it.

Finally, preserve the relationship to earlier decisions. Do not overwrite the historical explanation in a way that makes an earlier released configuration appear to have been evaluated using later evidence. A reviewer should be able to establish what was known at the time, what changed and why the conclusion was revised. That history supports learning from the change and prevents a later team from reusing an obsolete assumption because it finds an older test report without its superseding rationale.

How should a manufacturer scope the work and its cost?

Before requesting a quote, distinguish an evidence review from evidence creation. Reviewing an existing file can identify gaps and propose a work plan. Missing test results, clinical support or process validation require additional evidence-generating work. A useful statement of work names the device configurations, markets, available records, deliverables, review rounds, responsibilities and acceptance criteria for the consulting output. It also states which laboratory, clinical, manufacturing and software activities require separate ownership.

Pure Global's public pricing page, checked on September 18, 2026, lists US Agent support from $1,000 annually and EU representation from $2,000 annually for one device group. The EU scope includes review of prepared documentation; technical-documentation compilation is separate. The US annual scope likewise excludes 510(k) and other premarket submission compilation. Government and applicable third-party fees are separate. The page states a three-year contract, early termination with 50% of remaining contract value, and a one-year option with a 50% higher first-year fee. These terms describe the cited services, not a standalone price for an ISO 14971 file. Pure Global — Pricing, market-specific service scope and contract terms

The approved internal price workbook was also checked against the draft's commercial claims. Its US rows separately list regulatory-pathway work at $5,000 per project, 510(k) compilation and submission at $15,000–$20,000 per submission subject to scope confirmation, and RAQA ad hoc support at $250 per hour. No row specifies an ISO 14971 risk-management-file service. Those distinctions are preserved in the calculation supplement's scoped pricing extract. A reader should therefore request a specific scope and current quote for risk-file work rather than treating a representative's annual fee as the engineering budget. Pure Global — Reproducible recall aggregates, methods and scoped pricing extract for this report

For a practical scoping discussion, prepare an evidence inventory with status rather than a list of filenames alone. For each important control, identify whether implementation is documented, effectiveness evidence exists, applicability has been reviewed and a decision has been approved. Include the configuration and version. This makes it possible to separate a document-linking problem from a technical evidence gap. They can look similar in a submission checklist while requiring very different amounts of work.

Prioritize work by decision consequence. A missing link to an existing, applicable report may be resolved quickly. A mismatch between the claimed shelf life and available evidence can affect the release claim. A newly identified severe harm scenario may require broader investigation. Estimate the significance and cost from the evidence gap and the decision it affects, rather than the number of pages to edit. Ask for a work breakdown that identifies the decision enabled by each deliverable, along with dependencies and exclusions.

A manufacturer can begin with a bounded pilot review: one representative configuration, a selected set of important harm scenarios and the linked production and post-market evidence. The output should identify reusable structure, configuration-specific gaps and questions requiring specialist work. Expand the scope after those boundaries are understood. This is a proposed purchasing approach, not a fixed regulatory sequence or a guarantee of a particular timeline.

The release-ready result is a file whose conclusion can be followed and challenged. It identifies the device assessed, the controls chosen, the evidence that supports them, the limitations that remain and the information that could change the decision. Recall records, standards, legal requirements and service prices each contribute a different kind of evidence. Keeping those roles distinct helps a team spend its effort on the unresolved product decisions instead of producing a larger but less useful binder.