Security Should Protect the Business, Not Stop It
Early in my MSP days, I was convinced that bulletproof security meant locking down every digital door, window, and cat flap. If an engineer could build a five layer authentication moat with biometric drawbridges, we felt like heroes. Then Monday morning arrived. Our clients could not actually do their jobs. That rather takes the shine off a technically impressive solution. It also creates an awkward moment when you have to explain that the thing making work difficult was introduced to make the business safer. Looking back, there is a question worth asking about that instinct: were we designing around the client’s business, or around our enthusiasm for what was technically possible?
Nick Clift
10/6/20263 min read
Early in my MSP days, I was convinced that bulletproof security meant locking down every digital door, window, and cat flap. If an engineer could build a five layer authentication moat with biometric drawbridges, we felt like heroes.
Then Monday morning arrived. Our clients could not actually do their jobs.
That rather takes the shine off a technically impressive solution. It also creates an awkward moment when you have to explain that the thing making work difficult was introduced to make the business safer. Looking back, there is a question worth asking about that instinct: were we designing around the client’s business, or around our enthusiasm for what was technically possible?
Security and productivity live in a constant, slightly awkward tension. Make everything convenient and we may leave the business exposed. Make everything restrictive and we may make ordinary work unnecessarily difficult. People still need to get things done.
When the approved route feels impossible, people can become surprisingly creative about finding another one. Personal devices and alternative ways of working may seem like practical answers to the person trying to finish a task. From the security perspective, those workarounds can undo the protection we were trying to create.
That is not an argument for removing sensible controls. It is an argument for understanding how those controls fit the work people actually do. A technical discussion can tell us a great deal about a system, but it cannot, on its own, tell us everything we need to know about the business using it.
For that, we need a conversation. What does the owner need the business to do? Where does revenue depend on people being able to act quickly? What risks are they trying to manage, and what would disruption mean in practice? These questions are not a detour from designing the solution; they help us understand what an appropriate solution looks like.
A mature MSP needs to ask more than whether the stack is technically airtight. It also needs to ask whether the client can remain agile, profitable, and sane while using it. “Sane” may not appear in the specification document, but having been on both sides of a difficult technology decision, I think it deserves consideration.
This is where commercial viability enters the conversation. A solution has to work within the client’s reality, not just within its own technical design. That does not mean accepting every request for convenience. Sometimes the right conversation includes explaining why a control is necessary and what risk it addresses.
But the explanation should connect to the business. “Because that is how we configure it” is not quite the same as helping an owner understand the reason. Equally, an owner’s frustration is information worth exploring. It may reveal that the workflow has not been properly understood or that the implementation needs more thought.
Listening does not weaken the technical position. It can make the eventual decision more informed. That relationship between practical delivery and commercial understanding is part of what I bring to my work at Morphability, where sales and operations both benefit when the solution being discussed is grounded in the business it is supposed to support.
There is an understandable attraction to adding another tool. It gives us something concrete to do and can look like progress, particularly when it comes with an impressive list of capabilities. But another layer of technology is not automatically the answer to a problem created by the existing layers.
Before adding more, it is worth asking what is missing. Is it genuinely a technical capability? Is it a clearer understanding of how people work? Is it a decision that needs to be discussed with the owner? We should not assume the simplest solution is always sufficient, but we should be equally careful about assuming the most elaborate solution is always appropriate.
The lesson I took from those early experiences was not that security matters less. It was that security needs to protect a working business. People should be able to understand the route they are expected to follow and use it to do the work they need to do. If they cannot, we should be curious about why before deciding they are simply being difficult.
A useful conversation might reveal that the controls are appropriate and the team needs a better explanation. It might reveal that the design needs changing. Either way, we have learned more than we would by insisting the technology is right and the users are wrong.
Calm, sustainable security protects momentum rather than choking it. When did you last ask a client how your security decisions feel in an ordinary working day, and then give yourself time to listen to the answer?