Sign In
In this section

0.7 Exercise: Plan the Investigation

Module 0

Introduction

Module 0's exercise is the first piece of work on the case: an investigation plan, written before anything is collected. It is the plan an investigator sends the person who commissioned the work, saying what will be collected, from where, in what order and why, and it is the document the rest of the course carries out.

Module 2 collects what it names; Module 10's report answers the questions it maps.

From the reports to a plan Two reports WS-114 and WS-031 Four hosts what each holds Investigation plan questions, hypotheses, order, limits To Priya Raman before collection starts Nothing has been collected yet. The plan decides what will be, and why.

By the end of this lesson you can:

  • Map each of the investigation's questions to the hosts and the kinds of evidence that could answer it.
  • Write competing hypotheses that each name the evidence that would support or rule them out.
  • Order a collection by what each host stands to lose.
  • State the limits of a plan before any evidence exists.
1

The Request

understand: what Priya Raman has asked for

At 09:30 on Thursday 12 March, Priya Raman assigned the investigation to you. Before anyone touches a machine, she wants your plan. She has to tell Northgate Engineering's management what is being done, what it will cover and what it will not, and she needs it in writing.

From:     Priya Raman, IT Security Manager
To:       Investigator
Sent:     Thursday 12 March 2026, 09:30
Subject:  NGE-WS-031: investigation plan before anything is touched

Before anyone touches a machine, send me your plan for the investigation.

I need what you will collect, from which hosts, in what order, and why.
I need how each of my five questions will be answered, and what you think
may have happened. And I need what we will not be able to tell, so nobody
is surprised later.

One page, please. I brief management at 14:00.

Priya

The request is ordinary and it is important. An investigation that starts collecting without a plan collects whatever is in front of it, which on 12 March means the two machines in the reports.

A plan forces the questions first: what are we trying to establish, where could the answers be, and what will be gone if we wait. It also gives Priya something to hold you to. And it gives you something to hold yourself to.

Three weeks into an investigation, when the evidence has taken you somewhere unexpected, the plan shows what you set out to establish and whether you have. A question that has quietly dropped out of the work is easy to see against the plan and almost impossible to see without it.

Plan before you collect: the plan decides what evidence exists to analyze, and evidence you did not plan for is often gone by the time you look.

Write it as you would for Priya: plainly, briefly, with no claim the evidence cannot yet support. She will read it in a few minutes and rely on it when she briefs management.

2

The Task

do: six parts on one page

The plan has six parts, and each answers something Priya asked. The questions part shows how each of her five questions will be answered. The hypotheses part says what you think may have happened, in a form the evidence can test. Scope and order say what you will collect and when. The time basis and limits keep the plan honest.

The plan: six parts, one page
Questionseach of the five, mapped to hosts and kinds of evidenceQ1 to Q5
Hypothesesat least two that explain the reports, each with what supports it and what rules it outtwo or more
Scopeevery host in scope with its reason, including any no report namesfour hosts
Orderfirst to fourth, by what each host stands to loseloss
Timethe time basis, and what you will check on each host's clockUTC
Limitswhat the plan cannot establish yet, and what would change ithonesty

One page is a real constraint. It forces you to decide what matters: a plan that lists every artifact Windows records is a reference, not a plan, and Priya cannot use it. Name kinds of evidence, give one reason for each decision, and leave the detail to the modules that teach it.

A reason is the part Priya will use. "Collect DC-01 first" is an instruction; "collect DC-01 first because its logs are overwritten fastest" is a decision she can explain to someone else, and challenge if she knows something you do not, such as a log retention setting longer than the default.

Keep the plan to one page of decisions, each with its reason: a plan that lists everything decides nothing.

The plan contains no findings, because there is no evidence yet. Everything in it is a question, a hypothesis or a decision about where to look.

3

What You Have to Work From

understand: what is known on 12 March

You have the two reports, Priya's five questions and what you learned about the hosts in 0.3. That is everything known on the morning of 12 March. Nothing has been collected, nobody has examined either machine, and neither Laura Brennan nor Kieran Ashworth has been interviewed beyond what the reports say.

Everything known on 12 March
Laura Brennan's ticketa "broken PDF" on WS-114, closed as user errorreport0.2
Tom Hale's notean unknown task and service on WS-031; nothing changed, patching stoppedreport0.2
Priya Raman's five questionsthe terms of referencescope0.2
The four hoststheir roles, their users, what a collection from each will holdestate0.3
Evidencenone: nothing has been collectednot yet

Work only from those. You have read the case outline in this module and you know that the course goes on to find an intrusion, but the plan is written as of 12 March, by an investigator who does not know what the evidence will show.

A plan that already knows the answer is not a plan; it is a conclusion, and the exercise is to write one that would hold up whichever way the evidence fell.

