ISO 13485 Risk Management: Why the FDA Now Inspects It

ISO 13485 risk management is the requirement at Clause 7.1 that an organization document, apply and record risk management across the whole of product realization — contract review, design, purchasing, production, service provision and measuring equipment — not merely inside the design file. For nearly a decade that clause was treated as a formality, satisfied by pointing an auditor at an ISO 14971 risk management file and moving on. That era ended on 2 February 2026. The FDA's Quality Management System Regulation took effect, incorporating ISO 13485:2016 by reference into 21 CFR Part 820, and on the same day the agency retired the Quality System Inspection Technique in favor of Compliance Program 7382.850 — an inspection model that uses a manufacturer's own risk management documentation to decide which processes to examine, which records to pull, and how hard to push.

Here is the part that catches experienced quality managers off guard. Most organizations built their risk practice around the design project, because that is where ISO 14971 gets applied most visibly and where the deliverable is most obvious. Meanwhile a purchasing decision routed on price, a process change approved by production alone, and a contract commitment accepted by sales without a technical review all sit squarely inside Clause 7 — and all of them are places where the standard expects risk to have been considered and evidenced. An investigator working from Compliance Program 7382.850 does not have to find a missing design control to write an observation. A supplier file with no risk basis will do it.

This article maps ISO 13485 risk management the way the standard actually structures it and the way the FDA now examines it: clause by clause across product realization, then across every change you make afterward. It draws on 28 years of practice and 200+ audits attended, and it is written for the quality and regulatory professional who already owns a risk management file and needs to know whether it reaches far enough.

The Requirement Itself

What ISO 13485 Risk Management Requires at Clause 7.1

Documented. Applied. Recorded.

Clause 7.1 of ISO 13485:2016 is titled Planning of product realization. It requires the organization to plan and develop the processes needed for product realization, and to determine, as appropriate, quality objectives and product requirements, the need to establish processes and documents and provide resources specific to the product, the required verification, validation, monitoring, measurement, inspection and test activities specific to the product together with the criteria for product acceptance, and the records needed to provide evidence that the realization processes and resulting product meet requirements.

Then it adds the sentence that changes everything: the organization shall document one or more processes for risk management in product realization, and shall maintain records arising from risk management. That single requirement is the structural hinge of the entire standard. It does not say risk management in design. It does not say risk management for Class III devices. It says risk management in product realization — and product realization, in ISO 13485, is the whole of Clause 7.

Why ISO 13485 risk management sits at the top of Clause 7 rather than inside 7.3

Placement in a standard is never accidental. The drafters put the risk management requirement in 7.1, the planning clause, precisely so that it would govern every subclause beneath it rather than living as a design deliverable. Everything in 7.2 through 7.6 inherits it. Read this way, ISO 13485 risk management is not a process that runs alongside product realization; it is a lens through which every product realization decision is supposed to be made, and the standard expects to see the evidence of that lens having been applied.

The same architectural logic appears elsewhere in the standard. Clause 4.1.2(b) requires the organization to apply a risk-based approach to control the appropriate processes needed for the quality management system. Clause 7.4.1 requires supplier evaluation criteria to be proportionate to the effect on device quality and the risk associated with the device. Clause 7.5.6 requires validation of processes whose output cannot be verified by subsequent monitoring. None of these are design clauses. All of them are risk clauses. ISO 13485 risk management is distributed by design, and the organization that concentrated it in one department has misread the layout.

How ISO 13485 risk management differs from ISO 14971

The two are constantly conflated, and the conflation is the source of most of the trouble. ISO 14971:2019 is the method: it tells you how to analyze, evaluate, control and monitor risk relating to the safety of a medical device, and it produces the risk management file. ISO 13485 Clause 7.1 is the mandate: it tells you that a documented process must exist and that risk must actually be managed across realization, with records to prove it. ISO 14971 answers how. ISO 13485 risk management answers where, who, when and show me.

