Docs & Code Guide

Architecture diagrams for compliance audits: what auditors actually check

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

The requirement is indirect, which is why teams get it wrong. The AICPA description criteria that govern a SOC 2 report, DC section 200, issued in 2018 with revised implementation guidance in 2022, require the system description to describe the infrastructure and software the system runs on. A diagram is how service organisations usually satisfy that, which is why practitioners ask for a system architecture diagram and often a network diagram during fieldwork. ISO 27001 wants the same material inside the scope definition. The reviewer is not judging the drawing. They are checking four things, none of them aesthetic.

Try it free
8 min readFor engineers preparing evidence before fieldwork

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

157/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The four things a reviewer is checking

Consistency with the system description. The narrative says the platform runs three services and a warehouse. The diagram has to show three services and a warehouse. A mismatch between two pieces of your own evidence is the fastest way to turn a routine review into a longer one, because it suggests neither document was produced from the system.

A note on scope while you are here: the description criteria cover the whole system, meaning infrastructure, software, people, procedures and data. The diagram carries the first two. Do not let a good diagram become the excuse for a thin narrative on the other three.

Boundaries and control points. The common access-control criteria ask you to demonstrate how access is restricted, so the diagram needs to show which resources sit in public versus private subnets, where firewalls or security groups enforce the split, and how administrative access reaches the environment. A picture of logical components with no boundary is not evidence for that criterion.

Currency, with a date on it. An undated diagram is worth very little because the reviewer cannot tell whether it describes the period under review. A date is cheap and it is the single highest-value annotation on the page.

Agreement with your other evidence. The asset inventory, the configuration export and the diagram all describe the same environment. When a resource appears in the config export and not in the diagram, that gap is what generates follow-up requests.

Why the annual redraw is the expensive path

The common pattern is to redraw everything in the two weeks before fieldwork, largely from memory and from last year file. That is precisely the condition under which errors enter: the person drawing is reconstructing rather than reading, they are under time pressure, and nothing verifies the result.

It is also the most expensive way to spend engineering time in the compliance cycle, and it repeats every year with no accumulation. Nothing built during the scramble makes next year cheaper, because the artefact starts decaying the day after it is submitted.

The alternative is to derive the picture from the same source as the infrastructure, so it is never more than a day behind and no scramble is required. For teams whose infrastructure is declared in Terraform this is straightforward, because the declaration already contains the boundaries, the subnets and the external endpoints that the reviewer wants to see.

Making a diagram evidence-grade

Date it and version it. Keep the previous versions, because an audit covers a window rather than a moment, and a question about a control in April is best answered with the diagram as it stood in April. Pinning the sync to a release tag rather than to a moving branch gives exactly that: the architecture as of the version that was actually running. See diagram versioning.

Draw the boundaries, not just the components. Zones for the VPC, the public subnet, the private subnet and anything outside your control. Label every external system, including the processors and vendors, because data leaving your boundary is where most of the follow-up questions live.

Leave secrets out. No keys, no tokens, no internal hostnames carrying credentials, no full IP allocation tables unless asked. A diagram becomes evidence, evidence circulates, and it is easier to keep it clean than to redact it afterwards.

One diagram per environment, not one diagram for everything. Production is in scope, the sandbox usually is not, and a combined picture forces the reviewer to work out which parts apply. Terraform repositories with per-environment counts make this separation easy to keep honest, since the real numbers per environment are visible rather than assumed.

Export a PNG for the evidence package and keep the live version linked for the reviewer who wants to look again. Both come from the same canvas, so the exported file and the live picture cannot disagree.

Generating it from the infrastructure repository

Connect the infrastructure repository read only through repository sync on GitHub, GitLab or Azure DevOps, and pick the branch or tag that represents what is running. For Terraform repositories every .tf and .tfvars file is parsed directly: no terraform init, no state file access, and no cloud credentials of any kind.

