What you should avoid when writing an occurrence report

Outline (skeleton)

• Hook: Occurrence reports aren’t just boxes to tick; they’re the narrative that guides security response and investigations.

• Core rule: In an occurrence report, personal opinions have no place.

• Why opinions cause trouble: Bias, misinterpretation, and credibility gaps.

• What to include for clarity: Facts, times, locations, systems, people involved, evidence, and chain-of-custody.

• How to structure it: Chronological order, logical arrangement, clear sections that flow.

• Language that helps, not harms: Neutral tone, precise terms, objective descriptions; examples of biased versus objective phrasing.

• Practical tips and a simple template: checklists, revisions, privacy considerations, and a compact sample outline.

• Close: Credibility through objectivity, and the value of a clean, well-structured report.

Occurance reports with a clear head and a steady hand: why avoiding personal opinions matters

Let’s set the scene. In security-related work, an occurrence report is more than a narrative. It’s a document that supermarkets a sequence of events, signs, and evidence so others can understand what happened, why it happened, and how to respond. In Ontario security testing contexts, these reports help teams coordinate remediation, track behavior, and support any later analysis or investigations. The one rule that keeps the report trustworthy and useful is simple: avoid personal opinions.

Yes, you read that right. Personal opinions have a sneaky way of creeping in. A comment like “I feel this incident was caused by sloppy protocol” isn’t just opinion—it's a layer of bias that can tilt interpretation. When readers come from different roles—IT, security, legal, management—biased language can muddy the facts, slow down decisions, and even complicate investigations. So the big takeaway is this: an occurrence report should present what happened, not what you think about it.

What to avoid (and why)

• Personal opinions: This is the heart of the matter. Opinions color judgment and can obscure what actually occurred. They create doubt about the writer’s objectivity and escalate disagreements about root cause or impact.

• Speculation about causes: Jumping to conclusions without evidence wastes time and can derail root-cause analyses.

• Loaded adjectives that imply blame: Words like “careless,” “negligent,” or “incompetent” shift focus from facts to intent. Save judgments for the conclusions section, if needed, and only when supported by evidence.

• Ambiguity: Saying “a problem occurred” without specifics leaves readers guessing. Names, timestamps, systems, and actions taken are essential.

• Irrelevant impressions: If you weren’t directly involved, keep to what you can verify or document. The point is to be precise, not to air every thought.

Let me explain with a simple contrast. A biased line like, “The user ignored the warning,” presumes motive and responsibility. A fact-based line would be, “On 2024-09-14 at 14:22, the system generated alert A-204; user X acknowledged the alert at 14:26 but proceeded to access restricted file Y.” The second version sticks to verifiable events and leaves motive out of it—precisely what you want.

What to include to keep things crisp and credible

• Facts first: Gather what actually happened. Include date, time, and time zone. Note where the incident occurred, what systems or devices were involved, and what the user or operator did.

• Roles and entities: List who was involved, who detected the incident, who responded, and who reviewed the report. If somebody wasn’t present, don’t imply their involvement.

• Sequence of events: Build a chronological timeline from detection to resolution. Readers should be able to follow the incident step by step.

• Evidence and artifacts: Attach logs, screenshots, alerts, alarm history, and other tangible proof. Record where evidence is stored and how it’s preserved.

• System and environment details: Identify affected assets, configurations, versions, and network context. Include any relevant hashes, IDs, or asset tags.

• Impact and scope: Describe the measurable effects—downtime, data exposure, access changes—without sensational language.

• Immediate actions taken: What was done to contain or mitigate the incident? Note who performed those actions and when.

• Follow-up steps: Outline what’s planned to prevent recurrence, plus any required investigations, audits, or policy reviews.

• Privacy and legal notes: If personal data or sensitive information is involved, document how it was handled and who accessed it.

• Chain of custody: Record how the evidence was collected, stored, and transferred. This is essential for integrity.

Structure and flow: making the report easy to read

