Evidence Pack
DCB0129 – version 1.4
Approved by clinical safety officer12 of 12 hazards traced
MANAGED TESTING FOR CLINICAL SOFTWARE
Testing that writes your compliance evidence.
We test your real product and hand you the evidence your NHS buyer or notified body will ask for: a signed DCB0129 safety case or a traceable IEC 62304 record.
20-minute call · proposal within one working day · no patient data needed
Verification run
IEC 62304 §5.7 · build 2026.8.3
Manual regression on 5 platforms: about 3 days6 minutes
Illustration. Example values from a fictional project, not a client engagement.
We Specialise in Two Compliances.
DCB0129 and IEC 62304 are our two primary service lines, each with its own evidence structure, gatekeeper and vocabulary.
DCB0129
Selling clinical software into the NHS?
Your NHS buyer will ask for a signed safety case. We produce it: the hazard log, the Clinical Safety Case Report and our in-house CSO’s signature, with every control backed by a test on your real product.
Learn moreWhat's actually blocking you.
IEC 62304
Building a medical device?
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.
Learn moreWhat's actually blocking you.
What we produce
One engine.
Two evidence outputs.
DCB0129 and IEC 62304 are our two primary service lines, each with its own evidence structure, gatekeeper and vocabulary.
How it works
From requirements to evidence pack in four steps.
Steps 1 to 3 are the same for both service lines. Step 4 forks, because the handover differs: the two standards have different gatekeepers.
-
Scope and classify
We review your product and map the work. For IEC 62304 this includes safety classification.
-
Risk-mapped test execution
We run tests linked to the requirement or hazard each one validates.
-
Evidence pack assembly
Results, traceability and version context are gathered into one reviewable pack.
-
Handover, forks by standard
The pack is handed over in the shape the gatekeeper for your standard expects.
Why us
What makes us different.
Evidence produced by running tests
We produce evidence by running tests against your real product, not paperwork describing how you intend to test.
Testing and documentation in one engagement
One team runs the testing and writes the evidence, so nothing is lost in a handover between two suppliers.
Tool-validation pack included
The tooling we test with comes with its own validation evidence, which an assessor will ask to see.
Regulated-industry rigour
The habits come from twenty years of QA in regulated settings, where the evidence has to stand up.
-
20+
Years in regulated QA
-
2
Primary frameworks
-
2
Service lines
Twenty years of regulated QA, one team for the testing and the evidence, and a tool-validation pack in the box. That is the whole difference.
More about us
Frequently asked
Questions we get asked before every engagement.
Do I need DCB0129?
If your software is used in NHS care — in a clinical pathway, by clinicians, or handling patient information as part of care — then yes: NHS organisations are required to procure from suppliers who comply with DCB0129. If you’re purely consumer wellness with no clinical claims, you may not need it. A short scoping call settles this quickly.
How do I know if my software qualifies as a medical device under IEC 62304?
It comes down to intended purpose. If your software diagnoses, prevents, monitors or treats a condition — or informs clinical decisions about one — regulators will likely treat it as software as a medical device, and IEC 62304 becomes the expected lifecycle standard. We help you confirm the classification and the safety class (A/B/C) before any work starts.
What is a Clinical Safety Officer (CSO) and why do I need one?
A CSO is a registered clinician, trained in clinical risk management, who owns the clinical safety process and signs your safety documentation. DCB0129 requires a named CSO, and without that signature your Clinical Safety Case is not valid. We provide Clinical Safety Officer support in-house where it is included in scope. The manufacturer remains accountable for its product, and the accountable signatory signs the safety case.
What exactly do I receive at the end?
A review-ready evidence pack, shaped to the route. For DCB0129: Hazard Log material, Clinical Safety Case Report material, risk-control test evidence, a traceability matrix, and the CSO sign-off certificate, which records the Clinical Safety Officer’s signature on your safety documentation rather than certifying the product. For IEC 62304: a verification plan scoped to your safety class, test specifications, executed results with version records, a requirement-to-test traceability matrix and risk-control verification.
What is the difference between DCB0129 and DTAC?
DCB0129 is the clinical safety standard for manufacturers of health IT software. DTAC is the NHS’s broader procurement checklist — it covers clinical safety, data protection, security, interoperability and usability. Clinical safety is the section our evidence answers directly, and it’s the one most suppliers get stuck on.
Can this evidence be used for investor due diligence as well as NHS procurement?
Yes. The same pack, traceable requirements, executed tests and documented risk controls, is what technical due diligence looks for. It works for investor rounds, enterprise security reviews and partnership discussions as well as NHS procurement.
Do you need real patient data?
No. We never ask for patient data, and we do not work with it. Testing runs against synthetic data in your test environment.
How quickly can a Compliance Sprint begin?
A Compliance Sprint runs for two weeks from kickoff once product access, the test environment and the relevant team input are available.
Not sure which applies to you? We’ll tell you.
Book a 20-minute scoping call. We'll map your product to the right framework, DCB0129, IEC 62304, or both, and come back with a proposal within one working day.