2026-08-28: hero swapped again (hero-lab-wide -> hero-real-bench) and this preload was NOT updated with it, which silently reintroduced the exact bug above — preloading an image the page no longer renders while the real hero went unpreloaded. If you change Hero.tsx's background, change this line in the same commit. -->

Medical devices

ISO 13485 & Design Controls for Medical Devices

ISO 13485 and FDA 21 CFR 820.30 do not ask whether your device works — they ask whether you can prove how you knew it would. That proof is a traceable chain from design inputs through design outputs to verification and validation, with nothing orphaned and nothing stale. Kyros Engineering builds that evidence alongside the engineering rather than reconstructing it before a submission. To be clear about what we are not: Kyros is not a registrar and does not issue or hold ISO 13485 certification. Certification is granted by a notified body against your quality system; what we supply is the engineering and the design-control record that system has to contain.

Scope this with us
What we work inISO 13485FDA 21 CFR 820.30IEC 62304IEC 60601-1ISO 14971Design History FileRequirements traceabilityVerification & validationSOUP managementDesign reviewsChange controlSubmission support

Most medical programs that reach us do not have a compliance problem. They have a documentation-order problem. The device works, the team is competent, and the evidence was assembled at the end from memory and email — which is exactly when it becomes expensive.

The standard is less mysterious than it looks. Strip away the vocabulary and design controls ask four things: what did you require, what did you design, how did you check it, and can you show the links between them.

What the standard actually asks of engineering

ISO 13485 clause 7.3 and FDA 21 CFR 820.30 cover the same ground in different words. For an engineering team the practical obligations are short.

  • Design inputs: requirements that are specific enough to verify. "Shall be safe" is not a design input; "leakage current below 10 microamps under single-fault condition" is
  • Design outputs: the schematics, firmware, drawings and specifications that implement those inputs, under change control
  • Verification: evidence the output meets the input — bench data, test reports, analysis
  • Validation: evidence the device meets the user need in its actual use environment, which is not the same as verification
  • Design reviews at defined stages, with the decisions and the attendees recorded
  • A design history file that lets a reviewer follow all of the above without asking you a question

Where the evidence actually breaks

Two failure modes account for most of the traceability findings we see, and both are mechanical rather than intellectual — which is why they are worth automating instead of reviewing by eye.

  • Orphans: a requirement nothing implements, or a design output nothing verifies. Every orphan is either dead scope or a genuine hole, and you want to know which before an auditor decides for you
  • Suspect links: a requirement changed after the item beneath it was written, so the verification below it now proves something about a previous revision
  • Requirements that were never testable, discovered at the point somebody has to write the verification protocol
  • SOUP and third-party components brought in without the version, the known anomalies, or the justification recorded
  • A risk file and a requirements set that drifted apart, so mitigations reference controls that no longer exist by that name

How we work a design-control chain

The chain runs design input requirement to design specification to design output to verification and validation. We keep it in a form that can be checked mechanically rather than read line by line, so orphans and suspect links surface the day they appear instead of the week before a submission. Kyros publishes a requirements-traceability method and a template for exactly this, and it is deliberately not a QMS: it is the engineering evidence layer that sits inside whatever quality system you run, whether that is a full eQMS or a well-disciplined set of documents.

Who does what

The roles get conflated often enough that it is worth being blunt about them.

  • A notified body or registrar audits your quality system and grants ISO 13485 certification. Kyros is not one and does not issue certificates
  • A QMS consultant writes and maintains the procedures your organisation follows. That is a different discipline from ours
  • Kyros does the engineering — firmware, electronics, verification — and produces the design-control record that engineering generates, in a form your QMS can hold and an auditor can follow
  • If what you need is the QMS itself rather than the engineering inside it, we will say so and point you to someone who does that properly

You probably want this if…

A submission is approaching and the traceability was going to be assembled at the end
You inherited a device from another firm and cannot tell what was verified against what
Requirements have changed several times and nobody is certain which test reports are still valid
The risk file and the requirements set no longer agree with each other
Your quality system is sound but the engineering evidence going into it is thin

Frequently asked

Is Kyros Engineering ISO 13485 certified?

No, and we will not imply otherwise. ISO 13485 certification is granted to a quality management system by a notified body or registrar; Kyros is neither, and does not hold that certification. What we do is engineering under design controls — producing the requirements, verification evidence and traceability that a certified quality system has to contain. Plenty of medical devices are developed this way, with the manufacturer holding the certification and the engineering partner supplying evidence that fits inside it. If someone tells you their engineering firm's certification covers your device, ask them to put that in writing.

Can you build the traceability for a device that is already designed?

Yes, and it is common. We read what exists, reconstruct the requirement-to-verification chain, and give you a written list of the orphans and the gaps before anyone proposes new testing. Reconstruction is more expensive than doing it alongside the work, which is the argument for starting early — but it is far cheaper than discovering the holes during a review.

What is a suspect link and why does it matter?

A suspect link is a trace where the item above it changed after the item below was written — a requirement revised after its verification protocol was approved, for example. The link still looks intact, so a visual review passes it, but the evidence underneath now proves something about an older revision. Suspect links are found reliably by checking dates mechanically and unreliably by reading, which is why we check them with a tool.

Do you handle the FDA submission itself?

We produce the engineering content that goes into it — software documentation to IEC 62304, verification and validation evidence, traceability, and the design history file material. Regulatory strategy and the submission itself are usually better handled by a regulatory consultant, and we work alongside one routinely rather than pretending to replace them.

We are a startup in Cleveland. Where should we start?

With a read of what you already have. Most early-stage teams have more usable design-control material than they think and less structure than they need. A two-week architecture diagnostic at $6,000 covers the technical architecture and the state of the evidence, and ends in a written plan you keep whether or not you continue with us.

Can you help with ISO 13485 certification in Cleveland?

Not as a certifying body — Kyros is not a registrar and holds no ISO 13485 certification, so anyone offering to certify you is not describing an audit correctly. What we do from Cleveland is build the evidence an auditor asks for: design inputs and outputs, verification records, and a traceability matrix with no orphan requirements. Your registrar issues the certificate.

Not sure whether your design-control evidence would survive a review?

Send us what you have. We will tell you where the orphans and the stale links are before you commit to a scope.