Chapter 4 — Academic writing | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["4.1 Claims, evidence and warrants"]
  N2["4.2 Four labels"]
  N3["4.3 Calibrated uncertainty"]
  N4["4.4 Citation and verifiability"]
  N5["4.5 Audience and structure"]
  N6["4.6 Revision"]
  N7["4.8 Practical activity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["4.1 Claims, evidence and warrants"]
  N2["4.2 Four labels"]
  N3["4.3 Calibrated uncertainty"]
  N4["4.4 Citation and verifiability"]
  N5["4.5 Audience and structure"]
  N6["4.6 Revision"]
  N7["4.8 Practical activity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes and connection]
    |
    v
[4.1 Claims, evidence and warrants]
    |
    v
[4.2 Four labels]
    |
    v
[4.3 Calibrated uncertainty]
    |
    v
[4.4 Citation and verifiability]
    |
    v
[4.5 Audience and structure]
    |
    v
[4.6 Revision]
    |
    v
[4.8 Practical activity]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes and connection

You will be able to (1) distinguish a claim from the evidence offered for it; (2) express uncertainty with calibrated language instead of hedging everywhere; (3) cite sources so a reader can verify them; and (4) revise a text for its audience. Chapter 1 made claims precise; this chapter makes them readable and checkable by others. The skill returns in every report you write, from a shift handoff (Chapter 26 of the technologist book covers handoffs operationally) to the thesis in Chapter 40.

4.1 Claims, evidence and warrants

A claim is a statement you want the reader to accept. Evidence is what you observed or what a source recorded. A warrant is the reasoning that connects them. In "The account was compromised (claim) because it signed in from two countries ten minutes apart (evidence), which is physically impossible for one person (warrant)", the warrant hides assumptions: that both sign-ins were interactive, that the location data is accurate, that no VPN or shared credential explains the pattern. Good academic writing makes the warrant visible so that a reader can attack it.

4.2 Four labels

Throughout this book we label sentences in working notes as observation (what a named source recorded), inference (what you conclude and under which assumptions), decision (what someone chose to do) and unknown (what is not yet established). The labels do not need to appear in a polished report, but every sentence in the report should be traceable to one of them.

In the rcp-07 summary, "the API logged 4,100 requests" is an observation, "the session belonged to rcp-07" is an observation from a second source, "whether the account was misused" is an unknown, and "revoked at 09:40" is a decision. Labelling in this way exposes sentences that fit no label, which are usually opinions that need either evidence or deletion before the note goes further.

4.3 Calibrated uncertainty

Uniform hedging ("it may possibly suggest") is as unhelpful as overconfidence. Use a small vocabulary consistently and define it: confirmed (directly recorded by a reliable source, independently checked), likely (several independent indications, no strong contrary evidence), possible (consistent with evidence but alternatives remain), unknown. State what would change the assessment. Intelligence analysis has long used such scales; the point for you is consistency, not a particular wording.

Calibration also needs a note of what moved the estimate. If "possible" becomes "likely" between two updates, the reader should see which new indication caused the change. Avoid numbers that look more precise than the evidence allows; "likely" is honest where "78 per cent" would be invented.

4.4 Citation and verifiability

Cite so that a reader can find the exact source: author or organization, title, version or date, and a stable identifier (DOI or official URL). Cite primary sources for factual claims: the NIST publication, not a blog summarizing it. Distinguish a source's finding from your interpretation of it. When a document is superseded — NIST SP 800-61 Revision 3 (April 2025) superseded Revision 2 — say which version you used.

In a working incident note, internal sources need the same care as publications: name the log, its system, the query used and the time range, so that "API log" in the rcp-07 summary can be traced to one export rather than to someone's memory of a screen. When a source cannot be shared with the reader, say so and state who can verify it on request.

4.5 Audience and structure

Write for a named reader. An executive needs the decision required, impact, confidence and next update time in the first paragraph. A technical reviewer needs method, sources and limits. A common structure for incident summaries is: bottom line; what is known (with sources); what is not known; what is being done; when the next update comes.

The executive version of the rcp-07 summary follows this order: what may have happened, what was done, what is not known, and when the next update arrives. A technical reviewer reading the same incident would instead want the log names, the query window and the sample of 20 responses. Writing both from one set of labelled notes keeps them consistent with each other.

4.6 Revision

Revise in passes: first for claims and evidence (does every claim have support?), then for structure (does the reader get what they need first?), then for language (shorter sentences, active voice, defined terms). Ask a peer to mark every sentence they could not verify.

A useful final pass reads the text aloud as the named reader would. For the rcp-07 summary that means asking whether a clinic manager would know what to do before 12:00. Keep earlier versions; comparing drafts shows which claims were weakened or strengthened and why, which matters if the summary is later reviewed after the incident closes.

4.7 Worked example (synthetic): two summaries

Fictional. Summary A: "Attackers breached the booking system and stole patient data. The situation is under control." Summary B: "At 09:12 the booking API logged 4,100 requests for appointment records from one session (API log, observation). The session belonged to the receptionist account rcp-07 (IdP log). We have not established whether the account was misused or a scheduled export ran (unknown). The session was revoked at 09:40 (decision). Records returned contained names and appointment times (API response sample of 20). Next update 12:00."

A makes two unsupported claims ("attackers", "stole") and one vague one ("under control"). B is longer but every sentence is traceable. A revised executive version of B: "Possible bulk access to appointment records (names and times) via one staff account between 09:12 and 09:40; session revoked; cause not yet established; privacy team engaged; next update 12:00."

4.8 Practical activity

Take a published incident report from a public source and highlight each sentence as observation, inference, decision or unknown. Count how many claims cite a source.

Choose a report long enough to contain at least twenty sentences, so the counts mean something. Record the proportion of each label and note which sentences you could not classify, because those are usually the vague ones. Then rewrite the opening paragraph so that its first sentence states the decision or finding a reader needs most. Compare your rewrite with the original and note what you had to remove or move to make it work. Finally, list any claim whose source you could not locate within ten minutes; such claims are unverifiable for an ordinary reader, whatever their truth.

4.9 Common errors and limits

Stating inferences as observations ("the attacker used…").
Citing secondary summaries for primary facts; citing without version.
Burying the decision the reader must make.
Writing about a person's guilt; incident reports describe actions and accounts, not culpability, which belongs to authorized processes.
Hedging every sentence, so the reader cannot tell the solid findings from the guesses.
Using "confirmed" for a single source that nobody has checked independently.
Mixing audiences in one paragraph, with log identifiers interrupting the executive summary.
Omitting the next update time, which leaves readers to chase the team for news during the incident.

Exercises — chapter 4

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX010 — Label the sentences. Inputs: Summary A and B in §4.7. Steps: label every sentence; list the unsupported claims. Rubric: 3 = all labels defensible, unsupported claims listed with what evidence would support them; 2 = one mislabel; 1 = labels absent; 0 = none.

EX011 — Rewrite with calibration. Inputs: "It appears the server may have possibly been infected by ransomware which seems to have encrypted some files." Steps: rewrite using the confirmed/likely/possible/unknown scale and add what would change the assessment. Rubric: 3 = one calibrated term per claim, observations separated, change condition stated; 2 = calibration uneven; 1 = still hedged throughout; 0 = none.

EX012 — Citation repair. Inputs: "According to NIST, incidents should be handled in four phases (NIST, website)." Steps: identify the problems and write a correct, verifiable citation, noting what changed in Revision 3. Rubric: 3 = identifies missing document/version, cites SP 800-61 Rev. 3 with URL and date, notes that Rev. 3 organizes recommendations around CSF 2.0 functions rather than the Rev. 2 four-phase life cycle; 2 = citation correct, change missed; 1 = vague; 0 = none.

Chapter synthesis

Make the warrant visible, label observations, inferences, decisions and unknowns, use a small defined uncertainty scale, cite primary sources with version, and write the reader's decision first.