Comp AI: open-source compliance-as-code meets the medical device

“SOC 2 in a few weeks.” That is the promise of automated compliance platforms, and Comp AI offers an open-source one. The idea is appealing for a medical vendor who has to reassure hospital customers without drowning the team: treat compliance as code, collected and checked continuously. Here is what that automation really gives a medtech SaaS — and why the MDR file is exactly the part it cannot absorb.

What is “compliance-as-code” and what does a tool like Comp AI promise?

Definition: compliance-as-code treats controls, policies and evidence like code — versioned, collected automatically from your systems and re-checked continuously, rather than re-keyed into a spreadsheet before each audit. Comp AI (repository trycompai/comp) is an open-source implementation; per its repository, it automates evidence collection, policy management and control implementation for SOC 2, ISO 27001, HIPAA and GDPR.

It is released under the AGPLv3 license, on an open-core model, available self-hosted or as a managed cloud at trycomp.ai. Technically, it is Next.js with Trigger.dev for background jobs and Prisma for data. One thing to know before you fork it: AGPLv3 requires you to publish the source of any modified version you expose over a network — neutral for internal use, structuring if you turn it into a service for third parties.

SOC 2, ISO 27001: a commercial gate, not market authorisation

This is the distinction I hammer home with every medtech founder who mentions SOC 2. SOC 2 is not a certification: it is an attestation issued by a CPA audit firm against the AICPA’s Trust Services Criteria — Type I on control design at a point in time, Type II on operating effectiveness over a period. ISO 27001, by contrast, is a genuine ISMS certification. Both prove one thing: that you run your information security properly.

What neither does is authorise you to place a medical device on the market. That is CE marking under the MDR, or FDA authorisation. The confusion is common because both worlds say “compliance” — but they do not answer the same question.

Put another way: SOC 2 gets you customers, CE marking gives you the right to exist on the market. A tool like Comp AI accelerates the first. It does not touch the second.

What automation really gives you: continuous evidence over the one-off audit

The real gain is not cosmetic. Without automation, a SOC 2 or ISO 27001 audit is prepared in pain: you reconstruct months of evidence by hand — access, reviews, backups, patches — just before the auditor arrives. Compliance-as-code inverts the logic: evidence is collected continuously from your systems, the gap to target is visible at all times, and the audit becomes a snapshot of a state you already hold.

My field experience: this is where these tools earn their place — they remove the documentation sprint and make the state of compliance observable day to day. But keep the boundary sharp: automation collects and traces evidence, it does not replace analysis. A control ticked because a script saw it pass is not a control judged relevant.

HIPAA, GDPR: the health-data layer it addresses

Comp AI also references HIPAA and GDPR, the two health-data protection frameworks. Mind the scope: HIPAA is a US law (overseen by the Department of Health & Human Services), governing the Protected Health Information of covered entities and their business associates. A European vendor is not subject to it by default — it only becomes a topic if you serve the US healthcare market. GDPR, on the other hand, applies as soon as you process the data of people in the EU. On both frameworks, the tool helps structure evidence, whatever the software’s “medical device” status otherwise is.

What it will not automate: the IEC 62304 / MDR file

Here is the limit, and it is sharp. A pipeline can generate some of a medical software’s artifacts: traceability, test reports, release logs feed the IEC 62304 file — it is in fact the right approach, developed in automating 80% of your IEC 62304 docs. But an infosec evidence-collection tool does not know your medical software. It will produce neither your architecture in the sense of IEC 62304:2006+A1:2015, nor your ISO 14971:2019 risk management file, nor your clinical evaluation, nor the MDR technical documentation of Annexes II and III.

And there remains the irreducible part: judgment. Classifying a piece of software, analysing its clinical risks, appraising the worst reasonably foreseeable case — none of that is scraped from a system. The useful overlap sits on cybersecurity, where structuring your evidence also serves IEC 81001-5-1. The rest of the file is built, not collected.

Compliance-as-code collects the evidence; it does not produce the judgment. A medical file is judged, not scraped.

Comp AI or a GRC suite like Unicis?

Both are open-source and stop at the same MDR frontier; they simply do not target the same bottleneck. Comp AI is automation-first: its strength is SOC 2 velocity and continuous evidence, for a SaaS whose blocker is commercial. A suite like Unicis Platform CE is governance-first: risk register, RoPA, controls, to run in-house when the stake is owning your information-security governance. Choose by your current bottleneck: closing a SOC 2 to sell, or holding your ISMS in-house. Either way, the medical device file remains a distinct project.

FAQ

Does Comp AI get you CE marking for medical software?

No. It addresses SOC 2, ISO 27001, HIPAA and GDPR — information security and personal data. CE marking rests on the MDR, IEC 62304 and ISO 14971, outside its scope. Both efforts are useful; they do not replace each other.

Is SOC 2 mandatory to sell medical software?

No, it is not a regulatory requirement. It is a frequent procurement expectation, demanded by hospital IT and large accounts in their selection process. Useful commercially, unrelated to market authorisation.

Is the AGPLv3 license a problem?

It requires you to publish the source of any modified version you expose over a network. For standard internal use it is neutral; if you fork the tool to offer it as a service to third parties, weigh that obligation against the project’s commercial offering.

A SOC 2 to open, an MDR file to scope in parallel? Book a call — we separate what speeds up the sale from what gates market access.