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 agreeing with colleagues on what's real, deciding where to focus, and taking action without striving for perfection.

Security leaders spend a remarkable amount of time in spreadsheets, dashboards, slides, and emails. We track metrics, assess gaps, and plan improvements. Since we rarely control the resources we aim to secure, we evangelize remediation priorities and steps. This activity suggests progress.

Yet, if we merely express opinions and rely on others to act, we don’t change the organization in any meaningful way. We must move past the “Chief Opinion Officer” mentality and live up to the CISO title. Doing this requires earning colleagues’ support, deciding where to focus, and taking action without striving for perfection.

Earning Colleagues’ Support

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?”

Situational awareness and understanding colleagues’ objectives make this possible. When we learn what IT, engineering, and finance each see from their vantage point, we can build a shared view that holds up across all three. That is what shifts conversations from confrontation to collaboration. It’s a step toward building that alignment.

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.

We can escape the vulnerability management hamster wheel by shrinking what needs to be secured and accounting for context when assessing risk. 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 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. That credibility pays off when we need budget for the next project.

Take Action Without Striving for Perfection

Consultants can offer sound advice, but 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, applying pressure, and recognizing that progress is iterative.

To make improvements, 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 of the process 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 earn the right to influence teams we don’t control. To do that:

• Earn a seat in their sprint meetings and planning sessions.
• 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 require three years of steady pressure. The organization absorbs change slowly, and part of taking action is calibrating acceptable insecurity rather than chasing the perfect state.

That patience builds capital. Leaders who have accumulated trust and influence over time can accelerate into higher-impact initiatives that were not feasible earlier in their tenure.

Opinions are fast to produce and easy to ignore. The organizations that get more resilient over time have security leaders who agree with their peers on what is real, focus where it matters, and act even when conditions aren’t perfect.

I explored these ideas in a talk I delivered when I was the CISO at Axonius: