Cloud footprint diagram: what a security review needs to see

Reviews that start with control questions produce answers about the systems people remember. The estate that causes incidents is the part nobody mentioned: the account created for a proof of concept in 2024, the region enabled for a customer that churned, the storage bucket a data science team provisioned outside the platform.

So the first artefact is an inventory made visual. Which accounts or subscriptions exist and what each is for, which regions are in use, what has a public endpoint, and where personal data comes to rest. Everything else in the review hangs off that, including the parts you decide are out of scope.

Environment counts belong on the diagram rather than in a footnote. Ten of something in a development account and one in production is a different risk profile from the reverse, and reviewers who only see component names cannot tell which situation they are in.

Console screenshots age in hours and require the access that a reviewer usually cannot be given. Infrastructure code is the better source: it is what will be deployed next time, it is readable with a scoped read-only token, and it is versioned, so the diagram can describe a specific commit rather than a moment.

On a Terraform or OpenTofu repository, Datadef parses every .tf and .tfvars file directly. There is no init, no plan, no state file access, and no cloud credentials involved at any point. That sentence is usually what gets the connection approved, because it means the documentation tool has strictly less access than the reviewer does.

The parse keeps the structure the platform team already chose. Modules become zones, resources keep their real names and provider icons, repeated minor resources roll up into a single node carrying the count, and registry modules that cannot be expanded from your repository are drawn as one node with their source and version, which is exactly the detail a reviewer needs to check a known advisory. See Terraform diagrams without state.

State one limit before a reviewer assumes otherwise: this is an architecture diagram, not an IAM map. Resource types classified as wiring rather than architecture, role assignments, key vault secrets and access policies, group memberships, service principal roles, are counted and never drawn as boxes, because a canvas holding fourteen role assignments stops being readable as architecture. Data lookups are filtered the same way: a data block that anchors something real, an existing storage account or database being wired up, becomes a node, while a lookup that only fetches an id does not. If the question under review is who can reach what, the artefacts are the module reference table in the generated document and the .tf files themselves, not the canvas.

The subject of a security review is not the components, it is the crossings. A flow that stays inside one trust zone is background; a flow carrying personal data from an untrusted zone into a trusted one is the finding. Drawing boundaries as containers and putting components inside them makes that legible without a legend.

Label every edge that leaves a zone with what it carries and how it is protected. Unencrypted flows crossing a boundary and flows carrying sensitive data from untrusted to trusted are the two patterns worth making visually obvious, because they are the two a reviewer will look for first and the two most likely to be described inaccurately in prose.

Mark the resting places, not just the paths. A reviewer scanning for personal data should be able to find every store that holds it on the diagram, since data at rest and data in transit are separate control questions and a single picture can answer both.

A footprint diagram is a map of where to attack, which makes its own access control part of the exercise. Put the review in a restricted folder inside the team workspace: being a team member is no longer enough to see the projects inside, only people explicitly added to the folder can, while team owners and admins keep access. Security review is one of the cases restricted folders were built for.

Do not make this project publicly viewable. Public links are the right tool for onboarding diagrams and client deliverables and the wrong tool here, since anyone with the URL can open a view-only page without signing in. For the written report, export PNG or JPEG and control the document instead.

Team workspaces hold up to 5 seats and count pending invitations against that number, so a review that brings in an external consultant is usually better served by inviting them to the single project than by giving them a workspace seat that a team member then loses.

• Keep security architecture docs current
• Terraform diagrams without state or init
• Repository sync documentation
• Team workspaces and folders
• Documentation audit checklist