Your CI/CD pipeline already produces the evidence IEC 62304 asks for

A CI/CD pipeline is usually sold as a way to ship faster. In a regulated environment, that is the least interesting thing it does.

The common framing is almost the reverse of the useful one. The pipeline gets treated as a delivery accelerator, and compliance as a set of controls bolted on afterwards to slow it back to a safe speed - velocity on one side, audit-readiness on the other, in permanent negotiation.

Designed deliberately, a pipeline is not something you make compliant. It is the machine that produces the traceability the standard requires, and speed becomes a by-product of generating that evidence continuously instead of reconstructing it before an audit.

IEC 62304 asks for evidence, not a method

The standard does not prescribe a development methodology. Nothing in it requires waterfall, and nothing forbids frequent integration or deployment.

What it requires is that every requirement stay traceable through design, code, verification, release, and subsequent change, and that the environment in which software is built and released be documented and repeatable.

This is where the inversion has teeth. Continuous integration and delivery are not the obstacle to that evidence; done deliberately, they are the most reliable way to generate it. 

The second edition of IEC 62304, currently targeted for 2026, sharpens the line between maintenance and development: an acknowledgement that incremental change, not greenfield work, is how most regulated software actually evolves.

A well-designed pipeline generates evidence by running

Concretely, a pipeline built for traceability produces three things as a side effect of running, not as a separate documentation exercise.

A traceability thread, first: a common identifier carried across requirements, commits, builds, and tests, so any change traces back to the requirement that motivated it and forward to the evidence that verified it.

Verification evidence, second, with coverage scaled to risk rather than applied uniformly: the rigour follows the safety classification of the affected item.

And a release package, third, that is genuinely repeatable: infrastructure-as-code and containerised builds satisfy the requirement that a release be reproducible (Clause 5.8.8), instead of depending on one engineer’s machine.

The teams that get this right stop treating auditors as an external interruption and start treating them as stakeholders in the pipeline itself, people whose questions the system is designed to answer on demand.

Continuous integration and continuous deployment carry different risk

The distinction that matters most is between CI and CD. Continuous integration - frequent merging, automated build and test - sits comfortably inside IEC 62304. A team can run it internally and produce the documentation a reviewer needs without friction.

Continuous deployment is a different proposition. An automatic push to users is a release of a regulated product, and under the standard no feature reaches release before it has met its verification acceptance criteria (Clauses 5.5.3 and 5.8.6). The pipeline can do both, but the path to production has to be gated, not open by default. The gate is where compliance lives; everything before it can move as fast as the team can build.

DevOps tools need validating too

A pipeline that generates evidence is only as trustworthy as the tools generating it. If the build server, the test framework, and the deployment scripts have not themselves been validated, the audit trail they produce rests on an unexamined foundation. The standard makes this explicit by requiring that the software creation environment be documented (Clause 5.8.5).

This is where a risk-based approach pays off. Under ISO 13485, software used in the quality system has to be validated; the practical question is how much.

Validating a build server to the same depth as the diagnostic algorithm it helps ship is wasted effort. Common practice is to scale the assurance to the risk each tool carries (the logic the FDA formalised in its Computer Software Assurance guidance, and that GAMP 5 applies internationally). The point is not less rigour; it is rigour aimed where a tool failure could actually compromise safety.

Compliance becomes an output, not overhead

Teams that struggle with DevOps in regulated environments are usually the ones still treating compliance as a tax on delivery.

The shift is to design the pipeline so the audit trail is an output generated continuously, rather than a deliverable assembled under pressure. Controlled workflows, it turns out, tend to make pipelines faster, not slower; the discipline that satisfies a reviewer is the same discipline that keeps a release predictable.

That is the work we care about at Aimasoft: building pipelines where evidence is a product of the process, not a parallel burden bolted onto it.