One practical consequence follows immediately. An ISO 14971 risk management file that is complete, technically excellent and entirely self-contained can still leave ISO 13485 risk management unsatisfied — because nothing in the file demonstrates that its outputs reached the purchasing decision, the process validation protocol, the servicing instructions or the contract review. ISO/TR 24971, the guidance document on applying ISO 14971, is explicit that risk management is a lifecycle activity fed by production and post-production information. The link outward is the requirement. The file alone is not the evidence.

A second consequence matters for organizations running an integrated system. ISO 13485 retains the pre-Annex SL clause architecture rather than the harmonized ten-clause structure used by ISO 9001, ISO 14001 and ISO 45001. Risk in ISO 9001 lives at Clause 6.1 as risks and opportunities to the management system; risk in ISO 13485 lives at 7.1 as risk to the safety and performance of the device and to compliance with applicable regulatory requirements. One difference deserves stating outright, because it is the most common piece of cross-contamination in integrated systems: ISO 13485 contains no requirement to identify opportunities. The risks-and-opportunities construct belongs to the harmonized structure and does not appear in ISO 13485 at all. A register carrying an opportunity column in a device system is carrying an ISO 9001 habit, not an ISO 13485 requirement — harmless if the organization understands why it is there, misleading if someone believes the standard asked for it. They are different objects with different scopes, and a procedure written for one will not carry the other. MSI's cross-standard risk management procedure guidance sets out where the two diverge and where a single documented process can legitimately serve both.

What records ISO 13485 risk management actually generates

Clause 7.1 requires records arising from risk management to be maintained. In practice, a defensible record set spans more documents than most organizations expect, and it is worth listing them because an inspection will sample from across the list rather than from the top of it.

The Regulatory Shift

Why the FDA Now Inspects ISO 13485 Risk Management Directly

Incorporated. Retired. Replaced.

Two things happened on the same date, and the pairing is what makes ISO 13485 risk management a live inspection exposure rather than a certification topic.

The FDA states plainly on its Quality Management System Regulation page that it began using the inspection process described in the updated compliance program on 2 February 2026, and its Quality Management System Regulation frequently asked questions confirm that the two legacy compliance programs are withdrawn. MSI covered the underlying rule when it was finalized in its analysis of the FDA rule aligning 21 CFR Part 820 with ISO 13485.

How Compliance Program 7382.850 uses your ISO 13485 risk management file

This is the detail that most summaries of the new regime skip, and it is the one that should change how you maintain the file. The compliance program states that the goal of an inspection is to evaluate whether the manufacturer's quality management system meets FDA requirements and provides reasonable assurance that devices will be safe and effective, and whether risk management and risk-based decision making are effectively used in the quality management system. Risk management is not one topic among several. It is one of the two stated objectives.

The program's inspection model places patients and users at the center, with risk management forming the ring immediately around them and the quality management system areas arranged outside that ring. Investigators are directed to use the manufacturer's own risk management documentation to decide which areas to prioritize, which records to sample, and how deeply to evaluate the controls they find. In an FDA presentation on medical device risk-based inspections, that model is reproduced directly from Part III of the program.

Consider what that means operationally. Your ISO 13485 risk management file is no longer just a record the investigator asks to see. It is the document the investigator reads first in order to decide where to spend the rest of the visit. If your file identifies a sterilization process as your highest-severity hazard control and your process validation records are thin, you have effectively handed over the map to your own weakest area. That is not an argument for understating risk — understating it is both dishonest and, in an inspection, transparent. It is an argument for making sure the controls named in the file are the controls you can actually evidence.

The six quality management system areas and where ISO 13485 risk management appears in each

The four subsystems of the old technique — management controls, corrective and preventive action, design controls, and production and process controls — are gone. In their place are six quality management system areas: change control; design and development; management oversight; measurement, analysis and improvement; outsourcing and purchasing; and production and service provision. Four other applicable FDA requirements are inspected alongside them: medical device reporting, corrections and removals, tracking, and unique device identification.

