Security diagram
A fictional visual model that explains systems, identities, services, trust boundaries, data flows, controls, evidence sources, risks, owners, decisions, or recovery states.
High School IntermediateModule I17Lesson 4 of 8Diagram Builder
I17.4 Creating a Security Diagram
Create clear fictional security diagrams that explain architecture, data, identities, evidence, controls, trust boundaries, ownership, risk, recovery, uncertainty, and validation without exposing real systems or private information.
Lesson Progress
Creating a Security Diagram
High School Intermediate • I17: Intermediate Capstone and Portfolio • Lesson 4 of 8
50% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Diagram Can Look Correct while Telling the Wrong Story
A fictional diagram shows a supplier identity connected directly to confidential storage because two alerts happened during the same shift. The visual is polished, but no shared identity, session, or access record supports the relationship. Diagrams can create certainty faster than prose, so every node, boundary, arrow, control, risk, and status should have a purpose and evidence basis.
Weak diagram
Add plausible systems, use unlabeled arrows, hide uncertainty, omit boundaries, rely on color, draw controls as effective, and expose real architecture.
Professional diagram
Define the question, choose the right diagram type, cite evidence, label flows and boundaries, mark unknowns, show owners and control state, validate meaning, and protect privacy.
Objective 1
Define a fictional security-diagram purpose, audience, scope, question, systems, identities, data, services, suppliers, evidence sources, trust boundaries, privacy rules, assumptions, and review standard.
Objective 2
Choose the correct fictional diagram type for architecture, data flow, identity paths, evidence flow, incident sequence, control mapping, ownership, risk, or recovery.
Objective 3
Represent fictional systems, users, services, networks, cloud resources, suppliers, controls, evidence sources, boundaries, flows, risks, owners, and limitations with clear labels and a consistent legend.
Objective 4
Distinguish fictional architecture facts, inferred relationships, unknown connections, control states, evidence sources, risk points, owner responsibilities, and validated outcomes.
Objective 5
Create a complete fictional security-diagram package with a project brief, source register, legend, primary diagram, annotations, evidence references, reviewer notes, accessibility review, revision history, and portfolio-safety statement.
Why This Matters
Visuals Shape Technical and Leadership Decisions
Fictional diagrams help analysts understand flows, help service owners see dependencies, help leadership see risk and ownership, help recovery teams coordinate state changes, and help portfolio reviewers understand the student's reasoning. An inaccurate visual can also misdirect all of those decisions.
Core Concept
Use the Question–Evidence–Model–Review–Explain Process
Question
Which fictional decision, learning claim, audience, scope, and time window should the diagram support?
Evidence
Which fictional records prove the systems, identities, flows, boundaries, controls, owners, risks, and outcomes?
Model
Which diagram type, symbols, arrows, boundaries, annotations, and hierarchy communicate the answer clearly?
Review
Are fictional relationships accurate, uncertainty visible, labels consistent, controls stateful, and privacy protected?
Explain
Can the student defend every important node, line, risk marker, evidence reference, limitation, and revision?
Key Vocabulary
Security Diagram and Visual-Evidence Terms
Diagram purpose
The fictional question the visual must answer for a specific audience and decision.
Scope boundary
The fictional systems, identities, services, suppliers, data, time window, and evidence included or excluded from the visual.
Trust boundary
A fictional line where identity, ownership, network, security policy, administrative authority, or data-handling expectations change.
Data flow
A fictional movement of information between users, systems, services, applications, networks, suppliers, or storage locations.
Identity path
A fictional route through which a user, role, group, service account, supplier identity, or application gains access.
Control point
A fictional location where authentication, authorization, filtering, validation, logging, encryption, approval, monitoring, or recovery is applied.
Evidence source
A fictional log, configuration record, alert, owner statement, service record, diagram source, or validation result supporting a visual element.
Risk point
A fictional location where exposure, excessive access, source loss, weak validation, supplier dependency, or control failure may affect the system.
Owner label
A fictional role responsible for approving, operating, reviewing, validating, communicating, or accepting risk for a diagram element.
Legend
A fictional key explaining every symbol, line, arrow, color category, boundary, status, confidence marker, and annotation type.
Directional arrow
A fictional visual indicator showing the direction of data, identity, evidence, decision, communication, or recovery flow.
Bidirectional flow
A fictional connection where information moves in both directions and should not be represented as one-way without evidence.
Assumption
A fictional statement accepted for the diagram but not fully confirmed by supplied evidence.
Unknown relationship
A fictional possible connection that remains unconfirmed and should be marked rather than drawn as fact.
Portfolio-safe diagram
A fictional visual using invented systems, identities, services, evidence, dates, suppliers, addresses, labels, and outcomes.
Diagram Types
Eight Fictional Security Diagram Options
Architecture diagram
Best for
Showing fictional systems, zones, networks, cloud services, suppliers, applications, storage, controls, and trust boundaries.
Include
Components, zones, boundaries, owners, control points, service dependencies, evidence sources, and risk annotations.
Avoid
Trying to show every event or decision on one static architecture view.
Primary question
What exists, how is it organized, and where do trust or control expectations change?
Portfolio value
Demonstrates system understanding and security-boundary reasoning.
Data-flow diagram
Best for
Showing how fictional information moves among users, applications, services, storage, suppliers, and external destinations.
Include
Data type, direction, source, destination, processing, storage, encryption state, owner, and control points.
Avoid
Drawing arrows without labels, direction, purpose, or evidence.
Primary question
Where does the data come from, where does it go, and which controls protect each step?
Portfolio value
Demonstrates confidentiality, integrity, privacy, and control reasoning.
Identity and access path diagram
Best for
Showing fictional users, roles, groups, nested groups, service accounts, suppliers, conditions, exceptions, and effective access.
Include
Identity source, authentication, groups, roles, inherited access, conditions, resources, owners, and validation.
Avoid
Showing only the visible role name when indirect access exists.
Primary question
How does this identity gain capability, and where should access be limited or reviewed?
Portfolio value
Demonstrates IAM, least privilege, and effective-access analysis.
Evidence-flow diagram
Best for
Showing fictional event generation, collection, transport, parsing, enrichment, correlation, alerting, storage, analyst review, and validation.
Include
Event source, event time, collection time, source health, transformations, owners, gaps, compensating sources, and limitations.
Avoid
Treating the alert console as the original source of truth.
Primary question
How does evidence move from the system to the analyst, and where can delay or loss occur?
Portfolio value
Demonstrates logging, monitoring, source-health, and evidence-limit reasoning.
Incident sequence diagram
Best for
Showing fictional events, alerts, decisions, actions, communications, recovery, and validation across roles over time.
Include
Normalized timestamps, actors, systems, evidence references, decision points, owner authority, and uncertainty.
Avoid
Mixing event, collection, alert, action, and validation time.
Primary question
What happened in what order, who acted, and which evidence supports each step?
Portfolio value
Demonstrates incident coordination and timeline accuracy.
Control and risk map
Best for
Showing fictional assets, threats, weaknesses, controls, control gaps, owners, likelihood, impact, response options, and residual risk.
Include
Asset, risk statement, control state, owner, treatment, validation, dependency, and residual risk.
Avoid
Using technical severity as the entire business-risk explanation.
Primary question
Where is risk concentrated, which controls reduce it, and what decision remains?
Portfolio value
Demonstrates policy, risk, vulnerability, and recommendation reasoning.
Ownership and responsibility map
Best for
Showing fictional identity, network, cloud, application, data, supplier, service, communications, recovery, and risk responsibilities.
Include
Approver, operator, reviewer, validator, communicator, escalation path, and residual-risk owner.
Avoid
Assigning every decision to the analyst or one security team.
Primary question
Who owns each decision, action, validation, communication, and accepted risk?
Portfolio value
Demonstrates governance, authority, and cross-team coordination.
Recovery-state diagram
Best for
Showing fictional current state, containment state, restoration steps, dependencies, testing, service acceptance, monitoring, and closure.
Include
State transitions, entry criteria, owners, rollback, tests, blockers, acceptance, and residual risk.
Avoid
Treating a completed change as proof that recovery is validated.
Primary question
How does the service move safely from affected state to validated operation?
Portfolio value
Demonstrates recovery, validation, continuity, and closure reasoning.
Visual Language
Eight Core Diagram Elements
System or service node
Meaning
Represents a fictional endpoint, server, application, cloud service, identity provider, log source, storage resource, supplier platform, or business service.
Labeling rule
Use a short invented name plus purpose, owner, and classification where needed.
Evidence rule
Link the node to the fictional source proving it exists or matters.
Common mistake
Using real hostnames, addresses, tenant names, or company systems.
User or identity node
Meaning
Represents a fictional user, role, group, service account, supplier identity, administrator, or application identity.
Labeling rule
Show identity type, owner, role, business need, and access state.
Evidence rule
Reference approval, authentication, group, role, or owner records.
Common mistake
Showing a person’s real name or assuming identity equals intent.
Trust boundary
Meaning
Marks a fictional change in administrative control, network zone, identity authority, data handling, supplier ownership, or policy.
Labeling rule
Name the boundary and explain what changes across it.
Evidence rule
Reference architecture, policy, ownership, or configuration records.
Common mistake
Drawing a boundary only because the layout has empty space.
Flow arrow
Meaning
Shows fictional data, identity, evidence, communication, decision, or recovery movement.
Labeling rule
Include direction, purpose, data or event type, protocol category when relevant, and control status.
Evidence rule
Reference records supporting the direction and relationship.
Common mistake
Using an unlabeled arrow or implying a relationship that is not confirmed.
Control marker
Meaning
Shows fictional authentication, authorization, filtering, validation, logging, encryption, monitoring, approval, or recovery controls.
Labeling rule
Name the control, owner, expected state, observed state, and validation status.
Evidence rule
Reference policy, configuration, test, alert, or owner evidence.
Common mistake
Marking a control as effective only because it exists.
Evidence marker
Meaning
Links a fictional diagram item to logs, configuration, alerts, owner confirmation, source health, or validation.
Labeling rule
Use a consistent evidence identifier and optional confidence or source-health note.
Evidence rule
The marker itself should point to the evidence register.
Common mistake
Using evidence labels that do not appear anywhere else.
Risk marker
Meaning
Highlights fictional excessive access, policy drift, source gaps, weak validation, supplier dependency, exposed data, or service risk.
Labeling rule
State the risk condition, possible impact, confirmed impact, owner, and current action.
Evidence rule
Reference findings and control-state evidence.
Common mistake
Using dramatic risk symbols without explaining what is actually supported.
Unknown or assumption marker
Meaning
Shows a fictional relationship, state, owner, or impact that remains unconfirmed.
Labeling rule
Describe the open question and evidence needed.
Evidence rule
Reference the gap or conflicting records.
Common mistake
Drawing uncertain relationships with the same style as confirmed facts.
Quality Review
Eight Checks before Finalizing the Diagram
Purpose and audience
Does the fictional diagram answer one clear question for one primary audience?
Pass
The title, subtitle, scope, and annotations all support the same decision or learning claim.
Fail
The diagram attempts to explain architecture, incident sequence, risk, ownership, and recovery at once without hierarchy.
Scope accuracy
Are included and excluded fictional systems, identities, services, suppliers, data, and time periods explicit?
Pass
The diagram boundary and notes match the project brief.
Fail
The visual appears to represent the entire organization when only a small evidence set was reviewed.
Legend consistency
Does every fictional shape, line, arrow, marker, status, and annotation have one consistent meaning?
Pass
The same symbol means the same thing throughout the package.
Fail
A dashed line means unknown in one place and encrypted in another.
Flow direction
Are fictional data, identity, evidence, communication, and recovery flows directional and labeled?
Pass
The reader can identify source, destination, purpose, and control point.
Fail
Arrows are decorative or ambiguous.
Evidence traceability
Can every important fictional node, relationship, risk, and control state be traced to evidence?
Pass
Evidence identifiers connect diagram elements to the source register.
Fail
The visual includes plausible but unsupported systems or relationships.
Uncertainty handling
Are fictional assumptions, unknowns, alternate explanations, and source gaps visibly different from confirmed facts?
Pass
Unconfirmed relationships are marked and linked to evidence requests.
Fail
Possible relationships are drawn as established facts.
Readability and accessibility
Can a reader understand the fictional diagram without relying only on color or tiny text?
Pass
Labels, shapes, line patterns, spacing, contrast, text size, captions, and written summaries support accessibility.
Fail
The reader must distinguish meaning from color alone.
Portfolio safety
Is every fictional system, identity, address, supplier, message, incident, evidence item, date, and outcome invented?
Pass
The diagram is fictional from the beginning and contains no private reconstruction.
Fail
A real screenshot or architecture is lightly edited.
Diagram Workflow
Eight Steps from Question to Final Visual
Define the question
Choose the fictional audience, decision, learning claim, diagram type, scope, privacy boundary, evidence, deadline, and success criteria.
Output: Diagram project brief.
Build the source register
List fictional architecture, identity, data, log, configuration, owner, service, risk, decision, and validation evidence.
Output: Source and evidence register.
Identify elements and relationships
Map fictional systems, identities, services, suppliers, flows, boundaries, controls, owners, risks, unknowns, and dependencies.
Output: Element inventory.
Create the legend and layout
Define fictional shapes, line styles, arrow types, status markers, evidence labels, risk markers, confidence notes, and page hierarchy.
Output: Legend and wireframe.
Draw and annotate
Create the fictional diagram with clear labels, directions, boundaries, owners, controls, evidence references, assumptions, and reviewer notes.
Output: Diagram draft.
Validate technical meaning
Check fictional source, destination, direction, relationship, effective state, ownership, evidence, risk, and uncertainty against the register.
Output: Technical review record.
Review readability and safety
Check fictional hierarchy, spacing, labels, contrast, accessibility, audience fit, privacy, unsupported relationships, and portfolio safety.
Output: Design and safety review.
Revise and present
Apply fictional feedback, record version changes, finalize the diagram package, explain limitations, and defend the learning claim.
Output: Final diagram and presentation notes.
Fake Dashboard
Fake Northbridge Security Diagram Review Dashboard
Training dashboard for fictional visual quality only.
Supported diagram elements
24
Every fictional system, flow, boundary, control, risk, owner, and evidence marker links to the source register.
Unconfirmed relationships
2
Possible supplier-to-storage and phishing-to-cloud relationships remain marked as unknown.
Privacy review issues
0
All fictional names, systems, addresses, evidence, dates, suppliers, incidents, and outcomes are invented.
Fake SOC Alert
Diagram Shows Unsupported Supplier-to-Storage Relationship
Source: Fake Northbridge Diagram Quality Console • Time: 3:16 PM
A fictional solid arrow links the supplier identity to confidential storage even though the source register contains only shared timing and no common identity, session, or access evidence.
Defensive recommendation: Replace the solid arrow with an unknown marker, document the open question, cite the evidence gap, add required confirmation sources, and complete peer review before presentation.
Fake Log Panel
Fake Diagram Revision Timeline
training-log-viewer.log
09:00 BRIEF diagram-type='architecture-and-flow' 09:15 SCOPE systems='8' 09:30 LEGEND symbols='defined' 09:45 BOUNDARY supplier='missing' 10:00 FLOW data-direction='partial' 10:15 EVIDENCE markers='18' 10:30 UNKNOWN supplier-storage='drawn-solid' 10:45 CONTROL states='unlabeled' 11:00 ACCESSIBILITY color-only='detected' 11:15 REVIEW relationship='unsupported' 11:30 REVISION trust-boundaries='added' 11:45 REVISION flow-labels='added' 12:00 REVISION unknown-marker='added' 12:15 REVISION control-status='added' 12:30 REVIEW accessibility='passed' 12:45 FINAL diagram='presentation-ready'
Training note: this is fake data for defensive analysis practice only.
Diagram Findings
Six Fictional Visual-Quality Findings
NBR-DGM-F01High
The fictional architecture diagram shows all major systems but does not identify trust boundaries.
Evidence support
User, application, identity, cloud, supplier, storage, and logging nodes are present, while administrative and supplier boundaries are absent.
Alternate explanation
The author may have intended the page groups to imply zones.
Impact
Readers cannot see where security expectations and ownership change.
Next action
Add named trust boundaries with control, owner, and evidence notes.
NBR-DGM-F02High
The fictional data-flow arrows do not identify direction, data type, or purpose consistently.
Evidence support
Several lines connect services without arrowheads or labels.
Alternate explanation
The diagram may be intended as a topology rather than a data-flow view.
Impact
Readers may misunderstand what moves between systems and which control protects it.
Next action
Add direction, data category, purpose, and control-point labels to every important flow.
NBR-DGM-F03High
The fictional diagram presents one possible supplier-to-storage relationship as confirmed.
Evidence support
A solid arrow is drawn even though the evidence register contains only shared timing and no common identity, session, or access record.
Alternate explanation
The line may represent a question rather than a fact.
Impact
The visual could create an unsupported incident narrative.
Next action
Change the line to an unknown marker and state the evidence needed to confirm the relationship.
NBR-DGM-F04Medium-High
The fictional control markers show expected controls but not observed or validated state.
Evidence support
Authentication, authorization, logging, and encryption icons appear without status or evidence references.
Alternate explanation
The diagram may represent design intent only.
Impact
Readers may assume controls are effective because they are drawn.
Next action
Label expected, observed, corrected, and validated states separately.
NBR-DGM-F05High
The fictional diagram is visually attractive but difficult to interpret without color.
Evidence support
Risk, control, evidence, and unknown categories rely on color alone and use similar shapes.
Alternate explanation
The original display may have stronger contrast than the exported copy.
Impact
Accessibility and printed readability are reduced.
Next action
Add shape, line-pattern, text-label, and icon differences plus a written summary.
NBR-DGM-F06Medium-High
The fictional diagram package is ready after targeted revisions to boundaries, flows, uncertainty, control state, accessibility, and evidence labels.
Evidence support
System inventory, ownership, privacy, core layout, and evidence register are otherwise strong.
Alternate explanation
A new reviewer may identify additional audience-fit issues.
Impact
Remaining problems affect clarity and supportability rather than the entire model.
Next action
Complete peer review, revise the legend, rehearse the explanation, and record the final version.
Analyze the Evidence
Should the Supplier Identity Be Drawn as Connected to Confidential Storage?
The fictional supplier identity signed in to a support service.
A confidential-storage policy changed later in the same shift.
The systems use different identity records and owners.
No common session, access record, or configuration actor is supplied.
The grouped alert was created from temporal proximity.
Later evidence could establish a relationship.
Which diagram choice is strongest?
Common Mistakes
Mistakes That Weaken a Fictional Security Diagram
Creating a fictional diagram before deciding which question, audience, and decision it should support.
Combining architecture, data flow, identity, evidence, incident sequence, risk, ownership, and recovery into one unreadable page.
Drawing relationships because they seem plausible rather than because fictional evidence supports them.
Using unlabeled arrows that do not show direction, purpose, data type, or control state.
Showing a role name without direct, inherited, nested, conditional, or exception-based access paths.
Drawing a security control without identifying expected, observed, corrected, and validated state.
Using color as the only way to distinguish risk, evidence, trust, status, or uncertainty.
Leaving trust boundaries unnamed or unexplained.
Adding icons and decoration that do not answer the diagram question.
Using inconsistent symbols, line styles, status labels, or evidence identifiers.
Showing possible exposure, unknown relationships, or assumptions as confirmed facts.
Forgetting owners, authority, validation, residual risk, and next actions.
Including real screenshots, architecture, hostnames, addresses, identities, suppliers, logs, messages, incidents, or confidential project information.
Creating a diagram that becomes an instruction set for probing or changing real systems.
Safe Practice Lab
Build the Northbridge Fictional Security Diagram Package
Your fictional assignment
Architecture, Flows, Boundaries, Controls, Evidence, Risk, and Ownership
Use only fictional Northbridge evidence to build one primary security diagram and supporting visual package.
Required deliverables
- Diagram project brief with purpose, audience, question, scope, exclusions, privacy, evidence, deadline, and success criteria.
- Source register and element inventory covering systems, identities, services, suppliers, data, evidence, owners, risks, and controls.
- Legend defining every shape, line, arrow, boundary, control state, evidence marker, risk marker, confidence label, and unknown marker.
- Primary fictional diagram with clear hierarchy, labels, directions, trust boundaries, control points, evidence references, owners, and limitations.
- One supporting fictional data-flow, identity-path, evidence-flow, incident-sequence, risk, ownership, or recovery diagram.
- Annotation table explaining every important node, relationship, risk point, assumption, unknown, and validation result.
- Technical, readability, accessibility, privacy, unsupported-relationship, and audience-fit review records.
- Version history, reviewer feedback, final revision, presentation notes, reflection, and portfolio-safety statement.
Use only fully invented material. Do not copy, lightly edit, expose, trace, or recreate real architecture, identities, network maps, cloud diagrams, addresses, logs, screenshots, messages, suppliers, incidents, employee data, school systems, or confidential project information.
Scenario Decision Lab
The Diagram Uses a Solid Arrow for an Unconfirmed Relationship
The fictional supplier sign-in and storage-policy change happened during one shift, but no shared identity, session, or access evidence connects them.
Scenario Decision Lab
A Reviewer Requests the Original Real Network Diagram
The fictional portfolio visual demonstrates the learning claim, but the requested original diagram would reveal real systems, trust boundaries, addresses, suppliers, and private infrastructure.
Defender Habits
Creating a Security Diagram Checklist
Check Your Understanding
I17.4 Mini Quiz: Creating a Security Diagram
Choose your answers first. Explanations appear only after submission.
1. What should be decided before creating a fictional security diagram?
2. What is a fictional trust boundary?
3. How should an unconfirmed fictional relationship be shown?
4. What makes a fictional flow arrow useful?
5. Why should fictional control markers include status?
6. What improves fictional diagram accessibility?
7. What makes a fictional security diagram portfolio-safe?
Portfolio Prompt
Portfolio Prompt
Create a fictional Northbridge Security Diagram Package. Include the project brief, audience, learning claim, scope, exclusions, privacy rules, source register, element inventory, legend, primary architecture diagram, supporting flow diagram, trust boundaries, identity paths, data flows, evidence sources, controls, owners, risks, assumptions, unknowns, annotations, evidence references, technical review, accessibility review, privacy review, version history, reviewer feedback, final revision, presentation notes, reflection, and a portfolio-safety statement.
Use only fictional systems, identities, services, suppliers, addresses, evidence, dates, incidents, controls, and outcomes.
Make every important line, arrow, boundary, symbol, and risk marker answer a clear question.
Show unknown relationships differently from confirmed relationships.
Do not rely on color alone to communicate meaning.
Key Takeaways
What You Should Remember
1.A security diagram should answer a clear question for a specific audience.
2.The correct diagram type depends on whether the reader needs architecture, flow, identity, evidence, incident, risk, ownership, or recovery information.
3.Every important node, relationship, boundary, control, and risk should be supported by fictional evidence.
4.Assumptions and unknowns should never be drawn as confirmed facts.
5.Controls should show expected, observed, corrected, failed, or validated state.
6.Accessible diagrams use labels, shapes, line patterns, contrast, captions, and written explanation rather than color alone.
7.Portfolio diagrams must be fully fictional and should never expose or recreate real infrastructure.
Navigation