Do You Have a ‘Speak Up’ Culture?
Let me give you a clue: If your employees aren’t, you don’t!
We will again find that most organizations will describe the need to report issues, incidents or concerns scattered around in various awareness material and in policies. But there is a world of difference between what is written and what is done.
In this blog, I’ll try and tease out some of the factors influencing human behavior, and why your employees might not be engaging with the principle. The number of potential scenarios means this will be a slightly longer post, but bear with me and challenge yourself: “Could these be factors in my organization?”
- It’s not clear what to report.
- It’s not clear how to report.
- It is complicated to report.
- Nothing happens when you do.
- You don’t feel valued when you do.
- You have no idea if anyone else is.
So, let’s unpack these one by one.
1. It’s not clear what to report.
This issue sits at the heart of my second blog in the series, “Defining Weird,” which I am sure you have read and would be well prepared for a short test on! For those in need of a refresher, my thesis is that there is a tendency for well-meaning security folk to make assumptions about what appears unusual, risky and worthy of raising. What we need to do is take our risk scenarios and think of them through the lens of the employee. Don’t overburden them with the motives and techniques of various threat actors. Be specific about things that an employee may see that are out of the ordinary, be they “system prompts” or the behavior of individuals. Clarity on what should be reported will only increase the chance it is.
2. It’s not clear how to report.
This is where we might hear a quiet purr from someone who has designed a process to stick in the Information Security Management System (ISMS) library: “Of course it is defined, look at my process diagram!” We really need to think about the employee and the tools the organizations use. If an intranet is used, make sure there is a prominent place to link to the information, use Microsoft Teams or Slack, then have a channel set up. An email address buried in a policy isn’t good enough.
3. It’s complicated to report.
Whilst reporting issues is (should be) a clear responsibility of anyone using your systems and data, we are also vying for time and attention of the person trying to report. Other spheres of emergency response talk about “the golden hour,” a period where rapid information gathering and response can make the difference between success and failure. The tension we are looking at is the desire for as much information as possible and the user experience of the person trying to make contact. Depending on the organization, there could be widely different levels of technical knowledge.
So if you are asking people to fill in forms, make sure they are understandable – I would suggest involving non-technical users in their design. I would also highly recommend an easy way for the reporter to talk to an actual human being. Complex forms, an uneasy feeling of reporting a colleague or a sense of embarrassment over the lack of technical knowledge are real factors to consider. How well do you address those?
4. Nothing happens if you do.
The next three factors are intertwined. As human beings, we quickly lose interest and respect for a task or process that doesn’t seem to work or have any outcome. In fact, many organizations are actively encouraging employees to identify those situations. So, if your security reporting process doesn’t give feedback at a macro or individual reporter level, don’t be surprised if it is devalued to the point of being ignored. There is a great opportunity to use incidents as an ad-hoc way of giving context rich examples of what people should be looking for.
5. You don’t feel valued if you do.
Reward, recognition and — importantly — appreciation are common motivators, especially in the workplace. If employees are highlighting issues, we owe it to them to recognise their effort – and give feedback. Even if we deem it wasn’t an issue, there is a chance to engage and explain what things would have potentially been a threat to maintain interest. If it was a genuine issue, we can discuss at a high level what that allowed us to do to manage the threat. Some companies promote “security champions,” calling out individuals outside of security who have made contributions. As ever, find something that works with your company culture — but at a minimum, make sure the individuals are engaged with and feel valued.
6. You have no idea if anyone else is.
Advertising the fact that people do report potential issues is a big step to making it normal, expected behavior. We should strive to provide high-level information on the number of reports, the board categories of issue and what we managed to do with the information. Include recent stats in your onboarding sessions and it will become “just how we work here.”
Hopefully I have set the scene for the number of factors that could impact the likelihood of someone reporting an issue. I should stand out that they are largely human factors, not technical ones. I would encourage you to engage with your employees to understand their views and understanding of what to do, when and how. Security needs the data, but in this case, the “customer” is our employees.