Incident evidence handoff: separate observations from conclusions

What you will practise

• Write an observation without silently upgrading it to a confirmed cause.
• Link each important statement to an evidence ID and source limitation.
• Choose a next verification that discriminates between plausible explanations.
• Hand off to a named role without claiming containment or authority you do not have.

The case: an export request with incomplete visibility

Fictional Eastbank Tools supplies a selected six-item evidence extract. You are a read-only triage analyst; a senior incident responder owns containment and provider changes. Your job is a useful handoff, not a declaration of breach or clearance. All times in this exercise use UTC; the extract has no guaranteed complete event history.

A vendor account signed in from an unfamiliar address and requested an export. The visible job failed, but a sensor outage and unchecked retries leave gaps. A maintenance email is a lead to verify independently, not proof. Record the situation as a possible account-misuse investigation with incomplete visibility.

Use four different labels

Observation: a fact in the supplied evidence, with its source ID. Hypothesis: an explanation that could account for facts but needs testing. Unknown: a material question the available records cannot answer. Action: a bounded verification or authorized response owned by a role.

For example, H1 shows a recorded successful login. Account misuse is one hypothesis; approved vendor work is another. H4 adds context but cannot authenticate itself. H2 shows an export request, while H3 shows one failed execution. Neither supports saying that all customer records were stolen.

Do not collapse these labels into a dramatic narrative. A summary that hides unknowns can make the next analyst act on an invented certainty. A concise handoff can still be decisive: state what warrants investigation and who should investigate it.

A next check should be specific enough to return a useful result. “Investigate everything” does not name a source, window or decision. Request job history for J42 and linked retries, with status, output reference and the record collection window. If that source is unavailable, record the failed verification and keep delivery status unknown. If the source returns no matching output, disclose its coverage before treating the absence as meaningful. The receiving responder can then decide whether the coverage is sufficient for the operational question.

Preserve the evidence boundary

Reference source IDs, UTC timestamps, collection window, system origin and known gaps. Keep original evidence separate from your interpretation. If an evidence item changes, record the revision rather than silently rewriting the old handoff. Never paste API keys, private customer payloads or unrestricted personal data into the summary.

H5 is a coverage gap. No network record during a collection outage is not evidence that nothing moved. H6 is untrusted content to analyze, not an instruction to execute. Escalation should preserve relevant text without obeying it or sharing credentials.

In this learning exercise, evidence IDs are traceability labels, not cryptographic provenance. The table does not establish complete chain of custody, actor identity or a real incident. Use the senior responder’s approved procedures for any real investigation.

Choose a discriminating next check

A useful next step resolves uncertainty that matters to the decision. Ask an authorized responder to inspect export job history, retry identifiers and output-storage audit records for the defined window. That helps distinguish a failed request from a later completed delivery. Verify expected maintenance through an independently established vendor channel and its approved scope.

The response owner may need to assess containment while evidence is gathered. As the fictional read-only analyst, you can request that decision, not promise account disablement. Avoid asking the suspicious message for permission or using a newly supplied contact as the sole identity check.

This supports the course’s Observe Before You Explain, Triage and Respond, and Hand Off the Incident modules. It does not award a credential, establish incident experience, or turn this worksheet into an official response policy.

A good handoff also makes continuation cheap. Put the highest-consequence unresolved question near the top, list checks already completed, and distinguish planned checks from returned evidence. A second analyst should not repeat your read merely because you omitted it, or assume a suggested check succeeded because it appears in an action list. When new evidence arrives, append its identifier and explain exactly which conclusion changes.

Worked handoff: useful uncertainty

Scope: selected Eastbank evidence H1–H6,09:02–09:11 UTC; network collection unavailable09:03–09:08 UTC. H1 records a vendor-account login; H2 records export request J42; H3 records a timeout for that job. We have not checked retries or output storage, so successful data delivery remains unknown.

Assessment: possible vendor-account misuse or expected maintenance. H4 is an unverified maintenance claim. Neither account ownership nor exfiltration is confirmed. H6 contains suspicious credential-sharing instructions and was not followed.

Requested action: senior incident responder to review job/retry/output evidence and independently verify vendor maintenance; assess any containment under approved authority. Handoff owner: triage analyst. Receiving-role acknowledgment: pending. Next review: after those bounded checks return, not a fabricated deadline or completed response.

Put it into practice

Scope/window:
Observed evidence IDs:
Hypotheses:
Unknowns and coverage:
Bounded next check:
Decision/action owner:
Receiving acknowledgment:
Revision/new evidence:

Download the practice files

• fictional-eastbank-evidence.csv
• incident-handoff-template.txt

Review your reasoning

Try the exercise first, then open these self-review hints. They are guidance, not an assessment result.

Independent learning, clear boundaries

Original independent READY learning. Not official Google or Coursera training, not endorsed by either provider, and not a Google Professional Certificate, READYScore exam, certification or credited course completion. All case data are fictional. Writing is self-reviewed, not automatically graded. This public resource has no account save, submission or reward function.

These exercises use fictional examples. They do not replace production authorization, provider credentials, professional advice or certification requirements.

Official references

• NIST SP 800-61 Revision 3, final April 3, 2025

  Incident analysis, evidence documentation and response coordination principles. The Eastbank case, role restriction, template and thresholds are original, not NIST-prescribed procedures.