This article is based on CYBR.SEC.CAST Episode 80, featuring Michael Santarcangelo, founder of ValueSmith, in conversation with hosts Michael Farnum and Sam Van Ryder. Full episode and related article:


Cybersecurity professionals are trained to solve problems. Find the vulnerability. Fix the configuration. Deploy the technology. Close the gap.
But what if the problem they're solving isn't the one the organization actually needs solved?
"We solve the wrong problem perfectly, we deliver no value, and we register a visible loss," said Michael Santarcangelo, founder of ValueSmith, during the latest episode of CYBR.SEC.CAST.
It's a costly trap for an industry under constant pressure to move faster, deploy more technology and demonstrate progress. Security teams can complete projects on time, meet technical requirements and still leave the business wondering what it gained.
Speaking with hosts Michael Farnum and Sam Van Ryder, Santarcangelo drew on three decades of experience to make a deceptively simple argument: Before cybersecurity professionals can deliver meaningful value, they need to understand which problems are worth solving.
The request isn't always the problem
Security teams rarely lack things to do. Vulnerabilities need patching, systems need protecting, and business leaders want results.
When a request comes in, the instinct is to act. But Santarcangelo believes the rush to deliver can prevent teams from understanding what they're being asked to accomplish.
"We fear pausing long enough to understand what's being asked of us," he said.
What someone requests, what they expect and what they actually need aren't necessarily the same thing.
A business leader might ask for a new security tool when the real concern is an operational problem. A manager might request another assessment when the organization needs help making sense of findings it already has.
In either case, fulfilling the request could produce a technically successful outcome while leaving the underlying problem unresolved.
Santarcangelo warned that an initial request may be little more than a symptom of something larger.
"The problem that somebody asks you to solve is not the problem that you need to solve," he said.
That means security teams need to do more than accept requirements and execute. They need to ask why the request exists, what the stakeholder hopes to accomplish and who will ultimately determine whether the result was valuable.
The best technology isn't always the right solution
The discussion also exposed a familiar disconnect between technical capabilities and organizational reality.
A security product might be excellent. It might address a legitimate risk. It might even be the most sophisticated option available.
None of that guarantees the organization can use it effectively.
"Do we have the people? Do we have the resources? Do we have the time? Do we have the buy-in?" Santarcangelo asked.
Farnum recalled a former customer who understood those limitations particularly well.
The customer acknowledged that a proposed security tool could be useful but explained that his organization lacked the staff and operational capacity to support it. Rather than pretending otherwise, he suggested revisiting the opportunity in six months.
That honesty saved both parties from pursuing a deployment unlikely to succeed.
Santarcangelo argued that recognizing such constraints is essential to delivering value. A technically sound solution that an organization cannot implement or maintain is not necessarily a good solution.
The same principle applies to internal security initiatives. A team might propose an ambitious project without considering whether the organization has the personnel, resources or support to execute it.
The result can be wasted effort, rising costs and frustrated stakeholders.
Friction destroys value
Santarcangelo has a particularly sharp description of what happens when security initiatives become too complicated for the environments they're supposed to improve.
"Friction erodes value, destroys trust, burns people out," he said.
That friction might come from complicated deployments, excessive staffing demands, competing priorities or security processes that interfere with existing operations.
As friction increases, so do the time and resources needed to deliver results.
Eventually, the effort required to implement a solution can undermine the benefit it was supposed to provide.
For cybersecurity leaders, the lesson isn't to avoid difficult projects. It's to recognize the operational conditions necessary for success before committing to an approach.
Sometimes the best decision is to simplify a project, delay an implementation or acknowledge that a particular solution doesn't fit.
And sometimes the right answer is no.
Why getting to no can be a win
The conversation turned to cybersecurity vendors, where the same problems frequently surface.
Farnum described his frustration with vendors who spend too much time presenting familiar value propositions instead of explaining what problems their products actually solve and how they differ from competing solutions.
Santarcangelo suggested that both vendors and customers would benefit from determining whether there's a genuine fit much earlier.
He offered three questions:
- What problem are you trying to solve?
- What's the value that you can deliver?
- How can you deliver that value for me?
If the vendor's solution doesn't address a problem the customer has, continuing the sales process accomplishes little.
But ending that pursuit doesn't have to end the relationship.
The parties can still exchange ideas, share knowledge and build trust that may prove useful later.
The principle applies just as strongly to internal security teams.
Not every proposed project deserves approval. Not every technical improvement is worth pursuing immediately. And not every problem needs to be solved by the person who first encounters it.
Understanding those distinctions can make security teams more effective.
Solving the right problems builds careers
Santarcangelo believes the ability to identify meaningful problems and deliver recognizable benefits is also essential to professional growth.
"You can solve anything. Maybe you can solve all the things, but you sure as hell can't solve it all at once," he said.
The challenge is choosing problems that matter, understanding the conditions necessary to solve them and ensuring someone recognizes the benefit.
Relationships are central to that process.
Van Ryder observed that professionals who consistently help others build networks they can rely on throughout their careers. Sometimes the most valuable contribution isn't providing a solution personally, but connecting someone with the person who can.
Farnum offered a personal example from his time at Acuvant, before the company became part of Optiv.
He wanted to move beyond his security engineer role but wasn't comfortable with the popular title of security evangelist.
He reached out to Santarcangelo for advice.
Together, they developed the title Security Advocate, which better reflected the role Farnum envisioned. The distinction helped him clarify the responsibilities and present the position to company leadership.
Farnum credited the experience with helping advance his career. Santarcangelo, meanwhile, never asked for anything in return.
It's a reminder that value doesn't always come from a transaction, technology deployment or measurable financial return.
Sometimes it comes from helping someone understand what they're trying to accomplish.
Stop measuring activity. Start delivering outcomes.
Santarcangelo is extending these ideas through his work at ValueSmith and a forthcoming CYBR.SEC.Media series called Recognizing Cyber Value.
He has also developed a Value Delivery Check, designed to help professionals examine whether they have the necessary conditions in place to produce results others will recognize as valuable.
His message isn't that cybersecurity professionals should work harder. In fact, he suggests that some may already be doing too much.
The opportunity is to become more selective about where that effort goes.
For an industry accustomed to measuring progress through vulnerabilities remediated, tools deployed and projects completed, that's an important distinction.
Those activities matter, but they aren't automatically evidence that the organization received the benefit it needed.
Security teams must understand the problem, account for the constraints and define what success looks like to the people who will judge the outcome.
Only then can they determine whether they're delivering meaningful value.
Because solving the wrong problem perfectly isn't success.
It's an expensive way to accomplish nothing.


