The Other Half of Compliance: Why Your Technical Documentation Doesn't Know Your Code
The technical documentation is complete. SOPs are approved, risk management is documented, evidence is filed. Then the review question arrives: how exactly is this security requirement implemented?
The room goes quiet. Not because nobody knows the answer, but because nobody can substantiate it in reasonable time. The quality manager wrote the chapter but has no access to the repository. The engineer knows the implementation but has never read the document. Between them sits a translation gap – and in an audit, that gap is exactly what's under discussion.
Compliance is organised around documents – but it isn't only documentary
Medical device regulation has developed over decades around a single centre of gravity: the document. ISO 13485, MDR, IVDR, ISO 14971 all ask for traceable processes, defined responsibilities and complete evidence. That is as it should be, and it is the discipline where established compliance expertise lives.
But the document describes a product it cannot itself inspect. It states that authentication takes place, that data is transmitted encrypted, that sessions terminate. Whether the implementation delivers on that isn't in the document – it's in the code.
As long as regulation argued mostly in organisational terms, that was manageable. It is changing now.
The new regulation asks about the product
The EU Cyber Resilience Act sets requirements for products, not processes. BSI TR-03161 specifies in concrete terms how authentication, session handling and cryptography must work in digital health applications. BSI TR-02102 gets specific down to individual algorithms and key lengths. The EU AI Act demands technical evidence about systems many manufacturers have not yet fully inventoried.
None of this can be satisfied on paper alone. You can describe it – but the proof sits in the implementation. That makes the code base a regulatory artefact, and most manufacturers have no established process for it.
Two bases, two specialisations
This is why we are working with CertHub.
CertHub covers the documentation and organisational side: eQMS to ISO 13485, electronic technical documentation, design control, gap and conformity analysis, UDI and EUDAMED. That is org compliance as a profession in its own right.
At azuma we cover the code side – via two routes that complement each other in practice.
Route one: prove what you built
azuma nori analyses an existing code base against BSI TR-03161, BSI TR-02102 and the Cyber Resilience Act. The analysis runs locally on the developer machine – source code never leaves the company. The output isn't a list of red lights but line-level evidence, in formats that plug straight into evidence management: executive briefing, auditor deep-dive, compliance dossier.
Route two: don't build it yourself
For the most regulatorily sensitive parts of a digital health product – identity, authentication, access – there are ready-made components that already carry the requirements. doa provides IAM, multi-factor, passwordless and HSM integration as SaaS, built for BSI conformity and gematik readiness. mimoto delivers GesundheitsID as a service, so manufacturers don't have to run their own identity infrastructure.
This is the most pragmatic form of compliance there is: what you don't build, you don't have to prove. The identity stack is the obvious candidate – few areas absorb so much regulatory effort while offering so little product differentiation.
What changes
Manufacturers get one continuous path instead of two separate construction sites. CertHub structures what must be documented. azuma delivers what can be technically evidenced or bought in. Both sides speak the same regulation, approached from different ends.
This isn't a full-service promise. It's about customers no longer having to perform the translation between document and implementation on their own.
Three questions for a self-check
If you want to check whether you have the gap:
- For any three security requirements in your technical documentation, can you point to the corresponding place in the code?
- Who updates your documentation when the implementation changes – and how do they find out?
- How long would it take you today to produce defensible evidence for the Cyber Resilience Act?
If any of these is uncomfortable, a conversation is worth having. With us for the code side, with CertHub for the documentation side – or with both.
Frequently asked questions
Does azuma replace the work on technical documentation?
No. The two sides are complementary, not interchangeable. CertHub structures the eQMS, technical documentation and conformity assessment; we supply the technical evidence for what those documents claim. Without the documentation side there is no approval – without the code side there is no proof.
Which regulations does the code analysis cover?
nori covers BSI TR-03161 (parts 1–3) and BSI TR-02102 (parts 1–2) as regular policies, the EU Cyber Resilience Act in beta, plus BSI TR-03107 and the EU AI Act in development. The current state is listed on the product page.
Does our source code leave the company?
No. nori runs locally on the developer machine; source code never leaves the device. The background is in the article "Compliance analysis without code upload".
Do we have to buy both sides together?
No. Both sides can be approached individually. The partnership doesn't mean booking a bundle – it means having counterparts at both ends who speak the same regulation. The translation between document and implementation doesn't disappear, but you no longer have to do it on your own.
Want to know how defensible your evidence on the code side really is? Register for the free trial (three selected controls included) or get in touch. For the documentation and QMS side, reach CertHub directly.
Last updated: September 2026. Please check the feature scope and covered regulations of azuma nori on the product page before implementation.