See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
Auditors sample accuracy and check review dates
An ISO 27001 audit treats documentation itself as a controlled object: clause 7.5 requires documented information to be reviewed, approved and kept adequate, which in practice means your architecture docs carry owners, review dates and versions, and the auditor checks them. SOC 2 fieldwork is more concrete: the auditor asks for the current network and architecture diagrams as evidence, then samples claims against the environment. A diagram showing a VPC that was retired, or missing the new data store that holds customer data, is not a cosmetic issue, it is evidence that change management is not connected to documentation, and it invites deeper sampling everywhere else.
The inversion worth internalizing: for most teams stale docs cost onboarding time, for security docs they cost audit findings. That converts freshness from a virtue into a control requirement with a date on it.
The threat model is only as good as its data-flow diagram
STRIDE-style threat modeling enumerates threats per element of a data-flow diagram: each external entity, process, data store, data flow and trust boundary gets its threat categories walked. The arithmetic is unforgiving: a flow that is missing from the diagram gets zero threats enumerated, so every undocumented integration added since the last modeling session is an unexamined attack path. The threat model does not decay on its own schedule, it decays exactly as fast as the DFD under it.
This is why the DFD is the security doc to put the tightest loop on: it is upstream of the threat model, the pen-test scoping, and half the audit evidence. When a change adds a flow or crosses a trust boundary, the DFD update is the trigger for re-running the affected part of the threat model, not an afterthought to it.
Wire the update loop to the changes that matter
The triggers for security docs are narrower than for general architecture docs, which makes the loop easier to build: merges touching network or IAM modules in the IaC, a new vendor or data store entering the environment, and any change that adds a data flow or moves a trust boundary. Encode the review state in the docs themselves and the enforcement in the repo, so a network change cannot merge without the security reviewer who owns the affected document seeing it.
# Front matter every security doc carries; the auditor reads these fields --- owner: security-team last_reviewed: 2026-08-01 next_review_due: 2026-11-01 evidence: dated diagram export attached --- # CODEOWNERS: network and IAM changes cannot merge without security review /terraform/network/ @acme/security-team /terraform/iam/ @acme/security-team /docs/security/ @acme/security-team
Private material: regenerate on merge, export dated evidence
One Datadef mechanic changes for this page. Live embeds, the image URLs that follow the diagram within minutes, exist only for projects shared public, and a security architecture diagram is usually the last thing you make public. So the loop for security docs drops the live embed and keeps everything else: the diagram lives in a private Datadef project, an agent connected to the Datadef MCP server, registry name io.datadef/mcp, updates it from the IaC after the merges that match the triggers above, and the documents that need a copy get a dated export.
The export step, which looks like a downgrade, is actually what the audit wants: point-in-time evidence. A diagram export named and dated per review cycle gives the auditor exactly the artifact trail that clause-7.5-style document control asks for, with the regeneration loop guaranteeing the content was true on the date it carries. Datadef does not watch the repository, the regeneration is an agent call or CI step, and agent API keys belong to the paid plans. For the topology content itself, the general loop is in keep network diagrams up to date.
The audit-week test
Cadence, ownership, and the docs around the diagram
Event triggers catch changes; a review cadence catches everything else, and for security docs the cadence is part of the control. Quarterly review of the DFD, network diagram and threat model with the review date updated even when nothing changed is what makes the front-matter dates honest, and documentation review cadence covers how to size that without ritualizing it. The runbook side of security operations decays the same way with worse timing, which stale runbooks as incident risk takes up.
Scope note: this loop keeps the diagrams current. Policies, procedures and the prose of the threat model are documents your team writes and reviews; Datadef does not sync prose, it keeps the picture under those documents matching the environment they describe.
FAQ
What security documentation do SOC 2 auditors actually check?
How often should security architecture documentation be reviewed?
Can I use live diagram embeds for security documentation?
Why does a threat model need a current data-flow diagram?
What should trigger a security documentation update?