Fear, Uncertainty, and Doubt (FUD) is an emotional marketing tool, but it’s also simply a fact of cybersecurity. Even those of us who work in the industry live with a degree of it. And that FUD gets amplified when the very people delegated to manage it let it take an emotional toll on them, too.
A quick disclaimer before I go on: what follows is my admittedly negative take on how businesses get stuck in perpetual FUD. In fairness, there are some real diamonds out there, professionals carrying the weight of entire organizations on their backs to make sure FUD gets dealt with. Some of them lead whole teams that buy into the mission and work as a cohesive unit, securing the organization within real-world budget constraints. Those heroes exist. They’re just few and far between, and this isn’t their story.
The Three Ways Businesses Try to Outsource Their Fear
So how does a business handle FUD? Can you remove it from the equation by hiring the right people and saying “sic ’em”? Here are the approaches I’ve seen.
1. Hire an IT pro and make all FUD their responsibility
This person is often called a Chief Information Security Officer (CISO) or, if you’re on a budget, a “Technician.” Either way, you’ve thrown a person at the problem in hopes they’ll make all your wildest nightmares go away. In truth, they seldom do. A good CISO will either ask for a Publishers Clearing House–sized check to pay for all the security or quietly abdicate responsibility under budget constraints. Unless you have unlimited funds and a willingness to hobble your organization with heavy-handed security controls, this rarely solves anything.
2. Outsource FUD management to an MSP
Just like the in-house hire, the MSP will happily sell you every security solution known to man, and again, with unlimited funds, this might work out. To be fair, MSPs tend to have a wider breadth of knowledge and experience than an in-house CISO who stares at one stack of hardware, software, and security tools every day. Good MSPs touch hundreds, even thousands, of different environments. So, you’re likely on better footing than with a solo CISO, unless that CISO is backed by an extensive team of highly experienced, motivated engineers, which is seldom the case.
3. Do both: the co-managed model
Hiring an IT pro and partnering with an MSP is another step in the right direction, if the budget allows. But notice the pattern: none of these options actually solves the problem on its own merits.
Why Throwing People at FUD Doesn’t Work
Here’s the truth: nobody but leadership knows how to value the trade-offs between security, compliance, and productivity. And when leadership and IT square off, IT loses. Security becomes theater. The IT team demoralizes quickly and starts spending a great deal of time doing the CYA dance: “I requested budget for a SIEM and was refused, so I saved the email where the CFO denied my request to cover myself.”
Imagine you worked on a giant hydroelectric dam. You spot cracks. Your job is to keep the dam safe and functional, but leadership denies your repair request. How motivated would you be? If the dam breaks and the town downstream floods, you get the blame. You know it in your heart, and there’s nothing you can do except grit your teeth, cover yourself, or quit.
And about quitting there’s the famous “quiet quitting,” which is an absolute epidemic in IT. (We’re often pulled into organizations that need an MSP to fix, or outright replace, the quiet quitters.) When a disgruntled, demoralized, downtrodden IT professional finally does leave, do they ride off into the sunset? Nope. They get another IT job, where they hope to either “just get by without all the heartburn” or fall right back into the woe-is-me mentality of the perpetually victimized IT professional.
Many organizations shrug and conclude, “This is just how IT people are.”
It doesn’t have to be.
Everything Is Risk, So Start Measuring It
Everything in life is risk, starting the moment you decide to get out of bed. All day long you make risk calculations. If you sleep in and then speed to work, you’ve chosen greater risk in exchange for the reward of extra sleep. So why can’t you evaluate risk in your business when it comes to IT?
Honestly, where would you even begin? I’ll tell you: start with RPO and RTO.
- Recovery Time Objective (RTO): How long can your business survive without access to your systems and data?
- Recovery Point Objective (RPO): How much data can you afford to lose?
Here’s how it plays out in the real world:
- Your team backs up your server once per day at midnight.
- Your server dies an untimely death at noon.
- Your team orders a replacement server two weeks for delivery.
- When it arrives, your team spends three days building it, restoring your data, and testing until it’s operational.
Your RPO is 12 hours. The backup ran at midnight; the server died at noon. Any data entered during those 12 hours is gone recoverable only by scraping external sources like emails and handwritten notes, re-entering it by hand, or accepting the loss.
Your RTO is 17 days. Two weeks waiting on hardware, plus three days of restore and testing.
The damage? Twelve hours of lost data and seventeen days of business operations without your server. How badly would that hurt your business? Pretty badly? Then you need a shorter RPO and RTO and you build your environment around that requirement.
The Quarterly Conversation: RPO, RTO, and Prove It
We could get deep into the weeds on business continuity and disaster recovery, but what I’ve given you is an easy-to-understand framework that leadership can use to hold their IT professionals accountable. In its simplest form, once per quarter, ask three questions:
- What is our RPO?
- What is our RTO?
- Prove that we’re meeting them.
That’s it. Yes, this is a deliberately simple, high-level way to think about disaster recovery. We can dive into backup retention, GFS rotation schemes, immutable storage, dissimilar authentication systems, and more but for now, just remember those three: RPO, RTO, and Prove it.
It’s Not Just Your Servers
I applied this framework to servers because they’re likely the most important devices on your network. But there are other hidden-yet-critical pieces, too, like the small business that keeps QuickBooks Desktop on an admin’s work computer. What about the ISP serving internet to your facility? What happens if the internet goes down? What if your email is down?
Every one of these has its own RPO, its own RTO, and its own requirement to prove that recovery is possible within the timelines your organization has decided it can live with.
Beyond that, you’ll need policies, procedures, and a regular review process to make sure organizational expectations are actually being met. But if you have nothing or very little start here and expand outward.
You don’t have to abdicate responsibility to know your organization is recoverable. You just need to know what to ask, and how to ask it.
Brian Largent
Father to five, husband to one, founder, CEO, and all around swell fella (or so I'm told)
