Why English? | Writing a Threat Model Through Scope, Assets, Architecture, Trust Boundaries, Threats, Risk, Mitigations, Assumptions and Review

ORIENTATION

What this guide covers

Current fact check

Checked on 9 November 2026, the OWASP Threat Modeling Cheat Sheet defined threat modelling as a structured and repeatable process that models a system, identifies applicable threats and determines responses. It organised the process around application decomposition or system modelling, threat identification and ranking, mitigations, and review and validation. OWASP also described threat modelling as iterative, ideally begun early in the development lifecycle, and said each identified threat needs an agreed response and testable mitigation where mitigation is chosen.

What this guide does not cover

This article covers creating, documenting, reviewing and updating an application or service threat model. It does not cover enterprise-wide risk assessment, penetration testing, vulnerability scanning, secure coding implementation, privacy impact assessment, compliance certification, live incident response, criminal attribution, disclosure of exploitable details or formal acceptance of residual risk.

Worked example

Every chapter returns to a fictional school library reservation service with student and librarian roles, an identity provider, catalogue API, reservation database, notification service and administrator console. It is fictional, low-stakes and educational; it does not report a real school, clinical decision or guaranteed outcome.

Warm up with eduKate’s guides to explaining scientific evidence and asking better questions in class.

CHAPTER 1 OF 12

1. Define the Decision, Scope and Model Version

Back to contents

Why this move matters

State the system, lifecycle stage, environments, features, review question, owner and model version.

Model the real system before naming threats

State the system, lifecycle stage, environments, features, review question, owner and model version. For The model covers reservation creation and administration for design version 2.1, excluding catalogue search ranking., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. An excluded feature may still be a dependency and must be named.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. An excluded feature may still be a dependency and must be named. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Define the Decision, Scope and Model Version” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 2 OF 12

2. Identify Assets and Security Objectives

Back to contents

Why this move matters

List data, identities, services, keys, decisions and capabilities that require confidentiality, integrity, availability or other protection.

Model the real system before naming threats

List data, identities, services, keys, decisions and capabilities that require confidentiality, integrity, availability or other protection. For Assets include student identifiers, reservation integrity, privileged librarian actions and service availability., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. Not every database field has the same consequence.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. Not every database field has the same consequence. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Identify Assets and Security Objectives” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 3 OF 12

3. Map Actors, Roles and Privileges

Back to contents

Why this move matters

Describe legitimate users, services, administrators, external parties and plausible adversarial capabilities.

Model the real system before naming threats

Describe legitimate users, services, administrators, external parties and plausible adversarial capabilities. For A student, librarian, identity provider and notification worker have distinct permissions., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. Do not equate a user group with an attacker or assume insiders are identical.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. Do not equate a user group with an attacker or assume insiders are identical. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Map Actors, Roles and Privileges” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 4 OF 12

4. Draw Architecture, Data Flows and Trust Boundaries

Back to contents

Why this move matters

Show components, stores, processes, interfaces, data movement, protocols and places where trust or control changes.

Model the real system before naming threats

Show components, stores, processes, interfaces, data movement, protocols and places where trust or control changes. For The model marks the boundary between the reservation service and the external identity provider., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. A diagram without current implementation confirmation can create false confidence.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. A diagram without current implementation confirmation can create false confidence. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Draw Architecture, Data Flows and Trust Boundaries” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 5 OF 12

5. Record Entry Points, Dependencies and Assumptions

Back to contents

Why this move matters

List interfaces, administrative paths, update channels, third parties, environmental controls and facts the model relies on.

Model the real system before naming threats

List interfaces, administrative paths, update channels, third parties, environmental controls and facts the model relies on. For The design assumes signed identity tokens are validated against the intended audience., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. An assumption needs an owner and validation evidence.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. An assumption needs an owner and validation evidence. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Record Entry Points, Dependencies and Assumptions” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 6 OF 12

6. Choose a Threat-Identification Method Deliberately

Back to contents

Why this move matters

Name the method, why it fits, how workshops or review were conducted and what it may miss.

Model the real system before naming threats

Name the method, why it fits, how workshops or review were conducted and what it may miss. For The team uses STRIDE prompts on each data flow and supplements them with abuse cases for booking limits., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. A mnemonic is a prompt, not proof of completeness.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. A mnemonic is a prompt, not proof of completeness. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Choose a Threat-Identification Method Deliberately” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 7 OF 12

7. Write Threat Scenarios as Testable Stories

Back to contents

Why this move matters

Describe actor, capability, precondition, action, target, security property and consequence.

Model the real system before naming threats

Describe actor, capability, precondition, action, target, security property and consequence. For A compromised student account replays a reservation request to exceed the one-seat limit and deny availability to others., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. A one-word category cannot guide design or testing.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. A one-word category cannot guide design or testing. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Write Threat Scenarios as Testable Stories” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 8 OF 12

8. Prioritise Risk With a Stated Model

Back to contents

Why this move matters

Use agreed likelihood and impact evidence, uncertainty, existing controls and business context to order attention.

Model the real system before naming threats

