Regulatory audit documentation and operational runbooks have more in common than most teams realize. Both need to answer the same basic questions: what was the system doing, who made the decision, when, and what happened next. Teams that find audits least disruptive are usually the ones that already write documentation for incidents and handovers as if an external reviewer might read it later.
CRA Article 13 and Annex I Part II require manufacturers to document security properties, update mechanisms, and vulnerability handling procedures. AI Act Article 11 requires technical documentation for high-risk AI systems covering system purpose, architecture, and human oversight mechanisms. DORA Article 17 requires ICT incident logs with timestamps, classification, and evidence of the response taken. These are not separate document types — they are the same operational records, written with enough structure to survive external review.
WHAT_SURVIVES_AUDIT
Documentation that fails under scrutiny is usually documentation written primarily to satisfy an internal review process. It uses internal abbreviations, assumes prior context, and describes outcomes without explaining decisions. An auditor or incident responder coming in cold cannot reconstruct what happened. Neither can a team member who joins six months after the original author left.
Documentation that holds up is written for a reader with no ambient context: clear statements of what the system does, why a decision was made rather than just what was decided, what state the system was in at a given point, and who was responsible for each step. That sounds simple. It is not common.
"Good documentation is shared memory with structure attached."
RUNBOOKS_THAT_WORK
Runbooks fail when they skip steps that seem obvious to the author. During an incident, obvious is not available. Write runbooks with explicit verification steps, expected outputs at each stage, and decision criteria for when to proceed versus escalate. Per-environment configuration differences should be stated explicitly, not referenced from a separate system that might not be accessible during the outage.
Host staging
HostName 192.168.1.10
User deploy
IdentityFile ~/.ssh/id_ed25519_stagingA checked-in SSH config is a small example of operationally useful documentation: it reduces friction for new contributors, survives staff rotation, and does not live in a chat window that gets archived. The same principle applies to environment bootstrap sequences, rollback commands, and log query patterns.
DECISION_LOGS
For regulated systems, the most valuable document is often the one that explains why a design decision was made — not just what was built. Under the AI Act, DORA, and the CRA, you may need to demonstrate that you understood the risks of a particular approach and chose it deliberately. A short decision log entry with the date, the options considered, the reasons for the choice, and the person who approved it is worth far more than a technically accurate architecture diagram with no context attached.
- Keep common operational commands in reviewed scripts inside the repository, not in chat history that may be archived or lost.
- Write runbooks with explicit verification steps and expected outputs at each stage — not just the happy path.
- Document decisions with dates, alternatives considered, and the reasoning behind the choice — especially for security, data handling, and AI system design.
- Use
git worktreeconventions that keep urgent fixes and ongoing feature work in clearly separated contexts.
CONTROL_INVENTORY_STRUCTURE_FOR_REGULATED_SYSTEMS
A control inventory is the document that maps each regulatory requirement to the technical or procedural control that addresses it, the evidence that the control is operating, and the owner responsible for maintaining it. Under the CRA, AI Act, and DORA, this is not a theoretical exercise — it is the backbone of a conformity assessment or supervisory examination. Teams that have this document before they need it find audits substantially less disruptive than teams that produce it reactively.
The inventory structure that holds up under scrutiny maps requirements at the article level, not the regulation level. "CRA: security requirements" is not a useful inventory entry. "CRA Article 13(1): no known exploitable vulnerabilities at time of placing on market — Control: static analysis in CI pipeline, weekly dependency scanning, quarterly penetration test, Evidence: CI pipeline reports, SBOM, pentest report archive" is a useful entry. The difference is specificity: the second form tells an auditor exactly what to look for and where.
The hardest part of maintaining a control inventory is keeping it current after the initial build. Controls change: new tools replace old ones, process changes affect evidence collection, ownership changes when people leave. A control inventory that was accurate at the point of initial compliance work but has not been updated since is worse than no inventory in some circumstances — it creates false confidence and will fail a cross-reference check against actual current practice.
- Map requirements at the article and clause level, not the regulation level. Regulators examine at that granularity; your inventory needs to match.
- Include evidence location for each control — not just that evidence exists, but where it is stored, in what format, and how far back it goes.
- Assign a named owner to each control entry. Entries without owners go stale. The review cadence for each entry should match the rate at which that control area changes.
- Review the inventory after every significant change to the system, team, or toolchain — not just on an annual calendar cycle.
INCIDENT_RECORDS_THAT_MEET_THE_REGULATORY_STANDARD
DORA Article 17 requires ICT-related incident records with timestamps, classification rationale, evidence of the response actions taken, and the outcome. The practical standard for what survives regulatory review is: a timeline with UTC timestamps, a classification entry that explains why the incident met or did not meet the significant incident threshold, a record of each response action with the actor and the time, and a final summary that documents the root cause and remediation.
The classification record is often missing because it feels redundant when the incident clearly does or clearly does not meet the threshold. Under regulatory scrutiny, the documentation of a reasoned classification is what demonstrates that the team is operating the process, not just generating records. An unclassified incident log — even a detailed one — leaves an examiner to infer that the classification was never made, which is a process deficiency regardless of the outcome.
The final summary is where most incident records are weakest. It tends to either describe what happened technically without explaining the root cause in terms that connect to future prevention, or to describe the customer-facing impact without the technical detail needed to verify that the remediation addresses the actual failure mode. A useful final summary states the root cause, explains why existing controls did not prevent it, and describes the specific changes made to prevent recurrence — with enough technical specificity that the changes could be verified independently.