From Chief Opinion Officer to Action-Taker

Security leaders who only assess risks and express concerns operate as Chief Opinion Officers rather than change agents. Delivering outcomes requires three things: agreeing on shared data, focusing where decisions compound the defender's advantage, and taking action to advance the security program.

Security leaders spend a remarkable amount of time in spreadsheets, dashboards, slides, and emails. We track metrics, assess gaps, and strategize improvements. Since we rarely control the resources we aim to secure, we express opinions about remediation priorities and steps. All this activity suggests progress. Yet, if we merely rely on others to act, we don’t change the world in any meaningful way.

To succeed, let’s move past the “Chief Opinion Officer” mentality and live up to the CISO title. Doing this requires agreeing with colleagues on what’s real, deciding where to focus, and taking action without striving for perfection.

Agree on What’s Real

Before driving change, we need alignment with our peers on what needs to improve. That means convincing colleagues there’s a problem and that it’s worth addressing. This starts with a reliable source of truth because disagreements over basic facts kill initiatives before they even begin.

Consider this scenario: The security team believes the organization uses 200 SaaS applications. Finance counts 100 because that is how many have purchase orders. IT tracks 50 in their systems management tool. Until those numbers converge, it’s impractical to discuss SaaS governance and prioritize improvements. Each stakeholder will challenge others’ data rather than address the underlying problem.

A common view of the environment provides the foundation. When everyone looks at the same inventory of systems, users, software, and services, discussions shift from “is this real?” to “what do we do about it?”

Building situational awareness and understanding colleagues’ objectives helps make this possible. We need to understand what our peers in IT, engineering, and finance see from their perspectives. By constructing a shared view that represents reality, we can move from confrontation to collaboration.

Decide Where to Focus

Once everyone sees the same picture, we can ask, “Where should we focus?”

Start by challenging the “attacker’s advantage” myth. The conventional claim is that defenders must get everything right, while attackers need only one success. In reality, attackers must succeed at every step across the attack lifecycle. We only need to disrupt one step in that chain to force them to regroup. A single well-placed control, such as SSO across all SaaS applications, can affect multiple attack paths. Decisions that create choke points give us disproportionate returns.

Highest leverage decisions also reduce what needs protecting in the first place. Our time is often well spent decommissioning unused environments, consolidating overlapping tools, and disabling stale accounts. Every resource we remove is a resource we don’t need to patch, monitor, or defend. This is how we escape the vulnerability management hamster wheel: by shrinking what needs to be secured.

Prioritize remediation steps by context, not just severity scores. A medium-severity vulnerability on an internet-facing system with access to sensitive data may warrant faster remediation than a critical finding on an isolated test server. Context-based prioritization also builds trust with the teams who do the patching, because they see that our rankings reflect actual risk.

Focusing on the right areas can create allies throughout the organization. For example, decommissioning unneeded resources improves security while reducing costs. When the CFO sees that our efforts helped cut expenses, we’re more likely to get their support on future projects. Security decisions that align with business outcomes compound over time, building the credibility that funds future work.

Take Action Without Striving for Perfection

Consultants can deliver shared understanding and good decisions, then leave. Security leaders have the responsibility to see changes through and the satisfaction of experiencing their benefits. We must drive change, which means having uncomfortable conversations, negotiating with stakeholders, and accepting that progress is iterative.

To make improvements, we should apply a minimum viable product mentality. For example, we can work with IT to deploy automated weekly OS patching to a pilot group, gather feedback, adjust the scope, and expand from there. Crafting the perfect patching approach can freeze us into inaction. The first version will have gaps, and that’s OK if we’re iterating and moving in the right direction.

For the technical work, we can write policies and configure automation. For human work, we need to understand what motivates the teams that implement the changes. To do that, attend their sprint meetings. Learn how they are measured and what slows them down. Frame requests in terms of their delivery goals, not our risk scores. When people see that we understand their constraints and priorities, they are more likely to support our requests.

Some wins come in three months. Others take three years of steady pressure before the organization absorbs the change. Part of taking action is calibrating acceptable insecurity rather than chasing the perfect state. That patience compounds. Leaders who have accumulated trust and influence over time can accelerate into higher-impact initiatives that were not feasible earlier in their tenure.

Who are we as security leaders? Are we merely assessing and stating opinions? Let’s be action-takers who make the organization more resilient by being there.

If this way of thinking appeals to you, you might enjoy the 20-minute talk I delivered on the topic when I was the CISO at Axonius. I’ve since transitioned out of Axonius.