R — Review cause
Separate fictional trigger, immediate cause, root cause, contributing factor, control gap, and recovery complication.
High School AdvancedModule A7Lesson 5 of 10Cause, Clean State, Staged Recovery, Validation, and Reopening
A7.5 Eradication and Recovery Planning
Learn how fictional responders separate containment, cause correction, recovery preparation, staged restoration, validation, observation, rollback, owner acceptance, closure readiness, and reopening.
Lesson Progress
Eradication and Recovery Planning
High School Advanced • A7: Incident Response Lifecycle • Lesson 5 of 10
50% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Reachable Service Is Not Necessarily Recovered
Fictional Northbridge closes one stale session and restores the service. The page loads again, but the role lifecycle defect has not been corrected, the group source is Degraded, the data-access source is Blind, the supplier queue may contain duplicates, and critical users have not tested the workflow. The service is available, but the organization cannot yet defend a clean-state or recovery conclusion.
Weak recovery
“The service responds, so the incident is fixed.”
Strong recovery
“Cause correction, identity, configuration, data, supplier, source, user, monitoring, rollback, and acceptance gates must pass.”
Trusted recovery is a chain of evidence-supported decisions, not one successful service check.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Distinguish fictional containment, eradication, recovery preparation, restoration, validation, observation, closure readiness, and reopening without treating them as one step.
Objective 2
Build fictional eradication decisions from root-cause evidence, contributing factors, control gaps, ownership, dependencies, side effects, clean-state criteria, validation, rollback, and residual risk.
Objective 3
Design fictional staged recovery plans covering identity, sessions, configuration, service, data, suppliers, sources, monitoring, continuity, users, communication, and owner acceptance.
Objective 4
Evaluate fictional recovery readiness using clean-state gates, dependency gates, source-health gates, data-integrity gates, user-impact gates, rollback triggers, observation periods, and reopen criteria.
Objective 5
Create a portfolio-ready fictional Eradication and Recovery Planning Package containing a cause register, clean-state model, recovery waves, authority map, validation matrix, rollback plan, observation record, metrics, leadership brief, residual-risk record, and reflection.
Why This Matters
Recovery Decisions Change Trust, Mission, and Closure
Fictional recovery affects identities, users, services, protected data, suppliers, evidence, monitoring, continuity, risk, and future recurrence. Restoring too quickly can reintroduce the unsafe state. Restoring too broadly can create a large failure. Closing too early can hide Blind sources, unresolved debt, or delayed supplier and user effects.
Correct the supported cause
Fictional eradication targets an evidence-supported unsafe state rather than only its visible symptom.
Restore through gates
Fictional waves begin only when clean-state, dependency, monitoring, rollback, and owner conditions are ready.
Observe before closure
Fictional recurrence, delayed records, supplier queues, user effects, and residual risk remain visible.
Core Framework
The R-E-C-O-V-E-R Method
E — Establish clean state
Define fictional identity, session, configuration, service, data, supplier, source, dependency, monitoring, and business gates.
C — Choose correction
Select the fictional evidence-supported correction target, known-good replacement, authority, validation, and rollback.
O — Organize waves
Create fictional readiness, identity canary, function, user canary, expanded integration, and full-operation waves.
V — Validate outcomes
Confirm fictional expected state, source health, user effect, side effects, data integrity, suppliers, and owner acceptance.
E — Evaluate observation
Monitor fictional recurrence, delayed evidence, source recovery, user reports, dependencies, debt, and reopen triggers.
R — Record closure readiness
Document fictional acceptance, residual risk, corrective actions, communication, debt, observation, and authorized closure decision.
Decision-ready recovery statement
Fictional Northbridge will not restore broad access until the stale-role lifecycle cause is corrected, identity and group state reconcile, one canary session passes, the data limitation is accepted or resolved, supplier backlog is validated, and critical users complete the canary workflow.
Advanced Vocabulary
Terms for Eradication and Recovery Planning
Containment
A fictional authorized action that reduces current risk while investigation, eradication, and recovery continue.
Eradication
A fictional evidence-based process for removing or correcting the confirmed cause, unsafe condition, persistence point, control defect, stale authority, invalid configuration, harmful dependency, or other incident-enabling state.
Recovery preparation
A fictional planning phase that defines clean-state criteria, dependencies, owners, evidence, sequencing, validation, rollback, communication, monitoring, and acceptance before restoration begins.
Restoration
A fictional authorized process that returns identities, services, data, suppliers, sources, users, and workflows toward an approved operating state.
Validation
A fictional evidence-based check that eradication or restoration produced the intended state without unacceptable side effects.
Observation period
A fictional defined period after restoration during which responders monitor break conditions, source health, user impact, dependencies, and residual risk.
Closure readiness
A fictional state in which required evidence, owner acceptance, recovery obligations, residual risk, corrective actions, communication, and reopen triggers are complete enough for formal closure review.
Reopen trigger
A fictional new evidence, source recovery, recurring condition, validation failure, scope expansion, user impact, supplier issue, or control defect that returns a closed or closing case to active response.
Root cause
A fictional underlying condition whose correction materially reduces the chance that the same incident condition will recur.
Contributing factor
A fictional condition that increased likelihood, duration, scope, impact, uncertainty, or recovery difficulty but may not be the sole cause.
Trigger
A fictional event or condition that started or revealed the incident without necessarily being the underlying cause.
Control gap
A fictional missing, weak, stale, bypassed, misconfigured, untested, unowned, or poorly monitored safeguard relevant to the incident.
Clean state
A fictional evidence-supported condition in which identity, session, configuration, service, data, supplier, source, dependency, monitoring, and ownership requirements are satisfied for the stated recovery decision.
Known-good baseline
A fictional approved and evidence-supported reference state used to compare current identity, service, configuration, data, supplier, source, or workflow conditions.
Recovery wave
A fictional group of identities, functions, services, users, suppliers, data, or dependencies restored together under shared gates and monitoring.
Canary recovery
A fictional limited first restoration used to test assumptions, validation, monitoring, user impact, and rollback before broader recovery.
Rollback
A fictional approved path to reverse or replace a recovery step when clean-state, validation, continuity, source health, or monitoring fails.
Recovery dependency
A fictional identity, configuration, data, supplier, source, network relationship, user workflow, monitoring capability, owner, or approval needed before restoration.
Recovery owner
The fictional role accountable for planning, sequencing, executing, validating, documenting, and accepting a specific recovery area.
Business acceptance
A fictional owner decision that a restored service or workflow supports required mission outcomes within documented limitations.
Technical acceptance
A fictional owner decision that identity, service, configuration, data, dependencies, sources, and monitoring satisfy technical recovery gates.
Privacy acceptance
A fictional owner decision that data access, purpose, sharing, retention, exposure, and communication obligations are satisfied.
Recovery debt
Fictional unresolved temporary controls, missing automation, incomplete validation, stale dependencies, source limits, manual workarounds, untested rollback, or deferred redesign remaining after restoration.
Residual risk
The fictional risk remaining after eradication and recovery, including unresolved cause, scope, evidence, monitoring, supplier, privacy, continuity, or recurrence concerns.
Recovery freeze
A fictional pause in restoration caused by failed gates, worsening impact, conflicting evidence, Blind sources, rollback need, or missing authority.
Instructional Section 1
Separate Seven Lifecycle Stages
Containment
Purpose
Reduce fictional current risk and preserve decision options.
Key question
What must be limited now to reduce active or near-term harm?
Required evidence
Current scope, active state, source health, mission effect, authority, expected state, validation, rollback, and residual risk.
Exit gate
Risk is reduced enough for structured eradication and recovery work to continue.
Weak pattern
Calling containment a permanent fix.
Eradication analysis
Purpose
Determine which fictional cause, contributing factor, trigger, and control gap should be corrected.
Key question
What evidence-supported condition must change so the same incident state does not continue or recur?
Required evidence
Cause hypotheses, supporting and contradicting evidence, source health, owner review, dependencies, side effects, and alternatives.
Exit gate
The correction target, authority, validation, rollback, and residual risk are approved.
Weak pattern
Removing the most visible symptom without testing cause.
Eradication action
Purpose
Correct or remove the fictional confirmed unsafe condition.
Key question
Did the approved change remove the intended cause without creating unacceptable new risk?
Required evidence
Pre-action state, action record, source-side state, configuration, identity, data, supplier, service, dependency, and independent validation.
Exit gate
The intended cause or unsafe state is no longer present according to qualified evidence.
Weak pattern
Treating action completion as proof of eradication.
Recovery preparation
Purpose
Define fictional clean-state criteria, recovery waves, dependencies, owners, communication, monitoring, and rollback.
Key question
What must be true before each restoration step begins?
Required evidence
Known-good state, owner acceptance, continuity, source health, data integrity, supplier status, capacity, monitoring, and fallback.
Exit gate
Wave-specific entry criteria and authority are complete.
Weak pattern
Restoring first and deciding validation later.
Staged restoration
Purpose
Return fictional functions through limited, evidence-supported waves.
Key question
Can the smallest safe wave operate correctly before broader restoration?
Required evidence
Canary results, source health, service behavior, user impact, dependencies, data integrity, monitoring, owner review, and rollback readiness.
Exit gate
The current wave passes all required gates and the next wave is authorized.
Weak pattern
Restoring every user and dependency at once.
Observation
Purpose
Monitor fictional recurrence, side effects, user experience, source recovery, supplier behavior, data integrity, and residual risk.
Key question
Does the restored state remain trustworthy over the defined period?
Required evidence
Break conditions, alerts, source health, service metrics, user reports, owner review, dependency state, and corrective actions.
Exit gate
Observation criteria pass or the response rolls back, freezes, or reopens.
Weak pattern
Closing immediately after service availability returns.
Closure readiness
Purpose
Confirm fictional technical, business, privacy, evidence, communication, corrective-action, and risk obligations.
Key question
Is the response complete enough for formal closure while preserving reopen triggers?
Required evidence
Acceptance records, residual risk, debt, observation, source reconciliation, lessons, owners, dates, and reopen criteria.
Exit gate
Authorized closure decision or continued Conditional state.
Weak pattern
Closing because alerts became quiet.
Instructional Section 2
Build a Six-Part Cause Model
Trigger
Question
What fictional event or condition started or revealed the incident?
Fictional example
A temporary recovery role remained Active after its approved window.
Evidence needed
Event time, approval state, role state, session relationship, source health, and owner review.
Does not prove
The trigger does not automatically identify the deeper cause.
Immediate cause
Question
Which fictional condition directly enabled the observed incident state?
Fictional example
An active privileged session continued after approval expiration.
Evidence needed
Session, identity, role, destination, service, time, and source-side state.
Does not prove
The immediate cause may be one symptom of a larger lifecycle defect.
Root cause
Question
Which fictional underlying condition allowed the unsafe state to exist or recur?
Fictional example
Role expiration and active-session review were not linked to one owned lifecycle decision.
Evidence needed
Process design, ownership, approval, synchronization, session policy, monitoring, change history, exercises, and repeated conditions.
Does not prove
A root-cause statement must be tested rather than selected because it sounds plausible.
Contributing factor
Question
Which fictional condition increased duration, uncertainty, scope, impact, or recovery difficulty?
Fictional example
The group source was Degraded during effective-access validation.
Evidence needed
Source-health history, timing, alternate evidence, owner response, queue or synchronization behavior, and decision effect.
Does not prove
A contributing factor may not have caused the incident by itself.
Control gap
Question
Which fictional safeguard was missing, weak, stale, unowned, untested, or unable to support the decision?
Fictional example
No validated alert connected role expiration, group state, active sessions, owner acknowledgement, and break conditions.
Evidence needed
Detection logic, ownership, playbook, testing, alert quality, source health, escalation, and corrective-action history.
Does not prove
A control gap does not prove intentional bypass.
Recovery complication
Question
Which fictional dependency makes trusted restoration harder?
Fictional example
The data-access source is Blind and the supplier integration has delayed responses.
Evidence needed
Source recovery, supplier commitment, alternate evidence, data integrity, service dependency, backlog, and owner acceptance.
Does not prove
A complication may delay recovery without being part of the incident cause.
Instructional Section 3
Define Ten Clean-State Domains
Identity and access
Entry criteria
Fictional identity owner confirms current role, group, approval, sponsor, lifecycle state, effective access, emergency access, and session requirements.
Fictional evidence
Identity, role, group, approval, extension, sponsor, session, source-health, owner, and exception records.
Validation
Source-side state and independent review agree that only approved access remains.
Rollback trigger
Unexpected role, group, session, owner conflict, missing approval, or source-health degradation.
Owner
Identity owner and independent identity reviewer.
Sessions
Entry criteria
Fictional prior sessions are closed, reconciled, or explicitly accepted under current authorization.
Fictional evidence
Session IDs, identities, devices, services, destinations, start/end times, source health, and containment records.
Validation
No unexpected active session remains and approved new sessions follow current authorization.
Rollback trigger
Recurring stale session, unexplained continuation, conflicting source evidence, or unexpected destination.
Owner
Identity and service owners.
Configuration
Entry criteria
Fictional service and identity configuration match an approved known-good baseline or reviewed replacement state.
Fictional evidence
Configuration baseline, change history, owner approval, dependencies, exceptions, validation record, and source health.
Validation
Independent comparison shows expected values and no unexplained drift in the scoped area.
Rollback trigger
Validation mismatch, dependency failure, user-impact increase, or unexpected configuration change.
Owner
Service or technical owner with independent reviewer.
Service behavior
Entry criteria
Fictional critical functions, administrative functions, integrations, user paths, and error conditions are understood and testable.
Fictional evidence
Service health, functional checks, administrative state, user workflows, dependencies, monitoring, continuity, and owner acceptance.
Validation
Canary users complete intended tasks and unacceptable errors or side effects do not appear.
Rollback trigger
Critical function failure, unexpected administrative access, rising errors, or user-impact threshold breach.
Owner
Service and continuity owners.
Data integrity and privacy
Entry criteria
Fictional data categories, expected state, ownership, access, integrity, pending jobs, transfers, retention, and Blind periods are documented.
Fictional evidence
Data catalog, application records, access evidence, integrity checks, queue state, privacy review, alternate evidence, and source recovery.
Validation
Data state supports the required mission and privacy conclusions within documented limitations.
Rollback trigger
Integrity mismatch, unexplained access, exposure concern, pending transfer, or source evidence conflict.
Owner
Data owner and privacy reviewer.
Supplier and integration
Entry criteria
Fictional supplier status, service commitment, local dependency, data exchange, queue, fallback, owner, and recovery evidence are current.
Fictional evidence
Supplier notice, local integration state, data-flow record, backlog, contract expectation, owner communication, and validation.
Validation
The integration operates within accepted limits and local service behavior remains stable.
Rollback trigger
Supplier recurrence, queue growth, data mismatch, missed commitment, privacy concern, or service degradation.
Owner
Supplier relationship and service owners.
Evidence sources
Entry criteria
Fictional decision-critical sources are Healthy or their limitations are explicitly accepted for the recovery wave.
Fictional evidence
Freshness, completeness, schema, parser, queue, timing, coverage, conflict, Blind period, recovery, and alternate evidence.
Validation
Required sources support the wave's identity, service, data, user, supplier, and monitoring decisions.
Rollback trigger
Source becomes Blind, Degraded, Conflicting, or unable to support a required gate.
Owner
Source owners and evidence coordinator.
Dependencies
Entry criteria
Fictional identity, service, infrastructure, data, supplier, communication, continuity, monitoring, and recovery dependencies are available or have approved fallbacks.
Fictional evidence
Architecture, service catalog, owner statements, source health, supplier state, capacity, fallback, and test record.
Validation
Required dependencies remain stable throughout the wave.
Rollback trigger
Dependency loss, capacity failure, conflicting state, or fallback failure.
Owner
Technical, service, continuity, and supplier owners.
Monitoring and detection
Entry criteria
Fictional monitoring can observe the expected state, break conditions, recurrence signals, user effect, source health, and recovery milestones.
Fictional evidence
Detection logic, dashboards, source health, alert routing, owners, thresholds, validation cases, and escalation.
Validation
Test signals produce expected visibility and ownership without unsupported certainty.
Rollback trigger
Blind monitoring, missed break condition, duplicate noise, unowned alert, or failed source test.
Owner
Detection and incident-response owners.
Business and user acceptance
Entry criteria
Fictional critical users, accessibility needs, alternate workflows, communication, capacity, deadlines, and expected limitations are understood.
Fictional evidence
User tests, continuity metrics, queue, support reports, communication, service-owner review, and leadership decisions.
Validation
Critical users complete essential tasks within accepted quality and timing limits.
Rollback trigger
Critical user failure, unacceptable backlog, accessibility issue, conflicting guidance, or mission threshold breach.
Owner
Service, continuity, and business owners.
Instructional Section 4
Evaluate Ten Eradication Criteria
Cause confidence
Decision question
How strongly does fictional evidence support the proposed root cause or unsafe condition?
Fictional evidence
Cause hypotheses, supporting and contradicting records, source health, chronology, repeated patterns, owner review, and alternatives.
Weak pattern
Selecting a cause because it matches the alert title.
Correction precision
Decision question
Can the fictional correction target the cause without unnecessarily changing unrelated identities, services, data, suppliers, or workflows?
Fictional evidence
Scope version, relationship map, known-good state, dependencies, expected unaffected population, and side-effect review.
Weak pattern
Replacing or resetting everything because the exact cause is uncertain.
Authority
Decision question
Who may approve, execute, validate, accept side effects, and accept remaining risk?
Fictional evidence
Decision-rights matrix, owner charters, emergency exception, leadership threshold, privacy authority, and service authority.
Weak pattern
The technical operator also approves and validates every high-impact change.
Evidence preservation
Decision question
Will the fictional correction alter or remove evidence still needed for cause, scope, accountability, privacy, or lessons?
Fictional evidence
Evidence register, preservation obligations, pre-action state, source behavior, retention, privacy, and owner review.
Weak pattern
Removing the suspected cause before preserving decision-critical evidence.
Dependency effect
Decision question
Which fictional identity, service, data, supplier, source, user, continuity, monitoring, or recovery dependency could the correction change?
Fictional evidence
Architecture, service catalog, supplier map, data flow, source map, owner review, and fallback.
Weak pattern
Correcting one component without understanding its mission and recovery relationships.
Known-good replacement
Decision question
What fictional approved state will replace the unsafe state?
Fictional evidence
Baseline, configuration, identity model, owner approval, version, validation, and expiration.
Weak pattern
Removing a condition without defining the intended replacement state.
Validation
Decision question
What fictional source-side, service-side, data-side, user-side, and independent evidence will prove correction?
Fictional evidence
Expected state, source health, functional checks, owner acceptance, monitoring, and negative side-effect checks.
Weak pattern
Treating a completed change request as eradication success.
Rollback
Decision question
How will fictional response reverse or replace the correction when validation, continuity, or scope changes?
Fictional evidence
Prior state, rollback authority, dependencies, data integrity, service state, monitoring, and restoration gates.
Weak pattern
Calling a correction reversible without a tested path.
Recurrence prevention
Decision question
Which fictional lifecycle, monitoring, ownership, approval, source, playbook, or architecture changes reduce recurrence?
Fictional evidence
Control-gap register, corrective actions, owner, due date, validation, exercise, alert quality, and governance review.
Weak pattern
Correcting one case while leaving the systemic condition unchanged.
Residual risk
Decision question
Which fictional cause, factor, scope, evidence, supplier, privacy, source, monitoring, or redesign gaps remain?
Fictional evidence
Residual-risk statement, owner, authority, duration, compensating controls, review date, and reopen trigger.
Weak pattern
Describing eradication as complete resolution of every risk.
Instructional Section 5
Design Six Recovery Waves
Wave 0 — Evidence and readiness
Scope
Fictional evidence sources, owners, known-good state, rollback, communication, monitoring, and continuity preparation.
Entry criteria
Containment is stable enough to plan; urgent evidence-preservation obligations are complete.
Fictional actions
Reconcile sources, approve clean-state criteria, verify authority, define canary group, confirm fallbacks, and test visibility conceptually.
Validation
Required owners acknowledge gates and decision-critical sources are Healthy or explicitly qualified.
Rollback
Recovery remains frozen; containment continues.
Exit criteria
Wave 1 is authorized with documented residual risk.
Wave 1 — Identity and session canary
Scope
One fictional approved recovery identity, current role, limited session, and required owner coverage.
Entry criteria
Identity, role, group, approval, sponsor, session, source-health, and rollback gates pass.
Fictional actions
Restore the minimum approved identity capability and open one monitored canary session.
Validation
Effective access, session state, destination boundaries, monitoring, and owner acceptance match the known-good design.
Rollback
Close the canary session and return to scoped containment.
Exit criteria
Identity and session gates remain stable through the canary observation period.
Wave 2 — Administrative function
Scope
One fictional limited administrative feature required for recovery or urgent support.
Entry criteria
Wave 1 passes and the service configuration, identity, evidence, continuity, and monitoring gates are ready.
Fictional actions
Restore the narrow administrative function for the approved identity and purpose.
Validation
Function works, unrelated functions remain limited, evidence stays visible, and no unacceptable user effect appears.
Rollback
Disable the restored function and return to the prior known-good state.
Exit criteria
Technical and service owners accept the function state.
Wave 3 — Critical user workflow
Scope
A small fictional canary group of critical student-support users.
Entry criteria
Identity, function, data, supplier, source, continuity, privacy, capacity, and communication gates pass.
Fictional actions
Restore essential user workflow to the canary population with clear guidance and support.
Validation
Users complete essential tasks, data remains consistent, suppliers and dependencies remain stable, and monitoring sees expected behavior.
Rollback
Return canary users to the alternate workflow.
Exit criteria
Business, privacy, technical, and continuity owners accept the canary result.
Wave 4 — Expanded users and integrations
Scope
Broader fictional user population and approved supplier integration.
Entry criteria
Canary users pass, backlog is controlled, supplier evidence is current, and data reconciliation is complete enough.
Fictional actions
Expand access in bounded groups and restore the integration under monitored limits.
Validation
Capacity, queue, user experience, data flow, supplier behavior, privacy, source health, and alerts remain within thresholds.
Rollback
Pause the integration and return affected users to the prior recovery wave or alternate workflow.
Exit criteria
Service and supplier owners accept the expanded state.
Wave 5 — Full approved operation
Scope
All fictional approved users, functions, integrations, sources, and support workflows.
Entry criteria
Earlier waves pass; residual risk is accepted; recovery debt, observation, communication, and reopen triggers are documented.
Fictional actions
Restore remaining approved functions and retire temporary workarounds in a controlled sequence.
Validation
Technical, business, privacy, evidence, supplier, monitoring, and continuity acceptance are complete.
Rollback
Freeze or return to the last accepted wave when break conditions occur.
Exit criteria
Observation period begins; formal closure is not yet automatic.
Instructional Section 6
Assign Eight Recovery Decision Paths
| Decision | Recommends | Approves | Executes | Validates | Accepts impact | Escalates when |
|---|---|---|---|---|---|---|
| Approve fictional eradication target | Incident lead, technical owner, identity owner, service owner, or privacy owner | Owner with authority over the cause or unsafe state | Authorized operator | Independent technical or domain reviewer | Service, continuity, data, supplier, or leadership owner | Cause confidence, blast radius, policy exception, or mission effect exceeds delegated authority. |
| Approve known-good baseline | Technical, identity, data, service, or supplier owner | Configuration or service authority | Not an execution action; baseline is recorded and versioned | Independent reviewer and relevant business owner | Service or business owner | No trusted reference exists or the replacement requires major redesign. |
| Start a fictional recovery wave | Recovery owner with incident lead | Wave-specific technical, service, continuity, privacy, or supplier authority | Authorized recovery operator | Independent technical reviewer plus affected owners | Business or service owner | Critical users, protected data, supplier dependency, or broad mission impact is involved. |
| Freeze fictional recovery | Any owner observing a required gate failure | Incident or recovery lead within plan | Authorized recovery operator | Independent reviewer confirms the freeze and preserved state | Service and continuity owners | Freeze creates major or prolonged mission interruption. |
| Roll back a fictional wave | Technical, service, privacy, supplier, continuity, or monitoring owner | Recovery owner within rollback authority | Authorized operator | Independent reviewer and affected owners | Service or business owner | Rollback threatens data integrity, supplier obligations, or critical mission. |
| Accept a fictional recovered state | Technical, service, privacy, continuity, supplier, and evidence owners | Named recovery acceptance authority | Not an execution action; acceptance is recorded | Independent governance review | Business or leadership owner | Required acceptance domains disagree or evidence remains materially Blind. |
| Accept fictional residual risk | Incident, recovery, technical, service, privacy, supplier, or monitoring owner | Documented risk authority | Not an execution action; conditions and owners are recorded | Independent governance review | Named risk owner | Risk exceeds delegated threshold or lacks a time-bounded mitigation plan. |
| Declare fictional closure readiness | Incident lead | Closure authority defined by the response plan | Case manager records the decision | Technical, business, privacy, evidence, communication, and recovery reviewers | Leadership or designated incident authority | Observation, source reconciliation, corrective actions, or reopen criteria remain incomplete. |
Instructional Section 7
Validate Twelve Recovery Scenarios
| Case | Type | Fictional input | Expected result | Quality protected |
|---|---|---|---|---|
| REC-T01 | Containment mistaken for eradication | A fictional privileged session is closed, but the stale role lifecycle defect remains. | Keep eradication open and correct the evidence-supported lifecycle cause. | Cause accuracy |
| REC-T02 | Action completed | A fictional configuration change request is marked complete, but source-side state is not validated. | Keep eradication Conditional until expected state is independently supported. | Outcome validation |
| REC-T03 | Blind source | A decision-critical fictional source remains Blind before a recovery wave. | Freeze or narrow the wave unless the limitation is explicitly accepted with alternate evidence. | Source-health honesty |
| REC-T04 | No known-good state | The fictional team cannot identify an approved replacement configuration. | Do not restore broadly; define and approve the intended state first. | Baseline quality |
| REC-T05 | Canary failure | One fictional canary user experiences critical workflow failure. | Freeze expansion, investigate the side effect, and roll back or revise the wave. | Staged recovery |
| REC-T06 | Supplier queue | A fictional integration restores, but queued work duplicates records. | Freeze the integration, preserve queue evidence, reconcile data, and use rollback. | Data integrity |
| REC-T07 | Role and group conflict | The fictional role source is clean, but the group source shows unexpected effective access. | Keep identity recovery Conditional and reconcile the conflict. | Access integrity |
| REC-T08 | Service available | The fictional service responds, but monitoring, data, source, and business acceptance are incomplete. | Do not declare recovered or close the case. | Multi-domain acceptance |
| REC-T09 | Observation recurrence | A fictional stale session reappears during observation. | Trigger rollback or renewed containment and reopen the cause analysis. | Recurrence response |
| REC-T10 | Temporary workaround aging | A fictional manual continuity process remains after full restoration. | Record recovery debt, assign owner, validate retirement, and track risk. | Lifecycle governance |
| REC-T11 | Closure pressure | Leadership requests closure before source reconciliation and residual-risk acceptance. | Present the missing gates and maintain Conditional closure readiness. | Evidence-based closure |
| REC-T12 | Public portfolio | A student plans to sanitize a real recovery architecture and clean-state checklist. | Fail portfolio validation and invent every organization, system, owner, dependency, action, and outcome. | Confidentiality and safety |
Instructional Section 8
Measure Eight Recovery Outcomes
Time to approved eradication target
Review question
How long does fictional response take to move from competing cause hypotheses to an approved correction target?
Fictional evidence
Cause register, source health, owner review, alternatives, decision time, authority, and evidence quality.
Limitation
Faster selection can increase the chance of correcting the wrong condition.
Eradication validation quality
Review question
What percentage of fictional corrections have source-side, independent, service, data, user, supplier, and monitoring validation?
Fictional evidence
Expected state, validation records, source health, reviewer, side effects, rollback, and residual risk.
Limitation
High validation coverage does not guarantee the root cause was correct.
Recovery-wave pass rate
Review question
How often do fictional canary and expansion waves meet every required gate without rollback or freeze?
Fictional evidence
Wave entry, validation, failures, user impact, source health, supplier state, data integrity, and owner acceptance.
Limitation
A low pass rate may show strong gates catching real problems.
Rollback readiness
Review question
What percentage of fictional recovery waves have approved prior state, criteria, authority, dependencies, execution owner, and validation?
Fictional evidence
Rollback plans, conceptual tests, owner acknowledgement, monitoring, and recovery-wave records.
Limitation
A documented rollback can still fail when conditions change.
Time to trusted service
Review question
How long does fictional recovery take from containment stability to multi-domain accepted operation?
Fictional evidence
Wave times, technical acceptance, business acceptance, privacy acceptance, source health, supplier state, and observation.
Limitation
Speed alone does not measure recovery quality.
Recovery side-effect rate
Review question
How often do fictional restoration waves create unexpected identity, service, data, supplier, user, evidence, or monitoring effects?
Fictional evidence
Validation, user reports, data reconciliation, source health, rollback, scope changes, and corrective actions.
Limitation
Expected tradeoffs should not be counted as defects.
Observation recurrence rate
Review question
How often do fictional break conditions or related unsafe states recur during observation?
Fictional evidence
Alerts, source health, sessions, user reports, service behavior, supplier state, and reopen records.
Limitation
A recurrence may be unrelated and still deserve review.
Recovery-debt aging
Review question
How long do fictional temporary controls, manual workarounds, source gaps, monitoring gaps, supplier limits, or deferred redesign remain open?
Fictional evidence
Debt item, owner, mission effect, risk, due date, dependency, validation, escalation, and closure.
Limitation
Some long-lived debt may be formally accepted.
Fictional Recovery Architecture
Northbridge Cause-to-Recovery Model
This conceptual architecture is completely invented and intentionally non-operational. It teaches recovery decision quality without real identities, systems, services, configurations, data, suppliers, sources, incidents, or restoration procedures.
Cause inputs
Trigger, immediate cause, root cause, factors, control gaps
State inputs
Identity, session, configuration, service, data, supplier
Evidence inputs
Provenance, chronology, source health, alternatives, limitations
Mission inputs
Users, continuity, privacy, dependencies, owners, risk
Fictional Recovery Core
Correct
Evidence-supported cause and known-good replacement
Gate
Identity, service, data, supplier, source, monitoring
Sequence
Readiness, canary, function, users, integration, full
Authorize
Recommend, approve, execute, validate, accept
Validate
Expected state, side effects, user effect, integrity
Roll back
Prior wave, authority, triggers, dependencies
Observe
Recurrence, source recovery, supplier, users, debt
Close
Acceptance, residual risk, communication, reopen triggers
Technical output
Clean state, validated waves, rollback, monitoring
Mission output
Critical workflows, user acceptance, continuity
Leadership output
Cause, progress, decisions, debt, residual risk
Portfolio boundary
Fully fictional, privacy-safe, defensive, non-operational
Fake Dashboard
Fake Northbridge Eradication and Recovery Dashboard
Fictional cause confidence, clean-state readiness, recovery-wave progress, validation quality, source limitations, observation, recovery debt, and closure readiness.
Current fictional recovery state
Wave 1 Conditional
Identity canary is prepared, but group evidence is Degraded and the data-access source remains Blind.
Clean-state gates passing
7 / 10
Identity, sessions, configuration, service, dependencies, monitoring, and continuity pass; data, supplier, and source gates remain incomplete.
Open fictional recovery debt
9
Lifecycle redesign, group reconciliation, data-source recovery, supplier queue, canary completion, rollback test, user acceptance, observation, and risk acceptance remain open.
Fake SOC Alert
Recovery Expansion Blocked by Failed Clean-State Gates
Source: Fake Northbridge Recovery Coordination Console • Time: 11:18 AM
The fictional service is reachable and one identity canary is ready, but group evidence is Degraded, protected-data evidence is Blind, the supplier queue has not been reconciled, and critical-user acceptance is incomplete.
Defensive recommendation: Keep fictional recovery at Wave 1. Complete source, data, supplier, and user gates or obtain explicit qualified risk acceptance before any bounded expansion.
Fake Log Panel
Fake Eradication and Recovery Timeline
training-log-viewer.log
09:37 CONTAINMENT session='closed' 09:45 CAUSE trigger='role-expiration' 09:52 CAUSE root='lifecycle-ownership-gap' 10:05 CORRECTION target='role-session-linkage' 10:15 BASELINE identity='approved' 10:18 SOURCE group='degraded' 10:20 SOURCE data='blind' 10:24 SUPPLIER queue='unreconciled' 10:35 WAVE readiness='conditional' 10:50 WAVE identity-canary='prepared' 11:02 VALIDATION service='pass' 11:05 VALIDATION users='pending' 11:10 CLEAN-STATE pass='7-of-10' 11:18 ALERT expansion='blocked'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What Recovery Evidence Supports—and What It Does Not Prove
REC-E01
Fictional containment record
Observation
One privileged session was closed under identity-owner authority.
Supports
Immediate session risk was reduced.
Does not prove
Does not prove the stale role lifecycle cause was removed.
Recovery use
Keep cause analysis and identity recovery gates open.
REC-E02
Fictional role and approval evidence
Observation
Temporary role remained Active after approval_end.
Supports
The stale-authority condition is confirmed.
Does not prove
Does not prove why lifecycle enforcement failed.
Recovery use
Test ownership, synchronization, session, and monitoring hypotheses.
REC-E03
Fictional group-source health
Observation
Group evidence is Degraded during the relevant period.
Supports
Effective-access validation is limited.
Does not prove
Does not prove group state was safe or unsafe at every moment.
Recovery use
Keep identity recovery Conditional and assign source reconciliation.
REC-E04
Fictional service health
Observation
The service remains available with no broad error increase.
Supports
Broad active disruption is not confirmed.
Does not prove
Does not prove clean configuration, data integrity, authorization, or user acceptance.
Recovery use
Use service availability as one gate, not the recovery conclusion.
REC-E05
Fictional data-source state
Observation
The data-access source is Blind for the key period.
Supports
Data access and historical integrity remain Unknown.
Does not prove
Does not prove access or no access.
Recovery use
Require alternate evidence, privacy review, source recovery, and historical reassessment.
REC-E06
Fictional supplier notice
Observation
Supplier integration reports delay and possible queue backlog.
Supports
Supplier recovery and data reconciliation are required dependencies.
Does not prove
Does not prove the supplier caused the incident.
Recovery use
Use a bounded supplier wave with queue and integrity validation.
REC-E07
Fictional approved change
Observation
Recovery change matches identity and purpose but not time or destination.
Supports
A partial alternative explanation exists.
Does not prove
Does not fully explain the post-expiration session.
Recovery use
Preserve the alternative but do not close cause analysis.
REC-E08
Fictional monitoring review
Observation
No validated signal currently connects role expiration, group state, active sessions, and owner acknowledgement.
Supports
A detection and lifecycle control gap may exist.
Does not prove
Does not prove a single monitoring defect caused the incident.
Recovery use
Create a corrective action and validate it through fictional tests.
Analyze the Evidence
Which Recovery Decision Is Best Supported?
The confirmed privileged session is closed.
The stale-role lifecycle cause has an approved correction target.
Identity and session canary preparation is complete.
Group evidence remains Degraded.
The protected-data source remains Blind.
The supplier queue is unreconciled.
Critical-user acceptance has not occurred.
Seven of ten clean-state domains currently pass.
Which fictional recovery decision best fits the current Northbridge evidence?
Common Mistakes
Avoid Ten Eradication and Recovery Errors
Containment is called eradication
Fictional observation
A fictional team closes one session and says the root cause is removed.
Impact
The stale role, lifecycle ownership, group state, monitoring, or approval defect may remain.
Professional correction
Separate immediate risk reduction from cause correction and recurrence prevention.
The first plausible cause becomes the root cause
Fictional observation
A fictional responder blames one person or tool without testing alternatives.
Impact
Corrective work may target the wrong condition and encourage unfair conclusions.
Professional correction
Use supporting, contradicting, source-health, owner, repeated-pattern, and alternative evidence.
Action completion becomes eradication success
Fictional observation
A fictional change request closes without source-side or independent validation.
Impact
The unsafe state may remain or side effects may be missed.
Professional correction
Define expected state, qualified evidence, independent review, side-effect checks, and rollback.
Service availability becomes recovery
Fictional observation
A fictional service responds, so the case is marked recovered.
Impact
Identity, configuration, data, supplier, source, monitoring, user, and privacy gates may remain incomplete.
Professional correction
Require multi-domain clean-state and owner acceptance.
Everything restores at once
Fictional observation
A fictional team restores all users, functions, identities, and integrations in one step.
Impact
Failures have a large blast radius and are harder to isolate or roll back.
Professional correction
Use canary and bounded recovery waves with entry, validation, rollback, and exit gates.
Blind evidence is ignored
Fictional observation
A fictional recovery wave proceeds even though a required source is Blind.
Impact
The team cannot prove expected state or detect recurrence.
Professional correction
Freeze, narrow, or formally accept the limitation with alternate evidence and risk authority.
Rollback is written after failure
Fictional observation
A fictional recovery wave fails before anyone defines the prior state or restoration path.
Impact
The team may be unable to return safely to the last accepted state.
Professional correction
Design rollback before authorization and preserve its dependencies.
Observation is skipped
Fictional observation
A fictional case moves from service restoration directly to closure.
Impact
Recurrence, delayed source records, supplier queues, user problems, and data issues may appear later.
Professional correction
Use a defined observation period with break conditions and reopen triggers.
Recovery debt disappears
Fictional observation
Fictional temporary controls and manual workarounds are left undocumented after restoration.
Impact
Residual risk becomes invisible and the temporary state may become permanent.
Professional correction
Create a recovery-debt register with owner, due date, risk, validation, and escalation.
Real recovery details enter the portfolio
Fictional observation
A student sanitizes a real clean-state checklist, architecture, supplier dependency, or rollback plan.
Impact
Sensitive systems, authorities, dependencies, response capabilities, and incidents may remain identifiable.
Professional correction
Invent every organization, identity, service, source, supplier, baseline, action, owner, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Eradication and Recovery Planning Package
Use only invented Northbridge information. Do not access, copy, sanitize, upload, test, restore, replace, reconfigure, validate, monitor, or investigate any real identity, service, configuration, data set, supplier, source, organization, system, or person.
1
Define the fictional recovery mission
Document critical services, users, identities, data, suppliers, dependencies, sources, continuity, privacy, evidence, containment, and safety boundaries.
Required output
Eradication and recovery mission charter.
Quality check
Every organization, system, role, source, supplier, action, and outcome is invented.
2
Build the cause register
Separate fictional trigger, immediate cause, root cause, contributing factor, control gap, recovery complication, supporting evidence, contradicting evidence, and alternatives.
Required output
Cause and control-gap register.
Quality check
Cause statements are testable, evidence-based, and non-blaming.
3
Select the correction target
Compare fictional cause confidence, precision, authority, preservation, dependencies, known-good replacement, validation, rollback, recurrence prevention, and residual risk.
Required output
Eradication decision record.
Quality check
The selected target changes the supported cause rather than only the visible symptom.
4
Define clean-state criteria
Create fictional identity, session, configuration, service, data, supplier, source, dependency, monitoring, and business gates.
Required output
Clean-state matrix.
Quality check
Every gate names evidence, owner, validation, rollback trigger, and limitation.
5
Build recovery waves
Create fictional readiness, identity canary, function, user canary, expanded integration, and full-operation waves.
Required output
Recovery-wave plan.
Quality check
Each wave has entry, action, validation, rollback, exit, communication, and residual risk.
6
Assign authority
Document who recommends, approves, executes, validates, accepts mission effect, accepts privacy or data state, and accepts residual risk.
Required output
Recovery authority matrix.
Quality check
High-impact decisions use separation of duties.
7
Prepare validation and rollback
Record fictional pre-action state, expected state, source-health requirements, functional checks, side effects, prior accepted wave, rollback, and monitoring.
Required output
Validation and rollback package.
Quality check
Action completion cannot equal success without qualified evidence.
8
Run recovery validation cases
Test fictional cause, Blind source, baseline, canary failure, supplier queue, access conflict, service availability, observation recurrence, debt, closure pressure, and portfolio scenarios.
Required output
Recovery validation matrix.
Quality check
Cases protect against premature restoration and closure.
9
Observe and decide closure readiness
Monitor fictional recurrence, source recovery, user effect, supplier behavior, data integrity, corrective actions, residual risk, debt, and reopen triggers.
Required output
Observation and closure-readiness record.
Quality check
Closure remains Conditional until required acceptance and risk gates are complete.
10
Prepare the portfolio package
Combine mission, cause, clean state, waves, authority, validation, rollback, observation, metrics, debt, leadership brief, risk, and reflection.
Required output
Public-safe Eradication and Recovery Planning Package.
Quality check
No real architecture, identities, systems, suppliers, recovery procedures, or incidents appear.
Scenario Decision Lab
The Service Is Reachable but Clean-State Gates Are Incomplete
Fictional Northbridge can reach the service again. Identity and configuration gates pass, but the data-access source is Blind, supplier backlog is unreconciled, and critical users have not completed the workflow.
Scenario Decision Lab
A Canary Wave Reveals a Critical Workflow Failure
One fictional canary user can sign in, but the critical student-support submission workflow fails and creates an inconsistent queue state.
Advanced Challenge
Defend a Recovery Expansion Decision before a Readiness Board
Fictional Northbridge has corrected the stale-role lifecycle design, closed the confirmed session, prepared an identity canary, and restored service availability. Group evidence remains Degraded, protected-data evidence remains Blind, the supplier queue is not reconciled, critical-user acceptance is incomplete, and observation has not begun. Leadership asks whether full restoration can start.
Defend the cause
Explain the fictional trigger, immediate cause, root cause, contributing factors, control gaps, recovery complications, and alternative explanations.
Defend clean state
Explain fictional identity, session, configuration, service, data, supplier, source, dependency, monitoring, and user gates.
Defend the recovery wave
Explain fictional entry criteria, canary scope, actions, validation, rollback, exit criteria, communication, and owner acceptance.
Defend source-health decisions
Explain fictional Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering evidence effects on recovery confidence.
Defend observation and reopening
Explain fictional recurrence signals, delayed evidence, user reports, supplier queues, source recovery, rollback, and reopen triggers.
Defend residual risk
Explain fictional unresolved data, supplier, monitoring, debt, redesign, owner, authority, duration, compensating controls, and review.
Challenge output
Produce a fictional cause register, correction decision, known-good baseline, ten-domain clean-state matrix, six recovery waves, authority map, source-health decision, canary plan, validation record, rollback plan, user and supplier acceptance, observation plan, break conditions, reopen criteria, recovery metrics, debt register, residual-risk statement, leadership brief, closure-readiness decision, and public portfolio boundary.
Defender Habits
Eradication and Recovery Planning Checklist
Check Your Understanding
A7.5 Mini Quiz: Eradication and Recovery Planning
Choose your answers first. Explanations appear only after submission.
1. Which statement best distinguishes fictional containment from eradication?
2. A fictional service responds again, but data, source, identity, and business gates are incomplete. What is strongest?
3. Why use a fictional canary recovery wave?
4. A required fictional source is Blind before a wave. What is strongest?
5. Which statement makes a fictional root-cause conclusion strongest?
6. What should happen when a fictional canary wave fails a critical-user gate?
7. Which public portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Eradication and Recovery Planning Package for the Northbridge Student-Support Cooperative. Include mission, critical services, users, identity model, data categories, suppliers, dependencies, source inventory, privacy boundary, safety boundary, containment state, trigger, immediate cause, root cause, contributing factors, control gaps, recovery complications, supporting evidence, contradicting evidence, alternative explanations, source health, owner review, cause confidence, correction target, correction precision, authority, evidence preservation, dependency effect, known-good replacement, validation, rollback, recurrence prevention, residual risk, identity clean state, session clean state, configuration clean state, service clean state, data clean state, supplier clean state, source clean state, dependency clean state, monitoring clean state, business clean state, entry criteria, evidence, owner, validation, rollback trigger, readiness wave, identity canary wave, administrative-function wave, critical-user wave, expanded-user and supplier wave, full-operation wave, scope, actions, exit criteria, recommendation owner, approval owner, executor, independent validator, business acceptance, technical acceptance, privacy acceptance, risk acceptance, recovery freeze authority, rollback authority, closure-readiness authority, validation cases, recovery metrics, time to eradication target, validation quality, wave pass rate, rollback readiness, time to trusted service, side-effect rate, observation recurrence rate, recovery-debt aging, canary result, supplier reconciliation, data integrity, source reconciliation, user acceptance, observation period, break conditions, reopen triggers, corrective actions, recovery debt, residual-risk statement, leadership brief, closure-readiness decision, reflection, and a statement that every organization, identity, service, configuration, data category, source, supplier, dependency, baseline, action, owner, date, and outcome is invented.
Separate fictional containment success from root-cause correction and trusted recovery.
Require fictional clean-state evidence across technical, data, supplier, monitoring, user, privacy, and continuity domains.
Use fictional canary and staged recovery waves to limit the blast radius of failed assumptions.
Keep fictional closure Conditional until observation, source reconciliation, acceptance, debt, residual risk, and reopen triggers are complete.
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 Stakeholder Communication?
Before moving to A7.6, rate your readiness from 1 to 5 for lifecycle separation, cause analysis, known-good state, clean-state gates, recovery waves, authority, source health, canary validation, rollback, user acceptance, supplier reconciliation, observation, closure readiness, debt, residual risk, reopening, and complete fictionalization.
I can explain why fictional service availability is not the same as trusted recovery.
I can separate fictional trigger, cause, factor, control gap, and recovery complication.
I can define fictional clean-state evidence across ten domains.
I can design fictional canary and staged recovery waves.
I can freeze or roll back fictional recovery when a required gate fails.
I can require fictional technical, business, privacy, supplier, source, and risk acceptance.
I can use fictional observation and reopen triggers before closure.
I can produce a safe fictional recovery package without adapting real recovery architecture or procedures.
Record one fictional root cause, one clean-state gate, one canary wave, one failed-gate response, one rollback trigger, one observation condition, one residual-risk owner, and one question you will carry into A7.6.
Key Takeaways
What You Should Remember
1.Fictional containment reduces current risk, while eradication corrects the evidence-supported cause or unsafe state.
2.Fictional recovery preparation defines clean state, dependencies, owners, sequencing, validation, rollback, communication, monitoring, and acceptance before restoration.
3.Trigger, immediate cause, root cause, contributing factor, control gap, and recovery complication are different conclusions.
4.Action completion and service availability do not prove fictional eradication or trusted recovery.
5.Identity, session, configuration, service, data, supplier, source, dependency, monitoring, and business domains require separate clean-state gates.
6.Fictional canary and staged recovery waves limit the blast radius of failed assumptions.
7.Blind, Degraded, Conflicting, or Recovering sources must change fictional recovery confidence and may block or narrow a wave.
8.Rollback should be designed before every fictional recovery wave and preserve the prior accepted state.
9.Observation, delayed evidence, source reconciliation, debt, residual risk, owner acceptance, and reopen triggers belong before closure.
10.Every CyberShield recovery artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real recovery capabilities.
Navigation
Continue Module A7
Next, learn how fictional incident teams communicate facts, uncertainty, scope, impact, decisions, containment, recovery, privacy, user guidance, supplier coordination, leadership needs, correction, and next-update commitments to different stakeholders.