Map that against Clause 7 and the shape of the exposure becomes obvious. Outsourcing and purchasing corresponds to 7.4. Production and service provision corresponds to 7.5. Design and development corresponds to 7.3. Management oversight picks up 7.1 planning itself, alongside the medical device file and management review. And change control — which had no equivalent subsystem of its own under the previous technique — now cuts across all of them. Every one of those areas expects ISO 13485 risk management to be visible inside it.

One further change deserves attention from anyone who has been reassured by the old protections. Under the previous regulation, management review records, internal audit reports and supplier audit reports were excluded from routine FDA review under §820.180(c). ISO 13485 contains no such exclusion, and the FDA declined to preserve one. Those records are now within scope — which means the management review at which you discussed your risk profile, and the internal audit that examined your risk process, are both readable. MSI's ISO 13485 management review playbook covers what that meeting now has to contain and how the record should read.

The Whole of Clause 7

ISO 13485 Risk Management Runs Through Contracts, Purchasing and Production — Not Just Design

Contracts. Purchasing. Production.

What follows is the practical map: each subclause of product realization, the risk decision that lives inside it, and the record that proves the decision was made. Work through it against your own system and you will usually find that two or three of these are strong, one is adequate, and the rest have never been evidenced at all.

Clause 7.2 — ISO 13485 risk management in customer-related processes and contract review

This is the most consistently overlooked corner of Clause 7, because contract review is usually owned by sales or commercial operations rather than by quality. Clause 7.2.1 requires the organization to determine requirements specified by the customer, requirements not stated but necessary for specified or intended use, applicable regulatory requirements, any user training needed to ensure specified performance and safe use, and any additional requirements the organization determines necessary. Clause 7.2.2 requires those requirements to be reviewed before commitment, with differences resolved and the organization's ability to meet them confirmed. Records of the review and resulting actions are required.

Now read that through the ISO 13485 risk management lens. A commitment to a shortened lead time that removes a burn-in step is a risk decision. Accepting a customer's request to relabel a device for a use not covered in the validation is a risk decision. Agreeing to supply without the training that Clause 7.2.1(d) explicitly names is a risk decision. Each of them is made at the moment of contract review, usually by someone who has never opened the risk management file, and the record that survives is a signed quote.

The fix is structural, not exhortative. Contract review needs a defined route back into ISO 13485 risk management: a named condition set under which a commercial commitment cannot be accepted without a technical risk review, and a record field capturing which route was taken. MSI client experience suggests that organizations who add a single mandatory question to the review form — does this commitment change intended use, user population, use environment, or any control named in the risk management file? — catch the majority of these before they become nonconformities. Clause 7.2.3 then requires arrangements for communicating with customers on enquiries, contracts, feedback and advisory notices, which is the outbound half of the same loop.

Clause 7.3 — ISO 13485 risk management inside design and development

Design is where the practice is usually strongest, and it still fails in a specific and predictable way. Clause 7.3.3 names the applicable output of risk management as a required design input, which makes ISO 14971 structurally part of design rather than parallel to it. Clause 7.3.4 requires outputs in a form suitable for verification against inputs. Clause 7.3.5 requires systematic review. Clause 7.3.6 and 7.3.7 require verification and validation with documented plans including methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size. Clause 7.3.8 requires design transfer to verify that outputs are suitable for manufacturing before becoming final production specifications. Clause 7.3.9 governs design changes.

The predictable failure is not an absent risk file. It is a risk file that does not visibly drive anything. Hazards are identified, controls are named, the file is approved — and the design input list contains no requirement traceable to any of those controls, the verification plan tests function rather than control effectiveness, and the design review minutes record no discussion of residual risk. On paper, ISO 13485 risk management happened. In the trace matrix, it is invisible. MSI treats the linkage directly in its guidance on ISO 13485 design and development and in the measurement layer set out in design control metrics.

Two design-adjacent obligations now sit inside this clause that did not obviously belong to it a decade ago. Cybersecurity risk for connected devices enters as a design input through the same door, since FDA guidance expects security risk management to run alongside safety risk management — MSI's treatment of medical device cybersecurity and medical device threat modeling maps the artifacts to the clauses. And use-related risk enters through human factors work, where the validation evidence has become a quality record rather than a submission attachment, as covered in MSI's analysis of human factors validation testing.

