Lesson A19.2
A professional security diagram should make an architecture easier to reason about. It shows the relationships that matter: trust changes, identity, data movement, management, monitoring, dependencies, ownership, uncertainty, and the boundaries of the review.
This lesson teaches how to design and review a useful security diagram before you build the portfolio artifact. Every system, record, and architecture detail below is fictional and safe for classroom use.
Lesson Progress
High School Advanced • A19: Cybersecurity Portfolio Projects • Lesson 2 of 10
Readiness Check
0/4 ready
Professional Hook
Imagine a reviewer sees two architecture diagrams. The first contains thirty polished icons and dozens of arrows. The second contains fewer components, but clearly separates public access, application services, data, management, monitoring, and external dependencies. Its arrows are labeled, uncertain paths are marked, and the written notes explain the two design decisions that matter most.
The second diagram is more useful because the reviewer can reason from it. Security architecture is not improved by visual density. It is improved when important relationships become easier to understand, question, validate, and communicate.
A security diagram is successful when another person can use it to understand the architecture without inventing the missing story.
Learning Objectives
Explain what a security diagram is supposed to communicate and distinguish a useful defensive diagram from a decorative picture or unexplained topology sketch.
Represent scope, trust boundaries, data flows, identities, services, dependencies, controls, monitoring, and important assumptions with labels that another reader can understand.
Choose the right level of abstraction for a specific audience without hiding material security relationships or adding detail that does not support the diagram's purpose.
Review a fictional diagram for missing ownership, unclear flows, stale assumptions, concentrated dependencies, unsupported claims, and safety or publication concerns.
Create a portfolio-ready Security Diagram Project package that includes the diagram, legend, scope statement, design rationale, evidence notes, limitations, review findings, and revision summary.
Core Teaching
A security diagram is a simplified representation of a system designed to make selected security relationships understandable. It is not a complete copy of reality. Every diagram chooses what to include, what to group, and what to omit. Those choices should be driven by the purpose of the review.
A useful diagram explains how components relate: who communicates with what, where trust changes, which services depend on shared infrastructure, and where controls or monitoring sit. A list of boxes is not yet a security story.
Security decisions often happen at boundaries between users, applications, data stores, management systems, cloud services, external providers, and monitoring platforms. The diagram should make those transitions understandable.
A diagram should exist for a reason. It might explain segmentation, identity dependencies, data handling, recovery relationships, logging coverage, or a proposed design. The purpose determines which details belong on the page.
Good diagrams expose where a reviewer should ask questions: shared dependencies, unclear ownership, single points of failure, broad trust, missing telemetry, third-party reliance, or data crossing a sensitive boundary.
In a portfolio, the diagram is strongest when paired with a short explanation of the problem, the design choices, the evidence behind those choices, the limitations, and what changed after review.
Scope and Purpose
Diagram quality begins before drawing. First decide what the reader should learn. A diagram of the same fictional service could be built for segmentation review, identity review, recovery review, logging coverage, cloud dependency review, or executive communication. Each version would include different detail because each supports a different decision.
Write one sentence beginning with 'This diagram helps the reader understand...' If that sentence is vague, the visual will probably become vague too.
Name the fictional service, workflow, architecture slice, time context, and any intentional exclusions. Scope prevents the picture from appearing more complete than the review actually is.
Identify whether the primary reader is a technical peer, evaluator, hiring reviewer, manager, or nontechnical leader. Audience affects presentation depth, not the truth of the architecture.
List the supplied records used to support the drawing. This creates traceability between visual claims and the fictional evidence behind them.
Diagram Language
Defines what the diagram includes and what is intentionally outside the review. Scope should be visible in both the picture and the written context.
Marks a place where assumptions, identity, ownership, privilege, exposure, or control responsibility changes.
Represents people, service identities, administrators, external collaborators, or automated workloads that interact with the architecture.
Represents the application, API, gateway, database, storage service, management service, queue, identity provider, or monitoring component that performs a meaningful role.
Shows important movement of requests, records, events, telemetry, administrative commands, or recovery data between components.
Shows a defensive safeguard such as authentication, authorization, segmentation, encryption boundary, validation, backup, review, or monitoring point at a conceptual level.
Shows a service, provider, identity system, telemetry platform, network path, management plane, or recovery resource that another part of the architecture relies on.
Identifies the team or role responsible for a component or decision when that responsibility affects security review.
Records an unverified point that affects the interpretation of the diagram, such as an unclear data path or stale architecture record.
Abstraction
More detail does not automatically make a diagram more advanced. Professionals choose an abstraction level that preserves the relationships required for the decision while removing detail that would distract, overwhelm, or expose information unnecessarily.
Use when: The audience needs to understand major services, external dependencies, sensitive flows, major trust boundaries, and business significance.
Include: Business services, major zones, important data classes, material external providers, critical dependencies, and one or two major risk relationships.
Avoid: Tiny implementation details, every log source, every host-like object, or labels that only a technical operator would understand.
Use when: The audience needs enough detail to reason about segmentation, identity, monitoring, resilience, data flows, and ownership.
Include: Zones, services, identities, control points, management paths, telemetry, recovery relationships, dependencies, and relevant assumptions.
Avoid: Unrelated implementation detail or exact real-world configuration information that is not needed for the educational purpose.
Use when: The diagram supports one narrow question such as privileged administration, logging coverage, recovery, cloud storage exposure, or identity federation.
Include: Only the components and relationships that help answer the specific review question, plus enough surrounding context to avoid misleading conclusions.
Avoid: Copying an entire enterprise architecture into a diagram that is supposed to answer one focused question.
Visual Communication
Readers should not have to infer what colors, borders, arrows, dashed lines, icons, or labels mean. A legend turns visual conventions into explicit evidence.
An unlabeled arrow could represent a user request, administrative access, telemetry, replication, identity assertion, or backup transfer. Meaning matters more than the arrow itself.
Flow direction should be easy to follow. Avoid arrows that cross repeatedly or reverse without explanation because the reader may misread sequence or authority.
Boundaries should be visually distinct so changes in trust, exposure, ownership, or control responsibility are clear.
A label such as 'Identity Service' communicates purpose more effectively than an unexplained fictional asset code. Asset IDs can appear as secondary references when useful.
If a path, owner, or dependency has not been verified, mark it as unconfirmed. Do not draw an uncertain relationship with the same certainty as a supplied fact.
Every shape, color, line, icon, and annotation should help the reader understand scope, flow, responsibility, control, evidence, or risk.
Evidence Discipline
Architecture records are often incomplete. One document may be old, an owner may describe a path from memory, or a monitoring inventory may list only some sources. A professional diagram should preserve those limits. The visual can include an uncertain relationship, but uncertainty must be communicated rather than hidden.
| Evidence state | Diagram treatment | Documentation |
|---|---|---|
| Confirmed | Normal visual convention for the relationship | Reference the evidence source when the relationship is material to the review. |
| Supported but incomplete | Show the relationship with a note that limits what is known | State which part is supported and what remains unverified. |
| Assumed | Use a distinct unverified-flow convention | Explain why the assumption matters and what evidence should confirm or reject it. |
| Contradicted | Do not choose one version silently | Show the conflict in the notes and identify which records disagree. |
| Unknown | Leave the uncertainty visible | Record the gap rather than drawing a guessed relationship to make the picture look complete. |
Fake Dashboard
Synthetic portfolio-review metrics for a fictional architecture draft
Architecture zones
7
Includes external, identity, application, data, management, monitoring, and provider boundaries.
Evidence references
8
Stable fictional records DG-E01 through DG-E08 support the draft.
Unverified relationships
1
The reporting export is believed to exist but lacks a current integration record.
Monitoring gaps
1
No current telemetry source is listed for the external managed backup archive.
Major revisions
5
The portfolio version records why each material visual change was made.
Real system data
0
All names, identifiers, dependencies, and records are fictional.
Fake SOC Alert
Source: Northbridge Portfolio Review • Time: Fictional review checkpoint 14:20
Fake Log Panel
DG-E01 | architecture brief | CONFIRMED | customer request path reaches APP-NB-52 and API-NB-53 through the managed edge service DG-E02 | identity note | CONFIRMED | APP-NB-52 uses fictional service identity SVC-NB-52 for the API relationship DG-E03 | monitoring inventory | PARTIAL | application and identity telemetry listed; external backup archive telemetry not listed DG-E04 | change record | CONFIRMED | privileged administration depends on the access broker plus approved change workflow DG-E05 | recovery overview | CONFIRMED | operational data produces protected recovery copies before external archive transfer DG-E06 | classification note | CONFIRMED | customer records and derived reporting data have different sensitivity labels DG-E07 | owner interview | UNVERIFIED | nightly reporting export believed to exist; current integration document missing DG-E08 | operations note | SUPPORTED | message provider affects notifications but is not required for the core transaction
Training note: this is fake data for defensive analysis practice only.
Fictional Architecture
The Northbridge case is intentionally small enough to diagram clearly but complex enough to show professional security relationships. The project is not asking you to draw a real enterprise. It is asking you to convert supplied evidence into a defensible visual explanation.
Components: Customer Browser, Partner Portal Entry, Managed Edge Service
Represents public and partner entry points before requests reach internal application services.
Diagram review: Show which paths are public, which are partner-only, and where identity or request validation begins.
Components: Workforce Identity Service, Customer Identity Service, Privileged Access Broker
Provides authentication and identity context for different user populations and administrative workflows.
Diagram review: Keep customer, workforce, and privileged identity paths distinct so the diagram does not imply that every identity has the same trust level.
Components: Portal Service APP-NB-52, API Service API-NB-53, Task Queue QUEUE-NB-5
Handles fictional customer requests and application processing.
Diagram review: Show the portal-to-API flow, service identity dependency, queue dependency, and which telemetry leaves the zone.
Components: Customer Records Store DATA-NB-14, Reporting Store DATA-NB-15, Backup Repository BKP-NB-4
Stores fictional application records, derived reporting data, and protected recovery copies.
Diagram review: Distinguish operational data from reporting data and recovery data; do not imply that all three are interchangeable or have the same access model.
Components: Admin Workstation Pool, Change Workflow Service, Configuration Repository
Represents controlled administration and approved change coordination.
Diagram review: Administrative paths should not look like ordinary user traffic. The diagram should show that privileged activity depends on separate identity and change governance.
Components: Telemetry Collector MON-NB-20, Alert Service DET-NB-12, Analyst Queue
Receives fictional logs and events used for defensive monitoring and case review.
Diagram review: Show which zones provide telemetry and make any missing or delayed sources visible instead of implying complete visibility.
Components: Message Delivery Provider, Managed Backup Archive, Status Notification Provider
Represents fictional third-party services used by Northbridge workflows.
Diagram review: Place external dependencies outside internal trust boundaries and label what the organization relies on each provider to do.
Source Provenance
The customer portal sends application requests to API-NB-53 through the managed edge service.
Diagram use: Supports the primary customer request flow.
APP-NB-52 uses service identity SVC-NB-52 when requesting API-NB-53.
Diagram use: Supports a service-identity relationship between the portal and API.
APP-NB-52, API-NB-53, and customer identity events feed MON-NB-20. Backup archive telemetry is not listed.
Diagram use: Supports known telemetry paths and a monitoring gap note for the backup archive.
Privileged changes require the Privileged Access Broker and an approved change ticket before execution by the administration team.
Diagram use: Supports a distinct administrative path and governance dependency.
DATA-NB-14 produces recovery copies to BKP-NB-4, with later archive transfer to an external managed backup service.
Diagram use: Supports the internal backup flow and external archive dependency.
DATA-NB-14 contains restricted fictional customer records; DATA-NB-15 contains derived reporting data with lower sensitivity.
Diagram use: Supports differentiated data labels instead of one generic database label.
The reporting store is believed to receive a nightly export from DATA-NB-14, but the current integration document is missing.
Diagram use: Should be shown as an unverified or assumed flow, not a confirmed flow.
The message delivery provider is required for customer notifications but not for the core transaction to complete.
Diagram use: Supports an external dependency with a bounded impact note.
Analyze the Evidence
Review Model
Strong: The title and scope explain what the diagram helps the reader understand, such as customer-service trust boundaries and monitoring dependencies.
Weak: The diagram is titled 'Network Diagram' or 'Architecture' with no explanation of the review question.
Strong: Confirmed flows use the normal visual convention, while uncertain paths are labeled as unverified and tied to an evidence note.
Weak: Every arrow looks equally certain even when some relationships came from stale or incomplete information.
Strong: Public, partner, workforce, privileged, application, data, management, monitoring, and external-provider boundaries are visually distinct when they matter.
Weak: Everything appears inside one large trusted box, hiding where security assumptions change.
Strong: Important arrows identify request, identity, administration, telemetry, recovery, or data movement so reviewers understand why the connection matters.
Weak: Dozens of unlabeled arrows create a dense map without explaining the security meaning of the relationships.
Strong: Critical identity, monitoring, management, backup, and external-provider dependencies are visible, with ownership noted where it affects review or action.
Weak: The diagram shows components but not who owns them or what happens when a shared service becomes unavailable.
Strong: All names are fictional or generic, sensitive implementation detail is excluded, and the project explanation clearly states that the architecture is synthetic.
Weak: The student copies real internal hostnames, private system identifiers, confidential network details, or real organizational diagrams into a public portfolio.
Architecture Dependencies
Security review is often dependency review. A service may depend on identity to authenticate users, monitoring to preserve visibility, management infrastructure to make controlled changes, external providers to deliver a business function, and recovery services to restore important data. A diagram that hides those dependencies can make the architecture appear more resilient or self-contained than it actually is.
Customer, workforce, service, and privileged identities support different workflows. Show the relationships that affect access and trust without implying that all identities are equivalent.
Telemetry paths affect what defenders can observe. Missing sources should appear as evidence gaps rather than being silently represented as monitored.
Administrative changes rely on privileged identity, controlled workstations, approval workflow, and configuration governance. Keep this path distinct from ordinary user traffic.
Backups and external archives matter because recovery depends on them. The diagram can show the relationship without exposing real recovery locations or operational details.
Place third-party services outside internal trust boundaries and explain what function depends on them. External does not automatically mean insecure, but responsibility and resilience still matter.
A technically reasonable architecture can remain difficult to govern when ownership is unclear. Record which team or role should validate material components and decisions.
Anti-Patterns
Problem: The page contains many systems, but relationships, flows, boundaries, ownership, and purpose are missing.
Improve it: Reduce the component list and make the important relationships explicit. The diagram should answer a security question, not inventory every object.
Problem: The creator tries to include every service, dependency, log source, label, policy, data store, and control in one diagram.
Improve it: Choose an abstraction level and split focused views when necessary. More detail is useful only when it supports the diagram's purpose.
Problem: The diagram uses many colors but provides no legend, so readers cannot tell whether colors represent zones, owners, sensitivity, risk, or decoration.
Improve it: Use a small number of visual conventions and define them in a legend.
Problem: External services and privileged administration paths appear inside the same visual space as ordinary application components.
Improve it: Show where trust, ownership, exposure, or privilege changes and explain the meaning of those boundaries.
Problem: A possible data flow is drawn with the same certainty as a verified path because the creator wants the diagram to look complete.
Improve it: Mark uncertain relationships and record what evidence is needed to confirm them.
Problem: The visual may be strong, but the portfolio gives no explanation of the problem, design rationale, evidence, tradeoffs, review findings, or limitations.
Improve it: Add concise written context so the artifact demonstrates thinking, not only drawing skill.
Scenario Decision Lab
A fictional Northbridge architecture draft shows a reporting export as confirmed. During review, you discover that the current integration document is missing and the only remaining source is a low-confidence interview summary.
Scenario Decision Lab
A student wants to reuse an old diagram from a legitimate school or work experience. The original image contains real internal architecture relationships, identifiers, and private operational details.
Safe Fictional Lab
Your goal is not to create the most complicated picture. Your goal is to produce a diagram that another reviewer can use to understand the supplied architecture, ask better questions, and trace important visual claims back to fictional evidence.
Write a two-sentence scope statement for the fictional Northbridge Customer Services architecture. State what the diagram is meant to explain and what it intentionally does not represent.
Create a legend for zones, confirmed flows, unverified flows, identity relationships, telemetry, recovery paths, and external dependencies. Keep the conventions simple enough for a new reader to learn quickly.
Place the seven supplied architecture zones and their major components. Use role-based labels first and stable fictional IDs only where they help connect the visual to evidence.
Add the confirmed customer request path, service-identity relationship, privileged administration path, monitoring flows, recovery path, and external dependencies supported by DG-E01 through DG-E08.
Mark the reporting export as unverified rather than confirmed. Add DG-E07 as the provenance note and state what current evidence would be needed to raise confidence.
Label at least four trust or responsibility changes that matter to security reasoning: public-to-internal, customer identity-to-application, privileged management, data services, monitoring, or external-provider boundaries.
Add concise notes for data sensitivity, ownership, monitoring gaps, and critical dependencies without turning the visual into a wall of text.
Review the diagram using purpose, scope, boundaries, flows, dependencies, ownership, evidence, uncertainty, readability, and publication safety. Record at least three revisions and why they improve the artifact.
Write a short design rationale explaining two choices you made, one important tradeoff, one evidence gap, and one limitation of the diagram.
Prepare a final portfolio package containing the diagram, legend, scope, evidence references, rationale, review findings, revision notes, limitations, and a one-paragraph audience summary.
Lab boundary
Build only from the supplied fictional Northbridge records. Do not inspect real networks, cloud accounts, devices, identity systems, private diagrams, internal documentation, or organizational architecture to complete this project.
Revision Evidence
A portfolio reviewer learns more from a few meaningful revision notes than from a claim that the first draft was perfect. Revision shows that you can respond to evidence, correct overstatement, improve communication, and preserve uncertainty.
Observation: The first Northbridge diagram placed all identity services inside one generic Identity box and did not separate customer, workforce, and privileged access.
Revision: Split the identities by purpose and linked privileged access to the management path rather than ordinary user traffic.
Why: The original diagram hid a meaningful trust and privilege distinction.
Observation: The reporting export from DATA-NB-14 to DATA-NB-15 was drawn as a confirmed nightly flow.
Revision: Changed the line to an unverified-flow convention and added evidence reference DG-E07.
Why: The available evidence describes the path as believed but not currently documented.
Observation: The monitoring zone appeared to receive telemetry from every component.
Revision: Removed unsupported telemetry arrows and added a gap note for the external backup archive.
Why: A diagram should not imply complete visibility when the monitoring inventory does not support that conclusion.
Observation: External providers were mixed into internal zones and looked organization-owned.
Revision: Moved them outside the Northbridge trust boundary and labeled the service dependency for each provider.
Why: Ownership and responsibility boundaries are part of the security story.
Observation: The page contained too many asset codes and repeated labels for the intended portfolio audience.
Revision: Kept only stable fictional IDs that support evidence references and used role-based names as the primary labels.
Why: The final artifact should remain readable while preserving traceability to the supplied evidence.
Analyze the Evidence
Advanced Challenge
Build two portfolio-safe views of the same fictional Northbridge case. The first is an architecture-review view for a technical reader. The second is an executive-context view for a nontechnical reviewer. The underlying facts, uncertainty, and evidence references must remain consistent, but the amount and organization of detail should change.
A reviewer can understand the architecture question, major zones, important flows, and trust changes in less than a minute before reading deeper notes.
Material relationships connect to stable fictional evidence IDs so the reader can see why they appear in the diagram.
Unverified relationships remain visible but are clearly distinguished from confirmed facts and include a next evidence request.
The visual highlights boundaries, dependencies, identity, data, monitoring, resilience, ownership, and exposure rather than only network-like connectivity.
The portfolio version is understandable without removing the details needed to support the student's reasoning.
All systems, identifiers, flows, and records are fictional or safely reconstructed; no real internal architecture or private information is exposed.
Challenge rule
Simplification may change presentation, but it must not change the facts. Do not remove uncertainty, invent stronger control coverage, or alter the architecture story just to make the executive view look cleaner.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a portfolio-ready Security Diagram Project using only the fictional Northbridge evidence from this lesson. Include the final diagram, purpose and scope statement, legend, evidence inventory, trust-boundary notes, labeled flows, dependencies, ownership notes where relevant, uncertainty markers, design rationale, at least three meaningful revision notes, limitations, review findings, and a concise audience summary explaining what the artifact demonstrates.
Confidence / Readiness Reflection
A19.3 moves into the Incident Report Project. Before continuing, make sure you can turn architecture evidence into a clear visual without overstating what the evidence proves.
I can explain the purpose and scope of a security diagram before drawing it.
I can show trust boundaries, labeled flows, identity, monitoring, management, data, and dependencies when they matter to the review question.
I can distinguish confirmed architecture evidence from assumptions, stale records, and unknowns.
I can choose an abstraction level that fits the audience without changing the underlying facts.
I can explain how revision notes and written context turn a diagram into a stronger portfolio artifact.
Portfolio Build Guide
Use a title such as 'Northbridge Customer Services — Trust Boundaries and Defensive Dependencies' instead of a vague label such as 'System Diagram.'
Readers should see the meaning of zones, confirmed flows, unverified flows, telemetry, and external boundaries without searching through another page.
Use readable role-based component names first. Add fictional IDs where they help trace a relationship to the evidence inventory.
A few short annotations can highlight a monitoring gap, shared identity dependency, unverified path, or external-provider boundary. Do not annotate every box.
Record meaningful reasoning changes, such as correcting an assumption or clarifying a boundary. You do not need to document every formatting edit.
Tell the reader what the visual does not prove. This makes the artifact more credible and prevents a simplified architecture view from being mistaken for a complete environment description.
Key Takeaways
Lesson Safety Boundary
Do not inspect, copy, map, probe, scan, enumerate, or publish real networks, devices, cloud environments, identity systems, internal diagrams, private architecture records, credentials, configuration details, or confidential organizational relationships. Complete the project only with the supplied fictional Northbridge evidence or other purpose-built synthetic material.
Lesson Complete
You now have a portfolio-ready method for turning fictional architecture evidence into a clear, bounded, reviewable security diagram. Next, A19.3 applies the same evidence discipline to an incident report project.