Verification Pack
IEC 62304 · Class B · build 2.4.0
Linked to requirement and configuration61 of 61 requirements verified
IEC 62304 verification
A traceable verification record, built from real testing.
Your notified body will ask to see every requirement verified. We run the tests on your build and hand you the traceable record, from safety classification to technical-file index.
Illustration. Example values from a fictional project, not a client engagement.
What this route is for
Can you show what was required, what was tested, what was found and fixed, and which version the evidence covers?
IEC 62304 sets out how medical device software should be built, verified and maintained. It does not decide whether your product is a medical device. Once that is settled, a reviewer expects the software story to be coherent and traceable, version by version.
We produce that record from testing your real build. Where your software uses AI, a model or prompt change is a change too: we re-verify against it and record every difference. We do not determine classification or provide conformity assessment.
From requirement to proof
Every requirement ends in a verified result.
Each requirement is linked to the risk controls it carries, the test that verifies it, and the configuration it was verified on.
-
Classification and planning
We recommend your software safety class and plan the lifecycle activities that class requires.
-
Requirements and risk
We organise your requirements, link each to its risk controls, and register every third-party component.
-
Verification
We run integration and system tests on your real build, and verify every risk control.
-
Change and configuration
Every defect, fix, re-test and change is recorded against the version it applies to.
What you receive
The IEC 62304 Verification Pack, traced from requirement to release.
A fixed 10-day first engagement builds the foundation for the highest-risk area of your software. For a single product and release, the complete pack typically follows four weeks later. Class C software and larger products take longer, and the first engagement’s gap list tells you how much.
-
Software safety classification rationale
-
Lifecycle plan for the scoped activities
-
Requirements register and requirement-to-test traceability
-
Software architecture note, where the safety class requires one
-
Verification plan scoped to the safety class
-
Test specifications and executed records
Run on your real build -
Risk-control verification records
-
SOUP register
Every third-party component evaluated -
Problem resolution records: defect, analysis, fix, re-test
-
Change and configuration records, with change-impact analysis
-
Tool-validation pack for the tooling we use
-
Technical-file evidence index
Ready for your technical file
Who does what
Clear roles, agreed before day one.
We run the verification and produce the record. For class B and C software, some evidence can only come from your engineers, and we say so up front.
| We do | Your team provides |
|---|---|
| Recommend the software safety classification | The classification decision |
| Lifecycle plan, requirements register and traceability | Architecture description, for classes B and C |
| Integration and system testing, and risk control verification | Unit-level verification evidence, for classes B and C |
| SOUP register and problem resolution records | Maintaining configuration and change records after handover |
| A draft maintenance plan | Ownership of the maintenance plan |
AI Test Group is not a notified body. We do not certify or approve anything, we do not determine whether a product is a medical device, and we do not provide conformity assessment.
Common questions
Practical questions before the evidence work begins.
Does IEC 62304 decide whether our software is a medical device?
No. Medical-device status is a separate classification question shaped by intended purpose and product context. IEC 62304 defines life-cycle requirements for medical-device software once that context has been established.
Is IEC 62304 a certification?
No. IEC 62304 defines life-cycle requirements for medical-device software. Our evidence work is not a certificate, approval, or conformity assessment.
What does software classification mean for the evidence work?
The applicable lifecycle activities and evidence depend on the product context and software safety classification. The scoping work makes the relevant assumptions, inputs, and review route explicit.
Can we use evidence we already have?
Yes. We begin by mapping your requirements, software risks, test material, defects, releases, configuration information, and current review expectations.
How do defects and re-tests appear in the evidence?
The test record keeps the original requirement or evidence question connected to the build, finding, fix, re-test, and relevant configuration context.
What does the evidence help a technical-file review understand?
It gives the reviewer a controlled path through the lifecycle and verification records in scope: requirements, test results, defects, changes, configuration, and version context.
Does this cover AI components?
Yes. Where your software uses AI, we test what it does when the model’s output is wrong, verify the risk controls around it, and re-verify after every model, provider or prompt change.
What happens on the next software release?
Each release, and each AI model, provider or prompt change, can be re-verified and the record updated, based on your release cadence and change-control model.
A defined next step
Start with a fixed first engagement, finish with a verified record.
Typically 10 days · fixed scope
First engagement
Classification rationale, verification plan, traceability and executed tests for the highest-risk area, and the SOUP register started. You end with a costed route to the full pack.
Typically 4 weeks after
Pack completion
The remaining requirements, tests and records. You end with the full IEC 62304 Verification Pack and a technical-file evidence index.
Every release after that
Re-check on every change
Each release re-verified, and re-verification after a model change where your product uses AI.
Timings assume one product and release, access to your build and test environment, and fixes landing within the window. Class C software takes longer.
Bring the build and the review in front of you.
A free 45-minute session. We map your highest-risk requirements, what has been verified, and the evidence you already have. You keep the map.