Why your security incident reporting process matters

If a colleague forwards you an email they suspect is phishing, how do you respond? If someone makes a mistake that impacts security, are they comfortable calling to tell you? If someone leaves a laptop at the airport, do they know who to call?

The only expected outcome of a properly defined security awareness program (confirm the definition here  to stop others from conflating security awareness) is that people report suspected incidents. That requires the incident reporting program needs to match the needs of people.

How does your incident reporting process work?

• Do people know when and what to report?
• Do they understand how to report? Is it a specific person, a team, a generic “mailbox”? Can they use email, telephone, and other means?
• What does the process entail? What are they getting themselves involved in? Will they be scolded, mocked, or ridiculed?
• What sort of involvement does reporting an incident have on them?
• Do they get any confirmation of the incident? What if they are right, do they get any accolades?

Why the incident reporting process matters

Here’s the challenge: just telling people, “report suspected incidents” without demonstrating and building confidence in the process generally results in people choosing to remain quiet.

If someone doesn’t know what to expect or fears that reporting creates a problem for them, it’s easier to not engage. A poorly designed and executed incident reporting process derails an entire security awareness program.

How does your process work? How are people treated?

Two tenets build the right incident reporting process

James K runs an impressive program where people routinely contact him with potential and actual incidents. The director of security for a financial services firm, James agreed to share his experience in building the process.

James says the core of a strong incident reporting program has two basic tenets:

1. Say it: incorporate the incident reporting process into the security awareness program. In addition to explaining what to expect, James also sets the stage with his colleagues that his job “is protect the company, not catch you making mistakes.”
2. Do it: follow-through on the promise made. James explains that the first incident after launching the program defines how people will act in the future. When someone reports an incident, what happens to them? If the person gets chastised, punished, or fired, credibility is lost.

Practice communication over messaging

James explains that a successful incident reporting program means “you’re always communicating, and people are always communicating back.”

As a result, James gets a lot of email from colleagues about suspected phishing attacks and other security concerns. He notes that while more than half of the messages turn out to be concerns about spam, “it’s okay, because it means people are thinking about security.”

He replies to each message with a quick note of thanks. More than expressing his genuine appreciation, it reinforces that people should report suspected incidents.

If someone gets a bit too excited and sees an incident in everything, James simply uses that as an opportunity to provide “one-on-one security training” to explain the differences and what to look for.

Amplify the good

James points out that “if security is everyone’s job, then everyone deserves a pat on the back for a job well-done.”

When someone forwards a phishing email or discovers a targeted attack before the traditional systems catch it, James not only thanks them, but makes sure that the management chain is made aware of the great work.

While it takes a few extra seconds to find and copy the appropriate managers on the message, the approach creates allies and encourages broader participation.

Cultivating the change takes time – but it pays off

James suggests “it takes a year to work… but once it starts, it builds.” In his experience, people are happy to help. Especially because it’s exciting to catch something before others and make a difference.

In addition to seeing a rise in the number of incidents reported, James sees the benefits of his approach in the annual security testing. Because his colleagues are used to looking for things and comfortable reporting, they catch a lot of the tests before they are complete.

For example, James explained that during the last external security test, the sales team collectively figured out someone was attempting to social engineer them. Initially, they tipped each other off about the caller and scolded the tester. Then they reported the incident to James. Their success meant the tester was removed from the team.

Sometimes people make mistakes. It’s a busy world and we run at a hectic pace. We don’t expect people to catch everything all the time. We still need our tools in place, but having people aware and willing to share makes a difference.