As I get ready to step into my next assignment, I keep coming back to the same truth: the first couple of weeks in a CISO role can make or break the next twelve months.

Not because you’ll “fix security” in a fortnight. You won’t. Nobody does. But because those first days are when you learn what you’re really walking into—how the organisation behaves under pressure, where the trust sits (and where it doesn’t), and whether the security team is seen as a partner… or as the people who turn up late and say no.

As an independent consultant, I do have to compress this. When you’re parachuting in, you don’t get the luxury of a slow ramp-up. But whether you’re interim, permanent, or fractional, the shape of the work is the same. You’re building a base you can stand on. I’ve ended up calling it the fortnight foundation because it’s the same rhythm I’ve used across financial services, government, and retail—tweaked to context, but consistent in spirit.

There’s also a bit of borrowed wisdom in here. Over the years I’ve had strong mentors and I’ve paid attention to how good CISOs approach their opening moves. The best of them don’t start with tools. They start with the business.

You can’t secure what you don’t understand, and “understanding” isn’t a one-hour induction deck. You want a feel for what the organisation does, how it makes money (or delivers its mission), who it competes with, what it’s proud of, and what it quietly worries about. Ideally, some of that starts before day one. Read what the organisation says about itself in public. Scan press coverage. Look at how leadership talks about strategy. Then you turn up on day one with a bit of context already in your head, rather than trying to drink the ocean after you’ve been given a laptop and a calendar full of meetings.

Week 1: mapping the terrain (and your team)

The first week is about orientation, but not the passive kind. It’s active. It’s you walking the building—physically or metaphorically—and figuring out how things really work.

On paper, most organisations have neat charts and clean ownership. In reality, influence sits in odd places. Decisions get made in side conversations. And critical systems are sometimes “owned” by whoever has historically shouted the loudest in the meetings.

So, early on, I spend time immersing myself in the internal view of the business. Leadership comms, strategic plans, internal newsletters, recent incidents, major projects, and any security strategy that already exists. Then I talk to people. Not formal, stiff interviews. Proper conversations. The kind where you learn what’s working, what’s broken, and what people have stopped mentioning because they assume nobody can fix it anyway.

At the same time, I get to know the security team as people, not job titles. Skills, confidence, frustrations, strengths, gaps. You’re not looking to judge anyone in week one. You’re trying to work out what you’ve got to work with, and where the team needs air cover.

This is also when you start forming a view of the cyber risk environment. Nothing too detailed at this stage—no one has time for that in week one—but you should at least understand the contours. Where is the organisation exposed? What’s public-facing? What’s business-critical? What’s held together with string? What incidents have happened recently, and how did the organisation respond? Was it calm and structured, or chaotic and blame-heavy?

You’ll also get a feel for the risk process itself, if there even is one. Some organisations have beautifully maintained registers. Others have a spreadsheet that hasn’t been updated since someone left. The point is not to tidy it up on day three. The point is to see what the organisation thinks “risk management” means in practice.

Week 2: forging relationships that actually hold

Week two is about widening the lens. Most security leaders fail when they stay inside the security bubble for too long. You can have the best technical plan in the world, but if the rest of the organisation doesn’t buy into it—or sees it as irrelevant—you’ll spend your tenure pushing uphill.

So the focus shifts to stakeholders. Not in a performative “stakeholder management” way, but in a very practical way: who are the people whose work will be impacted by security decisions, and who are the people whose support you need to make anything stick?

This is when org charts become useful, but only as a starting point. The better approach is asking, gently but directly, “Who do I need to know?” Your team will tell you. Your peers will tell you. People in engineering will tell you—often with a smirk—who really runs the show.

Then you start meeting them. Intro chats, yes, but with intent. The goal is to understand what they’re trying to achieve, what pressure they’re under, and what their perception of security currently is. Some will have had great experiences with security teams. Others will have scars. Both matter.

The best question in these meetings is also the simplest: “What’s getting in your way?” Sometimes the answer is security. Often it’s not. But either way, you learn where you can remove friction while still improving control, and where you’re going to have to hold the line.

As those conversations stack up, patterns start to emerge. Common themes. Repeated frustrations. Risks everyone quietly knows about but nobody owns. Opportunities where security can enable something the business wants—faster product delivery, smoother onboarding, stronger customer trust, fewer incidents that derail teams for a week.

This is also where you start balancing proactive and reactive work properly. You’ll inherit problems that need fixing. You’ll also need a roadmap so you’re not just playing whack-a-mole for the rest of your time in the role.

Building foundations that people actually use

The whole point of the fortnight foundation isn’t to create a beautiful plan. It’s to create traction.

That means shaping a team culture where people feel safe raising issues early rather than hiding them until they explode. It means building trust with stakeholders so that when you do have to deliver hard messages—because you will—you’re not doing it as an outsider. It also means establishing a learning mindset from day one. Security is not static. The job changes, the threat landscape changes, the business changes, and your team needs permission to keep developing rather than just running flat out forever.

If those foundations are in place, everything that follows becomes easier. Not easy—just easier. You make better decisions because you understand the business context. You move faster because relationships exist before the crisis hits. And you’re far more likely to build sustainable, risk-based security that supports the organisation’s goals rather than constantly fighting them.

This is the first in the CISO Series blogs. In the next blog, we’ll look beyond the fortnight foundation. Once the initial relationships are in motion and you’ve started to understand the shape of the business and the risk landscape, the next question is obvious: what comes next, and how do you deepen that understanding without drowning in noise?

We’ll start by examining skills.