That last point matters twice for compliance work. The diagramming tool never holds a cloud credential that would itself have to appear in your vendor review, and the access it does hold is read-only on one repository pinned to one ref, which is a sentence you can put in a security questionnaire without qualification. The alternative, granting a diagramming tool the ability to read state or to call the cloud APIs, turns a documentation tool into an in-scope system. See Terraform diagrams without state.

What comes back is structured the way a reviewer reads: modules as zones, major resources as individual nodes with provider icons, repeated minor resources rolled into one node carrying the count, and per-environment counts preserved. Wiring is counted rather than drawn, which is the right call for evidence as well as for legibility: a role assignment or a generated password is a control detail belonging in the access-control evidence, not a box on an architecture page. The daily regeneration means the picture you submit at fieldwork is the picture that has been true all along, rather than an artefact created for the occasion.

The extract below is what a small stack produces before anything is drawn. Note the two lines a reviewer cares about most: a storage account declared once with for_each over a variable, resolved from the tfvars into a real number per environment, and the wiring counted instead of hidden.

9 declared resources + 0 data lookups + 1 registry module call across
1 stack (platform); 2 module directories. Curated to 7 nodes.
Providers: azurerm, random.
Environments (tfvars): DEV, QUAL - one deployment of every stack per environment.
State backend: azurerm.

(stack root):
  * node-storage-account-lakebase | lakebase | Storage account;
      per lakebase_projects (DEV 2, QUAL 1); account_tier Standard
  * node-vpc | vpc | Module terraform-aws-modules/vpc/[email protected]
      (registry module: one node for everything it provisions)
module lakehouse:
  * node-lakehouse-databricks-workspace | Azure Databricks workspace; sku premium
  * node-lakehouse-key-vault | Key vault; sku_name standard

Hidden wiring: 3 wiring resources not worth boxes:
  1 password, 1 role assignment, 1 key vault secret.

The diagram as of the release, not as of today

Pin the sync to the tag that was live during the period under review, and you can produce the architecture as it stood then rather than as it stands now. See keep infrastructure docs in sync with Terraform.

FAQ

Does a SOC 2 audit require an architecture diagram?

Not by name. The AICPA description criteria for a SOC 2 report, DC section 200, require the system description to describe the infrastructure and software the system runs on, and a diagram is the usual way to satisfy that, so practitioners ask for a system architecture diagram and often a network diagram during fieldwork. It has to agree with the written description and with your other evidence.

What does an auditor actually look for in the diagram?

Four things: that it matches the system description, that it shows trust boundaries and where access controls are enforced, that it is dated and current for the period under review, and that it agrees with the other evidence. Visual polish is not part of the assessment.

Should the diagram cover the audit period or the present day?

The period under review. Audits cover a window, so a question about a control in a given month is best answered with the architecture as it stood then. Keeping versioned diagrams, or pinning generation to the release tag that was running, gives you that without reconstructing anything from memory.

What should be left out of an architecture diagram used as evidence?

Secrets and anything that becomes a liability once the document circulates: keys, tokens, credentials embedded in hostnames, and detailed address allocations unless they are specifically requested. Also leave out the wiring, meaning role assignments, generated passwords and secret entries, which belong in the access-control evidence rather than on the architecture page. Keep the diagram clean from the start rather than redacting a copy later.

Can a compliance diagram be generated without cloud credentials?

Yes, when the infrastructure is declared in code. Parsing the Terraform source directly requires no terraform init, no state file and no cloud access, so the diagramming step needs nothing beyond read access to the repository. That also simplifies the vendor review, since no credential is held on the diagramming side. Counts that depend on a variable are resolved from the tfvars, so a for_each becomes a real number per environment rather than a guess.

How many diagrams should an environment have?

One per environment in scope, rather than a single combined picture. A combined diagram forces the reviewer to work out which parts apply to the audited environment, and that ambiguity produces follow-up questions that a separate diagram per environment avoids.