Compliance & evidence
Compliance evidence as a by-product
The documentation regulators, auditors and customers ask for — derived from the code you already have.
Why it matters now
Software organisations carry two debts at once: code nobody remembers writing — COBOL, RPG, ten-year-old Java services whose authors have retired — and code nobody wrote at all, generated by AI assistants faster than anyone can review it. Both land in the same place: systems a company cannot explain to its new hires, an auditor, a buyer in due diligence, or a regulator.
That pressure is becoming statutory. The EU Cyber Resilience Act and NIS2, and the safety standards beneath them — IEC 62443-4-1, IEC 62304, EN 50128, AQAP 2210 in defence — require evidence of a documented development lifecycle and a component inventory, not merely working software. Dev-Doc produces that evidence as a by-product of understanding the code.
Cyber Resilience Act & NIS2
A head start on supplier security reviews
Customers covered by NIS2 must check the security of their suppliers, so they send questionnaires: which components does your software contain, what does it connect to, where does it keep data? Manufacturers under the CRA must keep a machine-readable list of their software’s components. Every download includes a cra-nis2 folder for both.
| File | Contents |
|---|---|
sbom.cdx.json | CycloneDX 1.6 SBOM — every third-party component found in your code. |
sbom.spdx3.json | The same inventory as SPDX 3.0.1. Versions are shown only when your code pins them; ranges and unknowns are marked, never guessed. |
supplier-fact-sheet.md | One document for customers’ NIS2 security questionnaires: product overview, component table, external interfaces, runtime structure, data stores and tech stack. |
sbom-changes.md / .json | What changed between two releases: components added or removed, version and licence changes. |
tr-03183-2-completeness.md | The SBOM checked field by field against the German guideline BSI TR-03183-2 — what is filled, what is missing, and how to close each gap. |
For regulated supply chains
Engineering evidence package
Software that has been shipping for years, and a customer now asking for the documentation package. From the same analysis, Dev-Doc generates the technical documentation evidence a customer’s software quality standard asks for — downloadable as Markdown or Word.
Software design description
Including an AQAP 2210 variant for defence, with every inferred statement marked for human review.
Configuration-item records
Configuration items with change history, built from the repository history.
Traceability matrix
Requirements-to-code traceability, from requirements you import (e.g. ReqIF from DOORS).
Verification & validation
Which requirements are covered by tests and results, and what evidence is still missing.
Reverse-engineered
Built from the code as it is today — for projects whose documentation was never written or has drifted.
Bring your own evidence
Import requirements from DOORS via ReqIF, and findings from your own SonarQube, Semgrep or MISRA tooling.
Runs on your own host
Deployable on premises with your own AI model, so source code and analysis stay inside your network.
Covers the technical / engineering scope only. Organisational and process evidence — quality management, non-conformance handling, supplier audits — must be supplied separately, and generated documents need human review before submission.
arc42
An arc42 document, gaps marked — never invented
The same material arranged in arc42’s 12 chapters, as one Markdown file and as AsciiDoc sources laid out for docToolchain (./dtcw generateHTML or generatePDF). Every filled part names its source and review state — generated, edited by your team, or approved.
Chapters with no source in the code, typically the runtime view and the glossary, say to be completed by the team, with arc42’s own guidance on what belongs there.
Due diligence
Ready for a buyer, an auditor or a new CTO
They read the architecture, the module map and the technology inventory without opening a source file — or receive the whole set as one package. Legacy estates (COBOL, PL/SQL, T-SQL, decades-old Java or C) are documented with the same depth as a modern web stack.
Dev-Doc is read-only: nothing is installed alongside your code and nothing is written back to the repository. Downloads never contain source code.
Talk to us about your estate
On-premises deployment, individual quotes and invoices directly from Innovirtual Software GmbH are available on request.