A Wishlist Is Not a Recommendation

I’ve seen a troubling communication pattern among CISOs, most often appearing in post-incident briefings, budget requests, or board presentations after a near-miss. A lot of security leaders are walking into executive meetings with a list of things that need to happen. This list is accurate and the items on it are both real and usually critical, and then the decision-makers either approve a fraction of it. They deprioritizethe rest or maybe they're simply nodding along during the whole discussion but do nothing.

Unfortunately, the most common reaction I see from CISOs is to blame the audience by saying they don't understand the risk, don't take security seriously, or are distracted by other priorities. Sometimes that's true, but more often than not, the problem is the list itself.

A wishlist is a collection of things you want. A recommendation is an argument for what to do and why – in a specific order, with visible reasoning about what each choice will and won't solve. These are not the same thing, and conflating them is one of the most common communication failures I see in security leadership.

What does a wishlist look like?

The security wishlists I’ve seen in my engagements with CISOs tend to share a few characteristics. First, they are comprehensive and include everything that needs fixing, often organized by category or team. Also, they are roughly equivalent in urgency, claiming that everything is important, which means nothing is truly prioritized. And finally, they’re light on reasoning – the items are presented as conclusions rather than deliberate (or dare I say, strategic) choices. Instead of strategic recommendations, I see a lot of this in executive communications:

• "We need MFA on all privileged accounts." Agreed. Why is that first and not third? What does first mean — first to fund, first to implement, first to present to the board?
• "We need to improve our detection capabilities." Almost certainly true. Detection of what, specifically? Compared to what baseline? What would success look like in twelve months, and how would you know if you got there?
• "We need to address our third-party risk program." Does a bear shit in the woods? For your organization, is that a people problem, a process problem, or a tooling problem? What's the smallest version of this that can move the needle?

When every item on a list is stated with equal weight and vagueness, you have not made a recommendation. You’ve now essentially asked someone else to do the prioritization for you, and when they do, you probably won’t like the outcome.

Why this happens

The good news is that, based on my experience, I don’t believe the wishlist pattern is a laziness problem. It usually comes from one of three places:  

• Completeness anxiety – Security professionals are trained to identify risk comprehensively, so leaving something off the list feels like professional negligence. But completeness and prioritization are different disciplines, and defaulting to completeness in an executive communication context almost always lands poorly. Your job at that moment, in that room, is not to document every risk, but to give leadership what they need to make an informed decision without having to become security experts (if they all become security experts, they don’t need you).
• Fear of accountability – A ranked list is a commitment, and if you say "this is our top priority and here’s why," you can be held to it. A flat list may feel like it’s distributing accountability across everything, preventing any single item from being judged against your reasoning. Despite the instinct for self-protection, this is a poor communication strategy because it teaches your leadership team that your security recommendations lack ownership, so you end up with less influence over the outcome, not more.
• Genuine uncertainty – Sometimes the prioritization work hasn't been done yet, or it was harder than the enumeration work, and time ran out. But uncertainty can also come from an incomplete threat model, dependencies on other teams' roadmaps, budget constraints that haven't been finalized, or a technical environment that changed between the last assessment and today's meeting. The wishlist can be a symptom of neglect, but it can also reflect honest complexity. Either way, presenting it as a recommendation moves the prioritization burden to an audience less equipped to do it.
  

What does a recommendation require?

Generally speaking, a real recommendation includes a few universal elements. 

First, a good recommendation includes a specific claim about what to do. Not "improve detection," but "deploy behavioral monitoring on the management platform with alerting on anomalous credential usage and off-hours access." It needs to be specific enough that someone outside your team could determine whether it happened.

Next, visible reasoning. Not only what, but why, and why in this order rather than some other order. The reasoning should connect directly to what actually happened. For example, "We're recommending this first because it has the most direct causal connection to the incident we just had," is a different argument than "we're recommending this first because it's the fastest to implement." Both can be valid, but neither is implicit.

Recommendations also have an honest account of limitations including what this investment will reduce and what it won't eliminate. This is where a lot of security leaders lose their nerve because they're afraid that naming residual risk will undermine the case for the investment entirely, but it rarely does. What undermines the case is the appearance of overselling. Executives have been sold certainty before (we all have) and we’ve all watched those certainties fail. Naming residual risk explicitly makes a recommendation credible, not weak.

Finally, you’ll know if you’re presenting a real recommendation if you have a clear sense of what "done" looks like. Without a definition of success, you’re presenting an open-ended commitment with no endpoint, which is simply a project without a scope. Boooo. 

If you only make the case after something breaks, you're already behind.

There is a version of this problem that I see show up specifically in post-incident contexts. Security organizations that operate primarily in reactive mode, meaning they wait to make the investment case after an incident, when they think leadership will finally be receptive, are not managing risk. They’re managing by crisis.

A window for investment often opens after an incident, and a list is presented, but only a fraction is approved. Once the urgency fades, attention moves elsewhere, and a new quiet period begins, during which time, the risks that didn't make the approved list continue to accumulate. The next incident may or may not reopen the window. I’ve seen the “governing by crisis” approach consistently deliver two damaging things: 1) it makes everything feel like a crisis, and 2) it ensures that the work of building durable, proactive security programs never quite gets done. The improvements that get funded are only those visible in the rearview mirror of the last incident, not necessarily the ones that prevent the next one.

Security leaders who successfully break this cycle are continuously prioritizing, so they can walk into a leadership conversation on any day, not just after something goes wrong, and clearly state the three things that matter most right now, in this order, and why. Their recommendations don’t depend on an incident being credible – they’re credible because the reasoning is visible and the prioritization is defensible. They no longer need a crisis to be heard.