CySA+ v4 · Objective 3.2

Managing the incident lifecycle

Move an incident from preparation and triage to controlled recovery, using explicit authority, impact assessment, and evidence-based exit criteria.

What you will be able to do

  • Distinguish the purpose of each incident response stage.
  • Prioritise a developing incident using observed impact and credible exposure.
  • Choose containment and recovery gates that protect evidence and service continuity.
  • Convert post-incident findings into owned corrective actions.

Learn the concepts

  1. Lesson 1

    Prepare the team, then validate the signal

    An incident rarely arrives with a complete story or a convenient owner. Preparation supplies the authority and visibility that let responders make bounded decisions while the facts are still changing.

    Open lesson →
  2. Lesson 2

    Restore service without restoring the intrusion

    Stopping visible activity is only one milestone. Safe recovery requires removal of the cause, validation of the rebuilt service, and a deliberate decision about when normal access can resume.

    Open lesson →

Apply your judgement · Synthetic scenario

A restored server, an unfinished incident

A fictional appointment service loses availability after an unauthorised deployment. A clean replacement server is ready, but the deployment identity and recovery checks have not yet been reviewed. Operations wants the incident closed before the next booking window.

Confirmed activity
An unapproved package was deployed by svc-booking at 06:22 UTC; service errors began at 06:25.
Containment
The affected server is isolated; the deployment identity remains enabled.
Recovery state
Replacement server built from an approved image; booking test and credential rotation incomplete.
Business context
Bookings reopen in 45 minutes; a manual appointment list is available.

Your task

  1. Identify the current lifecycle activities and the unresolved access path.
  2. Define release criteria with technical and business checks.
  3. Propose a post-incident corrective action and validation method.
Compare your response

Containment is incomplete because the deployment identity may still affect the replacement. Continue analysis of its sessions and permissions; suspend or restrict the affected access through authorised procedures while preserving relevant audit records.

Before release, correct the deployment weakness, address exposed credentials and sessions, inspect the replacement configuration, and run the booking test. The incident lead and service owner should approve the release and monitoring plan; use the manual process if those gates are not met.

Investigate why an unapproved package passed deployment controls. Assign the platform owner a control improvement and validate it with an approved test that an unauthorised package is rejected and reported. Service restoration and corrective-action completion are distinct milestones.

Check your understanding

Choose the best response to each scenario, then check your reasoning. These are course practice questions.

1. An isolated laptop stops communicating, but the same account continues downloading files from a cloud service. Which action best addresses the containment gap?
2. A rebuilt business server passes a malware scan. The original configuration weakness and transaction tests have not been checked. What is the best release decision?
3. A review concludes that a temporary administrator account remained active after a project. Which follow-up most directly improves future preparation?

0 of 3 answered

← Course curriculumNext module: 3.3 →

Source reading: supplied book, chapters 9, 11. Lessons, scenarios, and questions are original CyberCorps course material.