Does this scenario sound familiar?
You set up a meeting with a client to go through their security stack and are planning to upsell them with an updated stack that you are certain they need. Maybe this is your strategic annual plan or a Quarterly Business Review (QBR). You see a need for them to move to a more security-centered solution.
The problem you have is convincing clients that often perceive IT as a cost on their P and L sheets. Their goal is to minimize their spend as much as possible on IT, especially security items that they perceive as having little return on investment.
While selling with penetration tests will definitely help them see WHY they need to be thinking about a long term solution to reduce their risk, a critical piece in getting your clients to trust your security solutions and realize their need for them will come from your teams of engineers being able to communicate this need to users.
One of the biggest problem I see within Managed Services teams— or any IT team today— is the ability to communicate security needs with non-technical workers. I saw this when running my MSP and continue to see the problem replay over and over across IT.
It is extremely hard to convince leadership teams that are focused on bottom line numbers to invest and see value in intangible security items that do not directly increase productivity or give them a perceivable market advantage.
Remember the last time an operational initiative was started without even considering security?
You can only make your security better if those who are making decisions are not only in the loop but understand what’s going on in a business context. Your challenge is bridging the gap between decision makers and your reality. And part of this challenge will be to challenge your teams to help get them to communicate needs as they see them while supporting your users and clients.
Your technical team will understand the cybersecurity needs much more than a client. What is obvious to them might not be so for users.
Your teams probably have an extensive understanding of security tools and why they’re needed. They also have a better grip on the specific tools your users probably will need and the solutions that you’re offering other clients that would work well for other clients missing out on those solutions.
You might be thinking to yourself, but my technical team aren’t salespeople. They don’t want to sell!
My response to you is you’re absolutely right. Their job is to provide an awesome service, to solve problems and to help keep your clients safe.
If they notice problems that would be completely fixed by bolstering their security stack, your technical team is doing their core mission.
When we think about being an effective support team member, we often think about getting problems solved quickly. Maybe they help a user understand how to do something specific with tech to make their job easier—perhaps how to use a function in Excel or Outlook, or to solve a problem that prevents them from being as effective in their job.
But most often, they’re solving the problem and calling it good.
My challenge to you: get your team to start looking for security issues and bringing them up. Just like at a construction site. If you were a construction worker and saw someone doing something that ultimately could risk hurting themselves or others, you probably would bring it up with that person—or their manager. That seems like common sense.
If you were to see a construction worker welding without eye protection or a window cleaner scaling a building without wearing an appropriate harness, I’m sure you’d be concerned enough to speak up.
Why wouldn’t your tech team do the same thing if they see dangerous or risky situations while working with users?
I’m confident that they are more than capable of seeing risk. How can you start engaging them to feel comfortable speaking up and saying something to your clients?
I am positive that no one on your team wants to see a data breach, ransomware attack, or other cyber incident occur on their watch.
You have the opportunity to make your teams heroes. Rather than not participating in the conversation, what is stopping them from being the hero helping your clients to see their risk or at least hearing that they should consider implementing a tool to help avoid a serious issue later on?
In this week’s Security Operations (SecOps) call, we will be diving into enabling your teams of their moral obligation to say something.
