A buyer-facing security architecture diagram should show where customer data enters, moves, rests and leaves your service, with trust boundaries marked and third parties named by role. Keep it to one page, leave out internal hostnames and credentials, and date it so reviewers know it is current.
What a reviewer is trying to learn
Reviewers read the diagram to answer a short list of questions. Where does our data live? Who can reach it? What other companies touch it? What separates one customer from another? A diagram that answers these on sight saves a call. One that looks like a marketing graphic with cloud icons and arrows invites a dozen follow ups.
OWASP's threat modeling guidance describes data flow diagrams as a common way to show the paths through a system and to highlight privilege or trust boundaries. That is also the right mental model for a buyer diagram: it is a data flow diagram, simplified for an outside audience.
What to include
- Entry points. Browser, mobile app, public API, webhooks, and any customer-installed agent or integration.
- Trust boundaries. Draw a line wherever the level of trust changes: internet to your edge, edge to application, application to data stores, your environment to a third party.
- Data stores. Name the type (relational database, object storage, cache, search index) and note where customer data rests, including backups.
- Hosting. Cloud provider and region, in plain words, because residency questions follow.
- Third parties. Show subprocessors that receive customer data, such as email delivery, error tracking or an AI model provider, and label what data goes to each.
- Tenant separation. A short note on how customers are separated, for example by tenant identifier enforced in the data layer. Keep it truthful and specific.
- Encryption points. Mark where traffic is encrypted in transit and where data is encrypted at rest.
- Admin access path. Show how your own staff reach production, for example through single sign-on and a bastion or access proxy.
What to leave out
- Internal hostnames, IP ranges, account identifiers and anything that works as a map for an attacker.
- Secrets, keys, and screenshots of consoles.
- Components you plan to build. Show what runs today. A roadmap box on a security diagram reads as a claim.
- Detail that changes weekly. A buyer needs the stable shape, not the pod count.
Level of detail
Make two versions if you must. A one page summary goes to every buyer. A deeper diagram, covering service to service calls and network segments, goes under NDA to buyers who ask for a technical session. The post on NDA gated versus public trust center documents covers how to decide which version goes where.
Keep it honest and current
Add a version date and an owner to the corner of the page. When you add a subprocessor, a region or a major data store, update the diagram in the same change. A diagram that conflicts with your subprocessor list or your questionnaire answers is worse than none, because reviewers notice the mismatch and begin to doubt other answers.
Review the diagram whenever an answer in your security answer library changes, since the two should always agree.
A simple self test
Hand the diagram to someone outside engineering, such as a sales colleague. Ask them to tell you where a customer's uploaded file goes and who else sees it. If they cannot trace it in a minute, a reviewer will not either.
For deeper background on trust boundaries, see trust boundaries in a data flow diagram explained.
Safeguard's asset discovery and dependency scanning can help you keep the list of components behind the diagram accurate, since an out of date inventory is a common reason diagrams drift.
Quick check
Should the diagram show every microservice?
No. Show the groups that matter for data handling and trust boundaries. Listing every service adds noise and exposes detail a buyer does not need.
Do I need to name my cloud provider and region?
Usually yes. Residency and subprocessor questions come next, and naming them up front saves a round trip. Say so truthfully, including backup regions.
Sources
- OWASP, Threat Modeling Process
Last reviewed: 19 October 2026.