Clause 7.4 — ISO 13485 risk management in purchasing and supplier control

Clause 7.4.1 is one of the most explicitly risk-worded requirements in the standard, and one of the most widely misapplied. It requires criteria for evaluation and selection of suppliers that are based on the supplier's ability to meet requirements, on the performance of the supplier, on the effect of the purchased product on the quality of the medical device, and — the phrase that matters — proportionate to the risk associated with the medical device. Purchase value is not among the criteria. Spend is not among the criteria. Volume is not among the criteria.

Yet the overwhelming majority of supplier tiering models an auditor encounters are built on annual spend, because spend is the number the enterprise system produces without effort. The result is a predictable and inspectable inversion: a high-value contract manufacturer receives an annual audit while a two-dollar molded component in a fluid path receives a certificate on file and no oversight at all. ISO 13485 risk management, applied honestly at 7.4.1, would have routed those two suppliers in the opposite order. Under the outsourcing and purchasing quality management system area, an investigator asking how supplier controls were set is asking exactly this question.

Clause 7.4.1 also requires that purchasing controls be proportionate and that records of evaluations and any necessary actions be maintained, while 7.4.2 requires purchasing information to include, where appropriate, a written agreement that the supplier notify the organization of changes to purchased product before implementation. That notification agreement is a risk control in contractual form, and it is the single provision most often missing from supplier files. Clause 7.4.3 requires verification of purchased product proportionate to the results of supplier evaluation and to risk — the same principle applied at receipt.

Clause 7.5 — ISO 13485 risk management across production and service provision

Clause 7.5 is the longest clause in the standard and carries the widest risk surface. Clause 7.5.1 requires production to be planned, carried out, monitored and controlled under defined conditions, with documented procedures, qualified infrastructure, defined monitoring and measurement, and defined labelling and packaging operations. Clause 7.5.2 addresses cleanliness of product and contamination control. Clause 7.5.3 covers installation activities. Clause 7.5.4 covers servicing, requiring servicing reports to be analysed and fed back into the improvement processes.

Clause 7.5.6 is where ISO 13485 risk management most directly determines an operational obligation: processes whose resulting output cannot be verified by subsequent monitoring or measurement must be validated, with documented procedures covering criteria for review and approval, equipment qualification, personnel qualification, methods, records and revalidation criteria. Deciding which processes fall into that category is a risk judgement, and it has to be documented as one. So is the scope of software validation for software used in production or in the quality management system, which 7.5.6 requires to be validated before initial use and after changes, proportionate to risk.

Clause 7.5.8 and 7.5.9 govern identification and traceability, and traceability extent is again risk-driven — with specific additional requirements for implantable devices, where records of components, materials and conditions must permit the device to be traced. Clause 7.5.11 requires preservation of product, including protection from contamination and deterioration during processing, storage, handling and distribution. Each of these decisions has a risk basis. In a well-built system that basis is written down once, in the risk management file, and referenced from each procedure. In a poorly built system it lives in the memory of a production engineer who is about to retire.

Clause 7.6 — ISO 13485 risk management and monitoring and measuring equipment

The last subclause of product realization is the shortest and the one most often delegated wholesale to a calibration vendor. Clause 7.6 requires the organization to determine the monitoring and measurement to be undertaken and the equipment needed, and to establish documented procedures ensuring that measurement can be carried out consistently. Equipment must be calibrated or verified at specified intervals against measurement standards traceable to international or national standards, adjusted as necessary, identified to determine calibration status, safeguarded from adjustments that would invalidate results, and protected from damage during handling, maintenance and storage.

Then comes the clause with teeth. When equipment is found not to conform to requirements, the organization must assess the validity of previous measurement results and take appropriate action regarding the equipment and any product affected. That is a retrospective risk assessment, mandated in the text, and it is the reason a failed calibration is a quality event rather than a maintenance ticket. The question an investigator will ask is simple: show me the last out-of-tolerance finding, and show me what you concluded about product already released. ISO 13485 risk management is what turns that question into a documented answer rather than an anxious silence. Software used for monitoring and measurement carries a parallel validation obligation before initial use and after changes.

