Learn how professional defenders identify what has value, who or what interacts with that value, and through which approved interfaces those interactions occur. Build a fictional relationship model that connects mission outcomes, data, identity, services, operations, evidence, privacy, trust, recovery, authority, ownership, expected behavior, controls, and review triggers.
Lesson Progress
High School Advanced • A3: Threat Modeling • Lesson 2 of 10
Readiness Check
0/6 ready
Professional Hook
A fictional Northbridge team describes its student-support portal as “a website and a database.” That description misses the outcomes students depend on, the authority represented by counselor and support identities, the privacy value of uploaded records, the integrity of case status, the evidence needed to review administrative actions, the supplier relationship that processes documents, the notification workflow that communicates decisions, and the recovery identities that restore service. It also fails to show which actors use which interfaces to affect those assets.
Weak inventory
“Website, database, users, admins, API.” This list is too vague to support ownership, trust, authority, privacy, evidence, recovery, or later risk decisions.
Decision-ready relationship
“The fictional support analyst role uses the controlled support console to correct notification preferences for verified users; the action affects identity, privacy, communication, and audit assets and requires reason, confirmation, evidence, review, and an accountable role owner.”
Exactly Five Learning Objectives
Objective 1
Classify fictional assets by mission value, data sensitivity, identity authority, service dependency, privacy impact, operational importance, trust, safety, evidence, and recovery needs.
Objective 2
Distinguish fictional actors by role, relationship, identity type, authority, lifecycle, origin, trust basis, expected behavior, and accountability without making unsupported claims about intent.
Objective 3
Identify and document approved fictional entry points through which requests, identities, data, files, messages, administrative actions, recovery actions, or supplier interactions enter a system.
Objective 4
Connect fictional assets, actors, and entry points to owners, business purpose, control expectations, evidence sources, assumptions, unknowns, and review triggers.
Objective 5
Create a portfolio-ready fictional Asset–Actor–Entry Point Register that remains ethical, defensive, non-operational, privacy-safe, and completely invented.
Why This Matters
A list of fictional assets without actors does not explain who or what can affect them. A list of actors without entry points does not explain how their actions enter the system. A list of entry points without assets does not explain what value is at stake. Professional threat modeling connects all three so teams can ask precise defensive questions.
What fictional value, outcome, authority, evidence, privacy expectation, trust relationship, or recovery capability requires protection?
Who or what interacts with that value, under which role, relationship, identity, authority, conditions, lifecycle, and expected behavior?
Through which approved fictional interface does the interaction occur, and who owns its purpose, validation, monitoring, change, failure, and retirement?
Core relationship statement
A fictional actor uses an approved entry point to perform an authorized action that affects one or more assets for a documented purpose, under defined conditions, controls, evidence, accountability, failure handling, and lifecycle decisions.
Core Framework
1. Asset
Identify the fictional mission, data, identity, service, process, evidence, privacy, safety, trust, or recovery value.
Record purpose, owner, classification, criticality, dependencies, impact, recovery, evidence, confidence, and review trigger.
2. Actor
Identify the fictional human or non-human role, relationship, identity type, authority, conditions, expected behavior, lifecycle, owner, and accountability.
Do not confuse actor category with intent, trustworthiness, or proof of harmful behavior.
3. Entry Point
Identify the fictional interface purpose, accepted interaction, connected actors, affected assets, owner, validation, authorization, monitoring, failure, and lifecycle.
Keep descriptions conceptual and defensive rather than operational or tied to a real system.
Relationship record template
Advanced Vocabulary
A fictional item, capability, outcome, relationship, or condition with value that requires protection from loss of confidentiality, integrity, availability, privacy, safety, trust, accountability, or recoverability.
A fictional service outcome, critical function, decision, workflow, or public responsibility that the organization must perform reliably.
A fictional record, message, document, event, metadata set, model output, configuration, report, or derived information that has business, privacy, legal, operational, or security value.
A fictional account, role, credential relationship, trust assertion, authorization state, recovery process, or identity lifecycle record that controls who or what may act.
A fictional application, API, queue, storage service, identity provider, notification service, processing function, archive, backup, or dependency required to deliver an outcome.
A fictional procedure, staffing capability, support workflow, monitoring practice, recovery process, supplier relationship, or knowledge base needed to operate safely.
A fictional relationship, reputation, assurance, approval, evidence trail, or user expectation whose loss could damage confidence or decision quality.
A fictional log, record, timestamp, approval, ticket, event history, change record, alert, health signal, or audit trail needed to explain or validate activity.
A fictional human, service, workload, device, supplier, automation, administrator, reviewer, support role, emergency role, or unknown party that interacts with the system.
A fictional person or role such as a student, counselor, support analyst, administrator, reviewer, supplier operator, or approver.
A fictional service, workload, device, process, scheduled task, integration, automation, or system identity that sends requests or performs actions.
The fictional basis for interaction, such as employee, student, customer, supplier, service dependency, administrator, auditor, temporary worker, or unknown external party.
The fictional set of actions an actor is permitted to perform, including limits, conditions, purpose, duration, approval, and evidence requirements.
An approved fictional interface through which a request, identity, file, message, data item, administrative action, recovery action, or supplier interaction enters a system.
The fictional role accountable for the purpose, configuration, validation, monitoring, lifecycle, and risk decisions associated with an entry point.
The fictional actions, volumes, timing, data types, sources, destinations, approvals, and outcomes considered normal for an actor using an entry point.
The fictional degree to which an asset, actor relationship, or entry point is reachable, discoverable, shared, privileged, externally dependent, or difficult to monitor.
The fictional records used to support asset, actor, and entry-point claims, such as approved diagrams, role maps, service catalogs, data inventories, tickets, owner interviews, and interface lists.
A fictional asset that lacks a confirmed owner, purpose, classification, lifecycle decision, recovery requirement, or evidence source.
A fictional interface that exists in the model but lacks an accountable owner for validation, authorization, monitoring, change, and retirement.
Instructional Section 1
A strong fictional asset inventory begins with mission and user outcomes, then connects supporting data, identities, services, operations, evidence, privacy, trust, safety, and recovery. The category does not determine priority by itself. Priority depends on context, dependencies, impact, authority, evidence, uncertainty, and recoverability.
Fictional examples
Fictional student-support availability, accurate case status, approved counselor decisions, timely notification, fair access, and successful recovery.
Defender questions
Which outcome must continue? What harm occurs if it is unavailable, incorrect, delayed, private information is exposed, or users cannot trust it?
Likely owners
Mission owner, service owner, program leader, or accountable executive.
Supporting evidence
Service objectives, business-impact notes, user journeys, continuity requirements, approved policies, and stakeholder decisions.
Common gap
Teams inventory servers and databases but fail to record the outcome those technologies exist to protect.
Fictional examples
Fictional uploaded documents, case records, status events, notification preferences, identity attributes, audit records, reports, and derived analytics.
Defender questions
Why is each field needed? Who may use it? Where does it flow? How long is it retained? What accuracy, privacy, integrity, and deletion requirements apply?
Likely owners
Data owner, privacy owner, records owner, application owner, or business process owner.
Supporting evidence
Data inventories, field-purpose records, classification notes, retention schedules, privacy reviews, and approved sharing decisions.
Common gap
A database name is listed, but the model does not distinguish data purpose, sensitivity, derived information, metadata, copies, or lifecycle.
Fictional examples
Fictional student accounts, counselor roles, support privileges, service identities, supplier identities, approval states, reset processes, and access-review evidence.
Defender questions
Who or what may act? Under which role, condition, purpose, duration, device, location, approval, and evidence requirements?
Likely owners
Identity owner, application owner, role owner, privileged-access owner, or business approver.
Supporting evidence
Role definitions, access policies, lifecycle records, approval tickets, access reviews, authentication logs, and ownership decisions.
Common gap
Accounts are treated only as credentials instead of assets that represent authority, trust, accountability, and recovery.
Fictional examples
Fictional portal, identity provider, validation service, processing supplier, notification service, storage, archive, monitoring, queue, backup, and recovery platform.
Defender questions
Which function does the service provide? What depends on it? Which state, availability, integrity, identity, configuration, and evidence must be protected?
Likely owners
System owner, platform owner, service owner, cloud owner, supplier owner, or operations owner.
Supporting evidence
Service catalogs, architecture views, dependency maps, support records, availability targets, configuration standards, and recovery exercises.
Common gap
A component is listed without its mission purpose, dependencies, failure behavior, owner, or replacement and retirement plan.
Fictional examples
Fictional account recovery, case review, document reprocessing, incident communication, shift handoff, supplier escalation, backup restoration, and change approval.
Defender questions
Which people, steps, approvals, records, timing, fallback paths, and knowledge are required for the process to work safely?
Likely owners
Process owner, operations manager, service desk owner, incident owner, recovery owner, or supplier manager.
Supporting evidence
Runbooks, tickets, process maps, exercise results, staffing plans, handoff records, and approval histories.
Common gap
The technical system is modeled while manual workarounds, support privileges, emergency steps, and communication dependencies remain invisible.
Fictional examples
Fictional authentication events, administrative action records, source-health signals, approval history, notification changes, deletion records, recovery evidence, and case notes.
Defender questions
Which defender question must the evidence answer? Is actor, target, action, reason, result, source health, and time context available and trustworthy?
Likely owners
Security operations owner, application owner, audit owner, identity owner, data owner, or process owner.
Supporting evidence
Logging requirements, event schemas, source-health dashboards, retention decisions, review procedures, and test results.
Common gap
Logs are assumed to exist, but their completeness, meaning, reliability, ownership, privacy, and review value are not modeled.
Fictional examples
Fictional user expectations, confidentiality, consent records, appropriate data use, safe communications, equitable service, reputation, and responsible decision-making.
Defender questions
Which harms affect people even if the system remains technically available? Which expectations, rights, relationships, or safety outcomes require protection?
Likely owners
Privacy owner, safety owner, legal or policy owner, communications owner, mission owner, or leadership.
Supporting evidence
Privacy assessments, user expectations, consent and notice records, policy decisions, complaint themes, and stakeholder review.
Common gap
Technical availability is treated as success even when privacy, communication, fairness, safety, or trust outcomes fail.
Fictional examples
Fictional backups, restoration procedures, recovery identities, configuration baselines, contact trees, alternate workflows, dependency recovery order, and validation records.
Defender questions
What must be restored, in which order, by whom, using which trusted evidence, within which target, and how will safe operation be validated?
Likely owners
Recovery owner, system owner, operations owner, data owner, identity owner, supplier manager, or mission owner.
Supporting evidence
Backup inventories, restore tests, recovery plans, exercise results, dependency maps, recovery approvals, and post-restoration validation.
Common gap
Backups are listed as assets, but restoration authority, dependencies, integrity checks, communication, and usable business state are not.
Instructional Section 2
Actor inventories must remain neutral and evidence-aware. A fictional external request is not automatically hostile. An administrator is not automatically trusted for every purpose. A service identity is not less important because no person signs in with it. Describe what is known, what authority exists, what behavior is expected, which evidence is available, and what remains unknown.
Fictional examples
Students submitting records, guardians reviewing status, counselors evaluating cases, and approved staff viewing assigned work.
Expected behavior
Use approved interfaces for assigned purposes with appropriate identity proof, session controls, data limits, and support paths.
Authority questions
Which records can each role view, submit, update, withdraw, or appeal? Does access depend on assignment, status, age, consent, or case ownership?
Lifecycle
Enrollment, role change, inactivity, graduation, transfer, revocation, and recovery.
Evidence
Approved role definitions, access policies, assignment records, session events, access reviews, and user-support records.
Fictional examples
Platform administrators, identity administrators, application operators, database operators, and recovery administrators.
Expected behavior
Perform approved administrative actions through controlled interfaces with limited scope, strong identity, justification, review, and evidence.
Authority questions
Which privileged action is necessary? Is approval required? Can duties be separated? What emergency path exists? Which evidence supports review?
Lifecycle
Appointment, training, approval, time-bound assignment, periodic review, emergency elevation, role change, and removal.
Evidence
Privileged-role records, approvals, administrative events, change tickets, review logs, and emergency-access records.
Fictional examples
Account-recovery staff, case-status support, notification support, document-reprocessing support, and escalation coordinators.
Expected behavior
Resolve approved user problems without receiving more data or authority than the support purpose requires.
Authority questions
Can support reset identity, view sensitive fields, change notification settings, reprocess records, or alter case state? Which approvals and evidence are required?
Lifecycle
Hiring, team assignment, training, shift change, temporary coverage, role change, and removal.
Evidence
Support role maps, tickets, approval records, administrative action events, quality review, and access recertification.
Fictional examples
Portal service identity, document-processing workload, notification sender, archival job, monitoring collector, and backup coordinator.
Expected behavior
Perform a narrow machine-to-machine function using only required permissions, approved destinations, defined timing, and monitored behavior.
Authority questions
Which resource, operation, data field, environment, destination, and schedule are necessary? Can the identity act interactively or outside its intended workflow?
Lifecycle
Provisioning, deployment, rotation, ownership change, environment separation, suspension, replacement, and retirement.
Evidence
Service-identity inventory, ownership, permission records, deployment manifests, activity events, and rotation history.
Fictional examples
Managed counselor laptop, student browser session, approved kiosk, administrative workstation, mobile device, and monitoring collector.
Expected behavior
Connect through approved channels under defined device state, ownership, management, and session conditions.
Authority questions
Does device health affect access? Is the endpoint shared, managed, temporary, remote, or privileged? Which actions require stronger conditions?
Lifecycle
Enrollment, assignment, health change, loss, repair, ownership transfer, retirement, and secure disposal.
Evidence
Device inventory, management status, health signals, assignment records, access events, and loss or retirement records.
Fictional examples
Document-processing supplier, notification provider, identity federation partner, archival service, and support subcontractor.
Expected behavior
Exchange only approved data and actions for a documented purpose under defined ownership, validation, monitoring, resilience, and exit conditions.
Authority questions
Which supplier identity or service may access what? Which fields are necessary? Who approves changes? What happens during failure, compromise, contract change, or termination?
Lifecycle
Selection, due diligence, onboarding, integration change, periodic review, incident handling, contract change, and offboarding.
Evidence
Approved data fields, interface records, ownership decisions, supplier reviews, service evidence, change history, and exit plans.
Fictional examples
Case-routing automation, archival scheduler, reminder generator, duplicate-submission detector, and access-review workflow.
Expected behavior
Apply documented rules with controlled inputs, bounded authority, reviewable outcomes, failure handling, and human escalation.
Authority questions
Which decisions may be automated? What data is used? What happens when confidence is low? Can a human review, pause, reverse, or correct the outcome?
Lifecycle
Design, approval, testing with fake data, release, rule change, monitoring, exception handling, and retirement.
Evidence
Rule definitions, approvals, test results, version history, outcome metrics, exception records, and human-review events.
Fictional examples
Privacy reviewer, security reviewer, risk owner, compliance reviewer, architecture board, and leadership approver.
Expected behavior
Review supplied evidence and decisions without receiving operational access beyond the approved review purpose.
Authority questions
Can the reviewer approve, reject, request evidence, grant exceptions, or accept residual risk? Which decisions require separation or escalation?
Lifecycle
Appointment, conflict review, assignment, evidence access, decision, recusal, and retention of review records.
Evidence
Review charters, decision records, evidence requests, approvals, exceptions, risk acceptance, and conflict disclosures.
Fictional examples
Unattributed external requests, stale service identities, unidentified devices, missing supplier ownership, and activity with incomplete actor context.
Expected behavior
No trusted behavior should be assumed until identity, relationship, purpose, authority, and evidence are established.
Authority questions
What is known? What remains unknown? Which interface accepted the request? Which control and evidence should limit or clarify activity?
Lifecycle
Observation, classification, owner assignment, validation, restriction, escalation, resolution, or continued monitoring.
Evidence
Request context, identity signals, interface events, source health, ownership records, tickets, and review conclusions.
Instructional Section 3
An entry point is not merely a technical address. It is a fictional interface with a purpose, accepted operations, connected actors, affected assets, validation rules, authority decisions, evidence, failure behavior, lifecycle, and owner. Describing it this way supports later trust-boundary, abuse-case, risk, and mitigation work without exposing operational real-system information.
Fictional purpose
Allow students and guardians to submit approved information, review status, manage notification preferences, and request help.
Incoming interaction
Authenticated sessions, forms, files, status requests, preference changes, and support requests.
Connected assets
Student records, account authority, case status, privacy expectations, notification settings, and service availability.
Connected actors
Students, guardians, counselors using delegated views, support actors, and approved browser or device sessions.
Expected controls
Identity proof, authorization, safe input handling, file policy, session protection, rate and workflow controls, privacy notices, evidence, and recovery.
Evidence needs
Actor, session, action, target, result, validation outcome, preference change, source health, and support correlation.
Accountable owner
Application owner with identity, privacy, data, support, and operations partners.
Fictional purpose
Support approved configuration, user support, workflow management, evidence review, and service operations.
Incoming interaction
Privileged sessions, configuration changes, account actions, recovery actions, approvals, and maintenance requests.
Connected assets
Privileged authority, system configuration, user accounts, case workflow, logs, recovery state, and trust.
Connected actors
Approved administrators, support roles, recovery operators, reviewers, and emergency roles.
Expected controls
Strong identity, least privilege, separation of duties, approval, reason capture, session protection, change control, monitoring, and review.
Evidence needs
Named actor, role, action, target, before-and-after state, reason, approval, result, source health, and ticket reference.
Accountable owner
Platform or application owner with identity, security operations, change, and recovery owners.
Fictional purpose
Exchange approved requests and responses between the portal, internal services, and fictional external dependencies.
Incoming interaction
Service requests, identity assertions, case updates, status messages, document results, and health signals.
Connected assets
Service availability, data integrity, identity trust, workflow state, supplier relationships, and evidence.
Connected actors
Service identities, workloads, supplier integrations, monitoring services, and approved automation.
Expected controls
Strong service identity, authorization, schema validation, data minimization, destination restriction, replay and error handling, monitoring, and version governance.
Evidence needs
Calling identity, interface version, operation, object, validation result, response status, timing, destination, source health, and correlation identifier.
Accountable owner
Service owner and integration owner with data, identity, supplier, and operations partners.
Fictional purpose
Receive approved documents or batch records for a defined fictional business process.
Incoming interaction
User-submitted files, approved batch imports, metadata, processing instructions, and validation results.
Connected assets
Submitted records, privacy, processing integrity, storage, workflow state, user trust, and recovery.
Connected actors
End users, authorized staff, approved suppliers, batch automation, validation service, and processing service.
Expected controls
File policy, content and metadata validation, size and type limits, quarantine or review workflow, data minimization, storage controls, evidence, and safe failure handling.
Evidence needs
Submitting actor, channel, declared type, validation outcome, processing state, storage reference, result, and user communication.
Accountable owner
Application and data owner with privacy, processing, storage, and support owners.
Fictional purpose
Move approved asynchronous events such as case updates, notifications, processing requests, and recovery tasks.
Incoming interaction
Structured events, status changes, retry requests, acknowledgments, and dead-letter or exception records.
Connected assets
Workflow integrity, event ordering, availability, notification accuracy, evidence, and recoverability.
Connected actors
Portal service, processing service, notification service, archival workflow, recovery automation, and monitoring.
Expected controls
Service identity, schema validation, destination policy, ordering and duplicate handling, bounded retries, failure isolation, source health, and monitoring.
Evidence needs
Producer identity, event type, object reference, creation time, processing status, retry count, destination, failure reason, and correlation.
Accountable owner
Integration or platform owner with application, operations, recovery, and security owners.
Fictional purpose
Exchange the minimum approved data and status needed for a documented external service.
Incoming interaction
Approved requests, processing results, status updates, error information, health signals, and support communication.
Connected assets
Data privacy, service availability, processing integrity, supplier trust, contractual expectations, recovery, and exit capability.
Connected actors
Supplier service identities, supplier operators, internal service identities, integration owners, and incident contacts.
Expected controls
Data minimization, strong identity, authorization, validation, monitoring, contract and ownership controls, failure handling, resilience, and offboarding.
Evidence needs
Supplier identity, approved operation, data fields, result, timing, health, exception, owner, and contract or change reference.
Accountable owner
Supplier manager and service owner with data, privacy, identity, legal or policy, operations, and recovery partners.
Fictional purpose
Authenticate fictional users and services or receive approved identity assertions and lifecycle updates.
Incoming interaction
Authentication requests, assertions, role or group attributes, session context, lifecycle events, and recovery actions.
Connected assets
Identity trust, authorization, account lifecycle, session integrity, privacy, evidence, and recovery.
Connected actors
End users, administrators, service identities, identity provider, federation partner, and recovery operators.
Expected controls
Approved trust relationship, strong identity, limited attributes, assertion validation, lifecycle synchronization, session controls, monitoring, and recovery governance.
Evidence needs
Identity, assertion source, authentication result, attributes used, policy decision, session state, lifecycle event, and failure reason.
Accountable owner
Identity owner with application, privacy, role, support, and security operations owners.
Fictional purpose
Receive approved operational, security, identity, application, and source-health records for defensive visibility.
Incoming interaction
Events, alerts, metrics, health signals, configuration state, approval records, and incident notes.
Connected assets
Evidence integrity, accountability, detection, triage, investigation quality, privacy, retention, and compliance.
Connected actors
Applications, services, devices, identity systems, collectors, analysts, case-management services, and governance reviewers.
Expected controls
Source identity, schema and time normalization, integrity, access control, privacy limits, retention, source-health monitoring, failure handling, and review.
Evidence needs
Source, event type, timestamp quality, ingestion state, parsing result, health, retention decision, access, and downstream correlation.
Accountable owner
Security operations or monitoring owner with source-system, privacy, data, and platform owners.
Fictional purpose
Support approved restoration, emergency access, failover, communication, and validation during disruption.
Incoming interaction
Recovery approvals, restore requests, emergency identity elevation, configuration baselines, backup data, validation results, and stakeholder updates.
Connected assets
Backups, recovery identities, configuration integrity, service availability, business state, communication, and trust.
Connected actors
Recovery operators, incident leads, system owners, identity owners, supplier contacts, mission owners, and approvers.
Expected controls
Documented trigger, approval, strong identity, time limits, separation, trusted baselines, integrity checks, evidence, communication, and post-event review.
Evidence needs
Trigger, approving actor, recovery identity, action, target, source artifact, validation result, time, business state, and closure review.
Accountable owner
Recovery owner with incident, system, identity, data, supplier, communications, and mission owners.
Instructional Section 4
The strongest inventories connect value, role, interface, purpose, authority, expected behavior, evidence, ownership, and change. Use the questions below when reviewing a fictional asset–actor–entry point relationship.
Asset view
Name the fictional mission, data, identity, service, process, evidence, privacy, safety, trust, or recovery asset.
Actor view
Identify which fictional human or non-human role interacts with that value.
Entry-point view
Identify the approved fictional interface through which the interaction occurs.
Evidence
Asset register, owner decision, workflow map, service catalog, data inventory, or identity record.
Asset view
Describe the business, service, user, privacy, support, monitoring, or recovery purpose.
Actor view
Describe the actor's approved responsibility and expected behavior.
Entry-point view
Describe why this interface exists and which operations it supports.
Evidence
Approved requirement, process design, role definition, support need, integration decision, or recovery plan.
Asset view
State which action affects the asset and what harm incorrect authority could create.
Actor view
State role, permission, scope, condition, duration, approval, and separation needs.
Entry-point view
State which operations the interface accepts and which should be denied or escalated.
Evidence
Access policy, role matrix, approval, service permission, interface contract, or change record.
Asset view
Define expected use, update, access, retention, recovery, and evidence patterns.
Actor view
Define normal timing, volume, source, destination, workflow, reason, and outcome.
Entry-point view
Define expected request types, fields, sizes, states, rates, versions, errors, and destinations.
Evidence
Baseline, workflow record, event history, service objective, support data, or owner statement.
Asset view
Consider sensitivity, classification, ownership, environment, state, retention, or recovery stage.
Actor view
Consider role change, supplier change, device state, location, lifecycle, conflict, emergency, or unknown identity.
Entry-point view
Consider external-to-internal transfer, user-to-admin transition, public-to-private zone, supplier boundary, or recovery path.
Evidence
Data classification, identity context, device health, architecture view, supplier record, or recovery event.
Asset view
Define which integrity, confidentiality, availability, privacy, and business-state checks matter.
Actor view
Define identity, authority, reason, approval, and accountability checks.
Entry-point view
Define validation, authorization, monitoring, source-health, error, and safe failure expectations.
Evidence
Validation result, policy decision, event schema, approval record, source-health signal, or test evidence.
Asset view
Assign a fictional owner for value, classification, use, recovery, and residual risk.
Actor view
Assign a role owner for authority, lifecycle, review, conflict, and removal.
Entry-point view
Assign an interface owner for purpose, configuration, monitoring, change, and retirement.
Evidence
Ownership register, RACI-style decision map, approval record, service catalog, or governance charter.
Asset view
Review when value, use, sensitivity, retention, criticality, owner, or recovery requirement changes.
Actor view
Review when role, relationship, authority, device, location, supplier, lifecycle, or expected behavior changes.
Entry-point view
Review when interface purpose, version, data, destination, exposure, ownership, control, failure, or retirement changes.
Evidence
Change record, access review, supplier update, architecture revision, incident lesson, recovery exercise, or scheduled review.
Instructional Section 5
One fictional system may have several legitimate owners. The mission owner decides which outcomes matter. The data owner approves purpose and use. The identity owner governs actor authority. The interface owner governs accepted interactions and technical lifecycle. The operations owner maintains service. The recovery owner validates restoration. A risk owner decides whether remaining exposure is acceptable. Combining these responsibilities can hide disagreement and weaken accountability.
| Decision area | Primary fictional owner | Required partners | Evidence of ownership |
|---|---|---|---|
| Mission value and acceptable outcome | Mission or business owner | Service, user, privacy, operations, recovery, leadership | Approved service objective and impact decision |
| Data purpose, fields, use, sharing, retention, deletion | Data and privacy owners | Application, supplier, records, security, mission | Data inventory, purpose approval, classification, retention decision |
| Actor role, authority, lifecycle, and review | Identity and role owners | Application, support, human resources, supplier, security | Role definition, approval, access review, lifecycle record |
| Entry-point purpose, controls, change, monitoring, retirement | Interface or service owner | Data, identity, platform, supplier, operations, security | Interface inventory, architecture decision, change history, review |
| Operational availability and support | Operations owner | System, supplier, identity, support, monitoring, mission | Service records, support procedures, metrics, exercise results |
| Recovery order, authority, validation, and communication | Recovery owner | Mission, system, data, identity, supplier, communications | Recovery plan, restore test, validation, closure review |
| Residual risk and exception | Named risk owner | All relevant owners and leadership | Risk decision, rationale, conditions, expiration, review trigger |
Criticality and Exposure Matrix
A fictional asset, actor relationship, or entry point should not be marked “critical” simply because it is technical, privileged, or internet-facing. Use evidence and context across several factors, then preserve uncertainty and owner judgment.
Strong question
How directly does the fictional service outcome depend on the asset, actor relationship, or entry point?
Evidence
Business impact, user journey, process map, service objective, and owner decision.
Warning
Do not rank a component highly only because it sounds technical.
Strong question
Could inappropriate disclosure, collection, inference, sharing, retention, or use harm fictional people or the organization?
Evidence
Data classification, purpose, field inventory, privacy review, sharing decision, and retention plan.
Warning
Metadata, derived data, support notes, and evidence can be sensitive even when primary records are protected.
Strong question
Could incorrect, incomplete, duplicated, delayed, reordered, or unauthorized changes affect decisions or workflow outcomes?
Evidence
Workflow state, validation rules, approval history, reconciliation, and business-state checks.
Warning
Technical processing success does not automatically prove correct business outcome.
Strong question
What happens if the asset, actor relationship, or entry point is unavailable, slow, isolated, or degraded?
Evidence
Service targets, dependency map, queue behavior, support impact, recovery exercise, and alternate process.
Warning
Availability includes timely communication and usable workflow state, not only server response.
Strong question
How much fictional power does the actor or interface have, and can that power be limited, separated, monitored, reviewed, and recovered?
Evidence
Role matrix, permission evidence, approvals, privileged events, access review, and emergency records.
Warning
A support function can be critical even when it is not labeled administrator.
Strong question
How many fictional services, workflows, or recovery steps depend on the same asset, actor, supplier, identity, or interface?
Evidence
Dependency map, service catalog, supplier record, failover design, and recovery order.
Warning
A small shared service can create broad impact if many paths depend on it.
Strong question
Could defenders reliably observe expected and unexpected use, denied actions, failure, source health, and business outcome?
Evidence
Logging requirements, event samples, dashboards, source-health records, alert reviews, and retention.
Warning
An entry point without useful evidence may create higher uncertainty than its apparent exposure suggests.
Strong question
Can fictional data, authority, configuration, service, workflow, and trust be restored and validated within acceptable time?
Evidence
Backup inventory, restore test, identity recovery, configuration baseline, communication plan, and exercise result.
Warning
A backup does not prove recovery of correct business state, identity, communication, or dependencies.
Inventory Quality
Example
Database, admins, website, API.
Remaining problem
The statement does not identify value, purpose, ownership, authority, data, lifecycle, expected behavior, evidence, or relationship.
Improvement
Record specific fictional assets, actor roles, approved interfaces, business purpose, owners, evidence, assumptions, and review triggers.
Example
Case-status integrity is a mission and data asset owned by the student-services program because counselors and users depend on accurate workflow state.
Remaining problem
Criticality, recovery, evidence, and actor relationships may still require more detail.
Improvement
Add impact, classification, dependencies, recovery target, evidence source, and connected actors and entry points.
Example
The fictional support analyst role may view assigned case status and initiate a verified notification correction through the support console.
Remaining problem
The statement still requires lifecycle, approval, evidence, volume, exception, and separation details.
Improvement
Add exact authority, conditions, owner, training, review cadence, reason capture, and emergency limitations.
Example
The supplier-status API accepts approved case-reference and processing-result messages from one managed supplier service identity.
Remaining problem
The statement still requires schema, destination, data-minimization, failure, monitoring, version, and retirement details.
Improvement
Add owner, accepted operations, validation, evidence, source health, recovery, change, and offboarding requirements.
Example
The fictional supplier service identity submits minimized processing results through the versioned supplier-status API to update the case-status asset; the service owner and data owner approve fields, the identity owner approves authority, and operations monitors validation, health, and failed updates.
Remaining problem
The relationship remains a model and requires validation against supplied fictional evidence.
Improvement
Record assumptions, evidence sources, confidence, unresolved questions, review trigger, and residual risk owner.
Fictional Architecture View
The diagram below is an invented learning model. It describes roles and interfaces conceptually and does not represent any real school, organization, network, application, supplier, or internal design.
Students and guardians
Use the public portal for approved submission, status, preferences, and support.
Counselors
Review assigned cases and record approved decisions.
Support analysts
Use controlled support workflows for verified user problems.
Administrators
Operate approved platform, identity, and recovery functions.
Fictional Northbridge Portal
Public interface
Submission, status, preferences, support
Administrative console
Approved support and operations
Identity interface
Human and service authentication
Supplier API
Minimized processing requests and results
Upload channel
Validated fictional documents
Message queue
Workflow and notification events
Monitoring ingestion
Events, health, and evidence
Recovery interface
Approved restoration and validation
Identity provider
Authenticates fictional human and service identities.
Processing supplier
Returns fictional document-processing results.
Notification service
Delivers approved fictional status messages.
Archive and backup
Preserves fictional records and supports restoration.
Fake Dashboard
Fictional inventory, ownership, lifecycle, and evidence status for training only.
Assets with confirmed owners
28 / 34
Evidence, notification-state, archival-deletion, recovery-identity, supplier-trust, and duplicate-submission assets need ownership review.
Actors past review date
4
Two service identities, one temporary support role, and one supplier operator relationship require lifecycle validation.
Entry points without complete records
3
Temporary batch import, recovery console, and supplier support channel lack complete purpose, owner, evidence, or retirement decisions.
Fake SOC Alert
Source: Fake Northbridge Architecture Governance Console • Time: 10:42 AM
Fake Log Panel
09:00 REVIEW scope='student-support-portal' status='authorized-fictional' 09:06 ASSET mission='accurate-case-status' owner='student-services' 09:12 ASSET data='support-free-text' purpose='unconfirmed' 09:18 ACTOR role='support-analyst' authority='reset,notify,reprocess' 09:24 ACTOR service='archive-worker' owner='missing' review='expired' 09:31 ENTRY public-portal owner='application-team' status='documented' 09:37 ENTRY supplier-api fields='case-ref,category,status,note' 09:43 ENTRY batch-import purpose='migration-test' owner='unknown' 09:49 EVIDENCE notification-change reason='missing' count='4' 09:56 RECOVERY identity-ref='stale' services='notify,archive' 10:03 DEPENDENCY identity-provider consumers='portal,admin,supplier' 10:10 GAP asset-owner='6' actor-review='4' interface-record='3' 10:17 ACTION data-owner='review-free-text-necessity' 10:24 ACTION identity-owner='validate-archive-worker' 10:31 ACTION interface-owner='validate-batch-import' 10:36 CONFIDENCE inventory='medium' relationship-map='draft' 10:42 ALERT unowned-interface='batch-import' 10:48 DECISION ranking='deferred' evidence-review='required'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Observation
The student-support portal depends on identity, document validation, processing, notification, storage, monitoring, archive, and recovery services.
Supports
The model contains multiple service, identity, data, evidence, and recovery assets with shared dependencies.
Does not prove
The catalog does not prove current ownership, effective permissions, actual data flows, control operation, or recovery readiness.
Threat-model use
Create initial service assets, dependency questions, owner assignments, and evidence requests.
Observation
A support role can reset accounts, view case status, change notification settings, and initiate document reprocessing.
Supports
The support actor has concentrated authority across identity, privacy, workflow, and communication assets.
Does not prove
The matrix does not prove that every listed permission is effective, necessary, approved, used, or monitored.
Threat-model use
Open least-privilege, separation, approval, lifecycle, evidence, and recovery questions.
Observation
The portal lists public web, administrative console, supplier API, upload, queue, identity, monitoring, and recovery interfaces.
Supports
The system has several distinct entry-point classes with different actors, data, authority, and evidence needs.
Does not prove
The inventory does not prove that undocumented, deprecated, test, temporary, or emergency interfaces are absent.
Threat-model use
Assign owners, purpose, accepted operations, validation, monitoring, change, and retirement requirements.
Observation
The processing supplier receives case reference, document category, processing status, and a free-text support note.
Supports
The supplier interface affects data, privacy, workflow, and trust assets and may receive more context than its primary purpose requires.
Does not prove
The review does not prove whether the free-text note is currently sent in every request or whether an approved exception exists.
Threat-model use
Ask the data owner to validate necessity, classification, minimization, retention, and supplier use.
Observation
A service identity used by the archival workflow is active, but the inventory owner field is blank and the last review date has passed.
Supports
The actor lifecycle and ownership evidence are incomplete for an identity connected to retention and recovery assets.
Does not prove
The summary does not prove misuse, compromise, excessive permission, or incorrect configuration.
Threat-model use
Assign an owner, validate purpose and authority, review activity and dependencies, and define lifecycle action.
Observation
Notification changes can be performed through the support console, but several tickets lack a recorded reason and user confirmation.
Supports
The support actor, administrative entry point, notification asset, and accountability evidence are not consistently connected.
Does not prove
Missing ticket fields do not prove that the changes were unauthorized or harmful.
Threat-model use
Improve reason capture, approval or confirmation, event correlation, quality review, and support-role design.
Observation
The portal was restored, but the notification service and archival scheduler used stale service-identity references during validation.
Supports
Recovery depends on current non-human actors, entry-point configuration, ownership, and trusted baselines.
Does not prove
One exercise does not prove the frequency or full production impact of future recovery failures.
Threat-model use
Add recovery identities and interfaces to the register and connect them to owner, dependency, evidence, and review triggers.
Observation
A temporary batch-import channel was created for migration testing and remains listed as enabled, but its current purpose and owner are unclear.
Supports
A potentially stale entry point lacks confirmed purpose, owner, lifecycle, and retirement evidence.
Does not prove
The note does not prove the interface is externally reachable, actively used, unsafe, or unnecessary.
Threat-model use
Validate status, purpose, accepted operations, exposure, controls, activity, owner, and retirement decision without testing a real system.
Analyze the Evidence
Common Mistakes
Why it fails
Mission outcomes, identity authority, workflow state, evidence, privacy, trust, operational knowledge, supplier relationships, and recovery capability may be more important than a named component.
Strong correction
Use a multi-class asset inventory and connect every technology asset to the outcome it supports.
Why it fails
A role, external source, failed request, unusual time, or unknown identity does not prove malicious intent.
Strong correction
Document identity, relationship, authority, expected behavior, evidence, uncertainty, and review needs without unsupported attribution.
Why it fails
Real names create privacy problems and become stale, while threat models need stable responsibilities, authority, lifecycle, and accountability.
Strong correction
Use invented role names and document purpose, permissions, conditions, owner, and lifecycle.
Why it fails
Services, workloads, devices, suppliers, queues, schedulers, automation, collectors, and recovery processes can possess authority and create dependencies.
Strong correction
Inventory human and non-human actors with ownership, permissions, expected behavior, evidence, and retirement.
Why it fails
A useful entry-point inventory distinguishes approved interfaces by purpose, accepted operations, actors, assets, ownership, controls, evidence, and lifecycle.
Strong correction
Document interfaces at a level that supports defensive decisions without exposing operational real-system detail.
Why it fails
An inventory may contain stale, planned, temporary, duplicate, test, deprecated, or missing entries.
Strong correction
Record evidence date, owner confirmation, confidence, unknowns, and review trigger.
Why it fails
Different fictional roles may own value, technology, data, identity, operations, supplier relationships, and residual-risk decisions.
Strong correction
Separate ownership and decision rights instead of assigning every responsibility to one technical owner.
Why it fails
Criticality and exposure depend on which actors use which entry points to affect which assets under which conditions.
Strong correction
Build the relationship register before applying impact and likelihood labels.
Why it fails
Account reset, emergency access, reprocessing, backup restoration, supplier escalation, and manual workarounds can have broad authority and weaker evidence.
Strong correction
Model normal, support, administrative, emergency, degraded, and recovery interactions.
Why it fails
Real diagrams, role maps, interface lists, logs, credentials, supplier records, and recovery details can expose systems and people.
Strong correction
Use completely invented organizations, systems, identities, actors, assets, interfaces, evidence, dates, decisions, and outcomes.
Safe Fictional Practice Lab
Use the supplied fictional Northbridge brief to state which design decision the inventory supports and which systems, workflows, actors, data, suppliers, environments, and time period are included.
Required output
One purpose statement, one scope statement, one exclusion list, and one safety boundary.
Quality check
The scope is precise enough that a reviewer can identify what the exercise does not cover.
Identify fictional mission, data, identity, service, process, evidence, privacy, trust, safety, and recovery assets.
Required output
An asset table with value, owner, purpose, classification, dependency, impact, evidence, confidence, and review trigger.
Quality check
Every technology asset is connected to a mission or user outcome.
Identify fictional end users, administrators, support roles, service identities, devices, suppliers, automation, reviewers, recovery roles, and unknown actors.
Required output
An actor table with role, relationship, identity type, authority, expected behavior, lifecycle, owner, evidence, and unknowns.
Quality check
The table does not claim intent and includes both human and non-human actors.
Identify fictional public, administrative, API, upload, queue, supplier, identity, monitoring, and recovery interfaces.
Required output
An interface table with purpose, accepted input, connected actors, affected assets, owner, controls, evidence, failure handling, and lifecycle.
Quality check
Every interface has a documented purpose and accountable owner or is marked as an unresolved gap.
Connect each important fictional actor to the entry points used and the assets affected.
Required output
An Asset–Actor–Entry Point relationship matrix with purpose, authority, expected behavior, evidence, and owner.
Quality check
The matrix can answer who or what uses which interface to affect which value and why.
Find orphaned assets, stale identities, unowned interfaces, temporary channels, unclear supplier relationships, and missing retirement decisions.
Required output
A gap register with owner, action, evidence request, deadline, confidence, and review trigger.
Quality check
No gap is silently converted into a fact or accusation.
Use the fictional criticality factors to compare mission dependence, privacy, integrity, availability, authority, dependency concentration, detectability, and recoverability.
Required output
A reasoned preliminary priority view without false precision.
Quality check
Every priority statement cites fictional evidence and identifies uncertainty.
Explain the most important fictional relationships, gaps, evidence needs, ownership decisions, and next modeling questions.
Required output
A one-page leadership summary and a technical appendix.
Quality check
The summary is useful without exposing real systems or providing operational harmful detail.
Scenario Decision Lab
The fictional archival service identity is active, its owner field is blank, and its review date has passed. No evidence on the page proves misuse, compromise, or excessive permission.
Scenario Decision Lab
A reviewer says the fictional project would look more professional if the student copied a real school interface list, removed addresses, and changed the organization name.
Advanced Challenge
The fictional mission owner says case-status integrity is a business asset. The application owner says it is a database responsibility. The data owner says the supplier creates the value. The supplier manager says Northbridge owns the final decision. Build a decision-ready ownership model instead of forcing one role to own every part.
Map the value chain
Separate user outcome, data accuracy, processing result, application state, supplier obligation, evidence, and recovery.
Assign layered ownership
Assign mission, data, application, supplier, identity, operations, recovery, and residual-risk responsibilities.
Identify decision rights
State who approves purpose, data fields, authority, interface changes, validation, exceptions, and residual risk.
Document disagreement
Preserve competing interpretations, evidence, assumptions, unresolved questions, and escalation path.
Define validation
Specify which fictional records show correct status, supplier result, application update, user communication, and recovery.
Set review triggers
Require review when supplier fields, workflow, ownership, identity, interface version, recovery design, or service objective changes.
Challenge output
Create a fictional ownership and decision-rights matrix for case-status integrity, then write a leadership paragraph explaining why shared responsibility does not mean unclear accountability.
Defender Habits
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a fully fictional Asset–Actor–Entry Point Register for the Northbridge Student-Support Portal. Include the modeling decision, scope, exclusions, safety boundary, at least twelve assets across multiple asset classes, at least ten human and non-human actor roles, at least eight entry-point classes, owners, business purpose, authority, expected behavior, lifecycle, connected relationships, criticality factors, evidence sources, evidence limitations, assumptions, unknowns, confidence, review triggers, gap register, decision-rights matrix, leadership summary, technical appendix, reflection, and a statement that every organization, system, asset, actor, identity, role, interface, owner, record, diagram, event, date, decision, and outcome is invented.
Confidence / Readiness Reflection
Before moving to A3.3, rate your readiness from 1 to 5 for each area: asset breadth, actor neutrality, non-human identity coverage, entry-point ownership, relationship mapping, authority, evidence, lifecycle, criticality, uncertainty, and complete fictionalization.
Key Takeaways
Navigation
Next, use the fictional asset, actor, and entry-point register to map how data and requests move and where trust assumptions change.