The first 100 days as a CISO: a practitioner playbook

Practitioner reference for new CISOs, hiring committees, and the executives sitting opposite a new security leader · 2026-05-24 · Written from twelve years of either being the new CISO, hiring one, or being the consultant called in three months after one started

Why the 100-day frame matters

Most CISOs do not last. The average tenure of a CISO globally has been hovering at around 18-24 months for the last decade, and in India it is shorter still. There is a survival pattern that distinguishes the CISOs who make it past year two from the ones who get reorganised out before year one ends, and almost all of it is set in the first 100 days.

The first 100 days are not about “doing the security.” They are about establishing the conditions under which you can do the security for the next four years. If you spend month one rebuilding the firewall ruleset you have already failed; if you spend month one talking to the right twenty people, you have a chance. The difference matters more than CISO job descriptions ever capture.

I have inherited four security programmes in my career, been brought in to coach incoming CISOs at probably ten companies, and watched a roughly equal number get fired or quietly walk away within the first eighteen months. The pattern is consistent and the playbook is teachable. This guide is what I tell people when they sign the offer letter and ask “now what.”

Before day one — the seven things to negotiate

The single most expensive mistake new CISOs make is treating the offer letter as a fait accompli. The right time to negotiate reporting line, budget authority, and incident-handling latitude is before you sign, not month four when you discover you cannot fix what you were hired to fix.

The seven things to settle before day one:

Reporting line. Is the CISO reporting to the CEO, to the COO, to the CIO, to the CFO, to the General Counsel? In the best case the CISO reports to the CEO or to a top executive who is not the CIO. Reporting to the CIO creates a conflict of interest — IT is the audited party in any meaningful security programme; the CISO cannot audit their own boss. Reporting to legal or risk is workable. Reporting to the CFO is sometimes good (budget alignment) and sometimes bad (security as cost centre).
Board access. How often does the CISO present to the board, with what audience, on what cadence? “Quarterly via the CIO” is materially different from “quarterly directly to the audit committee with no intermediary.” If the board sees you only through your boss’s editorial filter, the board does not really see you.
Budget authority. Independent budget line? Approval authority up to what amount without escalation? Hiring authority for direct reports? Vendor selection veto?
Incident authority. During a serious incident, who calls the shots? Can the CISO unilaterally take systems offline? Can the CISO engage external counsel and forensics without further approval? Is there a pre-existing incident response retainer the CISO can activate? These questions are too late to ask during an active incident.
What the previous CISO actually said when they left. If you can get an honest exit-interview summary from the prior CISO, the value is enormous. They will tell you what is broken, what is unfixable, who the difficult stakeholders are, and what they wish they had known on day one.
The “we are committed to security” sentence in writing. Get the security mandate explicitly stated in your offer letter or in the first board minutes after you start. Phrases like “the board has authorised a security programme commensurate with the risk profile of the business” matter when you are negotiating the budget six months later.
A defined honeymoon period. Most CISOs are expected to “do something visible” within 30 days. Push back. Negotiate for 60-90 days of listening before you are expected to publish your plan. If the executive team will not give you 60 days, the executive team does not actually want strategic security; they want a fall guy.

If any of these come back as “we’ll figure it out as we go” — be very cautious about taking the role. The conditions for success need to be set up front.

Days 1-30: listen, map, baseline

The first thirty days are reconnaissance. You are not making decisions; you are gathering enough information to make defensible decisions later.

The listening tour

Within the first three weeks, I aim to have one-on-one conversations with:

The CEO and CFO. What does security mean to them? What are they afraid of? What have they been told and by whom?
The CIO and head of engineering. These are your operational partners. You need to understand their priorities, constraints, team dynamics, and pet projects.
The General Counsel or head of legal. Especially for regulated industries, the GC is often the most important relationship for a CISO. Legal and security are natural allies.
The head of internal audit. Audit findings tell you what the most recent independent assessment of the security programme looked like. You inherit those findings whether you like it or not.
The previous CISO if reachable. Or the senior security person who has been holding the function in their absence.
Every direct report you will inherit. Individually. Not in a team meeting.
The senior people in HR, product, customer success, and operations. Get their perception of security. Their answer tells you what the gap between “security as marketed” and “security as experienced” looks like.
Two or three key customers if customer trust is part of your remit. Their security questionnaire response is your inheritance.

Do not promise anything in these conversations. Take notes. Ask the same three or four open questions to everyone. The patterns are what matter.

The four things to baseline

By day 30, I want concrete answers to four questions:

1. What do we have? An asset inventory, even an incomplete one. Endpoints, servers, cloud accounts, SaaS applications, network ranges, identity systems. If the existing inventory is bad, that itself is a finding.

2. Where are we exposed? Most recent vulnerability scans, last penetration test, open audit findings, known incidents in the last 18 months, public-facing attack surface (Shodan, BinaryEdge, or equivalent reconnaissance).

3. What are we already doing? Existing policy library, existing tools, existing controls, existing certifications, existing audit obligations, the team’s project backlog.

