When an auditor asks why the system is built this way
Audits rarely fail on the decision. They fail on the absence of a record of the decision — and a record assembled after the question is asked reads exactly like what it is.
The situation
A regulator, an internal audit function or a customer security review wants to know why the architecture is the way it is: what alternatives were considered, what risks were accepted and by whom, whether the design was reviewed before it shipped.
The answers exist, distributed across people, tickets and old chat threads. Reconstructing them takes weeks and produces something with no dates on it, which is the part the auditor notices.
The only way this is cheap is if the record accumulates as a by-product of doing the work. That means the decisions, the risks and the approvals live with the model rather than in a separate document written for the audit.
You are here if
- You have been asked for design rationale and are reconstructing it from memory.
- Risk acceptance was verbal and nobody recorded who accepted it.
- The current diagram exists but there is no record of what it looked like at the time of the decision.
- The evidence pack is rewritten from scratch for every audit.
How the work gets done
Record risks against what they are risks to
A risk register in a separate spreadsheet is disconnected from the architecture by construction, and reconnecting the two is most of the work in an audit. Record risks against the components they concern, so the connection is not something anyone has to rebuild.
The same applies to non-functional requirements: the requirement and the component meeting it belong together.
Arch ▸ Suggest risks from diagramArch ▸ RepositoryArch ▸ Tech Debt Report
Keep the version the decision was made against
An auditor asking about a decision from 2023 is asking about the design as it stood in 2023. Version history is what makes that answerable, and it costs nothing to have if the model is where the work happens.
Diagram ▸ Version historyDiagram ▸ Branches
Make approvals evidence rather than recollection
An approval workflow records what was approved, by whom and when. That triple is the substance of most architecture audit findings, and it is not reconstructable after the fact with any credibility.
Diagram ▸ Approval workflowDiagram ▸ Team & collaborators
Be able to hand over a pack
Auditors want documents. Export the model and its supporting records into something that can be handed over, rather than granting access to a tool and hoping.
The point is that the pack is generated from the live record instead of being written separately — which is what stops the evidence and the system from disagreeing.
Diagram ▸ Export CenterDiagram ▸ DocumentsDiagram ▸ PDF
What you end up holding
- Risks and non-functional requirements recorded against the components they concern.
- Version history showing the design as it stood when each decision was made.
- Approval records naming version, approver and date.
- An exportable pack generated from the live model rather than written for the audit.
Not this, if
- The audit is about controls in running systems — access logs, patch levels, data residency in practice. This evidences design and decisions, not operations.
- You need a certified compliance product for a specific framework. This produces the architecture evidence; it does not attest to a standard.
- The decisions were genuinely never made deliberately. Tooling will not retrofit a rationale, and an audit is not the moment to invent one.