01Blog
From code to compliance, in practice.
Architecture, testing, release to production and cybersecurity for medical device software. Long-form, sourced articles, written for teams that ship.
Lines
Featured
Comp AI: open-source compliance-as-code meets the medical device
Comp AI automates SOC 2, ISO 27001 and HIPAA evidence, open-source: what compliance-as-code gives a medtech SaaS, and why the MDR technical file stays separate.
Houssam Karrach ·
Read the article → Cybersecurity line
7 articles
Unicis Platform CE: open-source GRC for a medical device team Unicis Platform CE, self-hosted open-source GRC: what it covers for a medical device software team — ISMS, risk register, GDPR — and where the MDR file starts. 
The Stryker attack hit no medical device — and that is exactly the problem The Stryker attack reached no medical device, but the manufacturer's control plane. What that changes for the scope of your threat model. 
Threat modelling a medical device: architecture views and the risk matrix The threat model the FDA expects: four security architecture views, the risk matrix, exploitability rather than probability, and the transfer into ISO 14971. 
From SBOM to VEX: managing medical device vulnerabilities without drowning the team Scanning your SBOM, triaging CVE noise and recording every decision with VEX: the post-market surveillance pipeline the FDA and IEC 81001-5-1 expect. 
A medical device SBOM: what the FDA requires, what the MDR expects, and how to keep it SBOM required by the FDA (§524B), expected under the MDR (MDCG 2019-16), outside the CRA for a device: contents, CycloneDX/SPDX formats, generation. 
FDA §524B: the cybersecurity content without which your submission can be refused Section 524B of the FD&C Act: cyber device criteria, the 4 legal requirements (vulnerability plan, SBOM), differences with the EU, and an 8-point checklist. 
IEC 81001-5-1: where to start when you already have 100k lines of code A realistic 5-step IEC 81001-5-1 catch-up plan for existing code: SBOM, threat model, vulnerability handling, testing, documentation — without rewriting it. Engineering line
3 articles Comp AI: open-source compliance-as-code meets the medical device Comp AI automates SOC 2, ISO 27001 and HIPAA evidence, open-source: what compliance-as-code gives a medtech SaaS, and why the MDR technical file stays separate. 
Automating 80% of the IEC 62304 software architecture document: the human–AI boundary Generating 80% of the IEC 62304 software architecture document with AI: what to automate, the 20% a human must own, and the gate that keeps it defensible. 
IEC 62304 documentation: the part our CI/CD pipeline generates What CI/CD can generate of IEC 62304 documentation (SOUP list from the SBOM, requirements-tests traceability, reviews, release notes) and what stays human.