Every control linked to its evidence.

A traditional eQMS files the risk assessment. Seal links it to the evidence.

A traditional eQMS is a system of record. It keeps the risk assessment as a controlled document: the hazards, the scores and the controls meant to reduce them. The evidence that a control works, and the complaints and deviations that should change an estimate, sit in other records.

A named control is not evidence that it works. The claim rests on verification evidence, which usually sits somewhere else: a test record, a maintenance log, a spreadsheet. When the two drift apart, the file keeps asserting a control that nobody has shown to work. Seal links the risk file to the controls as they are configured and tested, so a failed verification or new complaint challenges the assessment it concerns, and a strengthened control is verified before the assessment relies on it.

ICH Q9(R1) sets two principles for quality risk management: the evaluation of risk to quality is based on scientific knowledge and ultimately links to the protection of the patient, and the level of effort, formality and documentation is commensurate with the level of risk.¹ For medical devices, ISO 14971 asks manufacturers to identify hazards, estimate, evaluate and control the risks, and monitor the effectiveness of the controls, across every phase of the device’s life cycle.² Both depend on evidence that a document cannot keep current by itself.

Figure 1 follows CTRL-⁠021, a fictional high-level stop that should close a vessel’s inlet valve before it overflows. Its verification, VER-⁠021, failed: the sensor tripped and the close command was sent, but the inlet remained open. The failure leads back to the control, the scenario it serves and the risk review it reopens. The sections below follow CTRL-⁠021 from the failed test to a strengthened control, with a complaint and a CAPA trend as the evidence that reaches the file from outside.

You can start with one risk file, alongside the eQMS you already run: Seal connects to the documents, CAPAs and change controls in systems such as Veeva Vault QMS, MasterControl, Qualio and ETQ Reliance. The advantage grows as quality, manufacturing and laboratory work run on the same connected records, because the evidence that tests a control is then recorded where the control runs.

Follow the failure back to the control.

The scenario, the control requirement, the tested configuration and the verification result point to one another. A failed test leads back to the control, the requirement it serves and the investigation needed next, without anyone reconciling references across spreadsheets.

In Figure 1, CTRL-⁠021 should close the inlet valve when the high-level sensor trips. VER-⁠021 records the required response, the inlet closes, beside the observed one, the inlet remained open. Link the failed result to an investigation and the affected control. Assess the cause and define the verification needed after the change.

Keep the original observation. An investigation can change the explanation or the proposed control; it should not rewrite what happened in the test. Retain the failed result and the tested configuration, and review the residual risk separately. Reviewers decide which checks must be repeated and whether the remaining risk is acceptable.

A missing result is not a pass. Without a recorded execution, the control’s effectiveness is not established and the risk review stays open. A passing result is evidence, not risk acceptance: review the test scope, the other controls and the remaining uncertainty, and record the residual-risk decision separately. ICH Q9(R1) treats risk acceptance as its own decision, made case by case, and notes that a risk reduction measure can introduce new risks, so the assessment may need revisiting after it is implemented.¹

New evidence can challenge an old assumption.

A complaint, maintenance finding or production deviation may change the basis of a risk assessment. Connect the source to the affected scenario and retain why it belongs in the review.

This related complaint separates the original report from the technical investigation and the safety assessment. INT-⁠031 records the reporter’s words, “The device stopped during use. The patient needed assistance. We no longer have the packaging.” The lot and serial number were not supplied, and the technical and safety assessments remain open. A reported malfunction is evidence to assess, not a confirmed cause or a risk conclusion.

Preserve the source wording and distinguish reported facts from conclusions. Give each unresolved question an owner, a source and a follow-up: INV-⁠031 asks what happened to the device during the reported use, and what evidence is needed before anyone draws a conclusion. Link it to the scenarios it may challenge, and record why each source was included in the review or left out. A similarity is not a confirmed cause.

ICH Q9(R1) asks for a mechanism to review or monitor events, and for the output of risk management to be reviewed against new knowledge and experience, whether the event is planned, such as a product review, an audit or a change, or unplanned, such as the root cause of a failure investigation or a recall. The frequency of review follows the level of risk, and a review may reconsider an earlier acceptance decision.¹ Configure the owners and the review triggers for each source of evidence, so a relevant complaint reaches the assessment rather than waiting for the next scheduled update.

Keep the denominator with the estimate.

Fewer failures do not necessarily mean less risk. Keep the population, exposure, observation period and uncertainty with each estimate, so a falling count is not mistaken for a falling rate.

In this related CAPA example, failures fall from 12 to 5, but use falls from 150 to 60 runs. The observed rates are 8.0 and 8.3 per 100 runs. Seal’s configured chart keeps the comparison visible. Assess the population, observation period, uncertainty and competing explanations before using it to revise an estimate. These observations alone do not establish a causal effect.

