Illustration and Visual Design Guide

A browser asks an API to export a tenant’s analytics. The API sends a job to a queue; a worker reads customer data and writes an archive to object storage. A diagram of those five components may be accurate and still conceal the one fact a security reviewer needs: whether the worker can read or write an object outside the requesting tenant.

A security visual earns its place when it makes such a decision possible. It should expose the identity that crosses a boundary, the point that enforces policy, the data that moves, the failure that becomes observable, or the next safe action. The governing rule is simple: specify the reader action first, then draw only the structure needed to support it.

Begin with the question the picture must answer

For the export path, the question is precise:

Can an export job ever read or write objects outside the requesting tenant?

That question gives the visual a reader, a moment, and a test. A reviewer must be able to follow tenant authority from the user request to the archive. If the picture cannot support that trace, adding color or icons will not improve it.

Before choosing a format, complete this sentence:

After studying this visual, the reader can ______ without reopening the surrounding text.

Useful completions name one decision or execution task:

• choose between session, token, and workload identity flows;
• identify every trust-boundary crossing in a request path;
• locate the control that stops cross-tenant access;
• rehearse the order of containment, evidence preservation, eradication, and recovery;
• explain which normal engineering artifact proves a control operates.

“Understand the architecture” cannot be tested. Narrow it until another reader can demonstrate recall. One visual should usually teach one primary model. If it asks the reader to compare controls, trace an attack, and operate an incident at once, split it. The same applies when its labels cannot survive a phone or printed page.

The task determines the form. A lifecycle map is useful when the reader must locate owners, gates, feedback, and exceptions. A decision tree can expose a default, rejection conditions, and escalation path. An attack path follows preconditions, boundary crossings, privilege, control opportunities, and signals. A timeline makes ordered actions and handoffs visible under pressure. An evidence map connects a requirement to implementation, verification, and a bounded assurance answer.

Sometimes the right visual is no visual. Use a matrix when simultaneous comparison across shared attributes is the work. Use a numbered runbook when the reader needs an exact command sequence. Boxes and arrows are not a measure of completeness.

Give the export path security meaning

The first draft already contains browser, API, queue, worker, and storage. Keep that useful skeleton, then add meaning in the order a reviewer needs it.

Mark the boundaries

Label the user identity and tenant claim where the browser request enters the service. Mark the public-to-edge boundary and the service-to-worker boundary. The queued job must carry a tenant-bound authorization context, not merely an object identifier supplied by the caller. The worker must appear with its own workload identity; drawing it inside a trusted box does not grant it the requester’s authority.

At object storage, show the tenant prefix, bucket, or other isolation boundary that the design actually uses. Name the assumption that changes at each edge. A dashed rectangle labelled only trust boundary says that trust changes somewhere, but not what the reviewer should challenge.

Each meaningful crossing should identify the actor and effective identity, the request or data object, its direction, and its classification when that affects the decision. Include the protocol only when its properties change the control. A response may follow a different trust path from its request; draw that path when the difference carries risk.

Put controls where they act

The API checks whether the requester may create an export for the named tenant. The worker then performs the final tenant and replay decision before reading source data or allocating an archive. Storage policy constrains the worker’s identity to the permitted tenant location. Put each control on that component or transition. A floating shield cannot tell a reviewer what is enforced or what happens when enforcement is unavailable.

Show dependencies that can change the answer. If the worker consults a policy service, connect the decision point to the enforcement point and name failure behavior: deny, use a bounded and versioned cache, or enter an explicitly approved degraded mode. Authentication and authorization need separate labels; so do logging and alerting, encryption and key authorization, and backup creation and tested restoration. Similar-looking controls answer different questions.

Draw the failure that tests the design

Now trace a hostile request: a valid user supplies another tenant’s object identifier. If the API checks only that the user may create exports, the job can enter the queue. If the worker trusts that admission or holds overbroad storage permission, the cross-tenant read succeeds.

The useful visual shows where the attempt stops and what remains if an earlier check fails. It also shows the time-bound exception path, if one exists, and prevents that path from silently bypassing tenant scope. A happy path alone cannot support a security review because it hides denial, dependency failure, degraded operation, and recovery.

Connect the claim to evidence

Link the enforcement points to the artifacts that challenge them: cross-tenant negative tests for the API and worker, the deployed storage-policy version, denial events, and an alert for repeated tenant mismatches. These links do not turn the diagram into evidence. They show where a reviewer can verify its claims.

Use different line treatments for runtime data, policy decisions, telemetry, and human approval or exception flow. Give each a label and explain the grammar in a legend. When every relationship uses the same arrow, a reader can easily mistake an alert for prevention or an approval for runtime authority.