Change Control

What ISO 13485 Risk Management Means Every Time You Make a Change

Assess. Approve. Notify.

Change control is the single largest structural difference between the old inspection technique and the new one. Under the previous four-subsystem model, change was examined inside whichever subsystem it happened to touch. Under Compliance Program 7382.850, change control is a quality management system area in its own right — listed first alphabetically among the six — which means an investigator can open an inspection by asking for your change log and follow it wherever it leads.

Design changes and ISO 13485 risk management at Clause 7.3.9

Clause 7.3.9 requires the organization to document procedures to control design and development changes. Changes must be determined for their significance to function, performance, usability, safety, applicable regulatory requirements and intended use of the medical device. They must be reviewed, verified and validated as appropriate, and approved before implementation. Records of changes, the review of changes, and any necessary actions must be maintained.

Note the ordering: determine significance, then decide the level of review, then verify and validate as appropriate, then approve, then implement. ISO 13485 risk management is the mechanism by which significance is determined, and the phrase as appropriate is only defensible if the appropriateness judgement is documented against risk. A change record that jumps straight to an approval signature has skipped the step the clause exists to require. MSI's design and development procedure guidance sets out how the change route should read in a written procedure.

The change that looks smallest is usually the one that fails hardest. Substituting a resin grade because the original went on allocation. Moving a molding operation to the supplier's second site. Updating firmware to fix an unrelated bug. Each of these is trivially justified inside the function that proposed it, and each of them can touch biocompatibility, process validation status or software verification coverage. The purpose of a documented ISO 13485 risk management route is to make the question unavoidable rather than dependent on who happened to be in the room.

Process, supplier and production changes under ISO 13485 risk management

Design is not the only place changes originate, and the change control inspection area does not confine itself to 7.3.9. Clause 7.5.6 requires revalidation criteria to be defined and revalidation performed when changes affect a validated process. Clause 7.4.2 requires the written agreement that suppliers notify you of changes to purchased product before implementation — without which you cannot possibly assess risk in advance, because you learn of the change when the part arrives. Clause 7.5.1 requires production to run under defined conditions, which a change silently alters.

Three questions make a change record defensible under ISO 13485 risk management, and they should appear as fields rather than as culture:

When ISO 13485 risk management intersects a regulatory submission decision

The most consequential output of a change assessment is often not technical at all. It is the determination of whether the change requires a new premarket submission. The FDA maintains guidance on deciding when to submit a 510(k) for a change to an existing device, structured around whether the change could significantly affect safety or effectiveness — a determination that draws directly on risk analysis. Under the change control inspection area, an investigator can ask how you make that call and ask to see recent examples where you concluded no submission was needed.

This is the point at which ISO 13485 risk management stops being a quality department activity and becomes the shared evidentiary basis for a regulatory position. The risk analysis supporting a no-submission decision is, in practice, the defence of that decision. If the analysis is a single line stating that risk is unchanged, the defence is a single line. Organizations that document the comparison properly — what was assessed, against what baseline, with what result — are in a materially different position when the question is asked two years later by someone who was not there. Nothing here constitutes regulatory or legal advice; submission determinations should be made against current FDA guidance and, where the stakes warrant it, with regulatory counsel.

Manufacturers selling into other markets carry parallel obligations. The EU Medical Device Regulation requires notified body involvement for significant changes to an approved quality system or device, and the Medical Device Single Audit Program examines change control against the requirements of every participating authority in a single audit. One well-built ISO 13485 risk management route serves all of them; several loosely coupled ones serve none of them well.

Evidence

The Records That Prove ISO 13485 Risk Management Is Actually Working

Linked. Current. Traceable.

The compliance program directs investigators to test real-world effectiveness — to pull actual records demonstrating the system works rather than to confirm that procedures exist. For ISO 13485 risk management, effectiveness is demonstrated almost entirely through linkage. Four connections carry most of the weight.

