Architecture brief
A fictional statement of mission, users, systems, data, constraints, trust, risks, dependencies, and decisions that the design must address.
High School AdvancedModule A2Lesson 10 of 10Integrated Design Lab
A2.10 Security Architecture Design Lab
Integrate every A2 concept into one fully fictional architecture: mission, trust boundaries, segmentation, identity, evidence, resilience, hardening, suppliers, tradeoffs, validation, governance, and portfolio-ready communication.
Lesson Progress
Security Architecture Design Lab
High School Advanced • A2: Security Architecture • Lesson 10 of 10
100% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Good Architecture Must Work beyond the Diagram
The fictional Northbridge Learning Support Service has attractive diagrams, several security tools, and a written baseline. Yet the public application reaches management through an undocumented path, one support role crosses every major zone, critical evidence sources are incomplete, full support content is overcollected, recovery shares the primary identity platform, accessibility testing fails for some users, and temporary migration rules have no sunset owner. The final design lab is about turning those disconnected controls into one coherent, operable, evidence-based, recoverable architecture.
Architecture as appearance
Fictional diagrams, policies, tools, and zones exist, but their identities, paths, evidence, owners, failures, and recovery do not work together.
Architecture as an operating system
Fictional mission, trust, controls, evidence, ownership, failure, recovery, tradeoffs, and validation form one governed design.
Objective 1
Integrate fictional mission, trust boundaries, segmentation, identity, logging, resilience, hardening, and tradeoff decisions into one coherent security architecture.
Objective 2
Translate fictional stakeholder needs and evidence into explicit architecture requirements, design decisions, controls, owners, assumptions, exceptions, and validation criteria.
Objective 3
Evaluate a fictional architecture across normal, degraded, failed, recovered, changed, supplier-outage, and growth conditions without relying on one control or one diagram.
Objective 4
Produce a defensible fictional design package containing diagrams, matrices, decision records, risk statements, evidence plans, recovery gates, and owner approvals.
Objective 5
Create a portfolio-ready fictional security architecture design lab using only invented organizations, systems, identities, data, evidence, decisions, dates, and outcomes.
Why This Matters
Security Architecture Coordinates Decisions across the Whole Mission
Fictional identity controls influence segmentation. Segmentation influences logging. Logging influences response and recovery. Recovery influences hardening and supplier design. Accessibility, privacy, cost, staffing, and delivery constraints influence every option. A strong architecture connects these decisions, states what remains uncertain, assigns owners, and proves that intended outcomes work during normal and abnormal conditions.
Integrate
Connect fictional mission, identities, paths, data, controls, evidence, suppliers, and recovery.
Validate
Test fictional normal, degraded, failed, changed, recovered, growth, supplier-outage, and staffing-loss conditions.
Communicate
Produce fictional diagrams, matrices, decisions, risk statements, executive summaries, and portfolio reflections.
Integrated Architecture Model
Mission → Context → Trust → Requirements → Controls → Evidence → Failure → Recovery → Decisions → Governance
Mission
Define fictional users, critical functions, privacy, accessibility, continuity, and success.
Context
Map fictional systems, services, identities, data, suppliers, owners, and dependencies.
Trust
Document fictional assumptions, boundaries, zones, flows, privilege, and denied paths.
Requirements
Write fictional measurable security, evidence, privacy, availability, and recovery outcomes.
Controls
Build fictional preventive, detective, responsive, recovery, governance, and compensating stacks.
Evidence
Design fictional questions, sources, schema, health, time, access, retention, and confidence.
Failure
Evaluate fictional identity, logging, supplier, service, staffing, and configuration failure.
Recovery
Restore fictional identity, data, services, evidence, users, suppliers, and normal access in order.
Decisions
Compare fictional options, constraints, costs, accessibility, privacy, and reversibility.
Governance
Assign fictional owners, exceptions, residual risk, corrective actions, reviews, and revision history.
Advanced Vocabulary
Language for the Integrated Design Lab
System context
A fictional view of the people, services, identities, data, suppliers, environments, owners, and external relationships surrounding the architecture.
Architecture requirement
A fictional measurable outcome the design must satisfy across security, privacy, availability, accessibility, evidence, operations, and recovery.
Architecture decision record
A fictional artifact documenting context, options, criteria, decision, consequences, assumptions, owner, evidence, review, and revision.
Trust model
A fictional explanation of which identities, services, data, paths, owners, and assertions are trusted, under what conditions, and how that trust is validated.
Control stack
A fictional set of preventive, detective, responsive, recovery, governance, and compensating controls working together for one risk or requirement.
Control objective
A fictional statement describing the outcome a control or group of controls must achieve.
Architecture pattern
A fictional reusable design approach for identity, segmentation, evidence, recovery, supplier access, administration, or another security concern.
Design assumption
A fictional condition treated as true during architecture work, with evidence, owner, confidence, review trigger, and fallback if it changes.
Design constraint
A fictional limit involving time, budget, staff, technology, supplier, policy, privacy, accessibility, operations, or recovery.
Design invariant
A fictional non-negotiable condition that must remain true across normal, degraded, failed, and recovered states.
Attack surface
The fictional identities, services, interfaces, paths, data, suppliers, administrative functions, and recovery mechanisms that could be reached or misused.
Failure domain
A fictional group of systems, controls, identities, owners, suppliers, or services that may fail together because of a shared dependency.
Blast radius
The fictional scope of users, systems, identities, data, evidence, suppliers, and mission functions affected by a failure or control weakness.
Architecture drift
A fictional mismatch between approved design and effective identities, paths, services, settings, data flows, exceptions, evidence, or recovery behavior.
Design evidence
Fictional records that prove or challenge assumptions, requirements, controls, effective state, failures, recovery, and owner decisions.
Validation gate
A fictional checkpoint requiring evidence and owner approval before a design phase, change, rollout, recovery, or closure proceeds.
Residual risk
The fictional risk remaining after architecture controls, decisions, and compensating measures are applied.
Exception architecture
A fictional temporary or approved deviation with purpose, owner, scope, evidence, compensating controls, expiration, recovery behavior, and removal.
Operational model
A fictional explanation of who runs, monitors, changes, supports, validates, recovers, and governs the architecture.
Recovery architecture
A fictional design for safe continuity, degraded operation, restore order, recovery identity, evidence, validation, and closure.
Portfolio artifact
A fictional educational deliverable that demonstrates reasoning, design, evidence, communication, and reflection without exposing real systems.
Architecture Brief
Eight Fictional Design Areas
Mission and users
The fictional Northbridge Learning Support Service helps students, teachers, and staff submit support requests, view status, and receive approved assistance.
Requirements
Critical read-only status must remain available during limited disruption; accessibility and privacy are non-negotiable.
Primary risk
A design may protect systems while blocking intended users or exposing unnecessary personal information.
Required evidence
User journeys, mission-owner approval, accessibility review, privacy review, and support outcomes.
Core services
The fictional service includes public access, application processing, identity, authorization, data, logging, administration, supplier integration, and recovery capabilities.
Requirements
Each service must have purpose, owner, identity, dependencies, approved paths, evidence, failure behavior, and recovery order.
Primary risk
Hidden dependencies and broad communication may collapse segmentation and recovery.
Required evidence
Service catalog, dependency map, flow matrix, source-health plan, and recovery exercise.
Identity
Fictional human, service, supplier, administrator, automation, observer, emergency, and recovery identities exist.
Requirements
Unique ownership, least privilege, separation of duties, lifecycle, time-bound privilege, and effective-access validation.
Primary risk
One broad identity may bypass segmentation, logging, data, and recovery controls.
Required evidence
Identity inventory, role matrix, approvals, privileged sessions, access reviews, and closure records.
Data and privacy
The fictional service processes support metadata, status, limited user information, and service evidence.
Requirements
Collect and retain only the minimum necessary fields for approved service, security, recovery, and governance questions.
Primary risk
Full message content, broad exports, unnecessary retention, or supplier sharing may increase privacy exposure.
Required evidence
Data inventory, field allowlist, flow map, access review, retention, deletion, and privacy signoff.
Trust boundaries and segmentation
Public, application, identity, data, management, logging, supplier, and recovery zones must remain meaningfully separate.
Requirements
Every crossing needs purpose, identity, action, data scope, owner, control, evidence, failure behavior, and denied alternatives.
Primary risk
Visual zones may be bypassed by broad roles, hidden paths, supplier overreach, or temporary recovery rules.
Required evidence
Boundary register, effective-flow review, denied-path evidence, rule changes, exceptions, and recovery closure.
Logging and evidence
Fictional identity, application, network, data, administrative, supplier, and recovery evidence must answer approved questions.
Requirements
Source health, time quality, schema version, privacy, access, retention, administrative evidence, and resilience are required.
Primary risk
A green dashboard may hide source silence, schema drift, overcollection, or privileged evidence control.
Required evidence
Coverage map, event schema, source-health dashboard, time-quality checks, access review, and reconciliation.
Resilience and recovery
The fictional mission must continue in a limited safe mode during identity, logging, supplier, or platform failure.
Requirements
Separate recovery identity, alternate evidence, local fallback, gated restore order, complete service validation, and temporary-access closure.
Primary risk
The application may return before identity, data, logging, suppliers, users, and trust are restored.
Required evidence
Recovery sequence, restore exercise, source reconciliation, user journeys, owner acceptance, and closure.
Constraints and tradeoffs
The fictional organization has limited budget, two specialized operators, a six-month timeline, a legacy dependency, and supplier reliance.
Requirements
Protect non-negotiable outcomes, stage delivery, preserve accessibility and privacy, and maintain reversibility.
Primary risk
Low purchase cost or fast delivery may create lock-in, shared failure, privacy risk, or permanent transition debt.
Required evidence
Option matrix, lifecycle cost, staffing model, pilot results, rollback, sunset criteria, and decision record.
Architecture Requirements
Ten Measurable Requirements for the Fictional Design
REQ-01
Fictional public users may access only approved public and user-facing functions.
Rationale
Reduces direct exposure to data, management, logging, supplier, and recovery capabilities.
Validation
Approved public journeys succeed; direct requests to protected functions are denied and recorded.
Owners
Mission, application, and network owners.
Failure condition
Public or anonymous access reaches internal service or management functions.
REQ-02
Every fictional service-to-service request must use a registered identity and explicit authorization.
Rationale
Prevents internal location from becoming automatic trust.
Validation
Approved service actions succeed; unregistered identities and unrelated actions are denied and visible.
Owners
Identity, application, and service owners.
Failure condition
Shared credentials or broad internal trust permit unrelated access.
REQ-03
Fictional sensitive data access must be minimum necessary by identity, purpose, fields, action, and duration.
Rationale
Reduces security and privacy exposure.
Validation
Approved fields and actions succeed; unrelated fields, exports, and out-of-purpose access are denied and reviewed.
Owners
Data, privacy, identity, and service owners.
Failure condition
A valid service or user can access all records or full content.
REQ-04
Fictional administrative access must use separate named privilege, approval, time limits, session evidence, and rollback.
Rationale
Separates normal use from high-impact control authority.
Validation
One privileged change is traceable from request through approval, action, result, validation, rollback readiness, and closure.
Owners
Privileged-access, system, evidence, and governance owners.
Failure condition
Shared administration or self-approval controls identity, systems, logs, backups, and evidence.
REQ-05
Fictional evidence must preserve actor, action, target, purpose, decision, result, source, time, health, integrity, and owner.
Rationale
Supports detection, response, recovery, governance, privacy, and leadership decisions.
Validation
Normal, denied, changed, failed, and recovered actions can be reconstructed end to end.
Owners
Evidence, source-system, service, and governance owners.
Failure condition
Events exist without enough context or source confidence to support a decision.
REQ-06
The fictional service must support a limited safe mode during identity, logging, or supplier failure.
Rationale
Preserves critical mission outcomes without uncontrolled fail-open access.
Validation
Read-only status and approved low-risk tasks work; high-risk updates and administration remain blocked.
Owners
Mission, service, identity, evidence, supplier, and recovery owners.
Failure condition
The organization chooses total outage or broad unrestricted fallback.
REQ-07
Fictional recovery must restore identity, authorization, data, services, logging, suppliers, user journeys, and normal access in gated order.
Rationale
Prevents premature recovery declarations.
Validation
All dependency gates and multi-owner acceptance checks pass before closure.
Owners
Recovery, mission, identity, data, service, evidence, and supplier owners.
Failure condition
The application is online while key dependencies or trust remain incomplete.
REQ-08
Fictional temporary exceptions must have purpose, owner, scope, evidence, compensating controls, expiration, remediation, and recovery behavior.
Rationale
Prevents temporary access from becoming permanent architecture debt.
Validation
The exception register matches effective identities, rules, paths, and settings; expired access is removed.
Owners
Security, service, governance, risk, and recovery owners.
Failure condition
An exception lacks current owner, end date, removal evidence, or residual-risk approval.
REQ-09
Fictional accessibility and privacy must remain release gates for user-facing design.
Rationale
Security architecture must protect intended users and minimize unnecessary personal information.
Validation
Diverse user journeys pass; only approved minimum fields are collected and retained.
Owners
Accessibility, privacy, mission, application, and governance owners.
Failure condition
A secure-looking design excludes users or collects unnecessary content.
REQ-10
Fictional architecture changes must be reversible and reviewable.
Rationale
Preserves future choice and reduces risk under uncertainty.
Validation
Pilot, rollback, migration, exit, sunset criteria, review triggers, and revision history are documented and exercised safely.
Owners
Architecture, operations, supplier, recovery, finance, and governance owners.
Failure condition
A temporary or supplier-dependent decision becomes permanent without review.
Architecture Decision Records
Eight Major Fictional Design Decisions
Use a staged hybrid architecture
Reason
Balances fictional staffing, budget, resilience, reversibility, and supplier dependence.
Alternatives
Immediate centralization, distributed specialized tools, or maintaining the current state indefinitely.
Consequence
Transition complexity and temporary duplication require strong sunset ownership and evidence.
Validation
Pilot critical identity, evidence, and recovery functions; test rollback, supplier outage, staffing loss, and closure.
Review trigger
Cost growth, failed accessibility gate, source-health weakness, staffing loss, or missed sunset milestone.
Keep identity and recovery authority in separate failure domains
Reason
Fictional recovery must remain possible during primary identity failure.
Alternatives
Use one production identity platform and administrator group for all normal and recovery actions.
Consequence
Adds governance, custody, exercise, and evidence requirements.
Validation
Run a fictional recovery exercise while the primary identity service is unavailable.
Review trigger
Recovery identity drift, failed exercise, custody gap, or changed identity architecture.
Use question-driven minimum evidence
Reason
Supports fictional decisions while reducing privacy, noise, cost, and retention burden.
Alternatives
Collect all available events or minimize evidence until critical questions cannot be answered.
Consequence
Blind spots must be documented and periodically reviewed.
Validation
Trace approved, denied, changed, failed, and recovered events across critical sources.
Review trigger
New threat model, source failure, privacy change, incident gap, or recovery evidence weakness.
Use mission-based segmentation with identity-aware flows
Reason
Limits fictional blast radius while avoiding trust based only on network location.
Alternatives
Flat internal trust or highly fragmented segmentation without dependency analysis.
Consequence
Requires accurate service identities, flow ownership, denied-path evidence, and recovery path planning.
Validation
Compare approved and effective flows during normal, degraded, supplier-outage, and recovered states.
Review trigger
New service, supplier, data use, hidden dependency, recovery exception, or flow drift.
Make accessibility and privacy non-negotiable release gates
Reason
The fictional service must protect and remain usable by intended users.
Alternatives
Treat accessibility and privacy as post-launch improvements.
Consequence
Some release scope may be reduced or delayed.
Validation
Diverse user pilot, field-minimization review, retention review, and safe alternate flow.
Review trigger
User exclusion, support spike, new data field, supplier change, or privacy concern.
Use secure defaults with explicit exceptions
Reason
Reduces fictional unnecessary capability and architecture drift.
Alternatives
Broad initial access or undocumented one-off configuration.
Consequence
Requires baseline ownership, drift review, dependency analysis, exception expiry, and recovery-state alignment.
Validation
Compare approved baseline with effective state after change, failure, supplier update, and recovery.
Review trigger
Service outage, stale exception, unsupported setting, configuration drift, or outdated restore state.
Use limited safe degraded service
Reason
Preserves fictional critical status and low-risk support while identity, logging, or supplier functions are unavailable.
Alternatives
Total outage or broad fail-open access.
Consequence
The architecture needs preapproved roles, data limits, alternate evidence, communication, and expiry.
Validation
Exercise degraded user journeys and confirm high-risk actions remain denied.
Review trigger
Mission change, new dependency, failed exercise, source-health gap, or broadened fallback.
Require complete multi-owner recovery acceptance
Reason
Application availability alone does not prove fictional mission recovery.
Alternatives
Close recovery when the main system starts.
Consequence
Recovery may remain open longer while identity, data, evidence, suppliers, users, and temporary access are validated.
Validation
Pass identity, authorization, data, service, logging, supplier, accessibility, communication, and closure checks.
Review trigger
Missed recovery target, data gap, unreconciled evidence, failed user journey, or open temporary access.
Control Stacks
Six Layered Fictional Control Objectives
Prevent broad privileged control
Preventive
Fictional separate identities, least privilege, just-in-time access, target allowlists, and separation of duties.
Detective
Privileged-session evidence, approval comparison, role-drift review, source health, and unusual-action alerts.
Responsive
Suspend narrow privilege, preserve evidence, validate changes, communicate owners, and use rollback.
Recovery
Use separately governed recovery identities and restore normal roles after validation.
Governance
Access reviews, conflict reviews, exception expiry, residual-risk decisions, and corrective actions.
Protect sensitive fictional data
Preventive
Purpose limitation, field allowlists, service identity, explicit authorization, export limits, and retention defaults.
Detective
Data-access evidence, volume review, denied-field events, export alerts, integrity, and source health.
Responsive
Limit access, preserve evidence, validate purpose, notify owners, and correct scope.
Recovery
Restore trusted data state, validate integrity and field scope, and reconcile gaps.
Governance
Privacy review, retention, deletion, supplier scope, exceptions, and owner signoff.
Preserve segmentation
Preventive
Mission-based zones, identity-aware flows, default deny, protected management, supplier, logging, and recovery paths.
Detective
Allowed and denied-flow records, rule changes, architecture drift, exceptions, and source health.
Responsive
Pause unapproved paths, narrow rules, preserve service, validate dependencies, and update architecture.
Recovery
Use approved temporary recovery paths with expiration and effective-state closure.
Governance
Flow ownership, rule hygiene, exception review, supplier review, and residual risk.
Maintain trustworthy evidence
Preventive
Question-driven schemas, minimum fields, source identity, time quality, integrity, separate administration, and protected retention.
Detective
Source-health alerts, schema tests, parser-version checks, access review, time-quality monitoring, and gap detection.
Responsive
Reduce confidence, seek alternate evidence, repair source or schema, reconcile records, and update cases.
Recovery
Restore sources, transport, parsing, access, storage, and delayed-event reconciliation.
Governance
Coverage review, privacy minimization, retention, blind-spot acceptance, and administrative evidence.
Support safe continuity
Preventive
Redundancy conceptually, separate failure domains, recovery identities, trusted restore states, dependency maps, and runbooks.
Detective
Service health, backup integrity, source health, dependency failure, recovery gate status, and user-journey checks.
Responsive
Enter limited safe mode, protect evidence and backups, coordinate owners, and communicate uncertainty.
Recovery
Restore identity, data, services, logging, suppliers, users, and normal access in approved order.
Governance
Recovery exercises, corrective actions, owner coverage, closure evidence, and residual-risk decisions.
Control supplier dependence
Preventive
Named supplier identity, sponsor, narrow paths, data limits, contract purpose, expiration, fallback, and portability.
Detective
Supplier health, access, data scope, flow evidence, changes, support sessions, and expiration review.
Responsive
Pause unapproved reach, preserve evidence, use fallback, communicate owners, and correct scope.
Recovery
Revalidate supplier identity, health, interface, data, evidence, and user impact before full use.
Governance
Supplier register, service requirements, exit test, residual risk, and renewal decision.
Validation Scenarios
Eight Conditions the Fictional Architecture Must Survive
Normal operation
Do fictional users, services, identities, data, evidence, suppliers, and administrators operate only through approved paths and roles?
Tests
Critical user journeys, service authorization, data scope, denied paths, privileged session, source health, and owner review.
Success criteria
Approved actions succeed; unrelated actions are denied; evidence is complete; privacy and accessibility gates pass.
Failure condition
Broad trust, missing context, user exclusion, or hidden path appears.
Identity service failure
Can the fictional mission continue in a limited safe mode without uncontrolled privilege?
Tests
Alternate identity assurance, low-risk roles, blocked high-impact actions, independent approval, alternate evidence, expiry, and recovery.
Success criteria
Critical status remains available; risky actions stay blocked; recovery identity remains separate and accountable.
Failure condition
Every user becomes trusted or every service stops unnecessarily.
Logging platform failure
Can fictional high-impact decisions remain cautious and attributable with minimum alternate evidence?
Tests
Source buffering conceptually, alternate records, action limits, manual review, source health, time quality, and reconciliation.
Success criteria
Minimum questions remain answerable; uncertainty is explicit; delayed evidence reconciles after restoration.
Failure condition
Silence is treated as safety or high-impact actions continue without evidence.
Supplier outage
Can the fictional mission continue safely without the external service?
Tests
Local fallback, narrow data use, alternate communication, owner decision, evidence, recovery, and exit readiness.
Success criteria
Critical service continues in limited mode and full supplier use resumes only after scope and health validation.
Failure condition
The mission stops completely or broad emergency supplier access is granted.
Configuration change failure
Can the fictional architecture detect mission impact, preserve the security objective, and roll back safely?
Tests
Change evidence, hidden dependency review, service health, rollback, denied actions, owner communication, and baseline update.
Success criteria
The change is paused or rolled back, the minimum dependency is documented, and broad access is not restored.
Failure condition
The organization removes all hardening or leaves the outage unresolved.
Recovery from disruption
Can fictional identity, data, services, logging, suppliers, users, communication, and normal access be restored in gated order?
Tests
Restore integrity, dependency gates, user journeys, source reconciliation, temporary-access closure, and owner acceptance.
Success criteria
Complete mission outcome passes and all temporary trust is closed or formally governed.
Failure condition
The application is online while dependencies, evidence, users, or access closure remain incomplete.
Rapid growth
Can the fictional architecture scale without expanding broad trust, overcollection, complexity, or supplier lock-in?
Tests
Capacity assumptions, identity lifecycle, segmentation, evidence volume, staffing, cost, privacy, and recovery.
Success criteria
Growth preserves minimum access, source health, owner coverage, user accessibility, and reversible decisions.
Failure condition
Scaling depends on shared identities, disabled evidence, broad paths, or unreviewed data collection.
Staffing loss
Can fictional alternate owners operate, change, validate, and recover the architecture?
Tests
Runbooks, role separation, alternate approvals, training, support, change, rollback, and recovery exercise.
Success criteria
Another authorized operator completes a safe change and recovery without privilege concentration.
Failure condition
Only one person understands or controls the design.
Lab Workflow
Ten Phases from Mission Brief to Portfolio Presentation
Phase 1: Frame the mission
Define fictional users, critical functions, data, service outcomes, accessibility, privacy, and recovery priorities.
Deliverable
Mission and stakeholder brief.
Validation gate
Mission owner confirms the problem and non-negotiable outcomes.
Failure pattern
The design begins with tools or controls before mission context.
Phase 2: Map the system context
Identify fictional systems, identities, services, suppliers, data, owners, environments, paths, and external relationships.
Deliverable
System-context and ownership diagram.
Validation gate
Every major component and relationship has current purpose and owner.
Failure pattern
Important supplier, administrative, evidence, or recovery elements remain outside the model.
Phase 3: Model trust and flows
Define fictional trust assumptions, boundaries, zones, approved flows, denied paths, data scope, and service identities.
Deliverable
Trust-boundary, zone, and flow package.
Validation gate
Every crossing has identity, purpose, action, data, owner, control, and evidence.
Failure pattern
Internal location or diagram color is treated as trust.
Phase 4: Design identity and privilege
Create fictional roles, service identities, supplier access, privileged access, lifecycle, emergency, and recovery identities.
Deliverable
Identity, role, lifecycle, and separation-of-duties package.
Validation gate
No one identity controls approval, execution, evidence, recovery, and risk acceptance.
Failure pattern
Shared or broad privilege bypasses the architecture.
Phase 5: Design control stacks
Choose fictional preventive, detective, responsive, recovery, governance, and compensating controls for major risks.
Deliverable
Control-objective and control-stack matrix.
Validation gate
Each control has owner, evidence, failure behavior, recovery, and validation.
Failure pattern
One control is treated as complete protection.
Phase 6: Design evidence
Define fictional evidence questions, sources, fields, health, time quality, integrity, access, retention, privacy, and resilience.
Deliverable
Logging, visibility, and evidence-chain package.
Validation gate
Critical normal, denied, changed, failed, and recovered actions are reconstructable.
Failure pattern
High event volume hides blind spots or overcollection.
Phase 7: Design resilience and recovery
Define fictional safe degraded modes, dependencies, restore states, recovery order, communication, evidence, closure, and acceptance.
Deliverable
Resilience, recovery, and continuity package.
Validation gate
The complete mission—not only the main application—can be recovered and validated.
Failure pattern
Recovery shares the same identity, evidence, or supplier failure domain.
Phase 8: Evaluate tradeoffs
Compare fictional options across mission, security, privacy, accessibility, availability, operations, cost, evidence, suppliers, recovery, and reversibility.
Deliverable
Option matrix and architecture decision records.
Validation gate
The selected option satisfies non-negotiable requirements and states its disadvantages.
Failure pattern
Criteria change to favor a preferred answer.
Phase 9: Validate scenarios
Evaluate fictional normal, degraded, failed, recovered, changed, supplier-outage, growth, and staffing-loss conditions.
Deliverable
Scenario, evidence, and validation package.
Validation gate
Owners agree that success criteria and stop conditions are met.
Failure pattern
The architecture is validated only in normal conditions.
Phase 10: Package and present
Create fictional diagrams, matrices, decision records, risk statements, executive summary, portfolio reflection, and revision history.
Deliverable
Complete security architecture design portfolio.
Validation gate
The artifact is clear, internally consistent, fully fictional, privacy-safe, and decision-ready.
Failure pattern
The package exposes real details or hides unresolved risk.
Architecture Ownership
Ten Owners for Mission, Identity, Data, Evidence, Recovery, Suppliers, and Risk
Mission owner
Owns
Fictional critical functions, users, service priorities, accessibility, acceptable disruption, recovery outcomes, and business risk.
Primary decision
Whether the architecture supports the complete mission.
Required evidence
Mission brief, user journeys, service impact, recovery acceptance, and risk decision.
Security architect
Owns
Fictional system context, trust model, requirements, patterns, decisions, control stacks, failure domains, and integrated validation.
Primary decision
Whether the architecture is coherent, layered, visible, recoverable, and governed.
Required evidence
Architecture package, decision records, control matrix, scenarios, and revision history.
Identity and privileged-access owner
Owns
Fictional human, service, supplier, administrator, automation, emergency, observer, and recovery identities.
Primary decision
Which identities may perform which actions, under which conditions, and for how long.
Required evidence
Identity inventory, roles, approvals, sessions, lifecycle, reviews, and closure.
Application and service owner
Owns
Fictional service functions, interfaces, dependencies, performance, user outcomes, errors, change, and rollback.
Primary decision
Which service capabilities and dependencies are minimum necessary.
Required evidence
Service map, interface catalog, health, dependency tests, change, rollback, and user journeys.
Data and privacy owner
Owns
Fictional data purpose, fields, access, sharing, logging, retention, deletion, supplier use, integrity, and restore states.
Primary decision
Which data use and evidence fields are necessary and proportionate.
Required evidence
Data inventory, flow map, field scope, access review, retention, deletion, and restore validation.
Network and platform owner
Owns
Fictional zones, paths, rules, platform services, configuration, health, drift, change, rollback, and recovery connectivity.
Primary decision
Which communication and platform states are supportable and safe.
Required evidence
Zone map, flow matrix, rule inventory, effective paths, changes, health, and rollback.
Detection and evidence owner
Owns
Fictional evidence questions, sources, schema, source health, time quality, integrity, access, retention, alerts, and reconciliation.
Primary decision
Whether important architecture behavior can be reconstructed with stated confidence.
Required evidence
Coverage map, source catalog, event samples, health, access, retention, gaps, and reconciliation.
Recovery and continuity owner
Owns
Fictional degraded mode, backups, restore states, recovery identities, sequence, communication, evidence, closure, and exercises.
Primary decision
Whether the architecture can continue and recover safely.
Required evidence
Recovery plan, exercise, restore records, source reconciliation, user journeys, closure, and signoff.
Supplier and resource owner
Owns
Fictional supplier scope, cost, staffing, service requirements, evidence, fallback, portability, change, and exit.
Primary decision
Whether supplier and resource constraints are sustainable and acceptable.
Required evidence
Supplier register, lifecycle cost, staffing model, service evidence, fallback, exit test, and review.
Governance and risk owner
Owns
Fictional requirements, assumptions, exceptions, residual risk, debt, corrective actions, deadlines, review triggers, and final acceptance.
Primary decision
Whether the remaining architecture risk is accepted, reduced, transferred, avoided, or monitored.
Required evidence
Decision records, risk register, exception register, owners, deadlines, corrective evidence, and signoff.
Fake Dashboard
Fake Northbridge Integrated Architecture Dashboard
Fictional mission, trust, identity, data, evidence, recovery, accessibility, supplier, and decision review for training only.
Architecture requirements
10
Fictional mission, identity, data, administration, evidence, continuity, recovery, exceptions, accessibility, and reversibility requirements are included.
Major design gaps
8
Undocumented path, broad role, evidence gaps, privacy overcollection, shared recovery failure, accessibility failure, stale transition rules, and weak closure remain.
Current decision
Redesign
The fictional architecture should not receive final approval until integrated validation gates pass.
Fake SOC Alert
Integrated Architecture Fails Multiple Non-Negotiable Gates
Source: Fake Northbridge Architecture Review Console • Time: 11:26 PM
The fictional design has an undocumented public-to-management path, cross-domain support privilege, incomplete management and recovery evidence, unnecessary full-content logging, recovery dependence on the primary identity platform, accessibility failure, and transition rules without reliable sunset closure.
Defensive recommendation: Pause final approval, preserve limited safe service, redesign trust and identity, minimize evidence, separate recovery authority, fix accessibility, govern transition rules, run all validation scenarios, close temporary access, and obtain multi-owner acceptance.
Fake Log Panel
Fake Integrated Architecture Review Timeline
training-log-viewer.log
22:00 MISSION critical-status='required' 22:01 GATE accessibility='required' 22:02 GATE privacy='required' 22:10 FLOW public-to-management='undocumented' 22:20 ROLE support='cross-domain-broad' 22:30 EVIDENCE management='partial' 22:31 EVIDENCE recovery='partial' 22:40 PRIVACY full-support-content='collected' 22:50 RECOVERY identity-dependency='shared-primary' 23:00 ACCESSIBILITY alternate-flow='failed' 23:10 TRANSITION temporary-rules='no-sunset-owner' 23:15 SUPPLIER fallback='incomplete' 23:18 RECOVERY closure='not-proven' 23:20 DECISION final-approval='paused' 23:22 ACTION integrated-redesign='required' 23:26 STATUS architecture='not-ready'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Evidence before Final Architecture Approval
LAB-01
Fictional mission brief
Observation
Critical status access, accessibility, privacy, and limited continuity are non-negotiable.
Supports
The architecture must preserve user and mission outcomes, not only technical controls.
Does not prove
Does not specify the complete control design.
Architecture use
Create measurable requirements and release gates.
LAB-02
Fictional system-context review
Observation
Identity, logging, supplier, and recovery services share one platform and administrator group.
Supports
Correlated failure and privilege concentration may exist.
Does not prove
Does not prove the platform will fail or the design must be rejected.
Architecture use
Separate recovery authority, alternate evidence, administration, and supplier fallback.
LAB-03
Fictional effective-flow review
Observation
The public application reaches a management service through an undocumented path.
Supports
Trust-boundary and segmentation drift may exist.
Does not prove
Does not prove harmful use.
Architecture use
Validate purpose, identity, action, data, owner, evidence, and correction.
LAB-04
Fictional role matrix
Observation
One support role includes application, data, identity, logging, backup, and recovery permissions.
Supports
The architecture violates least privilege and separation of duties.
Does not prove
Does not prove the role has been misused.
Architecture use
Split duties, use temporary privilege, preserve independent evidence, and validate effective access.
LAB-05
Fictional evidence review
Observation
Management and recovery sources are incomplete, while full support-message content is collected.
Supports
The architecture has both visibility gaps and privacy overcollection.
Does not prove
Does not prove current harm or total evidence failure.
Architecture use
Add question-driven sources and minimize unnecessary content.
LAB-06
Fictional recovery exercise
Observation
The application returned before identity synchronization, supplier validation, evidence reconciliation, and temporary-access closure.
Supports
Complete mission recovery was declared too early.
Does not prove
Does not prove the application itself was unavailable.
Architecture use
Add dependency gates, multi-owner validation, reconciliation, and closure.
LAB-07
Fictional accessibility pilot
Observation
One proposed identity flow excludes users who require an approved accessible alternative.
Supports
The design fails a non-negotiable user requirement.
Does not prove
Does not prove the entire identity model must be removed.
Architecture use
Redesign the flow, preserve security, and retest with diverse users.
LAB-08
Fictional architecture decision history
Observation
A previous temporary migration remained for years without a sunset owner or review trigger.
Supports
Transition architecture can become permanent debt.
Does not prove
Does not prove a staged design must fail again.
Architecture use
Require milestones, sunset criteria, rollback, transition owners, and review triggers.
Analyze the Evidence
Should the Fictional Architecture Receive Final Approval?
Critical status access, accessibility, privacy, and limited continuity are non-negotiable.
The public application reaches a management service through an undocumented path.
One support role includes application, data, identity, logging, backup, and recovery permissions.
Management and recovery evidence sources are incomplete.
Full support-message content is collected even though minimum metadata answers approved questions.
Recovery identity and logging depend on the same primary platform and administrator group.
One proposed identity flow fails accessibility testing.
Temporary migration rules have no reliable sunset owner or closure evidence.
Should the current fictional Northbridge architecture receive final approval?
Common Architecture Lab Mistakes
What Advanced Defenders Must Avoid
Starting the fictional architecture lab with tools or products instead of mission, users, data, trust, constraints, and recovery outcomes.
Drawing zones without defining identities, data, allowed flows, denied flows, owners, evidence, failure, and recovery.
Treating one control, supplier, platform, identity provider, or dashboard as complete protection.
Using broad fictional support or administrator roles that bypass every domain.
Collecting large fictional event volume while missing administrative, denied, supplier, or recovery evidence.
Designing strong controls that exclude intended users or collect unnecessary personal information.
Ignoring fictional hidden dependencies until hardening or segmentation causes outage.
Restoring the fictional main application before identity, data, logging, suppliers, users, and temporary access are validated.
Comparing architecture options with inconsistent criteria or unrealistic alternatives.
Ignoring lifecycle cost, staffing, supplier lock-in, portability, exit, and future flexibility.
Allowing fictional exceptions or transition architecture to remain without owner, expiry, remediation, and closure.
Using diagrams or policy documents as proof of effective state.
Failing to validate normal, degraded, failed, recovered, changed, growth, supplier-outage, and staffing-loss conditions.
Hiding fictional uncertainty, disadvantages, blind spots, residual risk, or incomplete evidence from decision-makers.
Using real internal diagrams, system names, identities, data, costs, suppliers, configurations, logs, incidents, or decisions in the portfolio.
Safe Practice Lab
Complete the Fictional Northbridge Architecture
Fictional assignment
Produce the Final A2 Architecture Package
Use only the invented evidence on this page. Do not upload, copy, quote, lightly modify, summarize, or reproduce real diagrams, systems, identities, addresses, configurations, logs, costs, suppliers, incidents, contracts, recovery plans, or private data.
Required deliverables
- Fictional mission, stakeholder, accessibility, privacy, and recovery brief.
- System-context, ownership, dependency, and trust-boundary diagrams.
- Zone catalog, approved and denied flow matrix, and service-identity model.
- Architecture requirements and decision records.
- Role, privilege, lifecycle, supplier, emergency, and recovery identity package.
- Preventive, detective, responsive, recovery, governance, and compensating control stacks.
- Evidence questions, source catalog, schema, source health, privacy, retention, blind spots, and resilience.
- Secure-default baseline, exception register, configuration-drift, rollback, and restored-state comparison.
- Normal, degraded, failed, recovered, supplier-outage, growth, staffing-loss, and change-failure validations.
- Executive summary, residual-risk decision, corrective actions, reflection, revision history, and complete fictionalization statement.
This activity creates a fictional educational architecture only. It does not authorize system access, testing, scanning, configuration, monitoring, recovery, purchasing, contracting, investigation, or collection involving any real organization or system.
Scenario Decision Lab
The Architecture Works Normally but Fails during Identity Outage
In fictional normal operation, users can access the support service. During an identity outage, however, every service stops because approval, administration, logging access, and recovery all depend on the same identity platform.
Scenario Decision Lab
The Preferred Option Fails Accessibility and Privacy Gates
A fictional architecture option is fast, low-cost, and highly visible, but several intended users cannot complete the identity flow and the evidence design collects full support-message content unnecessarily.
Advanced Challenge
Defend the Final Architecture before a Review Board
Prepare a fictional ten-minute architecture defense for a review board containing the mission owner, privacy owner, accessibility owner, service owner, recovery owner, supplier owner, finance owner, and governance owner. Explain the selected architecture, rejected alternatives, non-negotiable requirements, trust model, control stacks, evidence design, degraded service, recovery, costs, staffing, supplier dependence, residual risk, corrective actions, sunset criteria, and review triggers.
Required defense
Use only fictional diagrams, matrices, evidence, options, owners, costs, assumptions, and outcomes. State disadvantages and uncertainty honestly.
Required response
Answer one challenge about privacy, one about accessibility, one about failure, one about cost, one about evidence, and one about recovery.
Defender Habits
Security Architecture Design Lab Checklist
Check Your Understanding
A2.10 Mini Quiz: Security Architecture Design Lab
Choose your answers first. Explanations appear only after submission.
1. What should begin a fictional security architecture design lab?
2. What makes a fictional architecture requirement strong?
3. A fictional diagram has many zones, but one support role reaches all of them. What is strongest?
4. What is strongest evidence that fictional visibility is well designed?
5. When should fictional recovery be declared complete?
6. What is strongest when fictional uncertainty remains high?
7. What makes an A2.10 portfolio artifact safe to share?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Security Architecture Design Portfolio for Northbridge. Include the mission and stakeholder brief, accessibility and privacy gates, system-context diagram, ownership map, dependency map, trust assumptions, trust-boundary register, zone catalog, approved and denied flows, service identities, architecture requirements, decision records, role and privilege matrix, lifecycle design, supplier access, control stacks, evidence questions, source catalog, event schema, source health, time quality, privacy minimization, retention, blind spots, resilience, secure defaults, baselines, exceptions, configuration drift, rollback, recovery architecture, degraded modes, validation scenarios, lifecycle cost, staffing, supplier lock-in, pilot, sunset criteria, residual risk, corrective actions, executive summary, reflection, revision history, and a statement that every organization, system, identity, data flow, configuration, source, cost, supplier, decision, date, and outcome is invented.
Make the fictional package internally consistent: identities, flows, logs, recovery, and decision records should describe the same architecture.
State non-negotiable accessibility, privacy, evidence, and recovery requirements before selecting controls or options.
Include at least one failed scenario and show how the architecture changes in response.
Show effective-state validation rather than relying only on intended diagrams and policies.
Keep every organization, system, identity, data flow, configuration, source, cost, supplier, decision, date, and outcome completely invented.
Confidence / Readiness Reflection
Are You Ready for the A2 Module Test?
Before taking the module test, rate your readiness from 1 to 5 for each area: mission framing, system context, trust boundaries, segmentation, identity, evidence, resilience, hardening, tradeoffs, decision records, validation, governance, residual risk, and portfolio communication.
I can explain how fictional mission, trust, identity, data, evidence, recovery, privacy, accessibility, and cost influence one another.
I can build fictional measurable requirements, control stacks, decision records, validation gates, and owner maps.
I can identify fictional broad privilege, hidden paths, overcollection, source gaps, correlated failure, stale exceptions, and transition debt.
I can validate fictional normal, degraded, failed, recovered, supplier-outage, growth, staffing-loss, and change-failure scenarios.
I can state fictional uncertainty, disadvantages, blind spots, residual risk, corrective actions, and review triggers honestly.
I can keep the entire architecture design portfolio fully invented, defensive, and safe to share.
Record one fictional architecture strength, one unresolved residual risk, one validation result that changed your design, and one topic you will review before the A2 module test.
Key Takeaways
What You Should Remember
1.Security architecture integrates fictional mission, users, trust, identities, data, paths, controls, evidence, suppliers, recovery, and governance.
2.A strong fictional requirement is measurable, owned, justified, testable, and connected to failure conditions.
3.Trust boundaries and segmentation are meaningful only when identities, actions, data, paths, owners, evidence, and denied alternatives are explicit.
4.Control stacks combine fictional preventive, detective, responsive, recovery, governance, and compensating measures.
5.Question-driven fictional evidence must include source health, time quality, context, privacy, access, retention, confidence, and limitations.
6.Resilience requires fictional safe degraded service, separate recovery authority, alternate evidence, gated restoration, and temporary-access closure.
7.Secure defaults reduce fictional unnecessary capability, while exceptions require owner, scope, evidence, expiry, remediation, and recovery behavior.
8.Tradeoff decisions should compare fictional security, privacy, accessibility, availability, operations, cost, suppliers, evidence, recovery, and reversibility consistently.
9.Final architecture approval requires fictional normal and abnormal scenario validation, multi-owner acceptance, residual-risk decisions, corrective actions, and revision history.
10.Every CyberShield architecture design artifact must remain fully fictional, defensive, non-operational, privacy-safe, and incapable of exposing real organizations or systems.
Navigation