Write the plan from what was known on 12 March only: a plan that already knows the answer cannot be tested by the evidence.

If you find yourself writing a fact you could only know from later in the course, turn it into a hypothesis with the evidence that would test it. This is harder than it sounds, and it is the same discipline a real investigation needs.

Investigators often arrive with a theory from the first report, a colleague's guess or a similar case last month, and the plan is where that theory is written down as one possibility among several, with the evidence that would prove it wrong.

4

The Deliverable: An Investigation Plan

understand: the shape of the plan

The plan has six headed parts, in the order below. A short table works well for the questions; two or three lines each for the hypotheses; one line per host for the order.

Write it in the template, incident-investigation-plan.docx, and keep the finished plan with your case notes, where Module 2 will pick it up. The template's sections are the plan's parts, with grey guidance to delete as you write and yellow cells to fill:

incident-investigation-plan.docx
Case, prepared for, prepared by, date, statusthe header Priya reads firstheader
1. Questions and evidenceone row per question: hosts, kinds of evidencetable
2. Hypothesesone row each: the hypothesis, supported by, ruled out bytable
3. Scope and collection orderone row per host: order, role, reasontable
4. Time basisone or two sentencestext
5. Limitsthree or four linestext
6. ApprovalPriya signs it off before collection startssign-off

The hardest part is usually the hypotheses. Two reports from two people on two days invite a single story connecting them, and the plan's job is to keep that story at the level of a hypothesis, set beside an alternative, until the evidence decides between them.

The second hardest is the order: the instinct is to start where the first report pointed, and the better reason is what each host stands to lose.

Hold at least two hypotheses and order the collection by what each host stands to lose: those are the two decisions plans most often get wrong.

When you have a draft, mark it against the criteria below before you look at the model plan.

5

Acceptance Criteria

check: what a good plan does

Mark your plan against each criterion as Met, Partly or Not met, strictly, as 0.6 described. As you mark each one, the feedback shows how the model plan meets it and where plans most often fall short. The model plan opens when every criterion is marked.

Acceptance criteria Accept the plan before you send it

Mark each criterion against your own plan. Be strict: a criterion half met is Partly, not Met.

  1. Answerable. Every one of the five questions is mapped to at least one host and a kind of evidence that could answer it.

    How the model meets itEach question has a row naming the hosts and the evidence. Question 4, whether data left, points at the file server, where the data lives, and at removable media and network logons on the workstations, because how data could leave is as much a question as whether it did.

    Where plans most often failPlans map the questions they have leads for and leave question 4 or 5 with nothing beside it. A question with no route to an answer is a gap to state, not one to skip.

  2. Competing. At least two hypotheses explain the reports, each with evidence that would support it and evidence that would rule it out.

    How the model meets itThe model holds two hypotheses: the reports are connected, one intrusion that began with the file on WS-114 and moved to WS-031; and the reports are unrelated, a user error on WS-114 and an administrator's own unrecorded change on WS-031. Each names what would confirm or exclude it.

    Where plans most often failPlans state one story as the plan, usually the connected one, and then look only for evidence that fits it. The unrelated explanation is the one Tom Hale's and the service desk's own conclusions suggest, and it has to be ruled out, not ignored.

  3. Complete scope. All four hosts are in scope, with a reason for each, including the two neither report names.

    How the model meets itWS-114 and WS-031 are in scope because the reports name them; FS-01 because it holds the Engineering share, the data the business most needs to protect, and an administrator account can reach it; DC-01 because every logon on the domain is verified there, so it is where accounts and hosts meet.

    Where plans most often failPlans collect the two hosts in the reports and stop. The file server and domain controller are not named, which is the reason to look: the reports describe only what two people happened to notice.

  4. Ordered for loss. The collection order is justified by what each host stands to lose, not by the order of the reports.

    How the model meets itDC-01 first, because a domain controller's Security log is the busiest on the network and the oldest records are overwritten first. WS-031 second, because it is waiting to be patched and rebooted. FS-01 third, a busy server whose logs also roll. WS-114 last of the four, in daily use, its user activity growing on top of the old.

    Where plans most often failPlans collect in the order the reports arrived, WS-114 first because its report came first. Order collection by what is being lost and how fast; the reports' order says nothing about that.

  5. Kinds of evidence, not tools. Evidence is named as what Windows records (logons, execution, persistence, file activity, user activity, removable media), not as a list of tools.

    How the model meets itThe model names kinds of evidence: logon and authentication records, execution records, persistence (tasks, services, Run values), file system activity, user activity (shortcuts, recent files, folders opened), removable media records, and the event logs that record each. Tools come in Modules 2 to 8.

    Where plans most often failPlans list KAPE and a set of EZ Tools and call that the evidence. A tool processes evidence; the plan has to say what the evidence is and why it would answer the question.

  6. Time basis. The plan works in UTC and checks each host's clock and time zone before relying on its times.

    How the model meets itThe model works in UTC throughout, notes that Birmingham is on UTC in March, and checks each host's time zone setting and clock against a reference before comparing times across hosts.

    Where plans most often failPlans say nothing about time, or assume every host's clock was right. A cross-host timeline is only as good as the clocks it is built from, and question 5 asks how sure we are.

  7. Honest limits. The plan states what it cannot establish yet and contains no finding presented as fact.

    How the model meets itThe model states that the collections will be triage collections, not full disk images; that no email, proxy or network device logs are in scope; that the domain controller's logs may already have rolled past 10 March; and that the plan will change if either hypothesis is ruled out.

    Where plans most often failPlans write "the attacker used adm.kashworth" or "the PDF was malicious" as if it were known. On 12 March neither is: both are hypotheses, and a plan that states them as facts has already decided the answer.

