A report rarely contains everything an investigation team will eventually learn about an incident.
At registration, the information may still be incomplete. The reporter may describe what happened, but important details — the affected process, specific characteristics of the incident, its impact, or a more precise classification — often become clear only later.
Until now, structured incident information was largely tied to the registration form. That created a practical limitation: once the report was submitted, those attributes were difficult to develop alongside the investigation.
Incident–Event Analysis changes that by adding a dedicated section inside the case where structured incident information can be added and updated throughout the investigation.
Registration captures a snapshot.
It reflects what was known when the report first entered the system. But an investigation is a developing process.
A case that starts as a broad misconduct allegation may later reveal:
When structured data exists only in the original registration form, investigation teams face an awkward choice: leave outdated information untouched or move new details into notes and free-text fields.
Both approaches make structured comparison between cases harder.
Depending on an organisation's configuration, it can include attributes such as:
The important difference is that these attributes are no longer limited to the moment of registration.
They can be added when the information becomes known and updated as the investigation develops.
See how to add and update structured incident attributes throughout an investigation in our Help Center.
Think of registration information as the starting point.
Incident–Event Analysis becomes the structured layer that evolves alongside the case.
A typical process might look like this:
This allows teams to preserve the original submission while maintaining a clearer picture of what the organisation ultimately learned about the incident.
Not every field needs to be completed at the beginning of a case.
That matters because forcing investigators to classify an incident too early can create another problem: information gets recorded before there is enough evidence to support it.
With Incident–Event Analysis, teams can add structured attributes later.
For example, an investigator may initially know that a report concerns inappropriate conduct but not know whether it involves retaliation, conflict of interest, abuse of authority, or another specific issue.
Once the facts become clearer, the relevant structured information can be added to the case.
Structured data should not become outdated simply because the case has moved beyond registration.
Incident–Event Analysis keeps attributes editable after the case has been created.
That means investigators can update them when:
The result is a case record that better reflects the current understanding of the incident rather than only the information available on day one.
Free-text descriptions are essential for investigation context, but they are difficult to compare consistently.
One investigator may describe an issue one way, while another uses completely different wording for a very similar incident.
Structured incident attributes create a common language across cases.
Instead of relying only on narrative descriptions, organisations can record the same characteristics through the same configured fields.
This creates a stronger basis for:
Imagine a report about a procurement concern.
At registration, the reporter provides only a general description of suspicious behaviour involving a supplier.
During the investigation, the team later confirms that:
Previously, much of that information might have remained scattered across investigator notes, attachments, or free-text case descriptions.
With Incident–Event Analysis, those findings can also become structured attributes inside the case.
If the investigation later changes the team's understanding, the attributes can be updated again.
More complete incident records |
More consistent classification |
|
| Cases can contain structured information discovered after registration, not only information submitted at the beginning. | Teams can use the same incident attributes across multiple cases instead of relying on different free-text descriptions. |
Structured attributes remain part of the case record as the understanding of the incident develops, providing clearer context for later review.
More flexibility during investigations |
Better data for cross-case analysis |
|
| Investigators do not need to finalise every incident characteristic before the relevant facts are known. | Standardised incident attributes create a cleaner foundation for comparing cases and developing deeper analytical reporting. |
The new section does not replace the registration form.
They capture two different moments in the case lifecycle.
| Registration | Incident–Event Analysis |
|---|---|
| Captures information available when the report is submitted | Captures structured information developed during the case |
| Represents the initial report | Represents the organisation's evolving understanding of the incident |
| Primarily tied to intake | Can be updated throughout the investigation |
| Preserves the original submission context | Adds reusable structured incident attributes |
Using both gives investigation teams the original report and a structured record of what was subsequently established.
Incident–Event Analysis is configurable.
The attributes available in the section depend on the information your organisation needs to capture consistently across cases.
This means the same mechanism can support different investigation models, case types, industries, and internal classification structures without forcing every organisation into the same incident taxonomy.
Investigations naturally produce new information.
The problem begins when that information remains fragmented across notes, attachments, registration fields, and investigator memory.
Incident–Event Analysis gives teams a dedicated place to turn those findings into structured case data.
The result is not simply more fields in a case. It is a more consistent way to describe what happened, refine that understanding as evidence develops, and create information that can be compared across investigations.
See how Ethicontrol can help your team capture, update, and standardise incident information throughout the case lifecycle.