ICH Q9(R1) asks risk evaluations to consider the strength of evidence, and notes that revealing assumptions and reasonable sources of uncertainty enhances confidence in the output or shows its limitations. Qualitative descriptors such as high, medium and low should be defined in as much detail as possible.¹ ISO 14971 requires objective criteria for risk acceptability but does not set the acceptable levels.²

Configure the categories, definitions and criteria for your context, and record their version and the basis for each estimate, so reviewers can see what an assigned value means. Apply the criteria without turning incomplete counts into incidence claims.

Formality follows the risk.

ICH Q9(R1) treats formality as a continuum: higher uncertainty, importance or complexity call for more formal risk management, and resource constraints do not justify less.¹ Use a distinct template for each method your process needs.

Methods can share records. A device risk file, a pharmaceutical quality risk assessment and a process FMEA can reference common functions, controls, requirements and source evidence while keeping their own terminology and assessment criteria. ICH Q9(R1) lists tools from FMEA, FMECA and fault tree analysis to HACCP, HAZOP, preliminary hazard analysis and risk ranking and filtering. It also describes rule-based decisions, where an SOP or a well-understood limit determines the action without a new assessment, which is how a limit configured in a workflow routes an exception.

Subjectivity enters through poorly defined risk questions and poorly designed scoring scales; ICH Q9(R1) asks for it to be managed by addressing bias and assumptions, using the tools properly and making the most of relevant data.¹ Versioned criteria and the basis recorded with each estimate give reviewers something to challenge.

A shared product-family control does not cover every product automatically. Keep its applicability, configuration and supporting evidence explicit for each assessed scope. The shared reference helps identify the affected products; reviewers decide whether the evidence applies.

Neil prepares the work. Your team decides the risk.

Neil is Seal’s AI agent. Give it the risk file, the changed requirement or the new evidence; it investigates the records the requester is permitted to see and prepares assessments, verification cases and workflow changes as work in Seal.

To investigate a challenged control, ask Neil to find the requirements and scenarios linked to the failed verification and to compare the tested configuration with the current one. It prepares a proposed impact assessment with source versions, competing explanations and the evidence needed to distinguish them. Missing evidence becomes linked follow-up work.

To prepare the next verification, ask it to turn the proposed control change into requirements, capture fields and verification cases. It drafts inspectable configuration and cases covering the intended response, the failure paths and missing evidence, including verification of the configured workflow itself before publication.

To review the operating evidence, ask it to compare the relevant complaints and service findings with the assumptions in the risk file. It prepares a source-linked comparison with population and exposure limits, candidate affected scenarios and proposed review tasks, without an unsupported incidence estimate or an automatic risk acceptance.

The useful deliverable is inspectable work: source-linked reasoning, explicit gaps and a proposed change your team can test. People approve the technical scope, run verification and make the risk decision.

In line with the EU’s draft GMP Annex 22 on AI, Neil is not used in GMP execution. It helps set up configuration, which your team verifies and releases under change control. Customer data is not used to train AI models, and the requester’s permissions govern what Neil can read. See how Neil fits Annex 22 and more about Neil.

A stronger control goes through change control.

When the investigation points to a better control, a change carries it: the revised requirement, the instructions, capture fields and qualifications that depend on it, and the verification the assessment will rely on. Approval, verification and the effectiveness review remain separate decisions.

Follow a changed requirement into the instructions, capture fields, qualification and verification that depend on it, and record the assessment scope and rationale. CHG-⁠014 shows the same mechanism on a related line-clearance change: one added instruction reaches an execution form, a qualification and a controlled copy, each with an owner and the evidence needed to close it. For CTRL-⁠021, the change would carry the revised control and the cases its retest must pass before RSK-⁠021 relies on it.

EU GMP asks for quality risk management to be used to evaluate planned changes, including their effect on validation, calibration and maintenance, and to plan the verification or requalification they need.³ ICH Q9(R1) counts change control among the planned events that send a risk decision back for review.¹ See change control for how the revision, its verification and its effective point are handled.

Define which evidence will test the improvement, and when, before it is implemented. Keep completion of the work separate from the later assessment of whether the change helped. A completed action does not close the risk review: review the implementation, the verification, the remaining uncertainty and any required effectiveness evidence before recording the authorised conclusion.

Start with one risk file.

Bring one risk file and a recent piece of evidence that challenges it: a failed verification, a complaint or a deviation.

Neil prepares the impact assessment, the follow-up work and the verification cases from that material, and your team inspects them against the risk file and the evidence. Start with sample material or arrange an NDA before sharing confidential records.

Test the cycle before you rely on it: a missing result, a failed verification and its retest, a complaint that may or may not belong to a scenario, a changed estimate with its denominator, and the residual-risk decision that follows.

Seal can run beside the eQMS you already use. Agree which system owns the risk file, which records Seal reads and how status crosses the boundary. To scope the first risk file with us, book a demo.