Traceability and compliance
The file of an incident
While it is happening, nobody documents. Afterwards, what gets reconstructed is exactly what gets questioned.
A delivery that arrives damaged, a breakdown, a complaint that escalates, a fault that hits a client. For the first few hours everyone is fixing it, which is what they should be doing. The problem arrives three weeks later, when somebody asks for a report and it has to be reconstructed from five people's memories.
What is kept automatically and what must be captured
| Element | Generated on its own | Must be captured |
|---|---|---|
| Emails and messages with the client | Yes, with their time | — |
| Documents contributed during the incident | Yes, with who uploaded them | — |
| What was decided and why | No | Yes: a short note the same day |
| Calls and corridor conversations | No | Yes, and it is what is always missing |
| Photos of the state of things | No | Yes, at the time: later it no longer looks the same |
Important
The last three rows decide the report, and there is a reason they cannot wait: **anything written after the outcome already knows how it ended**. A note drafted the same day, with the incomplete information available then, shows you decided on reasonable grounds; the same note written three weeks later looks like — and sometimes is — a justification. The difference is not the content, it is the date.
The four notes worth a whole report
- 1
What happened and when you found out
With the time. «When did you know» is everyone's first question.
- 2
What was decided and on what information
Including what you did not have: that is what justifies the decision.
- 3
Who was notified and when
Client, insurer, supplier, whoever applies.
- 4
And what was left open at the end of the day
It turns the file into something someone else can pick up.
Watch out
What breaks most in practice is not missing data: it is that **the incident is handled on a private channel** — a messaging group, calls, emails between two people. When the claim arrives, half of what happened sits on the phone of someone who may be off sick or gone. It is enough to dump each decision into the file the same day, even if the conversation carries on wherever it is comfortable.
And when the incident touches personal data
Worth knowing
Where personal data is involved there are notification duties with their own deadlines and recipients — the **GDPR** in Europe and, depending on the sector, frameworks such as **NIS2**. **What applies to you and within what deadline is for your adviser to determine**; what matters here is that without the detection time noted, that conversation starts on the wrong foot.
›Is it worth documenting a small incident?
Four lines. The ones that end in claims all looked small at first.
›What if the decision turns out wrong?
Note it anyway. What is judged is whether you decided reasonably, not whether you were right.
›Who should write it?
Whoever is handling it, that day. Not the boss, three weeks later.
A real case
The situation
A company handles a damaged delivery over a messaging group and it ends in a claim.
What you do
- Dumps each decision and the detection time into the file the same day
What you get
The report is written by reading the file, not by reconstructing five people's memories.
The situation
The incident is documented days later.
What you do
- Records what happened at the moment
What you get
The account is exact rather than reconstructed.
The situation
Each person keeps their own notes.
What you do
- Gathers everything into an incident file
What you get
The sequence can be reconstructed.
The situation
There is no record of who decided what during the incident.
What you do
- Records decisions with author and time
What you get
What was done is explicable.
The situation
The incident is closed with no conclusions.
What you do
- Records what was learned and what changed
What you get
The next incident starts better.
The situation
A third party asks for the incident file.
What you do
- Shares what is relevant with controlled access
What you get
It is handed over ordered and verifiable.
This article answers
- how to document an incident
- reconstructing what happened after a problem
- incident report with a client
- what to keep when something goes wrong