Let AI write your IEC 62443-4-1 SDLC documentation — and keep it true to the code

What I kept seeing: documentation drifts, code moves on

The thing that struck me, team after team, is that IEC 62443-4-1 asks for two things that pull in opposite directions: a defined process, and evidence that the process was actually followed for each product. The process you write once. The evidence you have to keep producing, release after release, while the code shifts underneath it. I saw a lot of teams nail the first and quietly lose the second.

The pattern was almost always the same. Someone wrote the documentation near a release, and then it rotted. Six months on, the architecture had moved, dependencies had changed, and the security design document described a product that no longer existed. I never needed a hostile auditor to find that gap — it was the first thing any careful review surfaced. And the usual response, throwing manual effort at re-documenting before each audit, only ever produced a snapshot that was stale again by the next sprint. It was expensive, it drained people, and it never actually fixed the problem.

Where it started: writing the policy in a form the machine can read

The teams that got this right all started in the same place. Instead of interpreting the IEC 62443-4-1 PDF in meetings, they wrote their own structured SDLC policy in a format both people and models read natively — Markdown. Each of the standard’s eight practices became an explicit set of expectations: what a secure requirement looks like here, what the threat-modelling step must cover, what a release gate has to check, how security issues and updates are handled. It was their interpretation of the standard, written down as plain, versioned text. The policy documents the organisation's own development processes in its own words. IEC publication content must not be supplied to AI tools without the permission required by the applicable IEC licence terms.

I used to think the format was a detail. It is not. Plain text is diffable, so every change to the policy is reviewable the same way a code change is. It lives inside the repository rather than in a document management system nobody opens. And models read it without any conversion step, which turns out to matter for everything that follows. This is "policy as code" in the literal sense: the compliance intent sits in the same version control as the software it governs.

What made it work: the policy living next to the code and artifacts

The teams where this stuck kept the SDLC policy — and the documentation generated from it — in the same version control as the product itself. What I saw pay off was the proximity: when the policy, the source code, the build artifacts, and the SBOM all live in one place, both the AI and a human reviewer can see them together and reason about them as one system, instead of chasing evidence across five tools.

• The policy — your IEC 62443-4-1 interpretation as Markdown, versioned like any other source file.
• The product source — the code the documentation is supposed to describe.
• The build and CI configuration — the pipeline definitions themselves, which are already evidence of the process.
• The artifacts — SBOM, dependency and code-scan outputs, test results.
• The generated SDLC documentation — the output, sitting beside the inputs it was derived from.

The step teams skipped: preparing the human context first

This is the step I watched people skip, and it is the one that decided whether I trusted the output. Before anything was generated, the good teams prepared the context the code cannot supply on its own: the product scope and boundaries, the threat-model assumptions, the architectural decisions and the reasons behind them, the risks they had consciously accepted. The code shows what was built; only people can record why — and in my experience an auditor cares about both, often the why more.

They also defined, up front, what "good" documentation looked like for each practice — the questions it had to answer, the evidence it had to cite. That specification was what the AI generated against, and it was what a human checked the output against afterwards. The generation was automated; the judgement never was. Where I saw teams blur that line, the trust went with it.

Where the drift finally stopped: letting CI keep it current

With the policy, the context, and the artifacts all in the repository, I watched the AI generate SDLC documentation for each product that was actually aligned to the code — because it was derived from the code. For the first time the documentation described the product as it was that day, not as it had been at the last manual write-up.

But the real change came when teams automated this inside their pipeline. Whatever CI system they used, a workflow can regenerate or update the affected documentation whenever code changes, so the docs move in lockstep with the software rather than drifting behind it. That was the moment "keep it current" stopped being a promise people made before an audit and became something that simply happened on every merge.

• On each change, regenerate the documentation for the parts of the product that moved.
• Diff the result against the policy and flag anything that no longer satisfies a practice.
• Surface the gaps as review comments, so they are caught at merge time, not audit time.
• Require a human reviewer to approve before the updated documentation is committed.
• Keep the whole history — every generation tied to a commit — as a timestamped evidence trail.

Where it surprised me: AI that acts on the policy

What I did not expect was how the documentation changed once it existed as structured, current text sitting next to the code. It stopped being something you only read. The teams furthest along used the policy and the generated documentation together to do the work they described: implement a security requirement the policy demanded but the code was missing, draft the remediation for a finding in the threat model, propose the fix for a gap the pipeline flagged. The documentation stopped being a dead artifact filed away for auditors and became something the development process actually ran on.

The same discipline applies here, only more strictly — and this is where I have seen people get burned. Security-relevant changes are exactly where an unreviewed AI edit does the most damage, so the human gate is not negotiable: the AI proposes the requirement or the remediation, and an engineer owns the decision to merge it. Used that way, I watched the loop close — the policy drives the documentation, the documentation drives the fixes, and the fixes are evidenced back into the same record.

Why I think this supports CRA and IEC 62443-4-1 evidence

IEC 62443-4-1 wants a defined process and per-product evidence that it was followed. The CRA, in Annex I, wants security processes that are documented and maintained across the support period, plus technical documentation that stays accurate. In the end they both come down to the one question that is hardest to fake, and the one I saw sink the most audits: prove that your documentation reflects what you actually built and ship today.

Generating the documentation from the repository under CI is the only approach I have seen make that proof a byproduct of development rather than a separate project:

• Defined process — the policy-as-code is the definition, versioned and reviewable.
• Per-product evidence — generated documentation lives in each product’s own repository.
• Kept current — CI regenerates on change, so "maintained" is automatic, not a promise.
• Traceable — version history ties every version of the documentation to the commit it describes.
• Human accountability — the review gate records who approved what, which is what an auditor ultimately asks for.

What I take from it

The failure mode of SDLC documentation is drift: it is true on the day it is written and slowly stops being true. Everything I have watched work flips that around — documentation derived from the code, reviewed by people, and kept current automatically. What stayed with me is that this is not just less work at audit time. It is better evidence, because it was never allowed to fall out of date in the first place.