Linkage one: ISO 13485 risk management to acceptance criteria

Clause 7.1 requires the organization to determine the required verification, validation, monitoring, measurement, inspection and test activities specific to the product, together with the criteria for product acceptance. Where did those criteria come from? A defensible answer traces the tightest tolerances and the most sensitive tests back to hazards in the risk management file. An undefensible answer traces them to a drawing inherited from a predecessor product whose rationale nobody recorded. This linkage is easy to build going forward and painful to reconstruct retroactively, which is why it is worth doing on the next product rather than on the current one.

Linkage two: ISO 13485 risk management to post-market feedback

Clause 8.2.1 requires the organization to gather and monitor information relating to whether it has met customer requirements, and to document procedures for the feedback process, including provision for gathering data from production and post-production activities. That feedback must feed the risk management process as an input to monitoring and maintaining product requirements. The traceable evidence is a complaint or servicing trend that changed a probability estimate, a residual risk conclusion or a control — and the file revision that recorded it.

MSI client experience suggests this is the most commonly broken linkage in otherwise mature systems. Complaint handling is competent, corrective action is competent, and the risk management file has not been revised since design transfer. An investigator does not need a technical argument to write that observation; the revision history makes it for them.

Linkage three: ISO 13485 risk management to internal audit scope

Clause 8.2.4 requires the audit programme to take into consideration the status and importance of the processes and areas to be audited as well as the results of previous audits. Importance, in a device organization, is a risk statement. An audit programme that gives every process the same frequency and the same depth is telling an investigator that risk did not inform the programme — which is awkward when risk-based decision making is one of the two things the inspection is designed to evaluate. MSI's approach to building a defensible internal audit risk matrix shows how to score it and evidence it, and the wider internal audit programme work follows the same logic. The current guidance for auditing management systems, ISO 19011:2026, published on 27 May 2026 and cancelled the 2018 edition immediately with no transition period.

Linkage four: ISO 13485 risk management to management review

Clause 5.6.2 lists the required management review inputs, and Clause 5.6.3 requires documented decisions and actions. The risk profile of the organization belongs in that meeting, because management review is where top management demonstrates that risk-based decision making reaches the level that allocates resources. Now that management review records are no longer excluded from FDA review, the minutes are part of the evidence set — and a review that records no engagement with risk is a documented absence rather than a private one.

Failure Patterns

How ISO 13485 Risk Management Fails in the Inspection Room

Static. Isolated. Unproven.

Across 200+ audits attended, the same six patterns recur. None of them involve an organization that failed to care about safety. All of them involve a system that could not show its work.

Pattern one: the frozen file — ISO 13485 risk management that stopped at launch

The risk management file carries a revision date within a month of design transfer, and the device has been on the market for six years. Everything in it may still be true. Nothing in it demonstrates that anyone checked. Where post-market data exists in volume, an unrevised file is a claim that reality confirmed every estimate exactly — a claim no experienced investigator finds plausible.

Pattern two: undefined acceptability criteria in ISO 13485 risk management

A five-by-five matrix with coloured cells, and no policy stating what makes a risk acceptable, who may accept residual risk, or on what basis the boundaries between the colours were drawn. ISO 14971 requires criteria for risk acceptability to be established in the risk management plan. Without them, every acceptance decision in the file rests on an unstated standard, and the matrix is decoration.

Pattern three: ISO 13485 risk management that never reached purchasing

Supplier tiers built on spend, no written change-notification agreements in supplier files, and incoming inspection sampling plans that apply the same level to a critical component and a shipping carton. This is the pattern most exposed by the outsourcing and purchasing inspection area, and the one organizations are usually most surprised to be asked about.

Pattern four: change records without an ISO 13485 risk management step

Approval signatures present, risk impact field blank or filled with the word none, no reference to any specific hazard or control, and no record of who reached that conclusion. Since change control is now a named inspection area and investigators are directed to ask how risk impact is analysed, an empty field is an answer.

