Keep compliance documentation and technical evidence aligned with the software

Audit preparation is mostly archaeology

The week before fieldwork has a shape everyone recognises. Someone pulls the technical documentation, discovers it describes the system as of a release two quarters ago, and starts reconstructing the current version from the code — which is precisely the work that documentation was supposed to have saved.

That cost is paid by the most expensive people in the building, repeatedly, on a cycle set by somebody else's calendar. And it's paid twice: once to assemble the evidence, and once more when a reviewer asks how the team knows the document reflects what's actually running. Usually it doesn't, and usually the honest answer is that someone checked by hand last Tuesday.

The obligation sits on you, not on your tools

Worth stating plainly, because it determines what a documentation platform can and cannot do for you.

No compliance regime certifies documentation generators. Where a framework requires technical documentation, the obligation falls on the organisation building the product — the manufacturer, the provider, the certified entity. Your auditor assesses you. A tool's job is to produce an artifact your process consumes, and any vendor claiming more than that is selling you a liability.

So the useful question isn't "is this tool compliant." It's "does this produce evidence that is current, attributable, and defensible when someone asks where it came from."

Where current technical documentation is actually required

The frameworks differ enormously in scope, but they converge on a requirement that the documentation describe the system as built and stay that way.

• ISO/IEC 27001 clause 7.5 and SOC 2. Both require that documented information is controlled — identified, reviewed, version-managed, and available where it is needed. A record of what each page was derived from and when is control evidence that exists continuously, rather than a screenshot captured during fieldwork.
• EU Cyber Resilience Act. Annex II requires information and instructions that allow secure installation, operation and use. Annex VII requires technical documentation held at the disposal of market surveillance authorities. Reporting obligations have applied since 11 September 2026; the regime applies in full from 11 December 2027. The obligation is the manufacturer's.
• EU AI Act Annex IV. Technical documentation for high-risk systems, obligated on the provider, with the same as-built requirement.
• FDA § 524B. Premarket cybersecurity documentation for medical devices, obligated on the device maker, and documentation-heavy by design.

What's new about the CRA in particular is that documentation accuracy stops being a quality preference and becomes a legal obligation with a regulator behind it. That tends to move the budget line, and the owner, out of the docs team.

What Git2Docs actually contributes

• Technical documentation derived from the implementation — architecture, dependencies, data flows, interface surface — rather than from someone's recollection of the design review.
• Regeneration on every push, so the gap between the document and the system has no time to open up between audits.
• A record of derivation. Generated pages carry their origin in frontmatter — code-derived and validation-filtered — which is the attributability question every assessor asks.
• Coverage against the real surface, which answers "how do you know this is complete" with a measurement instead of an assurance.
• Executed examples. Documented commands and calls are run against your live deployment and mismatches reported, so "the documentation is accurate" is a tested claim about at least that part of it.
• Authored content alongside it. Policies, procedures and rationale are written by people and persist through regeneration. Only the derived material is rewritten.

What this looks like in practice

1. Identify the evidence that is derivable. Architecture, interfaces, dependencies, configuration, data flows. Anything you currently rebuild from the code before an audit is a candidate.
2. Connect the repository and generate, then compare the result against the documentation your last audit relied on. That delta is worth showing to whoever owns the control.
3. Keep the non-derivable evidence where it belongs. Policies, risk assessments, approvals and training records aren't in your source and shouldn't be pretended into it.
4. Agree with your auditor what the generated artifact covers before fieldwork, not during it. The conversation is easier when the document is already current.
5. Send the link instead of the export. The point is that the evidence doesn't need a preparation sprint to become true.

What we don't claim