S — Signal and state
Classify the alert, event, issue, suspected incident, confirmed incident, source problem, or non-incident condition.
High School AdvancedModule A7Lesson 3 of 10Detection, Activation, Scope, Relationships, and Change Control
A7.3 Detection and Scoping
Learn how fictional responders move from alerts, reports, service symptoms, supplier notices, and source-health conditions into a defensible incident activation and scope that separates confirmed, possible, unknown, unaffected, excluded, and out-of-scope entities.
Lesson Progress
Detection and Scoping
High School Advanced • A7: Incident Response Lifecycle • Lesson 3 of 10
30% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
The First Scope Is Usually Incomplete
Fictional Northbridge begins with one stale-role alert. Minutes later, a user reports a service delay, a supplier reports an integration problem, the device source becomes Conditional, and the data-access source is Blind. A weak response either marks everything affected or refuses to change the first scope. A professional response creates categories, assigns evidence questions, and changes scope only when supported.
Weak scope
“Everything connected to the alert is affected.”
Strong scope
“Identity and session relationships are confirmed. Device, supplier, and user impact are possible. Data access is Unknown because the required source is Blind.”
Good scoping is the disciplined process of matching every conclusion to the evidence that actually supports it.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Distinguish fictional alerts, events, issues, source-health failures, suspected incidents, confirmed incidents, and non-incident conditions without forcing early certainty.
Objective 2
Build fictional incident scope using identities, devices, services, destinations, data, suppliers, users, dependencies, time periods, evidence, source health, confidence, exclusions, and owner statements.
Objective 3
Separate fictional confirmed, possibly affected, unaffected, unknown, excluded, and out-of-scope categories while preserving the evidence and limitations behind each classification.
Objective 4
Maintain a fictional scope-change log with version, trigger, evidence, source health, owner, severity, priority, communication, containment, recovery, and reassessment consequences.
Objective 5
Create a portfolio-ready fictional Detection and Scoping Package containing an activation record, evidence matrix, chronology, entity register, relationship map, hypothesis register, source-health map, scope statement, change log, validation cases, dashboard, leadership brief, and reflection.
Why This Matters
Scope Controls Every Later Response Decision
Fictional severity, priority, containment, communication, evidence preservation, continuity, recovery, leadership decisions, privacy, residual risk, closure, and reopening all depend on scope. If scope is too broad, teams may disrupt unrelated services and overstate impact. If scope is too narrow, meaningful identities, devices, data, suppliers, users, or periods may remain unreviewed.
Evidence accuracy
Every scope category states what supports it, what limits it, and what would change it.
Decision accuracy
Containment, communication, recovery, and risk decisions use the current scope version.
Lifecycle accuracy
Scope changes remain traceable through chronology, versions, owners, consequences, and reopening.
Core Framework
The S-C-O-P-E-D Method
C — Chronology and coverage
Preserve event, collection, processing, report, decision, action, validation, communication, and source-health timing.
O — Objects and owners
Map identities, devices, services, destinations, data, users, suppliers, dependencies, sources, and accountable owners.
P — Possibility and proof
Separate confirmed, possible, unaffected, unknown, excluded, and out-of-scope conclusions.
E — Explanations and evidence
Compare hypotheses, alternatives, source health, provenance, confidence, supports, and non-proof statements.
D — Document change
Version scope changes with trigger, evidence, owner, consequences, communication, containment, recovery, and risk.
Decision-ready scope statement
Fictional Scope Version 1.5 confirms one identity, one session, one service, and one administrative destination. Two device categories, one supplier dependency, and one user-impact report remain possible. Protected data access remains Unknown because the required source is Blind.
Advanced Vocabulary
Terms for Detection and Scoping
Alert
A fictional signal that a condition may deserve review; it does not automatically prove an incident.
Event
A fictional recorded occurrence such as a session, change, service transition, identity update, source-health transition, or user report.
Issue
A fictional condition requiring attention that may belong to service management, source recovery, privacy review, supplier coordination, identity governance, or another workflow.
Suspected incident
A fictional response state in which evidence supports coordinated review but not a fully confirmed conclusion.
Confirmed incident
A fictional response state supported by sufficient evidence that an organization-defined harmful, unauthorized, or materially disruptive condition occurred.
Activation decision
A fictional choice to continue routine triage, activate incident coordination, involve specialists, escalate leadership, begin source recovery, or use another workflow.
Initial scope
The first fictional evidence-supported description of confirmed, possible, unknown, excluded, unaffected, and out-of-scope categories.
Scope statement
A fictional versioned description of affected entities, periods, relationships, confidence, evidence, source health, exclusions, assumptions, and unresolved questions.
Confirmed affected
A fictional category supported by sufficient evidence for the exact conclusion being stated.
Possibly affected
A fictional category for something connected by evidence or dependency but not yet supported strongly enough for confirmation.
Unaffected
A fictional category supported by relevant Healthy evidence showing the item does not meet the incident condition within the defined boundary and period.
Unknown
A fictional category used when evidence is missing, Blind, Degraded, conflicting, incomplete, delayed, or not yet reviewed.
Excluded
A fictional category for evidence-supported items removed from the current incident condition because another explanation or workflow fits better.
Out of scope
A fictional category for items not included in the current review boundary.
Scope boundary
A fictional limit defining which entities, relationships, periods, evidence, and questions belong to the response.
Scope confidence
A fictional conclusion-specific judgment about how complete and reliable the current scope is.
Scope hypothesis
A fictional testable explanation describing how identities, services, devices, data, suppliers, users, or periods may be connected.
Scope expansion
A fictional evidence-supported increase in affected or possibly affected identities, devices, services, data, suppliers, users, dependencies, or time.
Scope contraction
A fictional evidence-supported narrowing after alternatives, Healthy evidence, validation, or owner review remove items.
Relationship map
A fictional model connecting identity, device, service, destination, data, user, source, supplier, dependency, approval, change, and time.
Chronology
A fictional ordered record of event, collection, processing, report, decision, action, validation, and communication times.
Scope-change trigger
A fictional new evidence, source-health, relationship, impact, owner, supplier, data, time, validation, or recovery condition requiring reassessment.
Alternative explanation
A fictional plausible expected, technical, timing, source-health, change, supplier, ownership, or recovery explanation tested against evidence.
Non-proof statement
A fictional statement describing what an alert, record, owner claim, source-health condition, or relationship does not prove.
Instructional Section 1
Classify Six Response States
Alert
A fictional signal that a condition may deserve review.
Evidence threshold
One or more signals, reports, service symptoms, or source conditions.
Primary owner
Analyst or triage owner.
Next decision
Choose routine triage, source recovery, service review, privacy review, or incident coordination.
Does not prove
Does not prove intent, impact, authorization, or scope.
Event
A fictional occurrence recorded by a source or reported by a person.
Evidence threshold
A traceable record with source, timing, provenance, and meaning.
Primary owner
Source owner and analyst.
Next decision
Determine whether it supports a defender question or expected activity.
Does not prove
An event can be normal, expected, delayed, duplicated, or misunderstood.
Issue
A fictional condition requiring attention but not necessarily incident response.
Evidence threshold
Evidence of service, source, ownership, policy, supplier, privacy, or operational problems.
Primary owner
Appropriate service, source, privacy, supplier, identity, or program owner.
Next decision
Route to the correct workflow while preserving incident relevance.
Does not prove
A meaningful issue is not automatically an incident.
Suspected incident
A fictional condition with enough evidence or coordination need to justify structured incident response.
Evidence threshold
Supported observation, relevant scope, potential consequence, source-health review, and bounded questions.
Primary owner
Incident lead with specialists and service owners.
Next decision
Confirm, narrow, reclassify, contain, monitor, or transfer.
Does not prove
Suspected does not mean confirmed harmful activity.
Confirmed incident
A fictional condition meeting documented evidence and impact criteria.
Evidence threshold
Sufficient evidence for the exact harmful, unauthorized, disruptive, privacy, integrity, or mission conclusion.
Primary owner
Incident lead with required authorities.
Next decision
Coordinate containment, communication, preservation, recovery, and improvement.
Does not prove
Confirmation of one condition does not prove complete scope, intent, or final impact.
Non-incident condition
A fictional alert or issue explained by expected activity, source defect, service condition, approved change, duplicate delivery, or another workflow.
Evidence threshold
Relevant Healthy evidence, owner confirmation, scope match, timing match, and break-condition review.
Primary owner
Analyst with the appropriate owner.
Next decision
Document reclassification, assign fixes, and define reopen triggers.
Does not prove
Does not prove the alert was useless or future similar activity is safe.
Instructional Section 2
Review Ten Scope Dimensions
Identity
Questions
Which identities, sponsors, roles, groups, approvals, sessions, lifecycle states, and effective-access relationships are involved?
Evidence
Identity, role, group, approval, extension, session, sponsor, owner, and source-health records.
Common gap
Treating an identity as proof of the person controlling every action.
Owner
Identity owner
Device
Questions
Which devices, categories, ownership states, management states, service relationships, and sessions are involved?
Evidence
Device inventory, session, management, service, owner, change, and source-health records.
Common gap
Assuming every device associated with an identity is affected.
Owner
Device owner
Service
Questions
Which services, administrative functions, workflows, dependencies, owners, changes, and recovery states are involved?
Evidence
Service catalog, health, change, dependency, owner, continuity, and recovery records.
Common gap
Treating criticality as proof of current impact.
Owner
Service owner
Destination
Questions
Which application area, administrative destination, data location, supplier connection, or service endpoint is relevant?
Evidence
Session, service, destination, supplier, change, and source-health records.
Common gap
Grouping distinct destinations under one broad label.
Owner
Service or infrastructure owner
Data
Questions
Which data categories, user groups, sensitivity levels, stores, transfers, or integrity concerns are involved?
Evidence
Data catalog, application, service, access, change, owner, privacy, and integrity records.
Common gap
Claiming data access from a service session alone.
Owner
Data owner and privacy reviewer
User impact
Questions
Which students, staff, families, partners, or support workflows experienced confirmed, possible, unknown, or no impact?
Evidence
User reports, service health, workflow status, owner statements, continuity, errors, and communication.
Common gap
Using one report as complete population impact.
Owner
Service and continuity owners
Supplier
Questions
Which providers, integrations, support paths, data exchanges, dependencies, and response commitments are involved?
Evidence
Supplier register, integration map, service dependency, owner communication, source health, and timing.
Common gap
Treating a supplier statement as complete local evidence.
Owner
Supplier owner
Time
Questions
Which start, end, observation, Blind, change, session, approval, impact, recovery, and validation periods matter?
Evidence
Event, collection, processing, report, decision, action, validation, communication, and source-health times.
Common gap
Using processing time as event time.
Owner
Incident lead and source owners
Dependency
Questions
Which identity, service, infrastructure, source, supplier, data, communication, continuity, and recovery dependencies may change scope?
Evidence
Architecture, service catalog, owner statements, change, supplier, source, continuity, and recovery records.
Common gap
Ignoring indirect mission or recovery dependencies.
Owner
Service, infrastructure, continuity, and recovery owners
Evidence coverage
Questions
Which sources, populations, fields, periods, schemas, parsers, queues, Blind periods, conflicts, and recovery states limit scope?
Evidence
Source inventory, health, completeness, freshness, field coverage, alternate evidence, and recovery plans.
Common gap
Calling something unaffected when the required source is Blind.
Owner
Source owners and evidence coordinator
Instructional Section 3
Use Six Scope Categories
Confirmed affected
Professional standard
Evidence supports that the item meets the exact incident condition being stated.
Fictional example
One fictional session continued after approval expiration and reached the administrative destination.
Required documentation
Evidence IDs, relationship, time, source health, confidence, owner, and non-proof statement.
Reassessment
Reassess when source recovery, alternatives, corrected mappings, or owner validation change the conclusion.
Possibly affected
Professional standard
Evidence supports a meaningful relationship or dependency, but confirmation is incomplete.
Fictional example
A second fictional device shares the identity and period, but session evidence is Conditional.
Required documentation
Why possible, evidence needed, source limitation, owner, deadline, and decision consequence.
Reassessment
Move to confirmed, unaffected, excluded, unknown, or out of scope as evidence changes.
Unaffected
Professional standard
Relevant Healthy evidence supports that the item does not meet the condition within the defined boundary and period.
Fictional example
A fictional service has complete session evidence showing no relationship during the scoped period.
Required documentation
Coverage, period, condition tested, evidence IDs, source health, confidence, and limitations.
Reassessment
Reopen when period, source health, evidence, or incident condition changes.
Unknown
Professional standard
Evidence is unavailable, incomplete, Blind, Degraded, conflicting, delayed, or not reviewed.
Fictional example
A supplier integration may be related, but supplier and local evidence are unavailable.
Required documentation
Missing evidence, affected question, owner, alternate evidence, deadline, recovery path, and risk.
Reassessment
Unknown must have an owner and future decision point.
Excluded
Professional standard
Evidence supports a different explanation or workflow outside the current incident condition.
Fictional example
A change record fully explains one service event within matching time, owner, purpose, destination, and scope.
Required documentation
Exclusion reason, evidence, owner validation, break conditions, expiration, and reopen trigger.
Reassessment
Return to review when any matching field or source-health condition changes.
Out of scope
Professional standard
The item is outside the current boundary and not required to answer the response questions.
Fictional example
An unrelated fictional service with no identity, data, dependency, supplier, time, or evidence relationship.
Required documentation
Boundary reason, owner, relationship check, and condition that would bring it into scope.
Reassessment
Move into possible or unknown scope when a new relationship appears.
Instructional Section 4
Review Ten Fictional Evidence Records
SCOPE-E01
Fictional SIEM alert
Event time
08:58
Collection time
08:59
Processing time
09:00
Observation
Temporary recovery role remains Active after approval_end for identity NB-ID-042.
Supports
A time-sensitive stale-authority question exists.
Does not prove
Does not prove harmful intent, exercised privilege, service impact, or complete scope.
SCOPE-E02
Fictional session source
Event time
09:04
Collection time
09:05
Processing time
09:06
Observation
Session NB-SES-881 connects NB-ID-042 to service NB-SVC-07 and destination coordination-admin.
Supports
The identity, service, destination, session, and period are related.
Does not prove
Does not prove unauthorized use, modification, data exposure, or user impact.
SCOPE-E03
Fictional group source
Event time
09:02
Collection time
09:11
Processing time
09:12
Observation
Recovery-admin group remains Active, but the source is Degraded and synchronization is delayed.
Supports
Effective-access uncertainty remains relevant.
Does not prove
Does not prove exact group state at every minute.
SCOPE-E04
Fictional service-health source
Event time
09:07
Collection time
09:08
Processing time
09:09
Observation
NB-SVC-07 remains available with no confirmed error increase or user-impact signal.
Supports
Current service disruption is not confirmed.
Does not prove
Does not prove authorization, privacy, integrity, or historical safety.
SCOPE-E05
Fictional user report
Event time
09:09
Collection time
09:10
Processing time
09:10
Observation
One staff user reports an unexpected delay in the Student Assistance Coordination Service.
Supports
A user-experience question deserves review.
Does not prove
One report does not prove broad impact or connection to the identity event.
SCOPE-E06
Fictional supplier notice
Event time
09:12
Collection time
09:14
Processing time
09:15
Observation
Supplier reports delayed responses on an integration used by NB-SVC-07.
Supports
A supplier dependency may explain or contribute to the user report.
Does not prove
Does not prove the supplier caused the stale-authority condition or service impact.
SCOPE-E07
Fictional device source
Event time
09:03
Collection time
09:17
Processing time
09:18
Observation
NB-ID-042 has sessions from managed-laptop and support-console; source completeness is Conditional.
Supports
Two device categories may require relationship review.
Does not prove
Does not prove both devices were used in the relevant session.
SCOPE-E08
Fictional change source
Event time
08:20
Collection time
08:21
Processing time
08:22
Observation
Approved recovery change covers database reconciliation from 08:15 to 08:55 but not coordination-admin after 09:00.
Supports
The change is a partial alternative but not a complete match.
Does not prove
Does not prove later activity was unauthorized.
SCOPE-E09
Fictional privacy review
Event time
09:22
Collection time
09:23
Processing time
09:24
Observation
No evidence confirms access to protected records; the required data-access source is Blind for 08:50 to 09:20.
Supports
Data access and exposure remain Unknown.
Does not prove
Blind evidence cannot support either access or no-access conclusions.
SCOPE-E10
Fictional service catalog
Event time
07:30
Collection time
07:31
Processing time
07:32
Observation
NB-SVC-07 depends on supplier integration NB-SUP-03 and identity service NB-ID-SVC-02.
Supports
Supplier and identity dependencies belong in possible or unknown scope.
Does not prove
Dependency does not prove the dependent components are affected.
Instructional Section 5
Build a Ten-Relationship Map
Identity to role
From
NB-ID-042
To
Temporary recovery role
State
Confirmed relationship — Evidence SCOPE-E01
Limitation
Assignment does not prove exercised authority.
Identity to session
From
NB-ID-042
To
NB-SES-881
State
Confirmed relationship — Evidence SCOPE-E02
Limitation
Identity evidence does not prove the person controlling the session.
Session to service
From
NB-SES-881
To
NB-SVC-07
State
Confirmed relationship — Evidence SCOPE-E02
Limitation
Service access does not prove harmful effect.
Session to destination
From
NB-SES-881
To
coordination-admin
State
Confirmed relationship — Evidence SCOPE-E02
Limitation
Destination does not prove a configuration change.
Identity to group
From
NB-ID-042
To
recovery-admin
State
Conditional relationship — Evidence SCOPE-E03
Limitation
Group source is Degraded.
Service to user report
From
NB-SVC-07
To
one staff delay report
State
Possible relationship — Evidence SCOPE-E05
Limitation
The report may have another cause.
Service to supplier
From
NB-SVC-07
To
NB-SUP-03
State
Confirmed dependency; impact unknown — Evidence SCOPE-E06 and SCOPE-E10
Limitation
Supplier delay does not prove local service impact.
Identity to devices
From
NB-ID-042
To
managed-laptop and support-console
State
Possible relationship — Evidence SCOPE-E07
Limitation
Source completeness is Conditional.
Recovery change to session
From
NB-CHG-114
To
NB-SES-881
State
Partial alternative — Evidence SCOPE-E08
Limitation
Time and destination do not fully match.
Service to protected data
From
NB-SVC-07
To
protected student-support records
State
Service dependency; access unknown — Evidence SCOPE-E09
Limitation
Data-access source is Blind.
Instructional Section 6
Create a Ten-Entity Scope Register
NB-ID-042
Identity
Reason
Role and session evidence connect the identity to the stale-authority condition.
Evidence
SCOPE-E01 and SCOPE-E02
Confidence
High relationship confidence; Moderate authorization confidence.
Owner
Identity owner.
Next question
Did a valid matching extension exist, and which sessions remained active?
NB-SES-881
Session
Reason
Session occurred after approval_end and reached the administrative destination.
Evidence
SCOPE-E02
Confidence
High observation confidence.
Owner
Identity and service owners.
Next question
What activity occurred, and what state followed authorized containment?
NB-SVC-07
Service
Reason
The session reached the service, but service health shows no confirmed broad impact.
Evidence
SCOPE-E02 and SCOPE-E04
Confidence
High relationship confidence; Moderate impact confidence.
Owner
Service owner.
Next question
Did the session affect configuration, users, privacy, integrity, or recovery?
coordination-admin
Destination
Reason
The session reached this administrative destination after approval expiration.
Evidence
SCOPE-E02
Confidence
High relationship confidence.
Owner
Service owner.
Next question
Did the session only view status, or did any state change occur?
managed-laptop
Device category
Reason
Identity relationship exists, but device-source completeness is Conditional.
Evidence
SCOPE-E07
Confidence
Low to Moderate.
Owner
Device owner.
Next question
Was this device associated with NB-SES-881 during the relevant period?
support-console
Device category
Reason
Identity relationship exists, but session-to-device linkage is incomplete.
Evidence
SCOPE-E07
Confidence
Low to Moderate.
Owner
Infrastructure owner.
Next question
Did the support console create or continue the relevant session?
NB-SUP-03
Supplier integration
Reason
The service depends on it and the supplier reported delayed responses.
Evidence
SCOPE-E06 and SCOPE-E10
Confidence
Moderate dependency confidence; Low incident-relationship confidence.
Owner
Supplier owner.
Next question
Did supplier delay contribute to user impact or only create a separate service issue?
Protected student-support records
Data category
Reason
The service relates to the data, but the data-access source is Blind.
Evidence
SCOPE-E09
Confidence
Unknown.
Owner
Data owner and privacy reviewer.
Next question
Did any data-access event occur during the Blind period, and what alternate evidence exists?
One staff delay report
User impact
Reason
A report exists, but its relationship to identity activity or supplier delay is unresolved.
Evidence
SCOPE-E05 and SCOPE-E06
Confidence
Low to Moderate.
Owner
Service and continuity owners.
Next question
Was the delay caused by the supplier, service, identity session, or another condition?
Unrelated scheduling service
Service
Reason
No identity, session, destination, data, supplier, dependency, time, or evidence relationship is supported.
Evidence
Current relationship review.
Confidence
Moderate.
Owner
Incident lead.
Next question
Bring into scope only when a new supported relationship appears.
Instructional Section 7
Reconstruct the Fictional Chronology
08:15
SCOPE-E08
Fictional recovery change NB-CHG-114 begins for database reconciliation.
Scope effect: Creates an expected alternative for matching activity only.
08:55
SCOPE-E08
Fictional recovery change ends.
Scope effect: Later activity falls outside the approved change window.
08:58
SCOPE-E01
Fictional temporary recovery role remains Active near approval_end.
Scope effect: Identity and role enter confirmed relationship scope.
09:00
SCOPE-E01
Fictional approved role window ends.
Scope effect: Extension and continuing-session questions become time-sensitive.
09:02
SCOPE-E03
Fictional group membership is Active under Degraded source health.
Scope effect: Effective access becomes Conditional rather than confirmed or excluded.
09:04
SCOPE-E02
Fictional session NB-SES-881 reaches NB-SVC-07 and coordination-admin.
Scope effect: Session, service, and destination enter confirmed relationship scope.
09:07
SCOPE-E04
Fictional service remains available with no confirmed broad impact.
Scope effect: Service impact remains unconfirmed despite confirmed relationship.
09:09
SCOPE-E05
One fictional staff user reports a service delay.
Scope effect: User impact enters possible scope.
09:12
SCOPE-E06
Fictional supplier reports delayed integration responses.
Scope effect: Supplier dependency enters possible scope and alternative analysis.
09:18
SCOPE-E07
Fictional device source shows two categories under Conditional completeness.
Scope effect: Managed laptop and support console enter possible scope.
09:24
SCOPE-E09
Fictional privacy review identifies a Blind data-access period.
Scope effect: Protected data becomes Unknown rather than unaffected.
09:30
Scope decision record
Fictional incident lead publishes Scope Version 1.5.
Scope effect: Confirmed, possible, unknown, excluded, and out-of-scope categories are documented.
Instructional Section 8
Test Six Scope Hypotheses
H-01
A fictional stale temporary role allowed one session to continue after approval expiration.
Supporting evidence
Role and session evidence align on identity and time.
Contradicting evidence
Extension and group evidence are incomplete.
Next evidence
Source-side extension, group synchronization, session details, and identity-owner validation.
Current status
Supported, but authorization remains Conditional.
H-02
The fictional user delay was caused by the same session activity.
Supporting evidence
The report occurred near the session and involves the same service.
Contradicting evidence
Service health shows no broad impact, and supplier delay is a competing explanation.
Next evidence
User-impact details, service timing, supplier timing, destination behavior, and owner review.
Current status
Possible.
H-03
The fictional supplier delay caused the reported service delay.
Supporting evidence
Supplier reported delay and the service depends on that integration.
Contradicting evidence
Only one user report exists, and service health shows no broad error increase.
Next evidence
Supplier affected period, service dependency timing, and additional user reports.
Current status
Possible.
H-04
The fictional approved recovery change explains the session.
Supporting evidence
The identity had a recovery role and an approved recovery change existed.
Contradicting evidence
The change ended before the session and covers a different destination.
Next evidence
Change-owner confirmation and any additional approved change.
Current status
Partial alternative; not a full explanation.
H-05
Protected fictional data was accessed during the session.
Supporting evidence
The service relates to protected records.
Contradicting evidence
No direct data-access evidence is available, and the relevant source is Blind.
Next evidence
Alternate application evidence, source recovery, owner validation, and historical reconciliation.
Current status
Unknown.
H-06
Both fictional device categories participated in the relevant activity.
Supporting evidence
Both are associated with the identity.
Contradicting evidence
Session-to-device linkage is incomplete and source completeness is Conditional.
Next evidence
Session device field, source-side device evidence, and owner review.
Current status
Possible but weak.
Instructional Section 9
Maintain Six Scope Versions
Version 1.0
Initial role and session correlation
Scope change
Confirmed identity, role, session, service, destination, and initial period.
Evidence
SCOPE-E01 and SCOPE-E02
Source health
Role and session Healthy
Decision consequence
Activate incident coordination and identity/service ownership.
Version 1.1
Degraded group evidence
Scope change
Effective-access conclusion changed from assumed Active to Conditional.
Evidence
SCOPE-E03
Source health
Group source Degraded
Decision consequence
Lower authorization confidence and assign source owner.
Version 1.2
One staff user reports delay
Scope change
User impact enters possible scope.
Evidence
SCOPE-E05
Source health
Human report; service source Healthy
Decision consequence
Assign service and continuity question without claiming broad impact.
Version 1.3
Supplier delay notice and dependency map
Scope change
Supplier integration enters possible scope and alternative register.
Evidence
SCOPE-E06 and SCOPE-E10
Source health
Supplier statement not independently validated
Decision consequence
Assign supplier owner and compare timing with user impact.
Version 1.4
Conditional device evidence
Scope change
Managed laptop and support console enter possible scope.
Evidence
SCOPE-E07
Source health
Device source Conditional
Decision consequence
Request session-to-device evidence.
Version 1.5
Blind data-access source
Scope change
Protected data moves from unreviewed to Unknown rather than unaffected.
Evidence
SCOPE-E09
Source health
Data-access source Blind
Decision consequence
Activate privacy review, alternate evidence, and historical reassessment.
Instructional Section 10
Validate Twelve Scope Scenarios
| Case | Type | Fictional input | Expected result | Quality protected |
|---|---|---|---|---|
| SCOPE-T01 | Alert only | One fictional alert with no owner context, source-health review, or service relationship. | Remain in triage; do not declare confirmed incident or broad scope. | Proportionate activation |
| SCOPE-T02 | Multi-source alignment | Fictional role, session, and service evidence align on identity, destination, and time. | Confirm the relationship while preserving authorization and impact limitations. | Evidence-based confirmation |
| SCOPE-T03 | Blind source | Fictional data-access source is Blind during the key period. | Classify data-access scope as Unknown rather than unaffected. | Source-health honesty |
| SCOPE-T04 | Dependency only | A fictional supplier is a service dependency but has no evidence connection to the event. | Keep supplier out of confirmed scope; use possible or out of scope. | Avoiding over-scoping |
| SCOPE-T05 | One user report | One fictional user reports delay while service health remains normal. | Classify user impact as possible and request supporting evidence. | Population accuracy |
| SCOPE-T06 | Healthy exclusion | An approved change matches identity, service, destination, purpose, time, and owner under Healthy evidence. | Exclude matching activity with break conditions and expiration. | Defensible contraction |
| SCOPE-T07 | Partial alternative | A change matches purpose and identity but not time or destination. | Keep as partial alternative; do not exclude the event. | Scope accuracy |
| SCOPE-T08 | Second service | A second service appears through a confirmed shared dependency. | Enter possible scope, assign owner, and reassess response decisions. | Dynamic expansion |
| SCOPE-T09 | Source recovery | A recovering source provides new historical records after closure. | Reassess scope and reopen when the prior conclusion changes. | Historical continuity |
| SCOPE-T10 | Time confusion | An event processed at 10:00 actually occurred at 08:30. | Use event time for chronology and preserve collection and processing delay. | Timeline accuracy |
| SCOPE-T11 | Unaffected claim | A service has no alerts, but its required source is Degraded. | Do not classify unaffected solely from alert silence. | False-negative awareness |
| SCOPE-T12 | Public portfolio | Student plans to sanitize a real incident timeline and affected-system list. | Fail portfolio validation and invent every detail. | Confidentiality and safety |
Instructional Section 11
Measure Eight Scoping Outcomes
Time to first scope statement
Review question
How long does response take to document initial confirmed, possible, unknown, excluded, unaffected, and out-of-scope categories?
Fictional evidence
Activation time, first scope version, source health, urgency, owner availability, and quality review.
Limitation
Fast scope can be incomplete or unsupported.
Scope revision rate
Review question
How often does scope change as evidence, source recovery, owner input, impact, dependencies, or alternatives appear?
Fictional evidence
Version count, triggers, evidence, owners, reason, direction, and consequences.
Limitation
Many revisions may reflect healthy learning or poor preparation.
Unknown aging
Review question
How long do unknown identities, devices, services, data, suppliers, impacts, or periods remain unresolved?
Fictional evidence
Unknown register, owner, evidence needed, source state, deadline, escalation, and decision effect.
Limitation
Some uncertainty may remain legitimately unresolved.
False expansion rate
Review question
How often are entities added to scope and later excluded because the initial relationship was weak or misunderstood?
Fictional evidence
Scope versions, relationship evidence, source health, alternative explanation, and contraction reason.
Limitation
Contraction can reflect good evidence review rather than failure.
False unaffected rate
Review question
How often do items classified unaffected later enter confirmed or possible scope?
Fictional evidence
Prior unaffected evidence, coverage, source health, new evidence, reopened cases, and decision impact.
Limitation
A changed condition or period may make the earlier decision reasonable.
Source-limited scope
Review question
What share of scope decisions depend on Conditional, Degraded, Blind, Conflicting, or Recovering evidence?
Fictional evidence
Source-health map, affected dimensions, confidence, alternate evidence, and reassessment obligations.
Limitation
A high rate may reflect honest classification rather than poor analysis.
Owner acknowledgement
Review question
Do identity, service, device, data, supplier, source, privacy, continuity, and recovery owners acknowledge their scope questions?
Fictional evidence
Question log, assignment, acceptance, deadline, response, escalation, and quality.
Limitation
Acknowledgement does not prove the answer is complete.
Scope communication lag
Review question
How long does it take updates to reflect significant scope changes?
Fictional evidence
Scope version time, communication approval, audience, distribution, correction, and next-update commitment.
Limitation
Immediate communication may be inappropriate when evidence is weak.
Fictional Scoping Architecture
Northbridge Detection-to-Scope Model
This conceptual model is completely invented and intentionally non-operational. It teaches evidence-based detection and scoping without real alerts, identities, systems, services, suppliers, sources, incidents, or response actions.
Signal inputs
Alerts, user reports, service symptoms, supplier notices
Evidence inputs
Identity, session, service, device, data, source health
Mission inputs
Critical services, users, continuity, privacy, suppliers
Time inputs
Event, collection, processing, report, decision, validation
Fictional Scope Core
Classification
Alert, event, issue, suspected, confirmed, non-incident
Relationships
Identity, device, service, destination, data, supplier
Categories
Confirmed, possible, unaffected, unknown, excluded, out
Evidence
Source, provenance, timing, health, supports, limitations
Hypotheses
Supporting, contradicting, alternatives, next evidence
Ownership
Identity, service, data, supplier, source, privacy
Change
Version, trigger, consequence, communication, response
Lifecycle
Reassessment, closure, reopening, improvement
Response output
Activation, scope, severity, priority, owners
Decision output
Containment, communication, continuity, recovery
Leadership output
Impact, uncertainty, options, resources, risk
Portfolio boundary
Fully fictional, privacy-safe, non-operational
Fake Dashboard
Fake Northbridge Detection and Scope Dashboard
Fictional activation state, confirmed and possible entities, unknown data scope, source-health limits, owner questions, scope revisions, and communication lag.
Current fictional scope categories
4 confirmed / 4 possible / 1 unknown
One unrelated service remains out of scope; no broad service impact is confirmed.
Open fictional scope questions
9
Authorization, device linkage, supplier timing, user impact, data access, configuration change, session detail, group state, and recovery remain open.
Current fictional scope version
1.5
The latest revision changed protected data from unreviewed to Unknown because the required source is Blind.
Fake SOC Alert
Scope Reassessment Required
Source: Fake Northbridge Incident Coordination Console • Time: 9:24 AM
The fictional response confirms one identity, one session, one service, and one destination. Device and supplier relationships remain possible. A protected-data source is Blind, so data access cannot be classified unaffected.
Defensive recommendation: Publish Scope Version 1.5, classify protected data as Unknown, assign privacy and source owners, request alternate evidence, preserve the Blind period, and reassess response decisions when evidence recovers.
Fake Log Panel
Fake Detection and Scope Timeline
training-log-viewer.log
08:58 ROLE identity='NB-ID-042' state='active' 09:00 APPROVAL state='expired' 09:02 GROUP state='active' health='degraded' 09:04 SESSION id='NB-SES-881' service='NB-SVC-07' 09:07 SERVICE impact='none-confirmed' 09:09 USER-REPORT delay='one-user' 09:12 SUPPLIER delay='reported' 09:18 DEVICE source='conditional' 09:24 DATA-SOURCE health='blind' 09:25 SCOPE confirmed='4' 09:25 SCOPE possible='4' 09:25 SCOPE unknown='1' 09:30 VERSION scope='1.5'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What Scope Evidence Supports—and What It Does Not Prove
MATRIX-01
Role and session evidence
Observation
Identity, role, session, service, destination, and time relationships are supported.
Supports
Confirmed relationship scope.
Does not prove
Does not prove intent, data access, modification, or impact.
Scope use
Confirm bounded entities and open authorization, activity, and impact questions.
MATRIX-02
Group-source health
Observation
Group evidence is Degraded during the relevant period.
Supports
Effective access remains uncertain.
Does not prove
Does not prove group membership was active or inactive at every moment.
Scope use
Use Conditional scope and assign source recovery.
MATRIX-03
Service health
Observation
Service availability is normal with no broad error increase.
Supports
Broad active impact is not currently confirmed.
Does not prove
Does not prove no authorization, privacy, integrity, or limited-user effect.
Scope use
Separate service relationship from impact conclusion.
MATRIX-04
User report
Observation
One staff user reports delay.
Supports
Possible user impact.
Does not prove
Does not represent the full population or prove cause.
Scope use
Assign impact question and gather corroborating evidence.
MATRIX-05
Supplier notice
Observation
Supplier reports delayed integration responses.
Supports
Supplier dependency may be relevant.
Does not prove
Does not prove supplier caused the incident or local impact.
Scope use
Enter supplier into possible scope and test timing.
MATRIX-06
Blind data source
Observation
Data-access evidence is unavailable for the key period.
Supports
Data scope must remain Unknown.
Does not prove
Does not prove access or no access.
Scope use
Activate privacy review, alternate evidence, recovery, and reassessment.
MATRIX-07
Approved change
Observation
Change matches identity and purpose but not time or destination.
Supports
Partial alternative explanation.
Does not prove
Does not justify exclusion.
Scope use
Preserve the hypothesis and request owner clarification.
MATRIX-08
Device evidence
Observation
Two device categories are associated with the identity under Conditional completeness.
Supports
Possible device scope.
Does not prove
Does not prove either device created the session.
Scope use
Request session-to-device evidence before confirmation.
Analyze the Evidence
Which Scope Decision Is Best Supported?
Role and session evidence confirm one identity and one session after approval expiration.
The session reached one service and one administrative destination.
Group evidence is Degraded.
One user reported a delay.
Supplier delay may be relevant.
Two device categories have incomplete relationship evidence.
The data-access source is Blind.
No broad service impact is confirmed.
Which fictional Scope Version 1.5 decision best fits the evidence?
Common Mistakes
Avoid Ten Detection and Scoping Errors
The alert title becomes the incident
Fictional observation
A fictional analyst copies the alert title into the declaration and scope.
Impact
Unverified assumptions control severity, communication, containment, and evidence requests.
Professional correction
Start with neutral observations, questions, evidence, source health, and non-proof statements.
Everything related becomes affected
Fictional observation
Every associated device, service dependency, supplier, and data set is marked affected.
Impact
Scope becomes too broad and communication may overstate impact.
Professional correction
Use confirmed, possible, unknown, unaffected, excluded, and out-of-scope categories.
No alert means unaffected
Fictional observation
A service is called unaffected because no alert exists.
Impact
Blind or weak coverage becomes false reassurance.
Professional correction
Require relevant Healthy evidence for unaffected classification.
Unknown is treated as failure
Fictional observation
A responder avoids Unknown and forces every item into affected or unaffected.
Impact
Missing evidence becomes unsupported certainty.
Professional correction
Use Unknown with owner, evidence need, deadline, alternate evidence, and reassessment.
Processing time replaces event time
Fictional observation
A delayed event is placed in chronology when processed rather than when it occurred.
Impact
Cause, sequence, scope, and response decisions may be wrong.
Professional correction
Preserve event, collection, processing, report, decision, action, validation, and communication times separately.
Dependencies are treated as impact
Fictional observation
A supplier or service is confirmed affected only because a dependency exists.
Impact
Scope expands without direct or indirect impact evidence.
Professional correction
Distinguish confirmed dependency from confirmed incident effect.
Scope never changes
Fictional observation
A team protects its first scope after source recovery or new evidence.
Impact
Containment, communication, recovery, and risk decisions become stale.
Professional correction
Use versioned scope changes with trigger, evidence, owner, consequence, and communication.
Scope changes are undocumented
Fictional observation
Entities enter and leave scope without a decision record.
Impact
Reviewers cannot reconstruct why actions or messages changed.
Professional correction
Maintain a scope-change log and preserve prior versions.
One report defines broad impact
Fictional observation
One individual delay report is described as organization-wide disruption.
Impact
Severity and communication may be overstated.
Professional correction
Classify possible impact and seek population, service, timing, and owner evidence.
Real scope data enters the portfolio
Fictional observation
A student sanitizes a real affected-system list, timeline, supplier, owner, or identity relationship.
Impact
Sensitive architecture, services, people, incidents, and capabilities may remain visible.
Professional correction
Invent every organization, identity, device, service, source, supplier, relationship, date, decision, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Detection and Scoping Package
Use only invented Northbridge information. Do not access, copy, sanitize, upload, investigate, query, test, contact, monitor, or modify any real alert, incident, identity, device, service, source, supplier, data set, organization, system, or person.
1
Establish the mission and boundary
Document fictional critical services, users, identity model, data, suppliers, dependencies, sources, privacy, continuity, and safety.
Required output
Detection and scoping mission charter.
Quality check
Every organization, identity, service, source, supplier, relationship, event, and outcome is invented.
2
Classify the initial signal
Decide whether evidence supports alert, event, issue, suspected incident, confirmed incident, or non-incident status.
Required output
Activation and classification record.
Quality check
Classification includes threshold, owner, next decision, and non-proof statement.
3
Build the evidence register
Record evidence ID, source, event time, collection time, processing time, observation, supports, limitations, health, owner, and use.
Required output
Evidence matrix and source-health map.
Quality check
Missing or degraded evidence never becomes absence.
4
Create the chronology
Order changes, approvals, sessions, alerts, reports, source-health transitions, decisions, actions, validation, and communications.
Required output
Multi-time chronology.
Quality check
Event, collection, processing, report, decision, action, validation, and communication remain distinct.
5
Map relationships
Connect identities, roles, groups, sessions, devices, services, destinations, data, users, suppliers, changes, sources, and dependencies.
Required output
Relationship map.
Quality check
Every relationship states evidence, confidence, and limitation.
6
Assign scope categories
Classify items as confirmed, possible, unaffected, unknown, excluded, or out of scope.
Required output
Entity and impact register.
Quality check
Unaffected requires Healthy evidence; Unknown requires an owner and next evidence.
7
Test hypotheses
Compare stale authority, service impact, supplier delay, approved change, data access, and device participation explanations.
Required output
Hypothesis and alternative matrix.
Quality check
Each hypothesis has supporting, contradicting, next evidence, owner, and status.
8
Version scope changes
Record trigger, evidence, source health, added or removed items, confidence, owner, severity, priority, response, and risk effects.
Required output
Scope-change log.
Quality check
Prior versions remain available for reconstruction.
9
Validate the scope
Run alert-only, Blind-source, dependency, user-report, change, second-service, recovery, time, unaffected, and portfolio cases.
Required output
Scope validation matrix.
Quality check
Validation protects against over-scoping and under-scoping.
10
Prepare the portfolio
Combine activation, evidence, chronology, relationships, entity register, hypotheses, versions, metrics, leadership brief, risk, and reflection.
Required output
Public-safe Detection and Scoping Package.
Quality check
No real alerts, identities, services, devices, suppliers, sources, timelines, or incidents appear.
Scenario Decision Lab
A Blind Data Source and No Data Alert
Fictional Northbridge has no data-access alert, but the required data-access source is Blind during the key period. The service handles protected student-support records.
Scenario Decision Lab
A Second Service Appears through a Shared Dependency
A fictional second service shares an identity dependency with the affected service. No direct session or impact evidence currently connects it to the incident.
Advanced Challenge
Defend Scope Version 1.5 before an Incident Review Board
Fictional Northbridge confirms one identity, one session, one service, and one destination. Two device categories, one supplier, and one user-impact report remain possible. Protected data is Unknown because the source is Blind. A partial approved-change alternative exists, broad impact is not confirmed, and several owners have open questions.
Defend activation
Explain why evidence supports incident coordination without claiming every incident dimension is confirmed.
Defend relationships
Explain identity, role, group, session, device, service, destination, data, supplier, user, and time connections.
Defend categories
Explain why each item is confirmed, possible, unaffected, unknown, excluded, or out of scope.
Defend chronology
Explain event, collection, processing, report, decision, action, validation, communication, and source-health times.
Defend hypotheses
Explain supporting, contradicting, alternative, missing, and next evidence for each scope theory.
Defend scope change
Explain versions, triggers, owners, severity, priority, containment, communication, recovery, closure, and reopen effects.
Challenge output
Produce a fictional activation decision, classification record, evidence register, source-health map, chronology, relationship map, ten-entity scope register, hypothesis matrix, alternative register, six-version change log, validation matrix, dashboard, owner-question register, communication update, leadership brief, residual uncertainty, residual risk, reopen triggers, and public portfolio boundary.
Defender Habits
Detection and Scoping Checklist
Check Your Understanding
A7.3 Mini Quiz: Detection and Scoping
Choose your answers first. Explanations appear only after submission.
1. What is the strongest first response to a fictional alert?
2. A fictional data-access source is Blind during the key period. Which category is strongest?
3. Which condition supports a fictional unaffected classification?
4. Why should a fictional supplier dependency not automatically enter confirmed affected scope?
5. What should a fictional scope-change log preserve?
6. A fictional user report appears near an identity event, but supplier delay is also present. What is strongest?
7. Which public portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Detection and Scoping Package for the Northbridge Student-Support Cooperative. Include mission, critical services, users, identity model, device categories, data categories, suppliers, dependencies, source inventory, privacy boundary, safety boundary, alert classification, event classification, issue classification, suspected-incident criteria, confirmed-incident criteria, non-incident criteria, activation decision, activation evidence, source health, owner, next decision, non-proof statements, identity scope, device scope, service scope, destination scope, data scope, user-impact scope, supplier scope, time scope, dependency scope, evidence-coverage scope, confirmed category, possible category, unaffected category, unknown category, excluded category, out-of-scope category, category evidence standards, reassessment, evidence IDs, source, event time, collection time, processing time, report time, decision time, action time, validation time, communication time, observation, supports, limitations, relationship map, identity-to-role relationship, identity-to-session relationship, session-to-service relationship, session-to-destination relationship, identity-to-group relationship, service-to-user relationship, service-to-supplier relationship, identity-to-device relationship, change-to-session relationship, service-to-data relationship, entity register, confidence, owners, next questions, chronology, scope hypotheses, supporting evidence, contradicting evidence, alternate explanations, next evidence, hypothesis status, scope version, scope-change trigger, category changes, source-health effect, severity effect, priority effect, containment effect, communication effect, recovery effect, closure effect, reopen effect, validation cases, scope metrics, leadership brief, residual uncertainty, residual risk, reopen triggers, reflection, and a statement that every organization, identity, device, service, source, supplier, relationship, event, date, decision, action, and outcome is invented.
Match each fictional scope conclusion to the exact evidence that supports it.
Use Unknown honestly when evidence cannot support confirmation or absence.
Distinguish dependency, relationship, activity, impact, authorization, data access, and incident effect.
Version scope changes and connect them to response decisions.
Keep the 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 Containment Strategy?
Rate your readiness from 1 to 5 for signal classification, activation, evidence, source health, chronology, relationships, scope categories, hypotheses, alternatives, scope changes, metrics, owner questions, communication, and complete fictionalization.
I can distinguish a fictional alert from a confirmed incident.
I can build a fictional evidence-based initial scope.
I can separate confirmed, possible, unaffected, unknown, excluded, and out-of-scope items.
I can avoid using alert silence as proof of unaffected status.
I can preserve fictional event and processing time separately.
I can version fictional scope changes and explain response consequences.
I can test fictional alternatives without forcing early certainty.
I can produce a safe fictional scope package without adapting real incident information.
Record one fictional confirmed item, one possible item, one Unknown item, one excluded alternative, one scope-change trigger, one source-health limitation, and one question for A7.4.
Key Takeaways
What You Should Remember
1.A fictional alert is a signal for review, not proof of an incident.
2.Detection and scoping should distinguish alert, event, issue, suspected incident, confirmed incident, source-health problem, and non-incident condition.
3.Fictional scope should cover identities, devices, services, destinations, data, users, suppliers, dependencies, time, and evidence coverage.
4.Confirmed, possible, unaffected, unknown, excluded, and out-of-scope categories require different evidence standards.
5.Unaffected requires relevant Healthy evidence; alert silence or missing records are not enough.
6.Unknown is a professional category when evidence is Blind, Degraded, conflicting, delayed, incomplete, or unavailable.
7.Chronology should preserve event, collection, processing, report, decision, action, validation, communication, and source-health timing.
8.Relationships and dependencies do not automatically prove activity, impact, authorization, data access, or incident effect.
9.Scope should change through versioned evidence-based decisions rather than remain frozen.
10.Every CyberShield scoping artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real incidents or systems.
Navigation
Continue Module A7
Next, learn how fictional responders compare identity, session, service, network, data, supplier, evidence, communication, and continuity containment options using authority, reversibility, validation, rollback, mission impact, and residual risk.