Incident Response and Digital Forensics

Incident response and digital forensics. This is the final lesson of the course, and it draws together threads from every domain: a plan tested in advance, a disciplined order, evidence handled soundly, and learning fed back.

The scene. An alert fires: something is spreading across the network. The team’s response is improvised, there is a plan somewhere but no one has run it. In the rush, they wipe and rebuild the first infected machine to get it back fast, which destroys the only record of how the attacker got in. No one documented what was touched. They stopped this machine, maybe, but they cannot say how far it spread, cannot prove what happened, and are no better prepared for next time.

Incident response follows a sequence, and the exam cares about the order. First, preparation: the plan, the team, the tools, in place before anything happens. Improvising during an incident is the failure the scenario opens with.

Second, detection and identification: recognising that an incident is occurring and understanding its scope, the monitoring from the previous lesson.

And third, containment: stopping the spread and limiting the damage, for example by isolating affected systems. This is the immediate priority once an incident is detected.

The most tested point in the order is containment before eradication: when a breach is spreading, you stop it spreading first, then clean up. Chasing attribution, rebuilding everything, or issuing public statements ahead of containment all let the damage grow. Stop the bleeding, then treat the wound.

After containment come the rest of the phases. Eradication: removing the cause, the malware, the foothold, the vulnerability. Recovery: restoring systems to normal, often from the tested backups of Domain four, and confirming they are clean. And then the post-incident review.

Now the team’s forensic failure. Their instinct to wipe and rebuild the first machine destroyed the evidence. Digital evidence is fragile and easily altered, so forensics rests on preserving the original: work on copies or forensic images, not the live original, and verify integrity with a hash, from the cryptography lesson, so you can prove the copy matches and nothing changed.

Around this sits the chain of custody: a documented, unbroken record of who collected, held and handled each piece of evidence, and how. It preserves the evidence’s integrity and admissibility, so it can be trusted and, if it comes to it, stand up in legal proceedings. This is the evidence-reliability discipline from Domain one, made literal: evidence you cannot vouch for the handling of is evidence you may not be able to use. Wiping the machine destroyed both the evidence and the chain.

The final phase, the post-incident review, or lessons learned, is where the incident becomes improvement. Once resolved, the team looks back: what allowed this, how did the response go, what should change, and feeds the answers into stronger controls and a better plan. It is the same instinct as problem management in Domain four: address the underlying cause so the next incident is prevented or handled better.

And like every plan in this course, the incident response plan must be tested, not just written, the same lesson as the untested D-R plan and the unexercised continuity plan. A plan first run during a real incident is the scenario you do not want.

So carry this away, and it closes the course. Contain before you eradicate, preserve the original with an unbroken chain of custody, and review afterwards so the organisation is stronger next time. Across five domains, one habit runs through everything: reason from the control, not the memorised list. That completes the CISA course. Well done.