4. Where does the money go? Current security budget. Tool licences. Headcount cost. Consulting and outsourced spend. The percentage of IT spend allocated to security (see my cyber budget guide for the benchmarks; if you are below 8%, that is a finding).

Do not try to fix anything yet. Document what you find. The temptation to fix the broken thing immediately is the first reflex you have to suppress; you do not yet have the political capital, the budget approval, or the understanding to do it right.

The “what does the CEO think we do” gap

One thing I check in the first month: I ask the CEO what they think the security programme protects against and how. Then I ask the security team the same thing. The gap between the two answers is one of the most useful diagnostics you have.

If the CEO thinks you are protecting against state-sponsored actors but the security team is mostly fighting phishing and password reuse, you have a perception problem to manage. If the CEO thinks you are protecting against insider threats but the team has no DLP, no insider-threat programme, and no exit-monitoring, you have an expectation gap that will manifest the first time something goes wrong.

You either close the gap by educating the executive team about what is achievable, or you close it by raising the programme to match the expectation, or — in some cases — you decide the gap is unbridgeable and you start planning your exit. Better to know in month one than month fourteen.

Days 31-60: pick the wins, surface the truth

Now you are choosing. By day 60 you have published two things — a short list of immediate fixes and a draft 12-month plan.

The immediate-fix list

The criteria for an immediate fix: high impact, low cost, low political risk, and visible to the people you are trying to build credibility with. These are usually not the most security-relevant gaps; they are the ones that change perception.

Examples from real programmes:

MFA on the holdout systems. There are always two or three high-value systems where MFA was deferred. Push them through.
The “everyone has admin” problem. Reduce the number of people with domain admin or root from however many to a defensible number.
The dormant SaaS subscriptions. Tools the company is paying for that nobody uses, often security-relevant ones. Pull the budget back into your programme.
The expired or self-signed certificates on internet-facing services. Cheap to fix, embarrassing if it comes up.
The Stage-Three findings from the last audit that nobody closed. Closing them gets you a clean follow-up and signals competence.

The size of the win matters less than the visibility. The board needs to see momentum. The CEO needs a sentence to say in the next investor call. The team needs to feel that the new CISO is actually shipping.

The draft 12-month plan

By day 60 I want a one-page summary of the 12-month plan. Not a 40-page slide deck. One page. Three sections:

What we will accomplish. Three to five outcomes. Concrete. Measurable. Defensible.
What it will cost. Headcount, tools, services, training. With a single bottom-line number.
What I need from you. Decisions you need from the CEO and the board to execute the plan.

The page is a draft. It will not survive contact with the budget process unchanged. The point is to start the conversation in a structured way and to test whether the executive team will engage with security at this level. If they will not engage with a one-page plan, they will not engage with the programme.

The hard truths that need surfacing

This is where it gets uncomfortable. By day 60 you have seen enough to know what is genuinely broken. Some of it is going to make people defensive when you raise it.

The pattern I follow: surface the truth in writing to the executive who can fix it, before it becomes a public finding. The cycle is:

Document the issue with enough detail that the recipient can act.
Identify the cost of inaction (financial, regulatory, reputational).
Recommend a remediation path.
Set an expectation for response.

If the recipient acts, great. If they do not, you have a paper trail that protects you when the issue eventually becomes a finding or an incident. The CISO who does not document the issues they raised is the CISO who gets blamed for not raising them.

I have done this many times. I have never regretted it. I have several times regretted not doing it sooner.

Days 61-100: build the operating model

The final third of the 100 days is about getting the programme operating in a sustainable way. You are not yet executing the 12-month plan; you are setting up the function to execute it.

The team conversation

By day 60 you should have a view on the team you inherited. By day 80 you need to act on that view.

The team analysis I run:

Who is strong, motivated, and well-placed? Protect them. Make their job easier. Find them growth opportunities.
Who is strong but mis-placed? Move them. The DLP analyst who actually wants to do threat intel; the compliance lead who is bored stiff and would shine in incident response.
Who is weak and needs coaching? Coach them with a defined timeline. Document the conversation.
Who is actively damaging the programme? Manage them out. This is the hardest call to make in the first 100 days and the one that has the biggest long-term impact.

The hire-or-fire decisions you make in the first 100 days set the tone for the next two years. The team watches what you do; the executive team watches whether you can make hard calls.

Do not fire anyone in the first week. Do not fire anyone in the first month. Do not fire anyone without HR involved and documentation. But do not avoid the hard call past day 90 either.

The governance structure

By the end of the first 100 days I want three governance forums in place:

The Security Steering Committee. Monthly. Executive-level. Chaired by you. Attended by CIO, CFO or delegate, GC, head of engineering, head of operations. Reviews progress, surfaces issues, approves significant decisions. This is your forum.
The Security Operations Review. Weekly or biweekly. Operational level. Team leads, key engineers, key product owners. Reviews tickets, incidents, project status. The team’s forum, run by your senior lead, not you.
The Risk and Compliance Forum. Quarterly. Owns the risk register, audit responses, regulatory engagement. If you have a DPO and CISO split, this is where they sync. If GC is involved heavily this is their forum more than yours.

You do not need slide decks for these forums. You need a standing agenda, a tracked action list, and discipline about ending on time.

