Objective 3.2 · Lesson 1 of 2

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.

Prepare authority as well as tools

Preparation establishes who can declare an incident, isolate an asset, engage a supplier, or approve a disruptive recovery action. An incident response plan explains roles and escalation, while supporting playbooks describe repeatable actions for particular situations. Keep contact paths, emergency access, asset ownership, and evidence storage usable when the normal collaboration platform or identity service is itself affected.

Equipment and documents need rehearsal. A tabletop walks people through decisions and communication, revealing unclear authority or missing dependencies. A simulation also exercises selected technical actions in a controlled environment. Define the exercise scope and success criteria in advance. An impressive plan that nobody can find during an outage is less useful than a shorter plan that the team has practised.

Detection starts a question, not a verdict

Detection may begin with a person, a service failure, a third-party notification, or an automated alert. Preserve the original report and establish what it actually demonstrates. An unusual data transfer can reflect either unauthorised activity or a scheduled business process. Validation compares the signal with relevant baselines, approved changes, identity context, and independent telemetry rather than judging a single alert in isolation.

Triage determines which investigation needs attention first. Consider observed harm, the sensitivity and importance of affected services, the scope of access, and signs that activity is continuing. Confidence and severity are different: an uncertain report about a critical control system may justify urgent investigation. Use a provisional severity when necessary, record its basis, and reassess it as new facts arrive.

Analysis builds a revisable scope

Analysis connects events into a timeline and a working account of what happened. Start with known affected assets and identities, then examine credible links to other systems. Track confirmed scope separately from possible exposure. If a privileged account accessed five servers but only one has malicious artifacts, all five deserve assessment; that does not yet make five confirmed compromises.

Every significant decision should identify the supporting facts, remaining uncertainty, owner, and next review point. When evidence indicates active harm, authorised containment may proceed before the investigation is complete. Continue collecting and analysing during containment. The lifecycle is iterative: a newly discovered identity or persistent foothold can return the team to analysis after the initial response appeared successful.

Keep these points in mind

  • Preparation must establish decision authority, dependencies, and alternative contact paths.
  • Assess severity and confidence independently.
  • Keep confirmed compromise separate from systems that require investigation.

Pause and practise

A service owner says an unusual export is probably a routine job, but cannot identify a change record. Draft the next two analyst actions.

Show a worked response

Preserve the export and authentication records, then ask the owner to identify the job, authorised account, schedule, and expected data volume. Compare those details with the actual session and destination. Assign provisional priority based on service sensitivity and continuing activity; do not close the alert on an unsupported explanation.

Next lesson →
← Module overview