Most writing about the first 90 days in a security leadership role starts with the mechanics. Assess the environment. Map to a framework. Build a roadmap. Present to the board. That's not wrong, and I'll get to all of it in Part 2. But the engagements that produced lasting results started somewhere else.
They started with a different question: where is this business going, and what risks does that trajectory create?
The mechanics of standing up a security program are well documented. What's less documented is the thinking that has to happen before the first assessment begins, well before the contract is signed. That thinking is what separates a security program that lasts from one that becomes a long and fancy Confluence article no one reads.
This is how I approach the first 90 days. It's one approach, shaped by my own experience and the patterns I've seen repeat across industries, company stages, and organizational cultures. Your situation is likely different. The philosophy should still apply.
This is Part 1 of a two-part series. This post covers the philosophy: the thinking that I believe should come before any assessment, framework, or board briefing. Part 2 will cover the practical framework: pre-engagement scoping, the first weeks of assessment, building the board narrative, and standing up a program.
#The Philosophy
Before any assessment, framework mapping, or board briefing, I strive to understand three things about the organization. These aren't sequential steps; they inform each other and they inform everything that follows.
#Understanding the business trajectory
Security decisions shouldn't exist in a vacuum. A company preparing for an acquisition has a different risk profile than one scaling into a new market, and both look different from one that just landed its first enterprise customer with compliance requirements. The stated trajectory of the business determines which risks matter most. The ones that could prevent this specific organization from getting where it says it's going are paramount.
This means our first conversations aren't about policy. They're about business goals, timelines, and the bets the organization is making. What's the growth plan? What markets are you entering? What commitments have you made to customers, partners, or regulators? The security program has to serve those answers, or it becomes overhead that gets deprioritized the moment budgets tighten.
#Reading the culture
Experience tells me where to explore. But it never tells me what I'll find. What it has shown me is that the most important variable in any engagement is the organization's culture: how people solve problems, who has influence, how decisions actually get made versus how the org chart says they get made.
I've seen technically sound security programs fail because they were designed for an organization that didn't reflect reality. Controls that assume a culture of documentation in a company that runs on Slack threads. Approval workflows built for a hierarchical org imposed on a flat one. Often the people who have to implement and live with security processes every day matter more to the outcome than the people who approved the budget. Understanding how those people work, and building controls they'll actually follow, is what makes controls stick instead of getting routed around inside a quarter.
#Business enablement, not risk reduction
This is where my thinking may differ from conventional guidance. I don't treat risk reduction as the primary goal. Risk reduction that doesn't account for business objectives and human adoption fails at the earliest sign of pressure. When budgets get cut, when timelines compress, when a product launch is at stake, security controls that reduce risk on paper are the first thing to go.
The frame I prefer is based on business enablement. What does this organization need to do, and how does security make that easier or safer to accomplish? That reframe changes the conversation with leadership, with engineering, with the people on the ground. It changes whether leadership sees security as something that slows them down or something that helps them execute. It changes which controls get prioritized and how you measure whether they worked.
#Patterns Worth Avoiding
None of these are unique to new CISOs or fractional engagements. They're patterns that play out across organizations of all sizes, and ones I've fallen into. They usually show up when someone (me?) is in a hurry to demonstrate value.
The template trap. Years of experience create mental models, and those models are useful right up until they become assumptions. An approach that worked at the last organization can feel like a head start at the next one. It hasn't been (for me). The org structure is different, the culture is different, the business trajectory is different. Starting from a prior playbook instead of the current situation is a fantastic way to build something that doesn't fit.
The tool trap. There's a natural instinct to solve a security gap by purchasing something. A SIEM, an endpoint platform, a GRC tool. COTS products rarely do what they promise on the sales call, and budget spent on shelf-ware is both opportunity cost and opportunity lost. The money is gone, the problem isn't solved, and the organization is now more skeptical of the next recommendation. I've found that most early-stage security programs need process and clarity before they need products. A tool deployed into an environment that doesn't have the people or workflows to operate it just becomes something else to manage.
The executive silo. It's natural to orient toward the people who hired you. They're accessible, they speak your language, and they're the ones measuring your impact. But a security program built entirely through executive conversations misses the people who have to live with it. Engineering and operations, the people closest to the systems. Their input shapes whether controls get adopted or routed around.
Risk reduction as an end in itself. This one is subtle because it sounds right. Reducing risk is the job, isn't it? The trap is treating it as the whole job. A control that reduces risk on paper but doesn't account for how a team actually ships code, or how a sales cycle actually works, creates friction that builds quietly until someone with budget authority removes it. Security that doesn't connect to how the business operates gets treated as optional the moment priorities compete.
Banking on the big reveal. There's a temptation to spend weeks in quiet assessment and then deliver a comprehensive board presentation as the first major milestone. The problem isn't the presentation. It's that if leadership is hearing the findings for the first time in that room, the conversation starts with surprise instead of agreement. The biggest mistake I've personally made with executives is exactly this: walking into a room with conclusions that nobody had been prepared for. The presentation was thorough. The reception was not what I expected. The briefings that have gone well were the ones where the communication started weeks earlier and the room already understood the direction.
#What Comes Next
The philosophy and the patterns above are the foundation. They're what I think about before the first meeting, before the scope is defined, before any framework gets applied. Part 2 walks through the practical structure: what happens before the contract, during the first weeks of assessment, through the board narrative, and into building a program that the organization can sustain.
This is Part 1 of a two-part series on the first 90 days in a CISO role. Part 2 covers the practical framework from pre-engagement through day 90 and beyond.