|
OBJECTIVE |
To share examples of security incidents To understand the role of security incidents in risk analysis |
|
TIMING |
60 minutes |
|
TIME BREAKDOWN |
Introduction - 10 minutes Reading example - 5 minutes Identifying good practices - 25 minutes Documenting - 10 minutes Discussion & conclusion - 10 minutes |
|
MATERIALS NEEDED |
Projector, Flip chart, handout |
Module 15: Analysing Security Incidents
When planning and facilitating this session, it is important to consistently apply an intersectional lens to each participant's identity and experiences, and their protection needs. Overlapping systems of discrimination and privilege, such as gender, sexual orientation, religion, disability, racial and/or ethnic origin, economic status/class, marital status, citizenship, age and physical appearance, can have a profound impact on human rights defenders' and their communities' perception of and experience with risks and protection.
The facilitator introduces the module by explaining that a security incident is an unusual incident which may indicate that there is a threat.
The facilitator projects the scenario below and gives participants time to read it, before asking:
|
"We noticed taxis started parking outside our office. Staff would often take these taxis rather than going to the nearest taxi rank as usual. The taxi drivers started conversations with the passengers, asking what they had been doing that day. Our organisation met regularly with other organisations to discuss their work and security issues. At the next meeting, we mentioned this security incident. Members of the other organisations present then realised that taxis had also started parking outside their offices too. We concluded that the authorities were either using taxi drivers to collect information on us, or had planted security personnel as taxi drivers. Our organisations then decided that the safest response would be to pretend we had not noticed, but we warned the staff not to say anything about their work in the taxis but instead to chat about harmless issues." |
What were the good practices here carried out by the HRDs?
Most of the responses should organise themselves around the following, which the facilitator can synthesise on a flipchart:
- They noticed that something was amiss or strange
- A security incident is anything out of the ordinary which could indicate a change in your security situation.
-
These can include:
- Changes in the physical environment, or related to physical security (eg noticing that someone is following you
- Changes related to your digital devices or accounts (eg you get an email warning you that someone attempted to access your social media account from a new computer)
- Changes to your health or well-being (eg noticing that you are tired, or forgetful)
- Incidents experienced by your friends or organisations you are allied with or work on similar issues with.
Noticing security incidents also requires that you are aware of your surroundings, and have good, trustworthy sources of information.
- They shared discussed this both internally and externally.
- They analysed the potential meaning of the security incident – they used it to identify a risk.
- They updated their security practices as a result.
Every organisation should work these four steps into their security management practices. Identifying and sharing security incidents is like the “engine” of a good security culture: when they are identified and shared, they can then be analysed and measures can be taken. Furthermore, for historical memory, it is important to document incidents so that important information does not go missing.
Hand out the handout Security Incident Report Form to participants and give them the following task:
Think back over the last six months and document any security incidents you have experienced.
Security Incident Report Form
| When? | Who Experienced the Incident? |
What Happened? | What is your Analysis of the Incident |
What Action Will be Taken? |
Follow up |
|---|---|---|---|---|---|
What opportunities do you have in your team or organisation to share security incidents?
Who could be responsible for documenting them?
How often should you analyse them collectively?
In the plenary, ask participants to share their analysis of the incidents they have experienced. What does this tell them about their risk situation?
Finally, let participants know that they will build on this analysis when carrying out their risk analysis.
Note for facilitator: Analysing security incidents can be a useful way of more “objectively” identifying risks.
Related modules:
This module can be useful before doing a session on risk analysis, and is a good bridge to the module on context analysis.
Created by Daniel Ó Cluanaigh
