Evidence

Standards & quality, how we qualify as your software partner.

The RND Group builds Software as a Medical Device (SaMD) and embedded instrument software (SiMD) for FDA-regulated devices, specialising in in vitro diagnostics and connected instruments. We develop under an ISO 13485-compliant quality system, to the IEC 62304 software lifecycle (including Class B and Class C), with independent verification and validation and the SBOM and cybersecurity evidence FDA Section 524B now requires. Below are the four questions worth asking any medical device software firm, and how we answer them.

IEC 62304ISO 13485ISO 1497121 CFR Part 820.30QMSR21 CFR Part 11FDA Section 524BAAMI TIR57IEC 62366HL7ASTM 1394/1381POCT1-ASBOM (CycloneDX / SPDX)

Our Agile development follows IEC 62304, AAMI TIR45, ISO 14971, and FD&C Act Section 524B inside an ISO 13485:2016-compliant quality system, and is aligned to the FDA QMSR (21 CFR Part 820), EU MDR, GDPR, and HIPAA.

Talk to a medical device software expert

What to verify before you hire

Do you work within an ISO 13485 quality system?

Yes. RND develops medical device software within an ISO 13485-compliant quality management system, aligned with 21 CFR Part 820 and the incoming QMSR. Design controls, risk management, and verification records are produced inside that system and land in your design history file, so your quality team is not left managing us as a generic supplier and integrating our work after the fact.

How do you handle IEC 62304 Class B and Class C software?

We classify each item to its IEC 62304 software safety class, A, B, or C, and scale the lifecycle rigor to match. For Class C, where a failure could contribute to death or serious injury, that means the full segregation, detailed design, and verification activities the standard expects. Class B and Class C work is the core of what we do.

How do you manage cybersecurity?

Cybersecurity is built into the software lifecycle, not added before filing. For a cyber device under FDA Section 524B we deliver the full premarket set: a security risk management plan, STRIDE-based threat models with CVSS v4.0 scoring, a machine-readable SBOM (CycloneDX or SPDX) with support status for each component, security testing, and a postmarket vulnerability management plan. It is a dedicated practice, detailed under our cybersecurity services.

Who is responsible for the final verification and validation (V&V)?

We are, through a V&V team that is independent of the developers. That separation gives an honest assessment of the work, while running both teams inside one ISO 13485-compliant quality system keeps them efficient and in close communication. The V&V team produces the requirement-to-test traceability matrices and V&V records as engineering deliverables.