The first incident

There will be one. There is always one. Sometimes it is a real incident; sometimes it is a fire drill. How you handle it sets the tone for the rest of your tenure.

The pattern I follow:

Listen before acting. Get the facts before opinions.
Communicate frequently and clearly to executives.
Run the technical response through the lead engineer, not yourself; your job is the executive conversation, not the keyboard.
Document everything in real time.
Run a thorough post-mortem and share the lessons learned widely.

The CISO who personally leads the keyboard work during an incident is the CISO who is not doing the CISO job. Resist the urge.

The five traps in the first 100 days

The five patterns I see new CISOs fall into:

1. The reorganisation in week one. New CISO comes in, immediately restructures the team. They have not yet earned the right. The team disengages. The good people leave. Do not reorganise in the first 90 days. If the structure is wrong, sit with it; it is wrong now and it will still be wrong in three months, by which time you will know what to change it to.

2. The grand strategy in month one. New CISO publishes a 50-page strategy. Nobody reads it. The executives feel patronised. The team feels overwhelmed. One page first; the long version comes later, if at all.

3. The immediate red team. “I need to know what we look like to an attacker.” Maybe. But hiring an external red team in month one usually surfaces findings the team already knew about, costs ₹15-25 lakh, and creates a wave of remediation work that displaces the work that actually needs doing. Wait. Do internal validation first.

4. The hero CISO. “I will personally lead the response, I will personally review every incident, I will personally interview every candidate.” This works for about three months before you burn out. Build the team and the operating model that makes the function work without you in the room.

5. The honeymoon overspend. New CISO arrives, the board says “what do you need,” the new CISO commits to a big budget and a long list of deliverables. Three months in the reality of execution sets in. The promises were too aggressive. The credibility erosion is steep. Promise conservatively; deliver consistently; expand from there.

The Indian context — specific dynamics

A few things that are specifically Indian (or specifically intense in India):

Family-business CEOs. In many Indian companies the CEO is also the founder or part of the founding family. Security to them is often deeply personal — it is their company. The good news: they will support security if they trust you. The bad news: trust takes longer to build, is built differently, and can be lost in one bad meeting. Invest in the personal relationship; do not run everything through email.

The compliance-driven mandate. Most Indian CISOs are hired in response to a specific regulatory pressure — RBI Master Direction, SEBI CSCRF, DPDPA preparation, a customer requiring SOC 2. The mandate is narrow. Expanding the mandate beyond the original driver requires deliberate effort. Plan for it.

The CISO-CTO conflict. In many growth-stage Indian companies the CTO has been the de facto security lead for years and may not welcome a new CISO. This is a relationship-management problem more than an authority problem. The CISO who wins by escalating loses; the CISO who wins by genuinely partnering wins.

Budget reality. Indian companies often spend 4-7% of IT budget on security versus a 10-15% global benchmark. This is the headline number you will be fighting. It does not improve overnight. Plan a 24-month ramp, not a 6-month one.

Talent constraint. The pool of strong Indian security engineers is much smaller than demand. Senior people get bid up aggressively. Junior people churn. The team you inherit may be more constrained by external market dynamics than by anything you can fix internally.

What I would do differently if I were starting again today

Three things I now do that I wish I had done from the start:

Bring my own template for the first board update. Write it before day one. Edit it as you learn. Use it in the first board meeting. The CISO who walks into the first board update relying on the existing template is using the previous CISO’s framing — and the previous CISO’s framing did not work, which is why they are no longer in the role.
Document a “what I have not yet had time to assess” list. Make it explicit. Share it with the executive team. Things on the list are things you have not yet looked at; the executive team needs to know what is and is not covered by your current view. This prevents the “well, I assumed you had assessed that” conversation six months in.
Build the external network from week one. Other CISOs in your industry. Industry associations. The regulators if you are in a regulated sector. Auditors you trust. Forensics retainers. Counsel you trust. These relationships are extremely valuable when you need them and impossible to build in an emergency. Start them when you do not need them.

What this guide does not cover

Three areas worth their own treatment:

Specific technical priorities. I have not told you what to put in the 12-month plan because the answer depends entirely on the business. A SaaS company optimising for SOC 2 has different priorities from a manufacturing company optimising for IT/OT segmentation. The framework is universal; the content is not.
The CISO-CEO succession dynamic. What happens when you outlast your boss. What happens when your sponsor leaves. These are real questions for any CISO planning beyond year two, and they deserve a separate treatment.
What to do in the last 100 days before you leave. The exit handover is as important as the entry. The CISO who leaves a programme that survives is the CISO who has earned the right to take the next role. The CISO who leaves chaos behind takes that chaos with them. Worth a guide of its own.

This is a practitioner reference, not coaching. It reflects what works and what doesn’t across CISO engagements in India and internationally as of May 2026. Each context is different; the framework is portable, the playbook should be adapted.

ControlForge maps the operational controls that a new CISO inherits across ISO 27001, SOC 2, NIST CSF, RBI CSF, SEBI CSCRF, and DPDPA, and surfaces the cross-framework strictest-clause synthesis the programme will be assessed against.