Pattern five: two vocabularies, one system — the ISO 13485 risk management translation gap

Procedures written in the vocabulary of the old regulation — design history file, device master record, quality system regulation subsection numbers — while the investigator is working from ISO 13485 clause language. Nothing is technically wrong. Every answer requires a translation step performed under pressure, and translation under pressure produces the inconsistencies that generate follow-up questions.

Pattern six: ISO 13485 risk management owned by one person

One capable individual holds the whole picture. They facilitate every analysis, remember every rationale, and are the reason the system works. When the investigator asks the production supervisor how risk shapes the process controls they run, the answer is a name rather than a process. Clause 6.2 competence requirements exist partly to prevent exactly this, and a single-owner risk practice is a business continuity exposure long before it is a compliance one.

The Build

Building an ISO 13485 Risk Management Process That Holds Up

Scope. Criteria. Route.

Seven steps, in this order. Organizations that already hold certification usually find that steps one, three and five are where the work is, and that steps two and four exist in some form already.

Step one: scope ISO 13485 risk management across the whole of Clause 7

Write the process so that its scope statement names 7.2 through 7.6 explicitly rather than referring vaguely to product realization. This single sentence does more work than any other in the document, because it is the sentence an auditor reads when deciding whether purchasing and servicing are inside the process or outside it.

Step two: set criteria for acceptability before applying ISO 13485 risk management to anything

Define severity and probability scales in operational language, state where the acceptability boundaries sit and why, and name the role authorized to accept residual risk. Where probability cannot be estimated because data does not exist, say so and default to severity — that is a defensible position, and ISO/TR 24971 discusses it. Guessing a probability to fill a cell is not.

Step three: build the routes that carry ISO 13485 risk management into each subclause

A route is a defined trigger plus a defined record. Contract review triggers a technical risk review when intended use, user population, use environment or a named control is affected. Supplier selection triggers a risk-based criticality assignment recorded on the supplier file. Process change triggers a revalidation assessment. Each route needs an owner, a form field, and a rule for what happens when the answer is yes.

Step four: make ISO 13485 risk management competence explicit under Clause 6.2

Name the roles that perform, review and approve risk activity, define what competence looks like for each, and evidence it. A facilitator's experience is not a system control until it is written down as a competence requirement that someone else could be trained against.

Step five: close the post-market loop into ISO 13485 risk management

Set a defined review cadence and a defined data set: complaint categories mapped to hazards, servicing findings, nonconforming product trends, and field action history. Record the conclusion even when it is no change required — especially when it is no change required, because that is the entry that proves the review happened.

Step six: rewrite procedures in ISO 13485 clause language

Retire the old regulation's vocabulary from procedure titles, form headers and record names so that ISO 13485 risk management reads in the same language the investigator is working in. Keep a cross-reference table for anyone who needs the translation, but stop making the system perform it live. A structured ISO 13485 gap analysis is the fastest way to find where the old vocabulary is still embedded.

Step seven: audit ISO 13485 risk management as a process, not as a document

Audit the routes rather than the file. Pull five change records and test whether the risk step was performed before implementation. Pull three supplier files and test whether criticality was assigned on effect rather than spend. That is how an investigator will approach it, and an internal audit that mirrors the external method is worth several that do not. Training auditors to work this way is what MSI's internal auditor training and management review programs are built around.

Questions Answered

ISO 13485 Risk Management: Frequently Asked Questions

Asked. Answered. Sourced.

Does ISO 13485 risk management apply to processes other than design?

Is ISO 13485 risk management the same thing as ISO 14971?

How does the FDA inspect ISO 13485 risk management now?

What does ISO 13485 risk management require when we change a design?

Can supplier tiers be based on spend under ISO 13485 risk management?

Are management review and internal audit records still protected from FDA review?

How often should ISO 13485 risk management files be reviewed?

Does ISO 13485 risk management work the same way as risk in ISO 9001?

Keep Reading

Related Reading on ISO 13485 Risk Management and Device Quality

Deeper. Wider. Connected.