Lesson A15.2
Good risk analysis starts before the score. You need to understand what matters, what could happen, what the business consequence would be, how plausible the scenario is, and how strong the evidence behind that judgment really is.
This lesson uses fictional scenarios and safe business-risk evidence only. It does not teach or require scanning, exploitation, credential attacks, or testing of real systems or suppliers.
Lesson Progress
High School Advanced • A15: Risk Management and Compliance • Lesson 2 of 10
Readiness Check
0/4 ready
Professional Hook
A highly protected database can still be critical. A trusted vendor can still create concentration risk. A severe scenario can still be unlikely. Risk analysis becomes useful when it separates these ideas instead of collapsing them into one number.
Strong risk reasoning connects assets, threat events, consequences, plausibility, controls, evidence, and uncertainty.
Learning Objectives
Identify business services, assets, data, people, suppliers, identities, and operational dependencies that shape cybersecurity risk.
Write clear threat-event scenarios that describe what could happen without turning risk analysis into offensive testing.
Evaluate business impact across confidentiality, integrity, availability, financial, legal, operational, safety, and reputational dimensions.
Estimate likelihood using current evidence, exposure conditions, control strength, history, dependency, and uncertainty rather than treating a score as a prediction.
Build a Risk Analysis Worksheet that becomes the second artifact in the A15 Risk Register and Leadership Recommendation.
Asset View
Examples: Student support, scheduling, finance, learning systems, communications, recovery, analytics.
Why it matters: Risk matters because business services deliver outcomes people depend on.
Ask: What important service could be interrupted, degraded, misused, or lose trust?
Examples: Student records, employee information, reports, exports, credentials, audit evidence, backups.
Why it matters: Data sensitivity, integrity, retention, and availability shape impact.
Ask: What happens if this data is exposed, altered, unavailable, or retained incorrectly?
Examples: Students, staff, administrators, service accounts, workloads, partners, suppliers.
Why it matters: Identity controls determine who can act and what actions they can perform.
Ask: Which identity relationship could create a larger business consequence?
Examples: Web portals, APIs, databases, cloud services, backup platforms, internal tools.
Why it matters: Applications and platforms deliver business functions and enforce many controls.
Ask: What happens to the business if this technology fails or behaves incorrectly?
Examples: SaaS provider, payment processor, scheduling partner, managed service provider.
Why it matters: The organization can depend on systems it does not fully control.
Ask: Which supplier failure could create a major business or security consequence?
Examples: Approvers, operators, help desk, incident responders, business owners, auditors.
Why it matters: Human decisions and process quality can strengthen or weaken controls.
Ask: Which role or process is essential to prevention, detection, response, or recovery?
Threat Scenarios
Name the service, process, asset, or dependency that matters.
Example: Critical student-support portal used throughout the school day.
Describe the harmful event at a high level.
Example: The portal becomes unavailable during a high-demand period.
Describe the relevant weakness or dependency without offensive detail.
Example: The service depends on one external identity provider with limited alternate access.
Explain what the organization loses or struggles to do.
Example: Students and support staff cannot access critical support workflows.
Record safeguards that reduce the risk.
Example: Service monitoring, backup authentication path, continuity procedures.
Show what supports the judgment and what remains unclear.
Example: Continuity procedure is current, but the alternate-authentication test is six months old.
Impact
Low: Limited internal information exposed with little business consequence.
Medium: Sensitive information exposed to a bounded group or limited scope.
High: Sensitive or regulated information exposed broadly or to unauthorized parties.
Low: Minor incorrect data that can be corrected quickly.
Medium: Important records or decisions may be wrong until detected and corrected.
High: Critical decisions, financial records, release artifacts, or safety-relevant data cannot be trusted.
Low: Short interruption with easy workaround.
Medium: Noticeable service interruption requiring manual workaround or delayed work.
High: Critical service outage with major operational or recovery impact.
Low: Small operational cost.
Medium: Meaningful remediation, delay, contractual, or productivity cost.
High: Major direct or indirect financial consequence.
Low: Minimal policy issue with straightforward correction.
Medium: Material audit finding, notification obligation, or policy exception.
High: Major regulatory, contractual, legal, or governance consequence.
Low: Limited stakeholder concern.
Medium: Noticeable loss of confidence among a user or partner group.
High: Broad stakeholder or leadership trust loss affecting the organization.
Likelihood
How often is the service, data, or trust relationship exposed to the relevant condition?
Evidence: Architecture scope, user population, external dependency, workflow frequency.
How effectively do current controls prevent, detect, contain, or recover from the scenario?
Evidence: Control test, monitoring, access review, recovery evidence, policy state.
Has the organization or a closely related process experienced similar failures?
Evidence: Authorized incident summaries, outage records, control findings, trend reports.
Has the environment recently changed in a way that increases uncertainty?
Evidence: Migration, new supplier, new data class, ownership change, architecture redesign.
How much does the scenario depend on one system, team, vendor, or control?
Evidence: Single points of failure, supplier concentration, recovery alternatives.
How current and complete is the information behind the estimate?
Evidence: Source owner, freshness, consistency, completeness, validation.
Likelihood Scale
Scenario is plausible but currently constrained by strong controls, limited exposure, strong alternatives, or weak evidence of occurrence.
Caution: Low does not mean impossible.
Some exposure or dependency exists, but controls and evidence still reduce plausibility substantially.
Caution: Watch for change triggers that could move the estimate upward.
Scenario is reasonably plausible under current business and control conditions.
Caution: Document which assumptions would move the estimate up or down.
Several exposure, dependency, control, or evidence conditions make the scenario notably plausible.
Caution: Treatment or closer monitoring is usually warranted.
Current evidence strongly suggests the scenario is highly plausible or already recurring.
Caution: High likelihood should still be supported by clear evidence, not fear.
Evidence Quality
Example: Current access review, recovery test, supplier assessment, control validation, or architecture record.
Confidence effect: Strongest support for the present decision.
Example: Recent monitoring or related operational evidence that supports but does not directly prove the scenario.
Confidence effect: Useful with clearly stated inference.
Example: Some systems, owners, or dependencies are known while others are still being mapped.
Confidence effect: Supports a Conditional conclusion, not full confidence.
Example: An old control test or supplier review no longer reflects the current environment.
Confidence effect: Should reduce confidence and often trigger review.
Example: No current owner or evidence can be found for a material dependency.
Confidence effect: Use Unknown or a more cautious likelihood/decision state.
Example: One source says the control is current while another shows a failed test or unresolved dependency.
Confidence effect: Preserve the conflict and resolve what each source actually proves.
Reasoning Principles
Impact asks what happens to the organization if the scenario occurs.
Review: Would the impact still be serious even if likelihood were low?
Likelihood asks how plausible the scenario is under current conditions and evidence.
Review: What evidence makes the scenario more or less plausible?
A control can reduce the chance of the event, reduce the damage, speed detection, or improve recovery.
Review: Which part of the scenario does each control actually change?
A business-critical service may still have high impact even when controls make the event unlikely.
Review: Are you reducing impact just because controls are strong?
A once-strong control may no longer be strong after change or drift.
Review: When was the evidence last validated?
Risk matrices simplify a complex judgment.
Review: Which assumptions are hidden behind the label or score?
A strong supplier or platform can still create concentration or single-point-of-failure risk.
Review: What happens if the dependency is unavailable?
Likelihood and impact can change after new users, data, suppliers, architecture, controls, or ownership.
Review: What event should reopen the estimate?
Vocabulary
The importance of an asset or service to organizational objectives.
A harmful event or condition that could affect a business service or asset.
A weakness, dependency, or circumstance that affects how plausible or harmful a scenario is.
The business consequence if the scenario occurs.
A reasoned estimate of how plausible the scenario is under current conditions.
A structured description connecting a threat event, business context, exposure condition, and consequence.
How current, complete, direct, attributable, and consistent the supporting information is.
A condition treated as true for the analysis even though it may not be fully proven.
The degree to which the reviewer lacks complete confidence about the scenario, evidence, or future conditions.
A system, person, supplier, control, or process that another business service relies on.
Risk created when too much business capability depends on one provider, technology, location, or control.
A simplified tool that combines impact and likelihood labels to support prioritization.
Fictional Analysis Register
Asset / service
Sensitive student-support workflow
Threat event
Portal service becomes unavailable during a high-demand school period.
Exposure condition
Heavy dependence on a small number of critical platform services.
Impact
High — support workflows stop, users lose access, recovery effort increases.
Likelihood
Low-Medium — strong monitoring and redundancy exist, but dependency remains.
Evidence
Current availability architecture + current recovery test + service monitoring
Uncertainty
Actual business load during peak events can vary significantly.
Controls
Monitoring, redundancy, recovery procedures, capacity management
Asset / service
Historical sensitive reports
Threat event
Legacy trust or transport weakness contributes to unauthorized exposure or service disruption.
Exposure condition
Broad trust relationships, incomplete ownership, aging platform, modernization incomplete.
Impact
High — sensitive data exposure, operational disruption, investigation difficulty.
Likelihood
Medium-High — multiple active gaps increase plausibility.
Evidence
Current exception + partial inventory + current trust findings
Uncertainty
Several dependencies remain incompletely mapped.
Controls
Restricted network scope, partial monitoring, modernization plan
Asset / service
Scheduling data and partner availability
Threat event
Partner certificate lifecycle failure interrupts trusted service communication.
Exposure condition
Current certificate expires in 45 days.
Impact
Medium-High — scheduling disruption and partner-service interruption.
Likelihood
Medium — renewal is approaching but sponsor and workflow are active.
Evidence
Current certificate + renewal ticket + current partner sponsor
Uncertainty
Partner deployment timing remains externally dependent.
Controls
Certificate monitoring, renewal process, sponsor oversight
Asset / service
Critical recovery data
Threat event
A major disruption occurs and required data cannot be restored within business expectations.
Exposure condition
Recovery depends on current backup data, keys, procedures, and platform availability.
Impact
High — prolonged outage, potential data loss, major recovery cost.
Likelihood
Low-Medium when current restore validation passes.
Evidence
Current backup inventory + current key inventory + most recent restore test
Uncertainty
A real disaster can differ from a planned recovery test.
Controls
Encrypted backups, protected replication, restricted recovery, restore testing
Asset / service
Business workflow dependent on one supplier
Threat event
Provider outage or business failure interrupts the dependent service.
Exposure condition
No practical alternate provider is available today.
Impact
High — major business interruption until service or workaround is restored.
Likelihood
Medium — supplier is stable but concentration remains.
Evidence
Current supplier review + contract + continuity plan
Uncertainty
Future provider stability and outage conditions cannot be predicted precisely.
Controls
Supplier monitoring, contractual commitments, continuity procedures
Asset / service
Sensitive report package
Threat event
An approved export remains in temporary storage longer than intended.
Exposure condition
Temporary staging exists outside the primary application data store.
Impact
Medium-High — sensitive duplicate data remains accessible longer than necessary.
Likelihood
Low-Medium — automated cleanup exists but requires current evidence.
Evidence
Current retention policy + recent cleanup validation
Uncertainty
Large or interrupted export jobs may follow different timing.
Controls
Encrypted staging, short retention, cleanup monitoring, export authorization
Fake Dashboard
Fictional impact, likelihood, evidence, and treatment summary
Scenarios analyzed
6
Business-service, legacy, partner, recovery, supplier, and export risks
High impact
4
Portal outage, legacy reporting, recovery failure, and SaaS concentration
Medium-High likelihood
1
Legacy reporting has multiple active exposure conditions
Treat / Conditional
3
Legacy, supplier concentration, and partner lifecycle require action or conditions
Fake SOC Alert
Source: Fictional Risk Analysis Review • Time: 08:38
Impact vs. Likelihood
One of the most important risk-analysis habits is resisting the urge to make impact and likelihood move together. A critical service outage can have High impact and Low likelihood. A small recurring control failure can have Low impact and High likelihood. Both dimensions matter for different reasons.
“If this happens, what is the business consequence?”
“How plausible is this under current exposure, controls, dependencies, history, and evidence?”
Fake Log Panel
[08:14] ANL-01 portal impact=HIGH likelihood=LOW_MEDIUM evidence=CURRENT state=MONITOR [08:38] ANL-02 legacy impact=HIGH likelihood=MEDIUM_HIGH evidence=PARTIAL state=TREAT [09:02] ANL-03 partner impact=MEDIUM_HIGH likelihood=MEDIUM cert_expiry=45d state=CONDITIONAL [09:26] ANL-04 recovery impact=HIGH likelihood=LOW_MEDIUM restore=CURRENT state=MONITOR [09:50] ANL-05 supplier impact=HIGH likelihood=MEDIUM concentration=SINGLE_PROVIDER state=TREAT [10:14] ANL-06 export impact=MEDIUM_HIGH likelihood=LOW_MEDIUM cleanup=CURRENT state=MONITOR
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Analysis Mistakes
Why it fails: The worksheet lists servers and applications but never explains what service or business outcome they support.
Better approach: Connect technology assets to the business service, data, people, and dependency that matter.
Why it fails: A label like 'cyberattack' does not explain the scenario.
Better approach: Describe the high-level harmful event, affected service, exposure condition, and consequence.
Why it fails: A severe consequence is automatically treated as highly likely.
Better approach: Reason about consequence and plausibility separately.
Why it fails: A critical outage still has high consequence even if controls make it less likely.
Better approach: Use controls to change the part of the analysis they actually affect.
Why it fails: A dramatic scenario receives a High label without supporting evidence.
Better approach: Use exposure, controls, history, change, dependency, and evidence quality.
Why it fails: A years-old test continues to support today's risk estimate.
Better approach: Record evidence freshness and lower confidence when it becomes stale.
Why it fails: Supplier controls look strong, so concentration and continuity risk disappear from the analysis.
Better approach: Separate supplier control quality from dependency consequences.
Why it fails: The final output is only a colored box or number.
Better approach: Preserve scenario, impact reasoning, likelihood reasoning, evidence, uncertainty, and ownership.
Scenario Decision Lab
A legacy reporting service has several open control gaps, partial dependency evidence, and a current modernization exception.
Scenario Decision Lab
A stable SaaS provider has strong evidence and contracts, but one critical business workflow has no practical alternative provider.
Safe Fictional Lab
Use fictional business services, assets, suppliers, threat events, impact reasoning, likelihood reasoning, controls, and evidence only. No real system testing is needed.
Create at least twenty fictional risk-analysis records.
Give every record a stable ANL ID.
Record the business service.
Record the asset or dependency.
Write a high-level threat event.
Record the exposure condition.
Analyze confidentiality impact where relevant.
Analyze integrity impact where relevant.
Analyze availability impact where relevant.
Analyze financial/operational impact where relevant.
Analyze legal/compliance impact where relevant.
Analyze reputational impact where relevant.
Assign an overall impact label with reasoning.
Record current controls.
Record control evidence.
Record evidence freshness.
Analyze exposure frequency.
Analyze dependency or concentration.
Analyze recent change.
Analyze relevant history if available.
Assign a likelihood label with reasoning.
Record assumptions.
Record uncertainty.
Choose a decision state.
Record what evidence would move likelihood higher.
Record what evidence would move likelihood lower.
Include at least four High-impact / Low-or-Medium-likelihood scenarios.
Include at least three Medium-impact / High-likelihood scenarios.
Include at least three third-party dependency scenarios.
Include at least two scenarios with stale evidence.
Include at least two scenarios with contradictory evidence.
Lab boundary
Do not scan, probe, exploit, test, or investigate real systems, vendors, or people. Do not attempt to prove likelihood through unsafe testing. Use fictional and authorized evidence only.
Analyze the Evidence
Advanced Challenge
Create a fictional organization-wide method for describing impact and likelihood without turning the result into fake precision.
Impact dimensions
Likelihood factors
Evidence freshness
Assumption field
Uncertainty field
Dependency field
Control-strength field
Change trigger
Third-party concentration
Recovery dependency
Business criticality
Decision state
Narrative rationale
Score or matrix as optional summary
Review cadence
Leadership explanation
The strongest method should help reviewers compare risks without pretending that a label or score can perfectly predict the future.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the second artifact for your A15 Risk Register and Leadership Recommendation: a fictional Risk Analysis Worksheet with at least twenty records. Include ANL ID, business service, asset/dependency, threat event, exposure condition, impact dimensions, overall impact, controls, evidence, freshness, likelihood factors, overall likelihood, assumptions, uncertainty, decision state, evidence that would raise likelihood, evidence that would lower likelihood, and review trigger.
Confidence / Readiness Reflection
A15.3 focuses on Risk Registers and Ownership. Before continuing, make sure you can explain a risk clearly enough that it can be entered into a professional register.
I can identify business assets and dependencies.
I can write a safe, high-level threat scenario.
I can separate impact and likelihood.
I can explain how evidence freshness changes confidence.
I can document uncertainty instead of hiding it in a score.
Portfolio Build Guide
Show what service, asset, data, user group, or supplier matters before describing the threat event.
Consider confidentiality, integrity, availability, financial, legal, operational, and reputational consequences where relevant.
Show exposure, controls, history, change, dependency, and evidence quality behind the label.
Record missing, partial, stale, or contradictory evidence explicitly.
Include suppliers, identities, recovery, single points of failure, and concentration where relevant.
A score or matrix can summarize the result, but the narrative should remain the real analysis.
New data, owner, supplier, architecture, control, incident, or evidence changes should reopen the estimate.
A15.3 will turn these worksheets into a structured Cybersecurity Risk Register with accountable ownership.
Key Takeaways
Lesson Safety Boundary
Do not scan, probe, exploit, test, or investigate real systems, vendors, accounts, or people. Do not collect credentials or private organizational evidence. All scenarios, suppliers, assets, controls, logs, and evidence in this lesson are fictional.
Lesson Complete
You now have a structured way to analyze assets, threat events, business impact, likelihood, dependencies, evidence quality, and uncertainty. Next, A15.3 focuses on Risk Registers and Ownership.