High School Intermediate • I11: Incident Response Basics • Lesson 2 of 8
25% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
A High-Severity Alert Can Still Produce the Wrong Response
A fictional support-service monitor reports unusual storage access by a preview-worker identity. The alert is high severity, but one log source is delayed, a teacher started an approved preview job, and a configuration change occurred the previous evening. Strong triage does not ignore the alert or assume compromise. It preserves the signal, tests each explanation, protects the workflow, and records exactly what the evidence supports.
Weak triage
Copy the alert title, accept the tool severity, declare a confirmed incident, disable the entire support platform, and notify every stakeholder.
Build a defensible fictional initial assessment using asset, identity, file, transaction, service, deployment, source-health, business, and timeline evidence.
Objective 4
Assign fictional confidence, severity, owners, containment recommendations, evidence-collection actions, communication needs, and reassessment triggers.
Objective 5
Create a professional fictional Triage and Initial Assessment Package using only supplied records and safe, authorized defensive reasoning.
Why This Matters
Triage Controls the Quality of Every Later Incident Decision
If the initial classification is wrong, teams may lose evidence, disrupt critical services, communicate unsupported claims, miss real scope, or close a meaningful event too early. A defensible initial assessment creates a shared evidence baseline for containment, investigation, communication, recovery, governance, and closure.
Triage Workflow
Eight Steps from Signal to Initial Assessment
Preserve the original signal
Keep the fictional alert, user report, support ticket, vendor notice, or control event unchanged and record its source, time, and identifier.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for preserve the original signal.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of preserve the original signal.
Common failure
Avoid treating preserve the original signal as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Verify source health
Confirm that the fictional source is current, complete, correctly parsed, retained, accessible, and owned before relying on silence or detail.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for verify source health.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of verify source health.
Common failure
Avoid treating verify source health as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Identify the affected context
Map the fictional signal to a stable asset, environment, identity, service, user, file, transaction, data set, workflow, and owner.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for identify the affected context.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of identify the affected context.
Common failure
Avoid treating identify the affected context as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Compare expected behavior
Determine whether the fictional activity is normal, approved, unusual, unsupported, prohibited, or unknown for the reviewed scope and time.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for compare expected behavior.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of compare expected behavior.
Common failure
Avoid treating compare expected behavior as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Correlate independent evidence
Use fictional identity, application, transaction, file, queue, deployment, network, support, and business records to test competing explanations.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for correlate independent evidence.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of correlate independent evidence.
Common failure
Avoid treating correlate independent evidence as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Classify and assign confidence
Choose the narrowest fictional classification supported by current evidence and document confidence, alternatives, and gaps.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for classify and assign confidence.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of classify and assign confidence.
Common failure
Avoid treating classify and assign confidence as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Recommend severity and action
Connect fictional urgency, scope, consequence, business effect, controls, uncertainty, owners, communication, and protective action.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for recommend severity and action.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of recommend severity and action.
Common failure
Avoid treating recommend severity and action as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Document and hand off
Create a fictional initial assessment, evidence index, open questions, action register, next update time, and reassessment triggers.
What to examine
Review fictional asset, identity, time window, source health, expected behavior, related events, business workflow, and known controls for document and hand off.
Evidence standard
Use at least two relevant fictional sources when possible, preserve the original record, document confidence and limitations, and identify what additional evidence would change the assessment of document and hand off.
Common failure
Avoid treating document and hand off as confirmed impact, broad scope, or final severity when the supporting evidence is incomplete, duplicated, stale, delayed, or dependent on one source.
Collect the fictional records connected to alert and control records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about alert and control records when its health, scope, and relationship to the event are known.
Limitations
Do not use alert and control records alone to prove motive, full scope, production impact, or a complete incident narrative.
Identity and access records
Fictional sign-in, session, role, service identity, token, permission, revocation, approval, and access-decision evidence.
Useful records
Collect the fictional records connected to identity and access records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about identity and access records when its health, scope, and relationship to the event are known.
Limitations
Do not use identity and access records alone to prove motive, full scope, production impact, or a complete incident narrative.
Collect the fictional records connected to application and service records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about application and service records when its health, scope, and relationship to the event are known.
Limitations
Do not use application and service records alone to prove motive, full scope, production impact, or a complete incident narrative.
Collect the fictional records connected to file and data records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about file and data records when its health, scope, and relationship to the event are known.
Limitations
Do not use file and data records alone to prove motive, full scope, production impact, or a complete incident narrative.
Transaction and business records
Fictional approved workflows, support cases, user actions, reports, schedules, service outcomes, and business confirmations.
Useful records
Collect the fictional records connected to transaction and business records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about transaction and business records when its health, scope, and relationship to the event are known.
Limitations
Do not use transaction and business records alone to prove motive, full scope, production impact, or a complete incident narrative.
Deployment and runtime records
Fictional builds, artifacts, images, versions, configurations, feature flags, service identities, runtime inventory, and recovery state.
Useful records
Collect the fictional records connected to deployment and runtime records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about deployment and runtime records when its health, scope, and relationship to the event are known.
Limitations
Do not use deployment and runtime records alone to prove motive, full scope, production impact, or a complete incident narrative.
User and support reports
Fictional observations from students, teachers, staff, support, vendors, or service owners with time, scope, and uncertainty.
Useful records
Collect the fictional records connected to user and support reports, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about user and support reports when its health, scope, and relationship to the event are known.
Limitations
Do not use user and support reports alone to prove motive, full scope, production impact, or a complete incident narrative.
Collect the fictional records connected to source-health and evidence-quality records, including timestamps, source owner, expected events, retention, delay, parsing, and access history.
Can support
This source can support narrow conclusions about source-health and evidence-quality records when its health, scope, and relationship to the event are known.
Limitations
Do not use source-health and evidence-quality records alone to prove motive, full scope, production impact, or a complete incident narrative.
Core Concept
Use the Signal–Source–Context–Correlation–Classification–Action Chain
Signal
What fictional alert, report, event, transaction, or control record started the review?
Source
Is the fictional evidence current, complete, independent, correctly parsed, retained, accessible, and owned?
Context
Which fictional asset, environment, identity, data, file, service, workflow, owner, and time window are involved?
Correlation
Which fictional independent sources support or contradict the alert and competing explanations?
Classification
Which fictional facts, conclusions, alternatives, gaps, confidence, severity, and scope are justified?
Action
Which fictional collection, protection, escalation, communication, ownership, deadline, and reassessment should follow?
Classification
Eight Evidence-Based Triage Outcomes
Expected or approved activity
Fictional evidence shows the event matches an authorized workflow, identity, time, asset, data, and business purpose.
Definition
Use the fictional expected or approved activity classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to expected or approved activity.
Reclassify when
Reassess expected or approved activity when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Benign positive
The fictional control correctly detected real activity, but the activity was approved and did not violate the expected security requirement.
Definition
Use the fictional benign positive classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to benign positive.
Reclassify when
Reassess benign positive when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Operational or reliability issue
Fictional evidence points to service, deployment, capacity, configuration, queue, file, timing, or source-health failure rather than a security incident.
Definition
Use the fictional operational or reliability issue classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to operational or reliability issue.
Reclassify when
Reassess operational or reliability issue when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Duplicate or related record
The fictional signal belongs to an existing case or repeated source record and should be linked rather than counted as a separate event.
Definition
Use the fictional duplicate or related record classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to duplicate or related record.
Reclassify when
Reassess duplicate or related record when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Suspicious activity
The fictional behavior is unusual or inconsistent with expectations and requires more evidence, scope review, or protective action.
Definition
Use the fictional suspicious activity classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to suspicious activity.
Reclassify when
Reassess suspicious activity when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Insufficient evidence
The fictional team cannot classify reliably because important asset, identity, source-health, business, time, or outcome evidence is missing.
Definition
Use the fictional insufficient evidence classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to insufficient evidence.
Reclassify when
Reassess insufficient evidence when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Confirmed security event
Reliable fictional evidence supports a security-relevant occurrence, while full incident scope or business impact may remain uncertain.
Definition
Use the fictional confirmed security event classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to confirmed security event.
Reclassify when
Reassess confirmed security event when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Incident candidate
The fictional evidence supports coordinated response, containment, investigation, communication, recovery, and governance even if some scope or impact remains under review.
Definition
Use the fictional incident candidate classification only when the documented evidence matches its exact threshold and scope.
Required record
Preserve the facts, supported conclusion, alternatives, confidence, evidence gaps, owner, severity recommendation, and next action connected to incident candidate.
Reclassify when
Reassess incident candidate when new asset, identity, source-health, business, scope, transaction, file, or timeline evidence appears.
Decision Points
Eight Decisions That Require Evidence and Ownership
Open a new case or link an existing case
Determine whether the fictional signal represents a distinct event, duplicate record, related activity, or scope expansion.
Decision question
Ask which fictional action connected to open a new case or link an existing case is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for open a new case or link an existing case.
Stop condition
Pause escalation or broad action when open a new case or link an existing case depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Collect more evidence or act immediately
Balance fictional uncertainty, urgency, possible consequence, source health, business criticality, and available preapproved protection.
Decision question
Ask which fictional action connected to collect more evidence or act immediately is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for collect more evidence or act immediately.
Stop condition
Pause escalation or broad action when collect more evidence or act immediately depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Escalate severity or maintain current level
Use fictional scope, impact, confidence, privilege, data, service criticality, controls, and coordination needs.
Decision question
Ask which fictional action connected to escalate severity or maintain current level is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for escalate severity or maintain current level.
Stop condition
Pause escalation or broad action when escalate severity or maintain current level depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Apply narrow containment or continue monitoring
Choose fictional protective actions that are proportionate, reversible, evidence-preserving, and continuity-aware.
Decision question
Ask which fictional action connected to apply narrow containment or continue monitoring is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for apply narrow containment or continue monitoring.
Stop condition
Pause escalation or broad action when apply narrow containment or continue monitoring depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Notify business or leadership owners
Decide when fictional operational, privacy, continuity, legal, policy, or leadership attention is necessary.
Decision question
Ask which fictional action connected to notify business or leadership owners is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for notify business or leadership owners.
Stop condition
Pause escalation or broad action when notify business or leadership owners depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Request technical-owner review
Engage fictional application, platform, identity, data, network, vendor, or service owners for expected behavior and safe actions.
Decision question
Ask which fictional action connected to request technical-owner review is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for request technical-owner review.
Stop condition
Pause escalation or broad action when request technical-owner review depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Declare an incident candidate
Advance the fictional record when current evidence justifies coordinated response beyond routine triage.
Decision question
Ask which fictional action connected to declare an incident candidate is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for declare an incident candidate.
Stop condition
Pause escalation or broad action when declare an incident candidate depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Close intake or keep pending
Close only when the fictional explanation, evidence, ownership, documentation, and reopen triggers are sufficient.
Decision question
Ask which fictional action connected to close intake or keep pending is justified by current evidence, urgency, business context, and available authority.
Required evidence
Use the original signal, correlated sources, source health, asset and identity context, expected behavior, business effect, and documented uncertainty for close intake or keep pending.
Stop condition
Pause escalation or broad action when close intake or keep pending depends on unsupported assumptions, missing ownership, or an evidence source known to be unhealthy.
Correlated Triage Timeline
Follow a Fictional Alert from Intake to Initial Assessment
08:40
Support monitor
A fictional alert reports repeated preview failures and one unusual service-identity access decision.
The original signal requires preservation and review but does not prove an incident.
08:43
Source health
Application logs are delayed by eighteen minutes, while identity and transaction sources are current.
The team must lower confidence in application-level silence and use alternate evidence.
08:46
Asset inventory
The alert maps to the fictional student-support preview worker in production, owned by the support applications team.
Stable asset and owner context are established.
08:50
Identity records
The service identity uses its normal source, but requests one storage location outside its documented scope.
The behavior is unusual and security-relevant but not yet fully explained.
08:55
Business records
A teacher initiated an approved preview job for an active support case at the same time.
There is a legitimate workflow that may explain part of the activity.
09:00
Deployment record
A configuration update expanded a storage prefix during a maintenance window the previous evening.
A recent change provides a plausible operational or configuration explanation.
09:05
Transaction review
No unrelated documents were returned, and the preview transaction failed before file retrieval completed.
Current evidence does not support confirmed data exposure.
09:10
Technical owner
The storage prefix was intended for one recovery folder but was broader than the approved design.
A configuration weakness is confirmed even though harmful impact is not.
09:15
Triage decision
The case is classified as a confirmed security event with medium severity, high confidence, narrow containment, and additional scope review.
The classification matches the evidence without claiming a broader incident.
09:20
Containment
The identity is restricted to the approved support-case path, preview jobs continue, and monitoring is increased.
The response reduces risk while preserving legitimate workflow and evidence.
09:35
Application logs
Delayed logs arrive and confirm the failed job did not read or export unrelated files.
Confidence increases and production impact remains unsupported.
10:00
Handoff
The initial assessment records facts, conclusions, alternatives, gaps, severity, actions, owners, and reassessment triggers.
The investigation can continue from a complete and defensible triage package.
Key Vocabulary
Detection, Triage, and Initial Assessment Terms
Intake
The fictional process of receiving, preserving, labeling, deduplicating, assigning, and recording a new signal for review.
Triage
A fictional structured review that determines urgency, evidence quality, classification, ownership, severity recommendation, and next actions.
Initial assessment
A fictional early case summary separating confirmed facts, supported conclusions, alternatives, evidence gaps, confidence, scope, and immediate needs.
False positive
A fictional signal that appears security-relevant but is unsupported after evidence review and is better explained by expected or benign activity.
Benign positive
A fictional real event correctly detected by a control but caused by approved activity rather than harmful behavior.
Suspicious activity
A fictional condition that differs from expected behavior and deserves further review but is not yet a confirmed incident.
Confirmed security event
A fictional security-relevant occurrence supported by reliable evidence, though scope, impact, or incident status may still require investigation.
Incident
A fictional confirmed or sufficiently supported condition requiring coordinated response because security or business trust may be affected.
Confidence
A fictional statement describing how strongly the available evidence supports a conclusion and what limitations remain.
Severity recommendation
A fictional proposed response priority based on scope, consequence, confidence, business context, controls, and coordination needs.
Evidence gap
A fictional missing, delayed, conflicting, incomplete, inaccessible, or unhealthy record that limits the assessment.
Reassessment trigger
A fictional event that requires the triage decision to be reviewed again, such as new scope, impact, source health, identity, file, transaction, or business evidence.
Fake Dashboard
Fake Incident Triage Dashboard
Training dashboard for the fictional Meadowbrook district.
New signals awaiting triage
12
Fictional alerts and reports awaiting source-health, asset, identity, business, and classification review.
Evidence-limited cases
4
Fictional records with delayed sources, unknown assets, conflicting timestamps, or incomplete business context.
Median initial assessment time
24 min
Fictional time from preserved intake to documented classification, confidence, ownership, and next action.
Source: Fake Support Service Monitor • Time: 8:40 AM
High Severity
A fictional preview-worker identity requests one storage path outside its documented scope during an approved teacher preview job. Application logs are delayed, identity and transaction sources are current, and a configuration update occurred during the previous maintenance window.
Defensive recommendation: Preserve the alert; confirm source health; map the asset, identity, storage, workflow, owner, and change record; review expected behavior; correlate transaction and file outcomes; apply narrow least-privilege containment if justified; avoid claiming data exposure without evidence; assign technical and business owners; document confidence, gaps, severity, and reassessment triggers.
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Initial Assessment Is Best Supported?
The fictional service identity used its normal source and time window.
The identity requested one storage path outside documented scope.
An approved teacher preview job was active.
A recent configuration update broadened the storage prefix.
The transaction failed before unrelated file retrieval completed.
No supplied file or transaction record shows unrelated documents were returned.
Delayed application logs later confirm no unrelated file read.
The technical owner confirms the configuration exceeded the approved design.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Triage and Initial Assessment
Treating a fictional alert title, severity, or rule name as proof of an incident or business impact.
Rewriting the original signal before preserving the raw record, source, time, identifier, and context.
Using dashboard silence without checking source health, delivery delay, parsing, retention, and access.
Failing to map the signal to a stable asset, environment, identity, owner, workflow, and time window.
Counting repeated copies of one source as independent corroboration.
Ignoring expected maintenance, approved workflows, business transactions, and operational changes that may explain activity.
Closing a record as benign when important evidence is missing or conflicting.
Escalating to critical severity because the activity is unusual without evidence of scope, consequence, or impact.
Applying broad containment before understanding affected services, continuity, evidence needs, and rollback.
Writing an initial assessment that mixes facts, conclusions, alternatives, and assumptions in one paragraph.
Failing to assign evidence collection, technical review, source repair, communication, and reassessment actions to owners and deadlines.
Publishing real alerts, logs, users, identities, case details, owner names, system names, routes, or private organizational information in a portfolio artifact.
Safe Practice Lab
Complete a Fictional Detection and Triage Package
Fictional Evidence Set
Meadowbrook Initial Assessment
Review fifty-four supplied fictional records covering alerts, source health, assets, identities, services, files, queues, transactions, deployments, configurations, support reports, business workflows, owners, expected behavior, containment, communication, and handoff.
Required Deliverables
Preserve and deduplicate the fictional intake records.
Validate source health and identify alternate evidence.
Map asset, identity, service, data, file, transaction, workflow, owner, and time context.
Classify each signal and assign confidence, alternatives, gaps, and severity.
Recommend proportionate evidence collection, technical review, containment, communication, and escalation.
Produce an initial assessment, evidence index, action register, handoff summary, and portfolio-safe report.
Use only supplied fictional evidence. Do not access, test, alter, identify, contact, or publish real systems, users, identities, files, transactions, alerts, logs, owners, routes, credentials, or private organizational information.
Scenario Decision Lab
The High-Severity Alert Has a Plausible Approved Explanation
A fictional alert reports unusual service activity, but an approved business workflow and a recent configuration change may explain part of the behavior.
Scenario Decision Lab
A Quiet Dashboard Uses a Delayed Source
A fictional dashboard shows no further application events, but the application source is delayed while identity and transaction sources remain healthy.
Defender Habits
Detection, Triage, and Initial Assessment Checklist
Check Your Understanding
I11.2 Mini Quiz: Detection, Triage, and Initial Assessment
Choose your answers first. Explanations appear only after submission.
1. What is the first triage action after receiving a fictional alert?
2. Why must source health be checked during triage?
3. Which classification is best when activity is unusual but critical evidence is still missing?
4. What makes evidence truly corroborating?
5. What should an initial assessment separate?
6. When is narrow containment appropriate during triage?
7. What is the safest portfolio approach?
Portfolio Prompt
Portfolio Prompt
Create a fictional Detection, Triage, and Initial Assessment Package using at least fifty-four alert, source-health, asset, identity, service, file, queue, transaction, deployment, configuration, support, business, owner, expected-behavior, containment, communication, and handoff records. Include an intake register, source-health review, evidence index, classification matrix, severity rationale, initial assessment, action register, communication recommendation, reassessment triggers, and portfolio-safe summary.
Use only clearly fictional alerts, assets, identities, logs, files, transactions, owners, systems, routes, organizations, and timelines.
Preserve original evidence and show how source health, expected behavior, business context, and independent correlation change the assessment.
Do not include real alerts, scanner exports, logs, service names, user identities, routes, credentials, case notes, or private organizational information.
Key Takeaways
What You Should Remember
1.A fictional alert is an intake signal requiring validation and does not automatically prove an incident or impact.
2.Strong triage preserves the original record, verifies source health, maps context, and correlates independent evidence.
3.Classification should match current evidence and preserve uncertainty through confidence, alternatives, gaps, and reassessment triggers.
4.Severity recommendations combine scope, consequence, business context, controls, confidence, and coordination needs rather than tool severity alone.
5.Narrow containment may be appropriate during triage when it is justified, reversible, monitored, evidence-preserving, and continuity-aware.
6.A complete initial assessment gives later responders a reproducible evidence baseline, action register, ownership map, and decision history.