The components in the export system have not changed. The revised picture now supports a trace from requester to archive, an attack from forged identifier to enforcement, and a review from control to negative test and operating signal. That is the difference between depicting a system and explaining its security.

Specify the visual before rendering it

Copy this record into an issue, design document, asset request, or review record. Delete fields that genuinely do not apply rather than filling them with vague language.

# Security Visual Specification

- Visual ID:
- Working title:
- Owner:
- Intended reader and moment:
- Reader decision or execution task:
- Five-minute retention target:
- Mistake this visual prevents:
- Visual type:
- Intended placement and display size:

## Required Content
- Actors:
- Identities:
- Assets and data classifications:
- Trust zones and boundaries:
- External dependencies and third parties:
- Enforcement points and controls:
- Logs, alerts, and evidence:
- Exceptions or degraded modes:
- Failure path or attacker path:

## Visual Grammar
- Runtime data flow:
- Policy or control decision:
- Telemetry flow:
- Human approval or exception:
- Active, blocked, degraded, and recovered states:

## Acceptance
- Question a reader must answer:
- Facts that must remain legible on mobile:
- Facts that must remain legible in print:
- Technical reviewer:
- Accessibility reviewer:
- Last verified against system version/date:

The specification is stricter than a drawing prompt because the teaching contract should survive a change of rendering tool, style, or asset file. The visual type should follow the reader’s job, not the producer’s favorite tool.

Make meaning survive the rendering

Labels carry the primary meaning. Color, shape, and iconography reinforce those labels; they do not replace them.

Apply these rules consistently:

• Give every actor, service, store, boundary, control, and external dependency a specific name.
• Label arrows with the request, data, decision, or signal they carry.
• Use arrowheads and a legend; line proximity alone does not prove direction.
• Pair color with a second cue such as line style, shape, symbol, or state word.
• Keep text large enough for the asset’s smallest intended display.
• Preserve generous whitespace around trust boundaries and crossing labels.
• Put the most important decision path first in reading order.
• Use stable icon meanings across a book or system. Do not let the same shield mean authentication in one image and monitoring in another.
• Write alt text that states the relationships a sighted reader learns, not merely the visual appearance.
• Use captions to reinforce the recall rule or decision, not repeat the title.

For a complex architecture, use two coordinated images instead of a wall chart: an overview that establishes zones and ownership, then a focused flow that teaches the critical decision or failure path.

Several familiar shortcuts should stop a review. A lock icon suggests protection without locating enforcement. Anonymous arrows conceal identity, data, and direction. Unexplained boundary boxes become wallpaper. A product inventory substitutes vendors for the control model. Many colors without a stable legend create false distinctions. A control with no test or operating signal asks the reader to trust a claim. Correct the missing meaning before refining the visual style.

Review it without the prose

Give the rendered visual to someone who matches the intended reader. Hide the surrounding explanation and ask the original question. For the export example, the reader should be able to identify the effective identities, tenant boundaries, final enforcement point, dependency-failure behavior, forbidden path, and evidence links without guessing.

Review has failed if the reader mistakes monitoring for enforcement, overlooks a third party, or cannot tell what happens when an assumption breaks. The decisive test is behavioral: can the reader make the choice, perform the sequence, or locate the control correctly?

Then inspect the production details:

• labels remain readable at the smallest intended mobile and print sizes;
• arrows retain direction and their meanings remain distinct without color;
• the caption reinforces the decision or recall rule rather than repeating the title;
• alt text states the important relationships, sequence, and outcome rather than inventorying visual appearance;
• every technical label, boundary, and control agrees with the reviewed system.

Maintain the claim, not merely the file

Treat security visuals as versioned engineering artifacts.

• Store the source specification with an owner and review trigger.
• Use descriptive, stable filenames and meaningful alt text.
• Review diagrams when trust boundaries, identities, critical dependencies, data classifications, control ownership, or failure behavior change.
• Link a diagram to the system or control version it describes when confusion would create risk.
• Keep a previous version only when it supports incident evidence, audit history, or an architectural decision record.
• Test rendered assets at the actual mobile and print widths; a technically correct image with unreadable labels has failed production.

AI-generated raster visuals need the same technical review as manually produced assets. Inspect every label, arrow, boundary, icon meaning, and implied control. Regenerate or correct an image that invents components, changes terminology, or makes enforcement ambiguous.

The artifact is ready when a representative reader can answer its governing question without nearby prose and a technical owner can trace every important claim to the current system. Visual polish cannot supply either form of proof.