Use agreed likelihood and impact evidence, uncertainty, existing controls and business context to order attention. For The team records high impact but uncertain likelihood and explains the evidence behind both ratings., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. Risk scores are decision aids, not objective physical measurements.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. Risk scores are decision aids, not objective physical measurements. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Prioritise Risk With a Stated Model” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 9 OF 12

9. Select Responses and Define Mitigations

Back to contents

Why this move matters

For each threat, record mitigation, elimination, transfer or acceptance, plus owner, requirement, dependency and target date.

Model the real system before naming threats

For each threat, record mitigation, elimination, transfer or acceptance, plus owner, requirement, dependency and target date. For Idempotency and server-side limit enforcement become security requirements owned by the reservation service team., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. Transfer does not remove technical risk, and acceptance needs authority.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. Transfer does not remove technical risk, and acceptance needs authority. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Select Responses and Define Mitigations” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 10 OF 12

10. Make Mitigations Verifiable

Back to contents

Why this move matters

Define design review, unit, integration, abuse-case, logging or operational checks and the evidence that will demonstrate implementation.

Model the real system before naming threats

Define design review, unit, integration, abuse-case, logging or operational checks and the evidence that will demonstrate implementation. For A replay test verifies that repeated request identifiers cannot create a second reservation., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. A control listed but never implemented or tested is not assurance.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. A control listed but never implemented or tested is not assurance. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Make Mitigations Verifiable” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 11 OF 12

11. Document Residual Risk and Decision Authority

Back to contents

Why this move matters

Explain what remains after controls, who may accept it, time limits and monitoring or review conditions.

Model the real system before naming threats

Explain what remains after controls, who may accept it, time limits and monitoring or review conditions. For A third-party outage risk remains and is accepted conditionally with monitoring and a manual fallback., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. The threat-model author should not impersonate the risk owner.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. The threat-model author should not impersonate the risk owner. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Document Residual Risk and Decision Authority” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

CHAPTER 12 OF 12

12. Review, Version and Trigger Updates

Back to contents

Why this move matters

Validate the model with diverse stakeholders and update it after architecture, data, dependency, threat or incident changes.

Model the real system before naming threats

Validate the model with diverse stakeholders and update it after architecture, data, dependency, threat or incident changes. For A new notification provider triggers review of data flows, trust boundaries and existing scenarios., define scope, assets, actors, data flows, trust boundaries, dependencies and assumptions.

Identify and prioritise credible threat scenarios

Describe an actor, action, precondition, target and consequence; apply a stated method consistently. A threat model that never changes describes history, not the current system.

Turn responses into owned security requirements

Choose mitigation, elimination, transfer or acceptance; link controls to implementation, testing and residual risk ownership.

Review as the system changes

Validate the model with security, engineering, product and operations stakeholders and version the result. A threat model that never changes describes history, not the current system. A threat model improves decisions; it cannot prove a system secure.

Student, parent and career transfer

Practise “Review, Version and Trigger Updates” by separating observation, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to computing courses, software engineering, cybersecurity, solution architecture, product management, QA, DevOps, governance, risk and technical review without guaranteeing grades, approval, security, recovery, causal certainty, safety, employment or future outcomes.

PRACTICE LAB

Build a threat model decision trail

Student route

1. Choose one real example or official document inside this guide’s scope.
2. Copy its objective and underline actor, action, context, evidence and intended decision.
3. Draw the specific reasoning chain used in this article.
4. Mark each step reported, inferred, contested or unknown.
5. Rewrite the conclusion so it preserves the narrowest important limitation.

Parent or teacher route

Ask the learner to explain turn system knowledge into a reviewable threat model that shows what must be protected, how trust changes across the design, which attack scenarios matter and who owns the response twice: once to a classmate and once to a method specialist. Praise a precise correction and a well-stated unknown; both show disciplined attention to evidence.

Early-career route

Create a one-page threat model audit with source link, date checked, scope, method logic, decisive wording, contrary evidence, limit and next action. A colleague should be able to continue without guessing.

Continue with eduKate’s guides to reading course and career information and giving useful feedback in group projects.

USEFUL NEXT READING

Connect this narrow owner to its neighbour

Read the technical-design document guide for a related but different reader job. Return here when the question is specifically how to turn system knowledge into a reviewable threat model that shows what must be protected, how trust changes across the design, which attack scenarios matter and who owns the response. Use each guide for the reader task named in its heading.

For English practice across research, school and career communication, visit the Singapore English Tuition Centre learning site.

FREQUENTLY ASKED QUESTIONS

Questions students and parents often ask

Is a threat model the same as a risk assessment?

A threat model focuses on system structure and threat scenarios; broader risk assessments may include many non-adversarial and organisational risks.

Must I use STRIDE?

No. Choose a method that fits the system and purpose, explain it and record its limits.

Can a diagram be the whole threat model?

No. Diagrams support shared understanding, but scenarios, priorities, responses, ownership and review are also needed.

When should threat modelling begin?

Ideally early enough to influence design, then continue when the system or threat environment changes.

Who accepts residual risk?

The authorised risk owner under the organisation’s governance, not automatically the model author or developer.

Does a complete threat model prove security?

No. It improves reasoning and requirements but cannot guarantee that all threats were found or controls work.