The model plan opens when all 7 criteria are marked.

The model plan

  • Questions and evidence. Q1, how they got in and where: WS-114 (the file Laura opened, what ran after it) and WS-031 (how the task and service got there). Q2, which accounts and where: logon and authentication records on every host, especially DC-01. Q3, what they did on each host: execution, persistence, file and user activity on all three Windows hosts collected in full. Q4, whether data left: file activity on FS-01, removable media and network access records on the workstations. Q5, when and how sure: every time converted to UTC, with its source and its precision.
  • Hypothesis A: one intrusion. The file on WS-114 ran something that gave an attacker a way into WS-031. Supported by: a program running from an unusual place on WS-114 shortly after the file was opened; a logon to WS-031 from WS-114; the task and service created during that logon. Ruled out by: nothing running after the file was opened, and no connection between the two hosts.
  • Hypothesis B: two unrelated events. The PDF was simply broken, and the task and service on WS-031 were made by an administrator and not recorded. Supported by: no execution after the file was opened; the task and service created in Kieran Ashworth's own session, matching a change he can explain. Ruled out by: the evidence that would support A.
  • Scope and order. 1. NGE-DC-01: the authentication trail, and its Security log rolls fastest. 2. NGE-WS-031: the reported persistence, and a machine waiting for a patch and a reboot. 3. NGE-FS-01: the data the business most needs to protect, reachable by an administrator account, its logs also rolling. 4. NGE-WS-114: the reported file, in daily use.
  • Time basis. All times in UTC. Birmingham is on UTC in March. Each host's time zone and clock are checked before its times are compared with any other host's.
  • Limits. Triage collections, not disk images. No email, proxy or network device logs in scope. The domain controller's logs may already have rolled past 10 March. The plan changes if either hypothesis is ruled out, or if a fifth host appears in the evidence.

The model plan is one plan that meets the criteria, not the only one. Yours may order two hosts differently or frame the hypotheses differently, and still meet every criterion if each decision has a reason that holds. What matters is that every question has a route to an answer, no story is assumed, and the collection order protects what is being lost.

Mark your plan against every criterion before you read the model: the criteria are the standard, and the model is one plan that meets them.

Keep your plan. Module 2 collects the hosts it names, and you will check, in Module 10, which of its hypotheses the evidence supported.

Practice

Two pieces of practice. The first is the decision plans most often get wrong, made with the data an investigator would have on the morning of 12 March: the state of each host's Security log and what each machine is about to do. Decide the collection order before you write it into the plan.

The second is the plan itself, written in the template. When you have marked it, compare it with the completed model.

Do this Write the investigation plan

A written exercise: no VM needed. Write it in incident-investigation-plan.docx and keep it with your case notes from 0.6.

  1. Re-read the two reports. In 0.2, line by line: what each says, and what each does not establish.
  2. List what each host could tell you. From 0.3: the role, the users, and what a collection from it will hold.
  3. Map the five questions. For each, the hosts and the kinds of evidence that could answer it.
  4. Write two hypotheses. One that connects the reports and one that does not, each with what would support it and what would rule it out.
  5. Order the hosts. By what each stands to lose and how fast, then state the time basis and the limits.
  6. Accept it. Mark the plan against the criteria in section 5, fix what falls short, then read the model plan.
What you should end up with: a one-page investigation plan in your case notes, which Module 2's collections carry out and Module 10's report answers against.

Files this lesson draws on

The two reports and the terms of reference are in 0.2 The Incident as Reported; the hosts, their users and what each collection holds in 0.3 The Hosts and the People; marking and case notes in 0.6 Ground Truth and Checking Your Work.

© 2026 Ridgeline Cyber Defence™. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
← Previous Next →