A good occurrence report tells a story, but it tells it with structure, not flair. Here’s a practical way to lay it out, without overcomplicating things:

• Title and summary: A concise label and a 2–3 sentence overview of the incident, impact, and immediate response.

• Environment snapshot: Quick context—where, when, what systems, who noticed it.

• Chronology: A bullet-point timeline of events, in order.

• Findings: Objective statements that reference evidence and detections.

• Impacts: What was affected and any risks introduced.

• Actions taken: Containment and remediation steps, plus who did them.

• Recommendations: Objective steps to reduce risk, with assigned owners if possible.

• Appendix: Logs, screenshots, references, and evidence inventory.

Language that lands as professional but accessible

Keep sentences clear and direct. Use active voice when it helps clarity, but occasional passive wording is fine if it keeps the focus on events rather than people. Choose precise terms and avoid vague judgments. If you can replace a sentence like “The system acted strangely” with “System X logged error E-101 at 13:07,” you’ve boosted credibility.

A few practical phrasing tips:

• Replace “I think” with “The evidence indicates.”

• Swap “the team didn’t handle it well” for “Team A did not apply documented containment steps within the defined response window.”

• When you’re quoting actions, use exact words from logs or witness statements, with dates and times.

A brief template you can adapt

• Title: Incident Report — [Short Descriptor]

• Time and place: Date, time, time zone, location or asset name

• Parties involved: Names, roles, contact points

• Incident description: What happened, in plain terms

• Detection and notification: How and when the incident was detected

• Immediate containment steps: What was done first

• Evidence and artifacts: Logs, screenshots, file names

• Scope and impact: Affected systems, data, services, users

• Root cause (if known): Based on evidence; avoid speculation

• Corrective actions: What was changed or fixed

• Preventive measures: Policy updates, training, controls

• Review and sign-off: People who reviewed the report and dates

A small digression that helps with Ontario contexts

Security work isn’t done in a vacuum. In Ontario and similar jurisdictions, how you document incidents can influence audits, legal reviews, and ongoing risk management. The tone should respect privacy requirements and data handling norms. When in doubt, keep personally identifying information to what’s strictly necessary for the incident record, and anonymize where possible in the body of the report. It’s not about hiding things; it’s about protecting people while preserving the integrity of the record.

Common traps to avoid—and how to sidestep them

• Don’t mix “what happened” with “why it happened.” The why usually comes in a separate analysis phase after you’ve established the facts.

• Don’t rely on memory alone. If you didn’t witness something directly, cite logs or system data rather than guessing.

• Don’t overstate capabilities or controls that weren’t actually involved. If a control didn’t engage, say so with the available evidence.

• Don’t overwrite dates or times with uncertainty. If you’re unsure about a timestamp, mark it as approximate and note why.

• Don’t forget to protect privacy. Redact or minimize sensitive data in the body of the report and in attached evidence where appropriate.

A final thought on credibility

People notice the tone of a document more than you might expect. When readers see a report that sticks to verifiable facts, follows a clear sequence, and avoids guesswork, trust grows. In security work, trust translates to faster responses, cleaner investigations, and better decisions on risk.

If you want to keep your reporting consistent, consider weaving in a standard checklist at the start of every report. A short list like: “date/time, location, asset, detection method, actions taken, evidence,” can act as a mental safety net, ensuring you don’t skip critical elements. It’s not a rigid cage; it’s a steady compass.

Closing the loop

An occurrence report isn’t just a record of what happened; it’s a guide for what to do next. By steering clear of personal opinions and sticking to facts, you give readers a clear lens through which to view the incident. You also lay a solid foundation for learning and improvement without muddying the waters with bias.

If you’re building skills in this area, remember: practice makes for better clarity, not louder judgments. The goal is a document that’s easy to read, quick to understand, and tough to challenge on the facts. In the end, that’s what makes an well-crafted report genuinely valuable to anyone who relies on it—whether they’re a security analyst, an auditor, or a manager seeking clarity in the face of a disruption.