Ryan Frillman published a piece a few weeks ago called "What CEOs Actually Need From Their CISO", and it's stuck with me since. His core argument: an effective CISO doesn't eliminate risk, they increase the organization's confidence to move. He lays out five things CEOs need. They are: the three risks that matter instead of a spreadsheet of thousands, options with real tradeoffs instead of a flat no, AI governance that accelerates adoption instead of blocking it, a security function that runs on process rather than on one person's tribal knowledge, and a CISO willing to disagree with the room when the room is wrong. He also makes a point worth sitting with about M&A: security diligence increasingly decides whether a deal closes on schedule or drags, and the CISO who can speak to that in the room carries weight a checklist never will.
I don't think I've read a cleaner articulation of what the job actually is versus what it's usually measured as. It's worth reading in full. But I want to take the part of his argument I care most about (what "confidence to move" means in practice) and push on it further, because I think it points to something most security organizations still get backwards.
The metrics we report don't answer the question that matters
Walk into most board meetings and the security update looks the same: vulnerabilities closed this quarter, phishing simulation click rates, MFA coverage percentage, maybe a patching SLA chart. These aren't bad numbers. They're operationally useful. A security team should be tracking all of them. But none of them answer the one question a CEO or a board is in the room to find out: whether the business is more capable of executing on its goals because of the money and attention going into security.
A 94% MFA coverage rate doesn't tell you whether the company can close the acquisition it's been circling for eight months. A declining phishing click rate doesn't tell you whether the AI pilot in underwriting is safe to expand past the sandbox. Closing 400 vulnerabilities this quarter doesn't tell you whether the new market the company wants to enter has a regulatory security bar the company can clear. These metrics measure activity. They don't measure enablement, and enablement is what moves the security program from a cost center to a growth-impacting one.
The question I'd ask instead
If I'm reporting to a board, the question I want the numbers to answer is: how much more confidently can this company execute because of its security organization?
That's a different reporting exercise entirely. It means tying the program's output to the decisions the business is actually trying to make this year: not a generic maturity score, but "here's what stands between you and the market you want to enter, here's what we've closed, here's what's still open and what it would take." It means a board coming out of a security update with a clearer read on their own risk tolerance, not a longer list of things to worry about.
Here's the mechanism I'd build into that report: tie a real business-relevant metric to every environment in the asset inventory, not just an owner and a criticality label. What that metric is depends on what the environment does. For a customer-facing system, it's usually revenue and active-user count; for something like an HRIS, it's number of employees onboarded, offboarded, or moved; for shared infrastructure like proxies, it's the daily traffic volume the system handles. Once that mapping exists, remediation stops being a raw count and becomes a business-exposure number. A report can say "60 vulnerabilities closed this quarter in the environment behind $50M in quarterly revenue and 200,000 active users" instead of just "60 vulnerabilities closed."
Risk acceptance gets the same treatment: "leadership accepted this risk in an environment tied to $10M in quarterly revenue and 30,000 active users," instead of a line in a risk register nobody outside security ever reads. I've built plenty of board decks using the standard operational format, because that's genuinely what most executives ask for, and there's nothing wrong with meeting the room where it is. But now that I'm the one setting the reporting standard rather than just executing someone else's, this is the version I hold myself to.
This is the distinction I keep coming back to: security as an insurance policy versus security as an enterprise capability. Insurance is a cost center you tolerate because the alternative is worse. You buy it, you hope you never need it, and its value is invisible until something goes wrong. An enterprise capability is something the business actively draws on to do things it couldn't otherwise do safely. Four places this shows up concretely:
- Market entry. Getting into a new vertical or geography usually means clearing a security and compliance bar before the first customer contract can be signed (SOC 2 or ISO 27001, a state privacy regime, a prospect's own vendor security questionnaire). A security function that's already mapped that bar and knows the gap is the difference between a fast sales cycle and a stalled one.
- Acquisitions. Frillman's point is that security diligence on the target decides whether a deal closes on schedule or drags. What extends that further is what happens after signing: the integration plan for merging two environments without merging two sets of unmanaged risk decides whether that timeline holds just as often as the diligence itself does. A CISO who can walk into that process with a real answer (not "we'll assess it after close") changes what the deal team can commit to.
- AI deployment. Every business unit wants to move faster on AI than security is comfortable with. The programs that accelerate aren't the ones saying yes to everything, or no to everything. They're the ones that can say "here's what this model is allowed to access, here's what it's allowed to do, here's how we validate its output, here's who owns it if it does something wrong" fast enough that the business doesn't route around security to get there. In my previous role, that's how a Microsoft Copilot rollout to more than 1,000 users moved forward: governance guardrails on data access, action scope, output validation, and accountability went in ahead of the rollout instead of standing in its way.
- Cloud migration. Moving workloads is genuinely hard engineering. What actually causes incidents afterward is rarely the migration itself. It's a shared-responsibility gap: teams assume the cloud provider covers something that's still on them, like guest-OS patching in IaaS, and nobody notices until an incident finds it. A program that's already fluent in that line keeps it from becoming a multi-year risk overhang.
None of these get better because a company drove its vulnerability count to zero. They get better because someone in the security organization understood the business decision well enough to make the risk in it legible, and gave leadership something to act on.
What that means for how I evaluate an engagement
Frillman writes from a CISO's seat, laying out what CEOs should expect from theirs. I read it and thought about it from a slightly different angle: what I look for before I agree to take on an engagement.
I don't prioritize the biggest budget or the flashiest title. I prioritize partnering with organizations that actually want a partner: leadership willing to hear "here's what we're trying to accomplish, here's what could realistically stop us, and here's what I'd recommend," and then work through it together rather than delegate the whole risk decision and disappear, or override it without hearing the reasoning. That's the standard every North Avenue engagement is held to. Not "tell me it's fine" and not "tell me no." Tell me what's true, what it costs to change it, and let's make the call together. My job is getting you to a clear recommendation; the decision itself is still leadership's to make.
What would make me walk away? An organization that wants the certificate or the clean audit report and stops there, with no real interest in whether the risk behind it is actually managed. A certification is supposed to represent that the underlying risk is under control, not the risk itself, and chasing the paper instead of the control isn't a fit for how I work. A checked box doesn't tell leadership what their actual risk posture is or what it means for the business, and that's the only thing I'm there to answer.
The security organizations that earn a permanent seat at the strategy table aren't the ones with the cleanest dashboards. They're the ones that made the business more confident, more often, when it mattered. That's a harder thing to report than a vulnerability count. It's also the only number that was ever the point.