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

The problem: documentation drifts, code moves on

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 can write once. The evidence you have to keep producing, release after release, as the code changes underneath it.

In most teams the documentation is written once, near a release, and then rots. Six months later the architecture has moved, dependencies have changed, and the security design document describes a product that no longer exists. An auditor does not need to be hostile to find that gap — it is the first thing a careful review surfaces. The usual response is to throw manual effort at re-documenting before each audit, which is expensive, morale-sapping, and still produces a snapshot that is stale by the next sprint.

Step one: turn the standard into a policy the machine can read

The starting point is to convert IEC 62443-4-1 from a PDF you interpret in meetings into a structured SDLC policy in a format both people and models read natively — Markdown. Each of the standard’s eight practices becomes 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 is your interpretation of the standard, written down as plain, versioned text.

Markdown is not an aesthetic choice. Plain text is diffable, so every change to the policy is reviewable in a pull request. It lives inside the repository rather than a document management system nobody opens. And large language models read it without any conversion step, which matters 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.

Step two: keep the policy next to the code and artifacts

Store the SDLC policy — and the documentation generated from it — in the same Git or Azure DevOps repositories as the product itself. The point is 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.

• 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 — GitHub Actions or Azure Pipelines definitions, which are themselves 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.

Step three: prepare the human context before the AI writes a word

This is the step teams skip, and it is the one that decides whether the output is trustworthy. Before anything is generated, humans prepare 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 you have consciously accepted. The code shows what was built; only people can record why, and an auditor cares about both.

Reviewers also define, up front, what "good" documentation looks like for each practice — the questions it must answer, the evidence it must cite. That specification is what the AI generates against, and it is what a human checks the output against afterwards. The generation is automated; the judgement is not.

Step four: generate the documentation, then let CI keep it current

With the policy, the context, and the artifacts all in the repository, the AI can generate SDLC documentation for each product that is aligned to the actual code — because it is derived from the actual code. The result describes the product as it is now, not as it was at the last manual write-up.

The real gain comes from automating this in the pipeline. A GitHub Actions workflow — or the equivalent Azure Pipeline — can regenerate or update the affected documentation whenever code changes, so the docs move in lockstep with the software rather than drifting behind it.

• On each pull request, regenerate the documentation for the parts of the product that changed.
• 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.

Beyond documentation: AI that acts on the policy

Once the SDLC documentation exists as structured, current text sitting next to the code, it becomes an input for more than reading. The AI can use the policy and the generated documentation together to do the work they describe: implement a security requirement that the policy demands but the code is missing, draft the remediation for a finding in the threat model, or propose the fix for a gap the pipeline flagged. The documentation stops being a dead artifact filed away for auditors and becomes an operational source the development process actually runs on.

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

Why this satisfies the CRA and IEC 62443-4-1

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. The question both of them come down to is the one that is hardest to fake: prove that your documentation reflects what you actually built and ship today.

Generating the documentation from the repository under CI makes 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 — Git 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.

The bottom line

The failure mode of SDLC documentation is drift: it is true on the day it is written and slowly stops being true. Policy as code, AI generation, and CI flip that around — documentation derived from the code, reviewed by people, and kept current automatically. That 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.