T — Translate the alert
Rewrite the fictional alert as a neutral observation with evidence, timing, source health, and non-proof statements.
High School AdvancedModule A6Lesson 5 of 10Questions, Evidence, Ownership, States, Closure, and Reopening
A6.5 Triage Questions and Evidence Review
Learn how fictional analysts turn prioritized alerts into structured evidence reviews using neutral observations, bounded questions, source health, identity, service, destination, authorization, timing, scope, impact, alternatives, ownership, privacy, decision states, closure, and reopening.
Lesson Progress
Triage Questions and Evidence Review
High School Advanced • A6: SIEM and Alert Triage Concepts • Lesson 5 of 10
50% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
The Same Alert Can Support Conditional, Expected, or Source-Degraded
A fictional alert reports a temporary recovery role still Active after expiration. Role evidence is Healthy, group evidence is Degraded, extension evidence is Conditional, one session remains Active, and the service owner reports no current impact. A strong analyst does not force the case into confirmed misuse or false positive. The analyst separates what is known, what is delayed, what remains possible, which owners must answer, and which state current evidence supports.
Weak triage
“High alert plus active session equals confirmed misuse.”
Strong triage
“The role and session remain active after approval_end. Authorization is unresolved because extension evidence is delayed and group evidence is Degraded. Service impact is not confirmed. Identity, source, and change owners must answer specific questions.”
Triage is not the search for a fast label. It is the disciplined process of finding the strongest evidence-supported next decision.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Conduct a fictional alert triage using neutral observations, bounded defender questions, source-health review, evidence provenance, context, alternatives, scope, impact, ownership, and decision criteria.
Objective 2
Distinguish fictional direct evidence, normalized fields, enrichment, derived context, owner statements, hypotheses, assumptions, decisions, and unresolved questions.
Objective 3
Create purpose-limited fictional evidence requests covering identity, device, service, destination, authorization, timing, sequence, source health, scope, impact, and closure without collecting unnecessary information.
Objective 4
Use fictional New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, and Reopened states with explicit evidence, ownership, transition, and review requirements.
Objective 5
Create a portfolio-ready fictional Triage Questions and Evidence Review Package containing alert summaries, question maps, evidence matrices, owner requests, decisions, limits, privacy controls, closure criteria, reopening criteria, and reflection.
Why This Matters
Triage Turns Alerts into Defensible Work
Fictional alerts are useful only when analysts can understand what matched, what evidence is reliable, what remains unknown, which mission outcomes matter, who owns the next answer, and what state, deadline, escalation, closure, or reopening decision is justified. Weak triage creates unsupported conclusions, broad evidence requests, privacy exposure, stale cases, missed impact, inconsistent closure, and misleading metrics.
Evidence discipline
Separate fictional direct records, normalization, enrichment, derived context, owner statements, hypotheses, and decisions.
Question discipline
Use fictional bounded observation, authorization, source-health, scope, impact, alternative, and ownership questions.
Lifecycle discipline
Use fictional decision states, deadlines, escalation, closure, reopening, metrics, review triggers, and residual risk.
Core Framework
The T-R-I-A-G-E Method
R — Review evidence layers
Separate fictional direct evidence, parsed fields, normalized fields, enrichment, derived context, owner statements, and hypotheses.
I — Investigate bounded questions
Ask fictional identity, device, service, destination, authorization, timing, source-health, scope, impact, alternative, and ownership questions.
A — Assign owners and actions
Send fictional purpose-limited evidence requests to accountable source, identity, service, supplier, change, privacy, quality, and risk owners.
G — Grade the current state
Choose fictional New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, or Reopened.
E — Establish transitions
Document fictional deadlines, escalation triggers, closure criteria, reopen criteria, residual uncertainty, review dates, and lifecycle.
Decision-ready triage statement
This fictional alert remains Conditional because role and session evidence support continuing authority after expiration, while extension evidence is delayed, group evidence is Degraded, service impact is not confirmed, and identity, source, and change owners still owe bounded evidence.
Advanced Vocabulary
Terms for Triage and Evidence Review
Alert triage
A fictional structured first review that determines what was observed, how reliable the evidence is, what questions matter, who owns the next answers, and which decision state is justified.
Neutral observation
A fictional description of what records or conditions show without claiming intent, cause, authorization, complete scope, impact, or final outcome.
Primary defender question
The fictional bounded question the alert is designed to help answer.
Supporting question
A fictional narrower question about identity, device, service, destination, authorization, timing, source health, scope, impact, alternatives, or ownership.
Direct evidence
Fictional evidence recorded by a source for the underlying activity, state, result, assignment, authorization, or health condition.
Normalized evidence
Fictional source evidence mapped into shared fields or categories for consistent SIEM analysis.
Enrichment
Fictional identity, device, service, destination, owner, criticality, peer, change, authorization, or mission context added after collection.
Derived context
A fictional value calculated or inferred from one or more records rather than directly recorded by the source.
Owner statement
A fictional explanation, confirmation, or expectation provided by an accountable identity, service, supplier, source, change, privacy, or recovery owner.
Hypothesis
A fictional possible explanation that remains open to evidence review.
Alternative explanation
A fictional plausible approved, expected, technical, timing, source-health, ownership, or workflow explanation for the observation.
Evidence request
A fictional purpose-limited request for the specific information needed to answer a documented defender question.
Evidence gap
A fictional missing, delayed, conflicting, blind, stale, semantically unclear, or unavailable piece of information needed for a decision.
Decision state
A fictional label describing where the alert or case stands based on current evidence and unresolved questions.
New
A fictional state in which the alert has entered the queue but structured review has not yet begun.
In Review
A fictional state in which an analyst is actively evaluating evidence, source health, context, alternatives, ownership, scope, and impact.
Conditional
A fictional state in which the core observation is supported but one or more important contextual, ownership, authorization, or impact questions remain unresolved.
Expected
A fictional state in which the observation matches current approved, authorized, documented, time-bounded, and source-supported activity.
Source-Degraded
A fictional state in which required evidence is delayed, incomplete, conflicting, blind, or recovering and limits the supported conclusion.
Unknown
A fictional state in which available evidence cannot support a confident interpretation or absence claim.
Escalated
A fictional state in which broader, faster, or more specialized review is required based on evidence, impact, scope, time sensitivity, source loss, privacy, or owner conditions.
Resolved
A fictional state in which documented questions, evidence, owner actions, validation, residual risk, closure criteria, and reopen criteria are complete enough for closure.
Reopened
A fictional state used when new evidence, changed scope, failed validation, repeated behavior, source recovery, or unmet closure conditions require renewed review.
Residual uncertainty
A fictional record of important questions, evidence limitations, or risks that remain after the current decision.
Instructional Section 1
Ask Twelve Triage Question Domains
Observation
Primary question
What fictional condition matched, and which exact records, fields, relationships, thresholds, sequences, states, or source-health conditions support it?
Fictional evidence
Alert contract, source records, normalized fields, event time, collection time, processing time, correlation explanation, and source health.
Weak conclusion
The alert proves malicious behavior.
Strong output
Neutral observation with evidence references and non-proof statement.
Identity
Primary question
Which fictional identity, identity category, role, group, sponsor, owner, assignment, approval, or lifecycle state is involved?
Fictional evidence
Identity source, role catalog, group state, assignment record, sponsor record, approval, extension, revocation, and owner confirmation.
Weak conclusion
The identity name alone proves authorization or intent.
Strong output
Identity context, authority, ownership, lifecycle, and unresolved authorization questions.
Device
Primary question
Which fictional device, device category, management state, owner, onboarding state, replacement state, support state, or session relationship is involved?
Fictional evidence
Device inventory, ownership, lifecycle, support record, network class, session relationship, and source-health state.
Weak conclusion
A known device proves the expected person used it.
Strong output
Device context with ownership and lifecycle limitations.
Service and asset
Primary question
Which fictional service, data category, administrative function, supplier dependency, recovery capability, or mission outcome may be affected?
Fictional evidence
Service catalog, criticality, owner, dependencies, user-impact records, data classification, recovery plan, and current operating state.
Weak conclusion
A critical service label proves current impact.
Strong output
Potential and active impact separated with owner validation.
Destination and object
Primary question
Which fictional destination, object, service dependency, data category, administrative target, or supplier service is involved?
Fictional evidence
Destination catalog, service relationship, object class, policy, ownership, assignment, approval, and current change context.
Weak conclusion
A new destination automatically means harmful activity.
Strong output
Destination purpose, relationship, novelty, authorization, and limitation.
Authorization
Primary question
Which fictional approval, extension, assignment, sponsor, maintenance, emergency-use, change, or policy evidence supports or limits the activity?
Fictional evidence
Approval records, start and end times, purpose, scope, owner, destination, change record, sponsor confirmation, and source health.
Weak conclusion
Any approval authorizes every action, identity, destination, or time.
Strong output
Current authorization state with exact scope, time, owner, and unresolved differences.
Timing and sequence
Primary question
When did fictional events occur, arrive, process, correlate, and alert, and which sequence or duration is supported?
Fictional evidence
Event time, collection time, processing time, alert time, clock state, source delay, sequence, window, replay, duplicate, and blind-period records.
Weak conclusion
Dashboard order proves event order.
Strong output
Time-bounded chronology with delay and uncertainty visible.
Source health
Primary question
Are fictional required sources, fields, schemas, parsers, mappings, queues, clocks, coverage, and recovery states healthy enough for the decision?
Fictional evidence
Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering states plus affected fields, periods, populations, and detections.
Weak conclusion
No record proves no activity.
Strong output
Evidence-confidence boundary and alternate-evidence plan.
Scope
Primary question
How many fictional identities, devices, services, destinations, users, data categories, environments, records, or time periods may be affected?
Fictional evidence
Correlation relationships, service dependencies, owner reports, source coverage, duplicates, replay, case links, and current health states.
Weak conclusion
Alert count equals affected scope.
Strong output
Current scope, possible scope, excluded duplicates, and unknown coverage.
Impact
Primary question
What fictional user, service, privacy, identity, evidence, availability, administrative, supplier, or recovery effect is current, potential, or unconfirmed?
Fictional evidence
Application results, user-support records, service owner statements, availability state, privacy review, source-health effect, and recovery status.
Weak conclusion
High severity proves active impact.
Strong output
Potential severity, confirmed active effect, confidence, and recoverability separated.
Alternative explanations
Primary question
Which fictional approved change, maintenance, extension, supplier work, migration, recovery, timing delay, stale ownership, parser issue, mapping issue, or incomplete workflow could explain the observation?
Fictional evidence
Change records, owner confirmation, maintenance windows, extension records, source-health reports, mapping history, and recovery plan.
Weak conclusion
One alternative explanation automatically closes the alert.
Strong output
Ranked alternatives with evidence needed to confirm or reject each one.
Ownership and next evidence
Primary question
Which fictional source, identity, device, service, supplier, change, privacy, quality, risk, or leadership owner must answer the next question?
Fictional evidence
Owner matrix, service catalog, source inventory, identity ownership, supplier assignment, change ownership, and escalation path.
Weak conclusion
The security analyst owns every question and decision.
Strong output
Specific evidence request, accountable owner, deadline, and escalation trigger.
Instructional Section 2
Separate Eight Evidence Layers
Direct source evidence
Fictional original evidence about an activity, state, result, approval, assignment, session, service condition, or source-health state.
Fictional example
Role source records Active after approval_end.
Analyst caution
Direct does not mean complete, correct, current, or sufficient for every conclusion.
Parsed source fields
Fictional source evidence interpreted into documented source-specific fields.
Fictional example
role_state, approval_end, session_state, service_result.
Analyst caution
Parser defects or schema drift may change meaning.
Normalized fields
Fictional source fields mapped into shared SIEM categories.
Fictional example
authorization.state = expired; session.state = active.
Analyst caution
Shared categories may hide source-specific semantic differences.
Enrichment
Fictional identity, service, destination, owner, criticality, peer, change, or mission context added after collection.
Fictional example
service.criticality = essential; identity.owner = recovery-operations.
Analyst caution
Enrichment may be stale, incomplete, or nonauthoritative.
Derived context
Fictional calculated or inferred values created from multiple records.
Fictional example
authorization.state = Conditional because extension evidence is delayed.
Analyst caution
Derived context depends on logic, source health, timing, and assumptions.
Owner evidence
Fictional explanations, confirmations, approvals, or impact statements from accountable owners.
Fictional example
Service owner confirms current student-support disruption.
Analyst caution
Owner evidence should be documented and validated where possible.
Analyst hypothesis
A fictional possible explanation proposed to guide evidence review.
Fictional example
The role may remain active because revocation synchronization is delayed.
Analyst caution
A hypothesis is not a fact and should remain clearly labeled.
Decision
A fictional evidence-based state, priority, escalation, closure, or reopening conclusion.
Fictional example
Conditional, High priority, identity-owner response required within thirty minutes.
Analyst caution
The decision should show supporting evidence, limitations, owner, and review trigger.
Instructional Section 3
Use a Twelve-Step Triage Sequence
1. Restate the observation
Analyst action
Rewrite the fictional alert as a neutral sentence using only supported fields, timing, relationships, and source-health facts.
Required output
Observation statement.
Quality requirement
No intent, cause, authorization, complete scope, or impact is assumed.
2. Identify the primary question
Analyst action
State the one fictional defender question the alert should help answer.
Required output
Primary triage question.
Quality requirement
The question is bounded, evidence-driven, and tied to a decision.
3. Check evidence layers
Analyst action
Separate fictional direct evidence, parsed fields, normalized fields, enrichment, derived context, owner statements, and hypotheses.
Required output
Evidence-layer map.
Quality requirement
Derived context and assumptions are never presented as direct facts.
4. Check source health
Analyst action
Review fictional freshness, completeness, schema, parser, mapping, queue, coverage, blind periods, conflicts, and recovery.
Required output
Source-health and confidence statement.
Quality requirement
Missing evidence never becomes false absence.
5. Review identity and authority
Analyst action
Examine fictional identity category, role, group, assignment, approval, extension, sponsor, owner, and lifecycle state.
Required output
Identity and authorization statement.
Quality requirement
Assigned privilege and effective access remain separate.
6. Review device, service, and destination
Analyst action
Examine fictional device state, service criticality, destination purpose, object class, ownership, and relationship context.
Required output
Asset and relationship statement.
Quality requirement
A known device or destination does not automatically prove expected use.
7. Build chronology
Analyst action
Order fictional events by event time and preserve collection, processing, and alert time separately.
Required output
Triage timeline.
Quality requirement
Delay, replay, duplicates, out-of-order arrival, and blind periods remain visible.
8. Estimate scope and impact
Analyst action
Review fictional identities, devices, services, destinations, users, data categories, environments, periods, current impact, and recoverability.
Required output
Scope and impact assessment.
Quality requirement
Potential severity and confirmed active effect remain separate.
9. Rank alternatives
Analyst action
List fictional approved, expected, technical, timing, source-health, ownership, change, maintenance, supplier, and recovery explanations.
Required output
Alternative-explanation matrix.
Quality requirement
Each alternative has supporting evidence, contradicting evidence, owner, and next test.
10. Request next evidence
Analyst action
Ask the accountable fictional owner for only the evidence needed to answer the unresolved question.
Required output
Purpose-limited evidence request.
Quality requirement
The request has purpose, scope, period, fields, owner, deadline, privacy boundary, and expected decision use.
11. Assign a decision state
Analyst action
Choose fictional New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, or Reopened.
Required output
Decision state with rationale.
Quality requirement
The state matches current evidence rather than analyst preference.
12. Set transitions and triggers
Analyst action
Define fictional evidence, owner, source-health, scope, impact, deadline, escalation, closure, and reopen conditions.
Required output
State-transition and review plan.
Quality requirement
The case cannot remain stale or close without explicit criteria.
Instructional Section 4
Use Nine Decision States
New
Evidence requirement
Fictional alert identity, creation time, observation, severity, confidence, priority, source health, and owner routing are present.
Entry condition
Alert enters the queue.
Exit condition
Analyst begins structured review and records the primary defender question.
Risk if misused
New alerts may age without ownership or become mislabeled by their title.
In Review
Evidence requirement
Fictional analyst is actively evaluating evidence layers, source health, identity, device, service, destination, authorization, timing, scope, impact, alternatives, and owners.
Entry condition
Initial review begins.
Exit condition
Evidence supports Conditional, Expected, Source-Degraded, Unknown, Escalated, or Resolved.
Risk if misused
Cases may remain In Review indefinitely without deadlines or owner requests.
Conditional
Evidence requirement
Fictional core observation is supported, but important authorization, context, ownership, impact, scope, or lifecycle questions remain unresolved.
Entry condition
The analyst can support part of the interpretation but not the full decision.
Exit condition
New evidence moves the case to Expected, Unknown, Escalated, Resolved, or another documented state.
Risk if misused
Conditional can become a vague holding state without exact gaps and owners.
Expected
Evidence requirement
Fictional current approval, purpose, identity, device, service, destination, scope, owner, timing, and source health support the observed condition.
Entry condition
Approved or documented activity explains the observation.
Exit condition
The expected window ends, scope changes, source health degrades, owner evidence changes, or the case closes with validation.
Risk if misused
Expected labels may remain after authorization or scope expires.
Source-Degraded
Evidence requirement
Fictional required source, field, schema, parser, mapping, queue, clock, coverage, or recovery condition limits the supported conclusion.
Entry condition
Evidence reliability becomes insufficient for normal confidence.
Exit condition
Source recovery and validation complete, alternate evidence resolves the question, or escalation occurs.
Risk if misused
Source degradation may be treated as a reason to stop reviewing meaningful risk.
Unknown
Evidence requirement
Fictional available evidence cannot support a confident interpretation or absence claim.
Entry condition
Evidence is insufficient, conflicting, or unavailable after reasonable review.
Exit condition
New evidence, owner response, source recovery, or scope change supports another state.
Risk if misused
Unknown may be forced into false positive or true negative for reporting convenience.
Escalated
Evidence requirement
Fictional evidence, impact, scope, time sensitivity, source loss, privacy, recovery, owner nonresponse, or specialized review criteria are met.
Entry condition
Broader, faster, or specialized review is required.
Exit condition
Escalated questions are answered and the case transitions to another state.
Risk if misused
Escalation may become a handoff without retained ownership or evidence context.
Resolved
Evidence requirement
Fictional questions, source health, authorization, scope, impact, owner actions, validation, residual risk, closure criteria, and reopen criteria are complete enough for closure.
Entry condition
The case meets documented closure requirements.
Exit condition
New evidence, failed validation, repeated behavior, changed scope, or source recovery triggers reopening.
Risk if misused
Alert silence or elapsed time may be mistaken for resolution.
Reopened
Evidence requirement
Fictional new evidence, changed scope, repeated activity, source recovery, failed validation, unmet closure, or residual-risk trigger requires renewed review.
Entry condition
A documented reopen condition occurs.
Exit condition
The renewed review reaches another evidence-supported state.
Risk if misused
Reopened cases may lose the original chronology or repeat old assumptions.
Instructional Section 5
Write Eight Purpose-Limited Evidence Requests
Identity lifecycle request
Purpose
Determine whether fictional role, group, approval, assignment, extension, sponsor, or revocation evidence supports current authority.
Required fields
Identity category, role category, assignment, approval start, approval end, extension state, sponsor, owner, revocation, source health, and event time.
Privacy boundary
Do not request unrelated personal history, content, location, or full activity history.
Accountable owner
Identity owner and identity-source owner.
Device context request
Purpose
Determine whether a fictional device relationship supports or limits the alert interpretation.
Required fields
Device category, management state, owner group, onboarding state, replacement state, support state, session relationship, and source health.
Privacy boundary
Do not request personal files, messages, browsing content, or unrelated device activity.
Accountable owner
Device owner and device-source owner.
Service impact request
Purpose
Determine whether a fictional alert is affecting a service, users, availability, privacy, evidence, or recovery.
Required fields
Service category, criticality, current state, affected function, user-impact category, dependency, recovery state, owner, and source health.
Privacy boundary
Use aggregate or category-level user impact rather than personal user details.
Accountable owner
Service owner and recovery owner.
Destination-purpose request
Purpose
Determine whether a fictional destination or object relationship is expected, approved, new, changed, or outside documented purpose.
Required fields
Destination category, service relationship, object class, approval, assignment, purpose, owner, timing, and source health.
Privacy boundary
Do not request real addresses, internal routes, content, or unrelated destination history.
Accountable owner
Service owner, destination owner, or supplier owner.
Change and maintenance request
Purpose
Determine whether a fictional approved change, maintenance window, migration, recovery action, or emergency process explains the observation.
Required fields
Change identifier, purpose, scope, identities, services, destinations, start, end, owner, expected behavior, validation, rollback, and source health.
Privacy boundary
Do not request operational configuration or internal architecture beyond the bounded decision need.
Accountable owner
Change owner and service owner.
Source-health request
Purpose
Determine whether fictional delay, loss, duplication, conflict, schema drift, parser failure, clock issue, blind period, or recovery affects confidence.
Required fields
Source category, affected population, period, freshness, completeness, schema, parser, queue, clock, duplicates, blind state, recovery state, and owner.
Privacy boundary
Request health metadata rather than unrelated record content.
Accountable owner
Source owner and SIEM quality owner.
Scope request
Purpose
Determine which fictional identities, devices, services, destinations, users, environments, and periods may be affected.
Required fields
Relationship counts, unique entities, duplicate handling, coverage, source health, service dependencies, time range, and uncertainty.
Privacy boundary
Use categories and counts unless a specific identity is required for the documented decision.
Accountable owner
Analyst, service owner, source owner, and quality owner.
Closure-validation request
Purpose
Determine whether fictional revocation, session closure, source reconciliation, service recovery, owner validation, corrective action, and residual-risk requirements are complete.
Required fields
Current authority, session state, service state, source health, corrective action, validation result, owner confirmation, residual risk, closure criteria, and reopen triggers.
Privacy boundary
Do not attach unrelated historical evidence to the closure record.
Accountable owner
Case owner, identity owner, service owner, source owner, and risk owner.
Instructional Section 6
Compare Six Alternative Explanations
| Alternative | Supporting evidence | Contradicting evidence | Next evidence | Decision effect |
|---|---|---|---|---|
| Valid extension arrived late | Fictional extension record has current scope, owner, purpose, identity, role, destination, and time but entered the SIEM after the alert. | No valid extension exists at the source or the extension does not match scope. | Source-side extension state, event time, collection delay, owner confirmation, and source health. | May move Conditional to Expected after validation. |
| Revocation synchronization is delayed | Fictional role source says Revoked while group source remains Active and is Degraded. | Group source is Healthy and effective access remains active beyond expected synchronization. | Source-health report, event times, group state, session state, recovery estimate, and identity-owner confirmation. | May keep Source-Degraded until reconciliation. |
| Approved maintenance explains the destination | Fictional change record matches identity, service, destination, purpose, owner, start, end, and expected behavior. | Destination, identity, time, or activity falls outside the approved change. | Change scope, destination relationship, owner, event timeline, and service impact. | May move In Review to Expected or remain Conditional. |
| Recovery replay created duplicates | Fictional records share event identifiers and replay metadata during a Recovering source state. | Records represent distinct event times, sessions, destinations, or state changes. | Uniqueness keys, replay markers, event time, collection path, session, destination, and source owner. | May reduce apparent scope without lowering the underlying condition's importance. |
| Stale ownership caused routing error | Fictional service catalog owner differs from current change and support records. | Current catalog, assignment, and owner confirmations agree. | Owner catalog, service record, change record, support assignment, review date, and ownership authority. | May change owner and deadline without changing alert meaning. |
| Normalization changed source meaning | Fictional accepted and completed values map to the same Success category. | Source-owner review confirms the values are equivalent for the defender question. | Source fields, canonical mapping, transformation history, schema version, owner review, and regression tests. | May change confidence, alert logic, or historical case classification. |
Instructional Section 7
Require Eight Closure Criteria
Primary defender question answered
Fictional evidence
Fictional final observation, supported interpretation, alternatives, confidence, and non-proof statement are documented.
Failure if skipped
The case closes with the alert title rather than an evidence-based answer.
Authorization resolved
Fictional evidence
Fictional approval, assignment, extension, sponsor, purpose, scope, time, owner, and lifecycle evidence are current enough.
Failure if skipped
The case closes while authorization remains Unknown or Conditional.
Effective access and activity reviewed
Fictional evidence
Fictional role, group, session, device, service, destination, and result evidence are reconciled.
Failure if skipped
Assigned privilege is mistaken for exercised activity or vice versa.
Source health reconciled
Fictional evidence
Fictional required sources are Healthy enough or residual gaps are explicitly accepted and documented.
Failure if skipped
Blind, Degraded, Conflicting, or Recovering evidence is ignored.
Scope and impact documented
Fictional evidence
Fictional affected and unaffected identities, devices, services, destinations, users, environments, periods, active effect, and recoverability are documented.
Failure if skipped
One alert or one identity is mistaken for complete scope.
Owner actions complete
Fictional evidence
Fictional identity, service, supplier, source, change, privacy, quality, or risk owners completed assigned decisions and validation.
Failure if skipped
The case closes while owner requests remain open.
Corrective action validated
Fictional evidence
Fictional revocation, reconciliation, service recovery, mapping correction, tuning, documentation, or ownership update passed defined checks.
Failure if skipped
An action was performed but not validated.
Residual risk and reopen triggers recorded
Fictional evidence
Fictional remaining uncertainty, accepted limitations, owner, review date, and reopen criteria are documented.
Failure if skipped
The case cannot be revisited when new evidence or repeated behavior appears.
Instructional Section 8
Measure Eight Triage Quality Dimensions
Question quality
Review question
Do fictional triage questions remain bounded, neutral, evidence-driven, and tied to decisions?
Fictional evidence
Alert reviews, question maps, case notes, owner feedback, and quality audits.
Limitation
A well-written question may still rely on incomplete evidence.
Evidence-layer accuracy
Review question
Do fictional analysts separate direct evidence, normalization, enrichment, derived context, owner statements, hypotheses, and decisions?
Fictional evidence
Evidence matrices, case notes, review corrections, and analyst coaching records.
Limitation
Correct labels do not guarantee the source evidence is healthy.
Source-health visibility
Review question
Do fictional triage decisions show Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering evidence effects?
Fictional evidence
Case states, confidence statements, alternate evidence, source-owner requests, and reassessment.
Limitation
Visible health states still require correct interpretation.
Evidence-request precision
Review question
Are fictional owner requests purpose-limited, time-bounded, field-specific, privacy-aware, and connected to a decision?
Fictional evidence
Request logs, owner responses, unnecessary-field reviews, delays, and case outcomes.
Limitation
A precise request may still reach the wrong owner.
Decision-state accuracy
Review question
Do fictional New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, and Reopened states match current evidence?
Fictional evidence
State transitions, rationales, deadlines, owner actions, validation, and reopen history.
Limitation
Outcome labels can still become stale after new evidence.
Owner-response quality
Review question
Do fictional owners provide current, scoped, evidence-supported responses within documented deadlines?
Fictional evidence
Request time, response time, fields supplied, scope, source health, confirmation, and escalation records.
Limitation
Fast owner responses may still be incomplete or incorrect.
Closure quality
Review question
Do fictional cases close only after questions, source health, authorization, scope, impact, owner actions, validation, residual risk, and reopen criteria are complete?
Fictional evidence
Closure checklist, reopen rate, failed validation, residual-risk records, and quality review.
Limitation
Low reopen rate may reflect weak detection of reopened conditions.
Triage debt
Review question
Which fictional question maps, evidence requests, state definitions, owner records, deadlines, runbooks, privacy controls, or closure criteria are stale or unresolved?
Fictional evidence
Debt register, review dates, owner matrix, failed audits, reopened cases, and residual-risk records.
Limitation
Counting debt does not identify mission impact by itself.
Fictional Triage Architecture
Northbridge Alert-to-Decision Model
This conceptual architecture is completely invented and intentionally non-operational. It teaches triage without real alerts, identities, services, records, screenshots, case notes, queries, suppliers, incidents, or internal systems.
Alert input
Observation, evidence, source health, severity, confidence
Context input
Identity, device, service, destination, authorization
Timeline input
Event, collection, processing, alert, recovery
Owner input
Source, identity, service, change, privacy, risk
Fictional Triage Core
Translate
Neutral observation and primary question
Separate
Evidence layers, hypotheses, owner statements
Review
Source health, timing, identity, service, destination
Estimate
Scope, impact, recoverability, uncertainty
Compare
Approved, technical, timing, source-health alternatives
Request
Purpose-limited evidence from accountable owners
Decide
State, priority, escalation, deadline, closure
Maintain
Transitions, metrics, residual risk, reopening
Analyst output
Questions, evidence, state, deadline, next steps
Owner output
Specific evidence request and decision need
Case output
Chronology, rationale, actions, closure, reopen
Portfolio boundary
Fully fictional, privacy-safe, non-operational
Fake Dashboard
Fake Northbridge Triage Quality Dashboard
Fictional question quality, evidence layers, source-health visibility, owner responses, decision states, closure quality, privacy, and triage debt for training only.
Alerts with complete triage question maps
14 / 20
Six fictional alerts still lack source-health, scope, impact, or ownership questions.
Open fictional evidence requests beyond deadline
5
Two identity, one source-health, one change, and one service-impact response remain overdue.
Open fictional triage-debt items
9
Evidence-layer labels, state definitions, owner records, privacy fields, closure criteria, reopen triggers, metrics, runbooks, and review dates remain open.
Fake SOC Alert
Triage State Requires Reassessment
Source: Fake Northbridge Triage Governance Console • Time: 4:17 PM
The fictional stale-role case is labeled Resolved because the role was revoked and the session closed. However, extension-source recovery, historical authorization, group reconciliation, corrective-action validation, residual risk, and reopen criteria remain incomplete.
Defensive recommendation: Move the fictional case from Resolved to Conditional or Source-Degraded. Complete source reconciliation, historical review, owner validation, corrective-action testing, residual-risk documentation, closure criteria, and reopen triggers before closure.
Fake Log Panel
Fake Alert Triage Timeline
training-log-viewer.log
09:00 ALERT id='TRIAGE-ST-07' 09:01 STATE new='true' 09:03 QUESTION primary='stale-authority' 09:05 SOURCE role='healthy' 09:06 SOURCE group='degraded' 09:07 SOURCE extension='conditional' 09:08 SOURCE session='healthy' 09:10 OBSERVATION role-after-end='true' 09:11 IMPACT service='not-confirmed' 09:12 ALTERNATIVE extension-delay='open' 09:13 ALTERNATIVE maintenance='partial' 09:15 REQUEST identity-owner='sent' 09:16 REQUEST source-owner='sent' 09:17 REQUEST change-owner='sent' 09:19 STATE conditional='true' 09:31 ACTION role='revoked' 09:34 ACTION session='closed' 09:41 SOURCE extension='recovering' 09:45 CLOSURE validation='incomplete' 16:17 ALERT issue='state-reassessment'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What Triage Evidence Supports—and What It Does Not Prove
TRIAGE-01
Fictional alert contract
Observation
The alert says Temporary Recovery Role Remains Active after Approved End and provides role, extension, group, session, service, and source-health references.
Supports
A stale-authority review is justified.
Does not prove
The alert does not prove misuse, harmful intent, complete scope, or service impact.
Triage use
Begin with a bounded authorization and effective-access question.
TRIAGE-02
Fictional role and group evidence
Observation
Role source is Healthy and records Active; group source is Degraded and also records Active.
Supports
The role assignment appears active, while effective-access confidence is limited by group-source health.
Does not prove
The records do not prove current valid authorization or actual use.
Triage use
Separate role-state confidence from effective-access confidence.
TRIAGE-03
Fictional extension evidence
Observation
Extension source is Conditional and the latest record is delayed by eighteen minutes.
Supports
Authorization evidence may be incomplete at alert time.
Does not prove
Delay does not prove a valid extension exists.
Triage use
Request source-side extension state and owner confirmation.
TRIAGE-04
Fictional session evidence
Observation
One session remains Active across approval_end and reaches one critical student-support service.
Supports
Effective activity may continue beyond expiration.
Does not prove
The session record does not prove privileged action, harmful intent, or user impact.
Triage use
Review session purpose, operation category, destination, result, owner, and service effect.
TRIAGE-05
Fictional service evidence
Observation
The service is critical, but application results show no current error increase and the service owner reports normal availability.
Supports
Potential severity is High, while current service impact is not confirmed.
Does not prove
Normal availability does not prove no unauthorized or unnecessary access occurred.
Triage use
Keep severity separate from active impact.
TRIAGE-06
Fictional change evidence
Observation
A maintenance record exists but ends before the session crosses approval_end and does not include the observed destination.
Supports
The maintenance record does not fully explain the observation.
Does not prove
The record does not prove the activity was unauthorized.
Triage use
Keep maintenance as a partial alternative and request change-owner clarification.
TRIAGE-07
Fictional owner responses
Observation
Identity owner says no extension is visible; service owner reports no current impact; source owner confirms delayed extension ingestion.
Supports
Authorization remains unresolved while service impact appears absent and source delay is confirmed.
Does not prove
Owner responses do not replace source reconciliation.
Triage use
Assign Conditional or Source-Degraded state with targeted next evidence.
TRIAGE-08
Fictional closure review
Observation
The role is later revoked and the session closes, but extension-source recovery and historical reconciliation remain incomplete.
Supports
The immediate active condition ended.
Does not prove
The case is not ready for complete closure while source reconciliation and historical authorization remain unresolved.
Triage use
Maintain Conditional or Source-Degraded until validation and residual-risk review complete.
Analyze the Evidence
Which Triage State Is Best Supported?
Role and session evidence confirm the immediate active condition ended.
Extension-source recovery remains incomplete.
Historical authorization at alert time is still unresolved.
Group-source reconciliation remains incomplete.
No current service impact is confirmed.
Corrective-action validation has not finished.
Residual risk and reopen criteria are not documented.
The case was labeled Resolved only because the alert stopped.
Which fictional state best represents the Northbridge stale-role review after role revocation and session closure?
Common Mistakes
Avoid Ten Triage and Evidence Review Errors
The alert title becomes the analyst conclusion
Fictional observation
A fictional case note repeats confirmed misuse even though the alert title only describes stale authority.
Decision impact
Unsupported certainty enters the case record.
Professional correction
Rewrite the alert as a neutral observation and state the primary defender question.
Direct, normalized, enriched, and derived evidence are mixed
Fictional observation
A fictional analyst describes derived authorization state as a direct source fact.
Decision impact
Logic assumptions and source limitations become invisible.
Professional correction
Label evidence layers and preserve provenance, transformation, owner, and confidence.
No record becomes proof of absence
Fictional observation
A fictional analyst closes a session question during a Blind source period.
Decision impact
Missing evidence becomes false confidence.
Professional correction
Use Unknown or Source-Degraded and request alternate evidence or reassessment.
Evidence requests are too broad
Fictional observation
A fictional analyst requests complete identity and device history for one bounded authorization question.
Decision impact
Privacy, workload, retention, and relevance problems increase.
Professional correction
Request only the fields, period, scope, and owner evidence needed for the decision.
Owner statements are treated as unquestioned fact
Fictional observation
A fictional owner says activity is expected and the case immediately closes.
Decision impact
Stale, incomplete, or mistaken context may hide meaningful differences.
Professional correction
Document owner evidence and validate current authorization, scope, time, destination, and source health.
Alert count becomes scope
Fictional observation
A fictional case reports five affected identities when replay created five alerts for one identity.
Decision impact
Scope and priority may be inflated.
Professional correction
Review uniqueness, duplicates, replay, sessions, destinations, relationships, and coverage.
Conditional and Unknown are avoided
Fictional observation
A fictional reporting process forces every case into true positive or false positive.
Decision impact
Uncertainty and source-health limitations disappear from metrics and decisions.
Professional correction
Use evidence-supported Conditional, Source-Degraded, and Unknown states.
Resolved means the alert stopped
Fictional observation
A fictional case closes because no new alert appeared.
Decision impact
Authorization, sessions, source recovery, validation, residual risk, and reopen criteria remain incomplete.
Professional correction
Use documented closure criteria and validation evidence.
Escalation becomes abandonment
Fictional observation
A fictional analyst changes the state to Escalated and removes the original owner.
Decision impact
Context, accountability, and follow-up can be lost.
Professional correction
Retain case ownership, chronology, evidence, questions, deadlines, and handoff confirmation.
Real case evidence enters the portfolio
Fictional observation
A fictional learning artifact includes copied real alert details, usernames, screenshots, owner notes, service names, or case timelines.
Decision impact
Sensitive people, systems, suppliers, incidents, and defensive processes may be exposed.
Professional correction
Invent every organization, alert, record, field, identity, service, owner, date, decision, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Triage Questions and Evidence Review Package
Use only the supplied fictional information on this page. Do not access, copy, sanitize, upload, inspect, query, triage, investigate, collect, suppress, escalate, close, reopen, or modify any real alert, case, SIEM, source, account, endpoint, network, domain, service, supplier, platform, or organization.
1
Create the neutral alert summary
Rewrite the fictional Northbridge alert using only supported observation, evidence, timing, source health, and non-proof statements.
Required output
One-paragraph triage summary.
Quality check
No unsupported cause, intent, authorization, scope, impact, or final outcome appears.
2
Map the primary and supporting questions
Define fictional observation, identity, device, service, destination, authorization, timing, source-health, scope, impact, alternatives, and ownership questions.
Required output
Triage question map.
Quality check
Every question supports a specific decision.
3
Separate evidence layers
Classify fictional direct evidence, parsed fields, normalized fields, enrichment, derived context, owner statements, hypotheses, and decisions.
Required output
Evidence-layer matrix.
Quality check
No derived value or hypothesis is labeled as direct fact.
4
Review source health
Document fictional Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering sources and affected conclusions.
Required output
Source-health and confidence statement.
Quality check
Missing evidence never becomes false absence.
5
Build chronology
Order fictional role, group, extension, session, service, change, owner, source-health, and recovery evidence by event time while preserving other times.
Required output
Triage timeline.
Quality check
Delay, duplicates, replay, out-of-order arrival, and blind periods remain visible.
6
Evaluate scope and impact
Review fictional identities, devices, services, destinations, users, environments, periods, potential severity, active effect, and recoverability.
Required output
Scope and impact assessment.
Quality check
Potential consequence and confirmed impact remain separate.
7
Rank alternatives
Compare fictional extension delay, synchronization delay, maintenance, recovery replay, stale ownership, and normalization differences.
Required output
Alternative-explanation matrix.
Quality check
Each alternative has supporting evidence, contradicting evidence, owner, and next question.
8
Write evidence requests
Create fictional purpose-limited requests for identity, service, change, source-health, scope, and closure evidence.
Required output
Evidence-request register.
Quality check
Each request includes purpose, fields, period, owner, deadline, privacy boundary, and decision use.
9
Assign state and transitions
Choose fictional New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, or Reopened and document transition criteria.
Required output
Decision-state and transition record.
Quality check
The state matches current evidence and cannot remain stale.
10
Prepare the portfolio package
Combine the fictional summary, questions, evidence layers, timeline, source health, scope, impact, alternatives, requests, owners, state, closure, reopening, metrics, and reflection.
Required output
Public-safe Triage Questions and Evidence Review Package.
Quality check
Every organization, alert, record, field, identity, service, owner, date, decision, and outcome is invented.
Scenario Decision Lab
The Extension Source Is Delayed
A fictional stale-role alert has current role and session evidence, Degraded group evidence, and an extension source delayed by eighteen minutes. The identity owner does not see a current extension, but the source owner confirms ingestion delay.
Scenario Decision Lab
The Alert Stops after Revocation
A fictional role is revoked and the active session closes. The alert stops, but group reconciliation, extension-source recovery, historical authorization, corrective-action validation, residual risk, and reopen criteria remain incomplete.
Advanced Challenge
Defend a Triage Decision before a Review Board
Fictional Northbridge presents a stale-authority alert with mixed source health, one active session, no confirmed service impact, a partial maintenance explanation, delayed extension evidence, conflicting owner responses, and incomplete closure validation. The review board asks whether the case should be Expected, Conditional, Source-Degraded, Escalated, or Resolved.
Defend the observation
Explain the fictional matched condition using direct evidence, timing, source health, provenance, and non-proof statements.
Defend the questions
Explain fictional identity, device, service, destination, authorization, timing, source-health, scope, impact, alternatives, and ownership questions.
Defend the evidence layers
Explain fictional direct, parsed, normalized, enriched, derived, owner, hypothesis, and decision layers.
Defend the requests
Explain fictional purpose, fields, period, owner, deadline, privacy boundary, and decision use for each evidence request.
Defend the state
Explain fictional state entry, evidence requirement, unresolved gaps, exit criteria, aging, and escalation triggers.
Defend closure and reopening
Explain fictional authorization, access, source health, scope, impact, owner actions, validation, residual risk, closure criteria, and reopen triggers.
Challenge output
Produce a fictional triage summary, question map, evidence-layer matrix, source-health review, chronology, scope and impact assessment, alternative matrix, evidence-request register, owner matrix, state decision, transition map, closure checklist, reopen criteria, triage-quality report, residual-risk statement, leadership summary, and public portfolio boundary.
Defender Habits
Triage Questions and Evidence Review Checklist
Check Your Understanding
A6.5 Mini Quiz: Triage Questions and Evidence Review
Choose your answers first. Explanations appear only after submission.
1. What is the strongest first step in fictional alert triage?
2. Why should direct evidence and enrichment remain separate?
3. A fictional required source is Blind. Which decision state is strongest?
4. Which fictional evidence request is most privacy-aware?
5. When is Expected the strongest fictional state?
6. Which fictional closure condition is strongest?
7. Which public portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Triage Questions and Evidence Review Package for the Northbridge Student-Support Cooperative. Include mission, stakeholders, alert identifiers, neutral alert summaries, primary defender questions, supporting questions, non-proof statements, direct evidence, parsed fields, normalized fields, enrichment, derived context, owner statements, hypotheses, assumptions, decisions, unresolved questions, source categories, source owners, identity evidence, role evidence, group evidence, assignment evidence, approval evidence, extension evidence, sponsor evidence, revocation evidence, device evidence, device ownership, device lifecycle, session evidence, service evidence, service criticality, destination evidence, object categories, change evidence, maintenance evidence, supplier evidence, source-health evidence, event time, collection time, processing time, alert time, clock state, delay, duplicates, replay, out-of-order arrival, blind periods, recovery, Healthy states, Conditional states, Degraded states, Blind states, Conflicting states, Recovering states, identity questions, device questions, service questions, destination questions, authorization questions, timing questions, source-health questions, scope questions, impact questions, alternative explanations, ownership questions, current scope, possible scope, excluded duplicates, active impact, potential severity, recoverability, identity-lifecycle requests, device-context requests, service-impact requests, destination-purpose requests, change requests, source-health requests, scope requests, closure-validation requests, purpose, fields, periods, owners, deadlines, privacy boundaries, decision use, New state, In Review state, Conditional state, Expected state, Source-Degraded state, Unknown state, Escalated state, Resolved state, Reopened state, state-entry criteria, state-exit criteria, aging rules, escalation triggers, closure criteria, reopen criteria, corrective actions, validation evidence, residual uncertainty, residual risk, question-quality metrics, evidence-layer metrics, source-health metrics, evidence-request metrics, decision-state metrics, owner-response metrics, closure-quality metrics, triage debt, owner matrix, change history, review triggers, leadership summary, reflection, and a statement that every organization, alert, record, field, identity, service, owner, date, decision, and outcome is invented.
Begin with fictional observation and questions rather than a final label.
Separate direct evidence from normalization, enrichment, derived context, owner statements, and hypotheses.
Use purpose-limited fictional evidence requests with privacy, scope, time, ownership, and decision boundaries.
Make state transitions, deadlines, closure criteria, reopen criteria, residual risk, and review triggers explicit.
Keep the entire artifact completely fictional, defensive, non-operational, privacy-safe, evidence-aware, maintainable, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready for Escalation Criteria?
Before moving to A6.6, rate your readiness from 1 to 5 for neutral observations, defender questions, evidence layers, source health, identity, device, service, destination, authorization, timing, scope, impact, alternatives, ownership, evidence requests, decision states, closure, reopening, metrics, and complete fictionalization.
I can turn a fictional alert into a neutral observation and bounded primary question.
I can separate direct, normalized, enriched, derived, owner, hypothesis, and decision evidence.
I can request only the fictional evidence needed for a specific decision.
I can keep source-health limitations visible in confidence and state.
I can compare scope, impact, alternatives, owners, and timing without forcing certainty.
I can use all nine fictional decision states with evidence-based transitions.
I can define closure and reopening criteria beyond alert silence.
I can produce a safe fictional triage package without copying real alerts, records, or cases.
Record one fictional alert observation, one primary question, one evidence gap, one source-health state, one owner request, one decision state, and one question you will carry into A6.6.
Key Takeaways
What You Should Remember
1.Fictional triage begins with a neutral observation and bounded defender question, not the alert title or severity label.
2.Direct evidence, parsed fields, normalized fields, enrichment, derived context, owner statements, hypotheses, and decisions are different layers.
3.Triage should review identity, device, service, destination, authorization, timing, source health, scope, impact, alternatives, ownership, and next evidence.
4.Missing, delayed, conflicting, Blind, or Recovering evidence should remain visible through Conditional, Source-Degraded, or Unknown states.
5.Purpose-limited fictional evidence requests should specify purpose, fields, period, owner, deadline, privacy boundary, and decision use.
6.Expected requires current, scoped, evidence-supported authorization and context rather than a vague owner statement.
7.Resolved requires completed questions, source health, authorization, scope, impact, owner actions, validation, residual risk, closure criteria, and reopen criteria.
8.Alert silence, elapsed time, or a label change does not prove resolution.
9.Triage quality includes question quality, evidence-layer accuracy, source-health visibility, request precision, state accuracy, owner response, closure quality, and debt.
10.Every CyberShield triage artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.
Navigation
Continue Module A6
Next, learn how fictional defenders define evidence-based technical, service-owner, source-health, privacy, leadership, supplier, recovery, and time-sensitive escalation criteria without overreacting or delaying necessary review.