Use Case Guide

Giving an auditor the diagram: dated to the period, shared by link

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

An audit turns architecture documentation into evidence, and evidence has two requirements ordinary documentation does not. It has to describe the system as it was during the period under review rather than as it is this morning, and it has to reach somebody outside your company without that person becoming a member of your workspace. Both are mechanics rather than drawing advice, and both are the subject here. For what a reviewer looks for inside the picture, see architecture diagrams for compliance audits.

Try it free
7 min readFor engineering managers preparing an audit or an architecture review

See it as a diagram

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

175/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

What an auditor is actually asking for

The request usually arrives as system and data flow documentation, which sounds vague and is not. In practice it means a diagram showing the components in scope, a description of how data moves between them, and enough boundary detail that the reviewer can tell which flows leave your control. The reviewer then checks that picture against the other artefacts: the access policy, the logging paths, the monitoring evidence.

Consistency between artefacts is where audits go wrong more often than completeness. A diagram that shows an admin path the access policy does not mention creates a finding, even when both documents are individually true. Draw the boundaries first and reconcile them with whoever owns the policy before the diagram is submitted.

Say what is out of scope on the diagram itself. An explicit note that the marketing analytics estate is not in scope is a stronger artefact than a diagram that silently omits it, because the omission is the thing a reviewer will otherwise ask about.

The date on the diagram is the point

Audits look at a period, not at today. A diagram with no date attached is evidence of nothing, and a diagram that has quietly changed since the period ended is worse, because it invites a question about what else changed.

Two mechanics help here. Projects keep version history, and viewers can see the diagram and its versions, which means the auditor can be shown that the picture existed before the review started rather than being asked to take it on trust. And a repository connection can be pointed at a tag rather than a branch: connect at the release tag that was in production during the period and the generated diagram describes that release, not the one you shipped last Tuesday.

That second point is the one worth planning for. If your audit period ends at a release, connect a second project at that tag and leave it alone. It becomes the frozen artefact, while the branch-connected project keeps tracking production for everyone else.

Frozen is literal here rather than a statement of intent. Every sync begins by resolving the head commit of the ref it tracks and stops when that commit has not moved, and a tag does not move, so the daily job on an audit project never reaches the generation step at all. The figure in the audit pack in November is the same drawing that was there in July, and nobody has to remember not to touch it.

Tag, not branch

A repository connection reads a branch or a tag. Pointing an audit project at a tag gives you a diagram of a specific release that does not move under you. See repository sync.

Drawing trust boundaries so a reviewer can read them

The reviewer is looking for the crossings. A flow that stays inside one trust zone is uninteresting; a flow that carries personal data from an untrusted zone into a trusted one is the entire subject of the review. Zones make that legible: draw the boundary as a container, put the components inside it, and label every edge that leaves with what it carries and how it is protected.

For data platforms, the field level is often what gets asked about, because the question is rarely does customer data move and usually which columns and where do they end up. Column-level lineage answers that in the same artefact rather than in a spreadsheet nobody reconciles. See lineage for how that is drawn.

Mark the stores rather than describing them in a legend. A reviewer scanning a diagram for personal data should find the answer on the nodes, not three paragraphs below the figure.

Access for the auditor, and for nobody else

External auditors need to read the diagram, not to join your workspace. A view-only link opens without a sign-in, which means the audit contact can be given exactly the access they need by email with no account provisioning and no seat consumed. Turning that link on is owner-only and available on paid plans, and turning it off again stops the link immediately.

For the internal side, put the review in a restricted folder. Only people added to the folder see the projects inside, while team owners and admins retain access. Audit preparation is one of the cases restricted folders exist for, alongside acquisitions and client work under NDA.

For the written report, export the canvas as PNG or JPEG and place the figure in the document with the date and the release it describes in the caption. The caption is doing real work: it is what ties the picture to the period.

FAQ

Does using a diagram tool make us compliant with an audit framework?

No. A diagram is one piece of evidence among many, and the controls it describes are yours to implement and prove. What good documentation does is remove a class of findings caused by the picture disagreeing with the access policy or by nobody being able to say what the system looked like during the period under review.

Can we give an external auditor access without adding them to the team?

Yes. A project can be switched to a link anyone can open, which gives a view-only page with no sign-in required and no seat consumed. Turning that on is restricted to the project owner and available on paid plans, and switching it back off stops the link immediately.

How do we show the system as it was during the audit period?

Point a repository connection at the release tag that was in production during that period instead of at a branch. The generated diagram then describes that release and does not move. Version history on the project also lets a reviewer see that the diagram predates the review.

What should be on the diagram that is usually missing?

Three things: the trust boundaries drawn as zones rather than implied, a label on every flow that crosses one saying what it carries, and an explicit note about what is out of scope. Silent omissions are what generate follow-up questions.

Which formats can we put in the audit report?

PNG and JPEG exports from the canvas. Caption the figure with the date and the release it describes, because the tie between the picture and the period under review is what makes it evidence rather than an illustration.