Security incident information management handbook
Every agency records security incidents. Almost none record them in a way that allows the numbers to be compared with another agency's, or with their own from three years ago. This handbook sets out a shared approach.
The problem it addresses
An incident report serves two purposes and they pull in different directions. It is the record of what happened to a specific person, which requires detail, context and confidentiality. It is also a data point in a pattern, which requires consistency, comparability and the ability to aggregate without exposing anyone.
Most systems are built for the first purpose and produce nothing for the second. Categories differ between offices within the same organisation. An incident that one office files as a robbery appears elsewhere as an attempted robbery, a mugging or a theft, and the three cannot be counted together. The narrative holds the information that would resolve it, and the narrative is not machine-readable.
The shared approach
The handbook defines a common set of fields and a common set of values, on the principle that the analysis is only as good as the consistency of the input.
| Field | Why it is needed |
|---|---|
| Date, time and location | Trends by period and by area. Location is recorded at a consistent administrative level, not as free text. |
| Incident type | From a closed list. The list is deliberately short, so that offices cannot indefinitely subdivide it. |
| Who was affected | Category of person, and whether the incident was specific to them or indiscriminate. This is the field that makes profile analysis possible. |
| Perpetrator category | Armed actor, state actor, criminal, community member, colleague, unknown. Recorded as an assessment, with the basis for it. |
| Consequence | Physical, psychological, financial, programmatic. Including the incidents with no injury, which are the majority and are the most frequently dropped. |
| Action taken | What the organisation did, so that the response can be evaluated and not only the incident counted. |
Confidentiality and aggregation
Shared incident data creates a disclosure risk that individual reporting does not. A small number of incidents in a distinctive location can identify the person involved even with names removed. The handbook's rule is that aggregated figures are published only where the cell is large enough that no individual can be inferred, and that the restricted version of the record is held separately from the analysis extract. The extract carries no narrative and no identifying detail.
What the data can and cannot show
It can show trends over time, differences between locations, and whether a change in practice coincided with a change in incidents. It can show whether particular groups of staff are over-represented among those affected, which is the finding most likely to require action.
It cannot show the true number of incidents, because it only records what is reported. A rise in reported incidents is at least as likely to mean that reporting improved as that the environment worsened, and an organisation that cannot tell the two apart will draw the wrong conclusion from its own data. The handbook treats that limitation as a finding to be stated alongside the figures, not a reason not to collect them.
Related
Practical guidance and research on the security of humanitarian staff, for the organisations that send them.