How to Write an Incident Report: Facts, Response, Evidence and Follow-Up
Learn how to write an incident report for consulting work, with incident facts, immediate response, evidence, witnesses, follow-up actions and review criteria.

An incident report should make a confusing event understandable without pretending to know more than the evidence supports. The best reports separate facts, immediate response, evidence, witnesses and follow-up actions. They avoid blame language and leave a clear trail for review.
This guide uses a consulting scenario: a team member accidentally shares a client strategy-review folder with a subcontractor who was approved for analysis work but not for interview notes. No clinical, legal or regulatory advice is provided here. If an incident triggers legal, employment, safety, privacy or contractual duties, follow the applicable process for your jurisdiction and organization.
Record the Incident Facts
Start with facts that can be checked. Do not begin with a conclusion like "subcontractor breached confidentiality." At the first draft stage, you may only know that access was granted and later removed.
Draft language:
On [date] at approximately [time], [project manager] granted [subcontractor name] access to the project workspace for the [client] strategy review engagement. At [time], [analyst] noticed that the access included the interview-notes folder. The subcontractor was approved to receive the purchasing-volume input file only. Access to the workspace was removed at [time].
That paragraph names who, what, when, where and the known mismatch. It does not speculate about motive, harm or legal effect.
OSHA's incident investigation overview says investigations should use a systems approach to identify and control underlying root causes to prevent recurrence (OSHA, United States). Although OSHA's page is workplace safety guidance, the systems principle is useful in consulting incidents too: look at permission design, approval steps and review controls, not only the person who clicked the wrong setting.
Describe the Immediate Response
Immediate response is the action taken to contain the incident and protect people, records or services. In this consulting scenario, immediate response might include removing access, preserving logs, notifying the engagement lead and checking whether files were downloaded.
Draft language:
Immediate response: access for [subcontractor] was removed at [time]. The project manager preserved the workspace access log and notified the engagement lead. The engagement lead paused further subcontractor work pending review. The team is checking whether any interview-note files were opened or downloaded.
This section should be chronological. It should also say if something has not yet happened:
Client notification has not yet been sent. The engagement lead is reviewing contractual notice requirements with the account owner.
Do not hide uncertainty. A report that distinguishes confirmed actions from pending checks is more reliable than one that sounds complete too early.
Preserve Evidence and Witness Accounts
Evidence may include access logs, email requests, screenshots of permissions, file metadata, approval records and statements from people involved. Store evidence securely and avoid altering the original records.
Draft language:
Evidence preserved: workspace access log export dated [date], screenshot of folder permissions taken by [name], subcontractor approval email dated [date], and project manager statement taken at [time].
Witness notes should record what the person observed, not what the interviewer thinks happened.
Example witness note:
[Analyst] stated that while preparing the analysis file, they saw [subcontractor] listed under the interview-notes folder access panel. [Analyst] did not know whether the subcontractor opened any files.
OSHA's hazard-identification guidance notes that investigating incidents and reports can identify hazards likely to cause future harm and that the purpose is to identify root causes, often more than one, to prevent future occurrences (OSHA). For this consulting example, likely contributing factors might include a folder structure that makes broad access easy, unclear subcontractor-access instructions or no second review for permission changes.
Analyze Contributing Factors Without Guessing
Contributing factors are not excuses. They are conditions that made the incident more likely or harder to catch.
Draft language:
Preliminary contributing factors: the approved subcontractor-access instruction did not specify the exact folder path; the project workspace inherited permissions from the parent folder; no second-person review was required before granting external access.
Avoid phrases like "careless employee" unless a formal process has established that language and it is necessary. Operational reports are stronger when they describe control gaps:
Weak: The project manager was careless.
Stronger: The access request did not include a folder path, and the workspace allowed inherited permissions that exceeded the approved access.
If you cannot determine a factor yet, say so:
Unknown: whether any interview-note file was opened by the subcontractor. The team is awaiting audit-log confirmation.
It is also useful to separate immediate cause from system condition. The immediate cause may be "broad folder access was granted." The system condition may be "the access request form did not require a folder path, and inherited permissions were not checked before external access." The second sentence is the one that helps prevent recurrence.
Draft wording:
The immediate access error was corrected by removing the subcontractor from the workspace. The underlying control issue is that the approval record did not specify the exact folder path, so the project manager had no documented standard to compare against before granting access.
That language is specific without blaming the individual. It gives the action plan something to fix.
Assign Follow-Up Actions
Follow-up actions should have owners, due dates and closure evidence. "Review permissions" is too vague.
Example action table:
| Action | Owner | Due | Closure evidence |
|---|---|---|---|
| Confirm whether interview-note files were opened or downloaded | IT admin | [date] | Audit-log summary |
| Notify client sponsor if required under engagement terms | Engagement lead | [date] | Notice record or decision note |
| Replace inherited project permissions with role-based folders | Project manager | [date] | Screenshot and access list |
| Update subcontractor-access instruction | Quality manager | [date] | Revised SOP and team briefing record |
OSHA's root-cause publication says employers should go beyond the minimum investigation required and conduct root cause analysis to prevent recurrence (OSHA PDF). Do not overclaim that this is required for every consulting incident; use the principle to make follow-up actions address causes rather than symptoms.
Review Before Closure
An incident report is ready for closure only when an authorized reviewer can see what happened, what was done, what remains uncertain and what has changed.
Use these review criteria:
- Facts: Are time, date, location, people and systems recorded from verifiable sources?
- Response: Are containment actions listed in chronological order?
- Evidence: Are logs, screenshots, approvals and witness statements preserved without alteration?
- Witnesses: Are observations separated from assumptions?
- Contributing factors: Does the analysis focus on process and controls?
- Actions: Does every action have an owner, due date and closure evidence?
- Restrictions: Are continuing restrictions recorded?
- Notification: Are contractual, regulatory or internal reporting decisions documented by the right person?
Use a Structured Incident Draft
The consulting incident report template is an editable Word document with sections for facts and immediate response, impact and evidence, investigation and contributing factors, actions and closure. It gives you a structure for a reviewed report, but it does not decide legal reporting duties or guarantee compliance.
Write the report so a later reader can reconstruct the event without interviewing everyone again. That is the practical standard: clear facts, preserved evidence, specific actions and a closure decision that can be checked.
Last updated: September 26, 2026
Frequently Asked Questions
Related Articles
Audit Checklist Best Practices
Best practices for audit checklists, including scope, evidence, findings, actions, closure review, failure modes and sample wording.
Audit Checklist Checklist: Review Your Audit Form Before You Use It
A practical audit checklist checklist with decision gates for scope, evidence, findings, actions and closure review.
Audit Checklist Examples: Scope, Evidence, Findings and Closure
Audit checklist examples for consulting work, covering audit scope, evidence to inspect, findings and actions, closure review and practical draft wording.
Business Continuity Plan Best Practices for Consulting Teams
Business continuity plan best practices for consulting teams, including critical services, recovery priorities, communications, exercises and review criteria.
Business Continuity Plan Checklist for Consulting Teams
A practical business continuity plan checklist for consulting work, covering critical services, recovery priorities, communications, exercises and review criteria.
Business Continuity Plan Examples: Consulting Scenarios and Recovery Priorities
Business continuity plan examples for consulting teams, with critical services, recovery priorities, communications, exercises and review criteria.