Lesson A19.5
Threat models identify what could plausibly go wrong. Risk assessments decide what those concerns mean for the organization, which ones deserve attention first, who owns the decision, and what treatment is justified.
This lesson uses only fictional Northbridge systems and synthetic evidence. You are practicing professional reasoning and communication, not testing, scanning, exploiting, or changing real systems.
Lesson Progress
High School Advanced • A19: Cybersecurity Portfolio Projects • Lesson 5 of 10
Readiness Check
0/4 ready
Professional Hook
Cybersecurity work produces more concerns than most organizations can address immediately. A team may identify a privileged-access issue, an unclear recovery dependency, incomplete logging, a cloud design assumption, and a supplier question at the same time. Risk assessment helps decide which concern matters most and why.
The strongest assessments do not simply label everything high risk. They compare realistic likelihood, realistic impact, current controls, evidence confidence, business importance, recovery readiness, and ownership. The result is a decision record that another professional can understand and challenge.
Learning Objectives
Explain how a cybersecurity risk assessment turns technical concerns into defensible business decisions about likelihood, impact, ownership, treatment, and residual risk.
Distinguish assets, threats, vulnerabilities or control gaps, likelihood, impact, inherent risk, current controls, residual risk, and treatment decisions.
Write clear fictional risk statements that connect a plausible cause, affected asset, security consequence, business effect, and supporting evidence without exaggeration.
Compare risk-treatment choices such as mitigate, avoid, transfer, and accept while preserving accountability, review dates, evidence, and decision ownership.
Create a portfolio-ready Risk Assessment Project that demonstrates evidence-based prioritization, professional communication, safe assumptions, and traceable recommendations.
Core Teaching
A cybersecurity risk assessment is a structured analysis of potential loss. It asks what asset matters, what event or condition could affect it, how plausible that event is, what the consequence could be, what controls already reduce the exposure, what risk remains, and how the organization should respond.
Risk is not exactly the same as a threat, vulnerability, finding, or incident. A threat is a potential adverse event or condition. A control gap is a weakness or uncertainty that can increase exposure. An incident is an event that has actually occurred. Risk combines the possibility of an adverse event with the consequence to something the organization values.
In professional work, the assessment also records uncertainty. A rating based on strong evidence should not look identical to a rating based mostly on assumptions. Confidence is part of the quality of the decision.
Risk Vocabulary
Something the organization values and needs to protect, such as a fictional service, dataset, identity system, business process, reputation, or recovery capability.
Fictional example: Northbridge Student Portal availability and the fictional profile records it processes.
A plausible event or condition that could negatively affect an asset. In this course, threats are described at a defensive and non-operational level.
Fictional example: Unauthorized access, stale privilege, service disruption, incomplete logging, or a failed dependency.
A missing, weak, uncertain, or unverified defensive control that can increase exposure. A gap is not automatically proof that an incident occurred.
Fictional example: The review cadence for a privileged fictional role has not yet been confirmed.
A reasoned estimate of how plausible the risk event is in the defined context, based on exposure, conditions, control strength, history, dependencies, and uncertainty.
Fictional example: Moderate because the workflow is privileged but already has several limiting controls.
The realistic consequence if the risk event occurs, including confidentiality, integrity, availability, operational, financial, legal, trust, or recovery effects.
Fictional example: A privileged configuration error could interrupt an important service and require recovery work.
The level of risk considered before giving credit to current controls.
Fictional example: A privileged administrative function may have high inherent impact because it can change important settings.
Existing preventive, limiting, detective, recovery, validation, or governance measures that reduce the risk.
Fictional example: Strong authentication, narrow role membership, approvals, logging, and recurring access review.
The remaining risk after considering the current controls and their known effectiveness.
Fictional example: Residual risk remains moderate until the role-review cadence and evidence are confirmed.
The decision about what to do with a risk: reduce it, avoid the activity, transfer part of the exposure, or knowingly accept it under defined conditions.
Fictional example: Mitigate by improving role review, or accept temporarily with an owner and expiration date.
The person or role accountable for deciding how the organization will handle a risk and for ensuring that the decision remains reviewed.
Fictional example: A fictional service owner or security governance lead.
Assessment Reasoning
Do not rate likelihood from fear or technical complexity alone. Consider who can reach the workflow, how often the condition could occur, current controls, dependencies, prior synthetic evidence, and what remains unknown.
Technical effects matter, but a portfolio-quality assessment also explains what those effects mean for users, service availability, data trust, recovery effort, legal obligations, reputation, or business operations.
A risk can have high inherent exposure but lower residual exposure when strong, relevant controls exist and there is credible evidence that they are working.
Missing evidence should reduce confidence in the rating. It should not be hidden or automatically converted into a worst-case conclusion.
A moderate technical issue may deserve earlier attention if it affects a critical dependency, has unclear ownership, or blocks recovery. A severe theoretical issue may rank lower if exposure is tightly limited and controls are strong.
The final assessment should show who owns the decision, what treatment was chosen, what evidence supports it, when it will be reviewed, and what would cause the decision to change.
Inherent vs Residual
Inherent risk asks what the exposure would look like before giving credit to current controls. Residual risk asks what remains after those controls are considered. This distinction helps explain why a powerful administrative function can have high inherent risk but lower residual risk when access is tightly limited, strongly authenticated, logged, reviewed, and recoverable.
Imagine the relevant controls are not yet receiving credit. Focus on the value of the asset, plausible event, exposure, privilege, and realistic consequence.
Now consider current controls and the evidence supporting them. Residual risk is the remaining exposure, including uncertainty and control limitations.
Risk Statements
A useful risk statement explains cause and effect. It should be clear enough that a technical reviewer and a business owner can both understand why the concern matters.
Practical structure
Because of a defined condition or control gap, a plausible event could affect a named asset, leading to abounded security and business consequence. Current controls reduce the exposure to a stated residual level, with any uncertainty kept visible.
Admin access is dangerous.
It does not identify the condition, asset, consequence, controls, evidence, or decision.
If privileged role membership remains after responsibilities change, unnecessary administrative authority could increase the scope of an incorrect configuration change. Strong authentication, approvals, logging, and recurring access review reduce the exposure, but review cadence still needs evidence.
It connects condition, asset, consequence, controls, and uncertainty.
Risk Treatment
Reduce the likelihood, impact, or uncertainty by improving controls, architecture, monitoring, recovery, training, ownership, or validation.
Example: Add a documented access-review schedule and evidence requirement for a fictional privileged role.
Caution: Mitigation should be specific enough to verify. 'Improve security' is not an actionable treatment.
Stop or redesign the activity that creates the risk when the value does not justify the exposure or when safe control is impractical.
Example: Remove an unnecessary fictional integration that adds no meaningful business value.
Caution: Avoidance may affect functionality, cost, or user needs, so the decision should include business context.
Shift part of the financial or operational responsibility through a contract, service agreement, insurance arrangement, or managed provider while recognizing that accountability does not disappear.
Example: Use a fictional managed service with defined security responsibilities and service commitments.
Caution: Transfer never means the organization can ignore governance, oversight, or residual risk.
Knowingly retain the residual risk because further reduction is not currently justified, while documenting owner approval, rationale, conditions, expiration, and review.
Example: Temporarily accept a low-impact fictional reporting limitation until a planned platform upgrade.
Caution: Acceptance should be explicit and time-bounded where appropriate. Ignoring a risk is not the same as accepting it.
Fake Dashboard
Synthetic portfolio dashboard for a fictional security-governance review.
Risks reviewed
6
All records are synthetic and derived from fictional architecture and threat-model evidence
Highest inherent
High
Privileged access, authorization, service identity, and federation carry larger uncontrolled consequences
Residual priorities
3
Role review, API validation evidence, and monitoring-source freshness require follow-up
Open evidence gaps
4
Control validation, review cadence, telemetry freshness, and recovery evidence remain bounded uncertainties
Fake SOC Alert
Source: Northbridge Risk Review Queue • Time: Synthetic governance checkpoint
Fake Log Panel
[RISK-201] Privileged-role review cadence remains an assumption; inherent High, residual Moderate. [RISK-202] API authorization is a confirmed design requirement; implementation validation evidence is outside the student model. [RISK-203] Monitoring freshness is an evidence gap, not proof of telemetry failure. [RISK-204] Service identity has elevated function; least-privilege review is required when workload scope changes. [RISK-205] Queue dependency creates availability concentration; recovery ownership lowers residual exposure. [RISK-206] Federation lifecycle requires named relationship ownership and closure evidence. [GOV] No accepted risk is complete without an accountable owner and review point. [SAFETY] All evidence is synthetic; no real systems, accounts, credentials, or production records are used.
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Fictional Case
These records are designed to show how a portfolio risk assessment connects security reasoning to a business decision. Each record includes the asset, cause, consequence, rating, controls, evidence, residual risk, treatment, owner, and review point.
Asset
Admin Review Console ADM-NB-2 and configuration integrity
Cause / Condition
A privileged fictional role may remain assigned longer than the user's current responsibilities require if lifecycle review is inconsistent.
Consequence
Unnecessary administrative authority could increase the scope of an accidental or unauthorized configuration change.
Current Controls
Restricted admin zone, stronger authentication, approval workflow, administrative logging, named role concept
Inherent
High
Likelihood
Moderate
Impact
High
Residual
Moderate
Evidence
Architecture and threat-model evidence show the privileged boundary, but the review schedule is still an assumption.
Treatment
Mitigate by defining an owner, review cadence, expiration for temporary grants, and evidence that each review occurred.
Ownership / Review
Identity Governance Lead · 30-day design review checkpoint
Asset
Synthetic student profile confidentiality and integrity
Cause / Condition
The model depends on API-NB-14 to enforce resource-level authorization, but the student portfolio intentionally contains no production configuration evidence.
Consequence
If authorization were not implemented as designed, a valid identity context could potentially receive or change a record outside its approved scope.
Current Controls
Identity authentication, API authorization requirement, application logging, owner review
Inherent
High
Likelihood
Low to Moderate
Impact
High
Residual
Moderate
Evidence
The architecture clearly assigns authorization responsibility to the API; implementation is recorded as an unverified design requirement.
Treatment
Mitigate by defining validation evidence that an authorized implementation owner would review before production approval.
Ownership / Review
Application Security Owner · Before fictional production approval
Asset
Detection confidence, investigation quality, and recovery validation
Cause / Condition
Synthetic identity, application, queue, and logging sources may not all arrive with the same freshness or coverage.
Consequence
Defenders could make a slower or less confident decision when reviewing unusual activity or validating recovery.
Current Controls
Centralized monitoring, source-health concept, escalation process
Inherent
Moderate
Likelihood
Moderate
Impact
Moderate
Residual
Moderate
Evidence
A fictional review note records telemetry freshness as an open evidence gap rather than a confirmed failure.
Treatment
Mitigate by defining expected source coverage, freshness targets, source-health ownership, and fallback review steps.
Ownership / Review
Security Monitoring Lead · Next monitoring design review
Asset
Data Service DS-NB-6 integrity and least-privilege design
Cause / Condition
A service identity used by Worker WK-NB-8 could gain permissions as the workload changes if grants are not periodically reviewed.
Consequence
A software defect or unintended automated action could affect a broader set of fictional records than required.
Current Controls
Dedicated service identity, scoped role design, service logging, workload ownership
Inherent
High
Likelihood
Low
Impact
High
Residual
Low to Moderate
Evidence
The threat model identifies the privileged service dependency but contains no real permission list.
Treatment
Mitigate through least-privilege requirements, change-triggered review, named ownership, and synthetic validation evidence.
Ownership / Review
Platform Engineering Owner · At each material workload change
Asset
Application availability and workflow integrity
Cause / Condition
API-NB-14 and Worker WK-NB-8 both depend on Queue Q-NB-5 for asynchronous work.
Consequence
A fictional queue outage or backlog could delay important updates and increase recovery effort.
Current Controls
Queue-health monitoring, worker monitoring, retry concept, documented recovery procedure
Inherent
Moderate
Likelihood
Low to Moderate
Impact
Moderate
Residual
Low to Moderate
Evidence
The architecture confirms dependency concentration, while exact performance thresholds are outside the exercise.
Treatment
Mitigate with clear health criteria, backlog monitoring, recovery ownership, and safe synthetic recovery testing.
Ownership / Review
Application Operations Lead · Quarterly architecture review
Asset
Identity trust, authorization, and accountability
Cause / Condition
A fictional external trust could remain active after the associated relationship changes if ownership and offboarding are unclear.
Consequence
Access could continue beyond the intended business relationship, creating unnecessary authorization exposure.
Current Controls
Federation approval, relationship owner concept, role mappings, access review
Inherent
High
Likelihood
Low
Impact
High
Residual
Low to Moderate
Evidence
The model includes the dependency but no real external partner or live federation metadata.
Treatment
Mitigate by defining relationship ownership, lifecycle review, mapping validation, and closure evidence.
Ownership / Review
Identity Architecture Lead · At relationship change and scheduled governance review
Analyze the Evidence
Evidence Confidence
Several independent synthetic sources agree, ownership is clear, timestamps and scope are consistent, and the evidence directly supports the rating.
Use: A rating can be stated with higher confidence while still acknowledging normal limitations.
The main condition is supported, but one or more control-effectiveness, ownership, timing, or dependency details remain incomplete.
Use: Keep the rating but include a confidence note and a validation action.
The concern is mostly based on assumption, a single ambiguous record, or incomplete context.
Use: Avoid strong claims. Record the gap, identify safe evidence needed, and consider a provisional rating.
Common Mistakes
A number or color is useful for sorting, but include a short rationale based on likelihood, impact, controls, and evidence confidence.
Risk assessment considers plausible future loss. Keep hypothetical risk separate from confirmed incident evidence.
Residual risk cannot be reasoned about fairly without considering controls and the evidence supporting their effectiveness.
Explain what the technical consequence means for users, operations, trust, recovery, compliance, or business objectives.
An evidence gap changes confidence. It does not automatically prove the worst case.
A valid acceptance decision needs an accountable owner, rationale, conditions, review date, and clear residual risk.
Safe Fictional Lab
Use the six supplied records as the evidence set. Your task is to refine the assessment, not to investigate anything outside the page.
Choose the three risks you believe deserve attention first. Explain the order using asset importance, likelihood, impact, controls, uncertainty, dependencies, and recovery.
Pick one record and argue for a different likelihood, impact, or residual rating. Your argument must cite the supplied fictional evidence and controls.
Rewrite one treatment so it has a clear owner, action, evidence of completion, and review point.
Create a low or moderate fictional risk that can reasonably be accepted. Include owner, rationale, residual risk, conditions, expiration, and review date.
Summarize the risk posture in one short paragraph without copying all six records. State the highest priorities, overall confidence, and immediate decisions.
Confirm that the final artifact contains only fictional systems and synthetic evidence and reveals no real internal security information.
Scenario Decision Lab
A fictional service owner asks to accept a moderate residual risk because the planned mitigation would not be completed until the next quarter.
Scenario Decision Lab
Two fictional risks both receive a Moderate residual rating. One affects a low-impact reporting feature; the other affects a shared monitoring dependency used during incident response.
Advanced Challenge
Choose one of the six Northbridge risks and explain it to each audience below. Keep the facts and rating consistent while changing the emphasis.
Focus on the condition, controls, evidence quality, residual exposure, and validation need.
Focus on the business consequence, treatment choices, cost or effort tradeoffs, ownership, and review date.
Focus on how the artifact proves your reasoning, evidence discipline, ethical boundaries, communication, and revision skill.
Defender Habits
Assessment
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a professional fictional Northbridge Risk Assessment. Include scope, assets, at least six risk statements, likelihood and impact rationale, inherent risk, current controls, evidence confidence, residual risk, treatment, owner, review date, top-three priorities, one carefully governed accepted-risk example, an executive summary, and a short publication-safety statement.
Confidence / Readiness Reflection
A19.6 moves into the Detection Plan Project. Before continuing, make sure you can explain how risk priorities influence what defenders choose to observe, what evidence they need, which conditions deserve alerts, and how detection quality supports decisions without becoming an offensive exercise.
I can explain inherent risk and residual risk.
I can write a risk statement that connects cause, asset, consequence, controls, and uncertainty.
I can explain why likelihood and impact require context and evidence.
I can compare mitigate, avoid, transfer, and accept treatments.
I can describe what makes a risk decision accountable and reviewable.
Portfolio Build Guide
IDs make it easy to connect the register, treatment plan, executive summary, and future revisions without repeating entire paragraphs.
A reader should understand why a risk is Moderate or High even if the scoring method is removed.
List only relevant controls and explain how they reduce likelihood, impact, or uncertainty.
A serious risk can still have low evidence confidence. Record both rather than pretending uncertainty does not exist.
The owner should know what action is expected and what evidence will show that the treatment or review is complete.
Owner, rationale, review date, acceptance conditions, exceptions, and residual risk prove that the assessment supports real decisions.
Use technical details where they support the decision, but summarize the business meaning so nontechnical reviewers can understand the priority.
A school portfolio should prove your reasoning with fictional systems, not with confidential details from a real organization.
Key Takeaways
Lesson Safety Boundary
Use only fictional Northbridge records and synthetic evidence. Do not scan, probe, enumerate, exploit, fuzz, guess credentials, test access, collect private information, bypass controls, change configurations, or investigate real environments. Do not publish real internal diagrams, credentials, private records, confidential findings, or unresolved weaknesses from a real organization. The purpose is defensive risk reasoning, prioritization, governance, communication, and portfolio development.
Lesson Complete
You now have a portfolio structure for turning threat-model findings into owned, evidence-based risk decisions. Next, A19.6 builds a Detection Plan Project focused on what defenders need to observe and how detection evidence supports safe decisions.