Programme Leadership·~18 min read·3,917 words

The last 100 days as a CISO: the exit handover playbookPremium

Practitioner reference for outgoing CISOs preparing to leave well, incoming CISOs about to inherit a programme, and the executive team holding the chair while it transitions · 2026-05-25 · Written from twelve years of either leaving programmes, inheriting them, or being the consultant called when a CISO transition went badly and the regulator started asking questions about who is now accountable


Why the exit matters as much as the entry

The first 100 days as a CISO get the attention. Coaches write about them, executive search firms reference them, the CISO themself thinks about them. The last 100 days get almost no attention. The result is that most CISO exits are bad — for the outgoing CISO, for the incoming CISO, and for the organisation that has to absorb the gap.

I have watched perhaps twenty CISO transitions closely over the last twelve years. The pattern of what works at the entry is reasonably well documented (and I have written about it elsewhere). The pattern of what works at the exit is barely written about. The conventions are vaguer, the politics are harder, and the outgoing CISO often has a foot already out the door, focused on the next role rather than the one they are leaving. The result is that institutional knowledge walks out with the departing CISO, the programme drifts during the gap, and the incoming CISO inherits chaos they have no context for.

This guide is the exit playbook I wish I had been given the first time I left a CISO role. It is also the playbook I now coach outgoing CISOs through when they ask me to help them leave well. The thesis is that the last 100 days are as career-defining as the first 100 — not because of what they do for your next role, although they affect that, but because of what they do for the programme you are leaving. The CISO who leaves chaos behind takes that chaos with them; the CISO who leaves a programme that survives earns the right to be remembered as the leader who built it.


When to decide you are leaving

The decision to leave a CISO role usually comes from one of four places, and the place matters for how the exit goes.

You are leaving for a better opportunity. A larger role at a larger organisation, a strategic move into a CSO-style position, an industry change you have been wanting. The exit can be planned and clean. You owe the organisation a long notice period and a thorough handover.

You are leaving because the role has become impossible. The reporting structure changed, the budget was cut, the executive team changed, the strategic priorities shifted, the new CEO does not value security. The exit is forced even if not formally so. You owe the organisation an honest handover but a shorter notice; staying longer in a role that has been made impossible benefits nobody.

You are leaving because something went wrong. An incident, an audit finding, a governance breakdown. The exit is reactive. The handover is partial because you are still close to the events. You owe the organisation continued cooperation in the investigation but not a long handover; the next CISO needs to come in with their own framing.

You are leaving for personal reasons. Burnout, family, health, geography. The exit can be planned but the energy may not be there for a long handover. You owe yourself the priority here; a thorough handover is good but not at the cost of your wellbeing.

The decision-to-act timing is its own question. The CISO who decides to leave should give themselves a 6-12 month horizon between deciding and announcing. The decision is private during that period. Use the time to either fix the problems that made the role untenable (which sometimes works and changes the decision) or to position the programme for handover (which always works and improves the eventual exit).

The CISOs who exit poorly tend to share one pattern: they made the decision and announced it within the same month. The compression leaves no time to position the programme for the transition; the handover is rushed; the next CISO inherits a worse version of the programme than they would have inherited with a longer planning horizon.


The four-week notice window

When the formal notice goes in, the clock starts. The conventional notice period in CISO roles is 4-8 weeks; some senior roles negotiate longer transition periods. The four-week minimum is what most contracts specify; eight weeks is more realistic for a clean exit.

What gets done in the notice window, in order of priority:

Week 1: Triage and stabilise. The organisation now knows. Communications to the team, to stakeholders, and to the board are first. Frozen for the duration of the notice window: any major new initiatives, any new vendor commitments, any organisational changes within the team. The programme runs in maintenance mode. This is not the time to launch the new GRC tool, sign the new MSSP, or restructure the security operations team. Continue what is running; do not start what is new.

Week 2: Documentation sprint. This is where the institutional knowledge gets externalised. The documentation that exists is rarely sufficient for someone new to operate the programme. The CISO who has been running the programme in their head needs to externalise that operating knowledge for the successor.

Week 3: Stakeholder handover. The board, the audit committee, the executive team, the regulators if applicable, the major customer auditors if applicable, the key vendors and IR retainers. Each stakeholder needs a personal handover, not just a notification. The relationships the outgoing CISO built do not transfer automatically.

Week 4: Team handover and exit. The direct team gets time with the outgoing CISO that is not about transactional work. What is each team member working on, what are their growth needs, what are the risks the outgoing CISO sees in the team, what should the next CISO know about specific individuals. This is the most sensitive week and the one most often shortened or skipped.

If you have an eight-week notice or longer, the additional weeks go into deeper documentation, more stakeholder time, and a shadow period where the successor (if identified before exit) starts to take operational decisions while the outgoing CISO is still in the chair.


Documentation that travels (and documentation that doesn’t)

The documentation problem is the largest single failure point in CISO exits. The CISO has been running an operating model in their head — what matters, what doesn’t, which controls are real and which are paper, which relationships matter, what the live risks are. The documentation that exists tends to capture the formal version of all of this but misses the operating model itself.

What needs to be written down, in priority order:

The live risk register, with the unwritten parts. The formal risk register lists known risks with treatments. The unwritten parts are the risks the CISO has been carrying mentally but has not formalised: the legacy system that is one bad week away from a serious incident, the vendor that is technically fine but the relationship is brittle, the team member whose departure would be operationally significant, the audit finding that is officially closed but practically open. These belong in a confidential handover document, not in the public risk register.

The capability inventory with reality flags. What the programme is rated as doing well, what it is rated as doing poorly, and what the public rating overstates. “We are rated mature on detection because the SIEM exists; the operational reality is that the use cases are not tuned and the SOC alert quality is poor” is the kind of honest annotation that survives the transition. The next CISO discovers the same gap eventually; better that they discover it on day three from documentation than on day ninety from an incident.

The board narrative. What story has the CISO been telling the board over the last 1-3 years. What did they commit to. What metrics did they emphasise. What questions did the board ask repeatedly. What is the board’s current understanding of the programme’s posture. The incoming CISO needs to know what story the board has been hearing in order to either continue it credibly or change it deliberately. Walking in blind to the board narrative and reflexively contradicting it is the most common credibility-destroying move for a new CISO.

The vendor map. Not the contract list — the operating-level map. Which vendors are critical, which are replaceable, which have specific quirks the next CISO needs to know, which contracts are coming up for renewal, which vendor relationships are personal (the CISO’s relationship with a specific account exec at a specific firm) and will need rebuilding.

The audit history and the regulator history. What audits have been done in the last three years, what findings recurred, what findings closed and how, which auditors are easier to work with and which are harder. If the organisation is in a regulated sector, what supervisory letters were received, what inspection visits happened, what the regulator’s known concerns are. The regulatory memory is hard to reconstruct; preserve it.

The pending decisions. What decisions have been deferred. The investment that was queued for next quarter, the policy revision that is in draft, the structural change that is being considered. The next CISO needs the option to inherit these decisions or to defer them further; what they cannot do is rediscover them three months in.

What does not need to be written down: anything in the formal policy library, the formal control inventory, the formal procedure manuals. Those exist and the incoming CISO will read them. The handover document is for the operational reality, not the formal documentation.

The handover document is best built in two layers: a publicly-shareable layer (the maps, the capability inventory with reality flags, the vendor map) that can be reviewed with HR and the executive team, and a confidential layer (the unwritten risks, the personnel notes, specific named concerns) that goes only to the incoming CISO and the audit committee chair.


The board exit conversation

The CISO’s last board meeting is significant. Not because the board needs a tearful exit speech — they do not — but because it is the last opportunity to set the record on the programme’s actual state and to position the incoming CISO.

The structure that works:

State the truth about the programme. This is the moment to tell the board honestly what is real and what is not. Where the programme is genuinely strong, where it is exposed, what the next CISO will likely find. The board needs the honest baseline so that they can hold the next CISO accountable to it.

Acknowledge what you did not get done. Every CISO leaves with unfinished work. Naming it is more credible than pretending it does not exist. “I committed to closing the third-party assessment programme gap and did not. The next CISO will likely raise this as a priority; the board should support that.”

Position the incoming CISO if known. If a successor has been named, the outgoing CISO has an opportunity to publicly back them. Specific: “I have spent eight hours with [name] and I believe they are well-suited for the next phase. The programme will benefit from their focus on [area].” This statement carries weight with the board that the new CISO cannot manufacture on their own.

Make the asks you have been holding. The investments you wanted but did not get. The structural changes you wanted but did not push hard enough for. Lay them out for the board so the next CISO can pick them up. The outgoing CISO has no further career stake; the board hears the asks differently from someone who is leaving than from someone still in the role.

Thank the board specifically. Specific board members who supported the programme. Specific decisions that were the right ones. The thanks should be genuine; performative gratitude reads as insincere in this moment.

The exit board conversation should be a separate agenda item from the routine update, with 30-45 minutes allocated. If it is squeezed into the closing minutes of an ordinary meeting, the conversation does not happen properly. The audit committee chair usually facilitates this if the dynamic is healthy.


The team handover

The team is the part of the handover that most affects the programme’s continuity. Documents can be rewritten; the team is the institutional memory and operational capacity.

The outgoing CISO’s job in the final weeks:

One-on-one with each direct report. Honest conversations about what each person is doing, what their growth needs are, what the outgoing CISO sees as their strengths and gaps. The conversation should produce notes that the incoming CISO can read. The notes should be honest; the team member should know the notes exist; the team member should not necessarily read them.

Skip-level conversations with the next layer down. The CISO who only talks to their direct reports loses visibility into the broader team during the handover. Skip-level conversations surface what the directs may not be saying, particularly about team morale, hiring needs, and the things the next CISO should know.

Honest assessment of who needs support during the gap. Some team members thrive during a leadership gap; others struggle. The outgoing CISO can identify who needs additional support from peers, from HR, or from the interim leadership, and arrange it before exit rather than discover it from a resignation letter three weeks later.

The retention conversations. During a CISO transition, the strongest team members are the most at risk of leaving. Recruiters know about the transition; they target. The outgoing CISO should have a direct conversation with each at-risk person about what would keep them, and pass that information to the incoming CISO. Some retention conversations have to be backed by compensation commitments; the outgoing CISO can advocate for these even if they cannot directly authorise them.

The unspoken farewells. Some team members the outgoing CISO has been carrying — not formally, but in the sense of running interference for them, protecting their projects, smoothing political conflicts. The next CISO may not have the same instinct or the same context. The outgoing CISO should be honest with these team members about what changes when the protection ends. Sometimes the change is fine; sometimes the team member needs to consider whether the next phase is right for them.

The team is also where the cultural transition happens. The outgoing CISO has been setting a tone — what is expected, what is rewarded, what is tolerated. The incoming CISO will set their own tone. The handover should help the team understand that the tone change is normal and not a critique of the previous CISO. Avoiding this conversation produces a team that resists the new CISO’s tone because they read it as betrayal of the previous one.


Vendor and external-party transitions

The CISO’s external relationships are sometimes formal (contracts, MSAs, retainers) and sometimes informal (the specific human who picks up the phone at 2am during an incident). The formal relationships transfer automatically; the informal ones do not.

A short list of the external relationships that need active handover:

The IR retainer. Who is the named contact, what is the activation protocol, what is the contracted response time, what is the actual response time experience. The incoming CISO should have a meeting with the retainer’s senior contact in the first 30 days; the outgoing CISO can broker that meeting before exit.

External counsel. Both the regular outside counsel for privacy and security work, and the specific incident counsel if separately retained. The relationship is partly with the firm and partly with the named partner; the named partner is what matters. Broker the transition explicitly.

The cyber insurance carrier and broker. Not the contract — that transfers — but the relationship with the broker who advocates for you during a claim. Brokers who like the CISO advocate harder; new CISOs without the broker relationship get the standard service.

The major customer auditors. If you have specific customers whose security questionnaires and audits dominate your time, the relationship with their security and procurement teams is meaningful. A handover call with the next CISO included can save weeks of friction in the next audit cycle.

The regulator if applicable. For regulated sectors, the CISO often has named contacts at the supervisory authority. RBI cybersecurity supervision, SEBI’s IT cell, IRDAI’s information security team, sectoral CERTs. The transition should be communicated to these contacts deliberately, not discovered when the next CISO sends an email from an unknown signature.

Industry peers and ISACs. The peer-CISO network the outgoing CISO has been part of. Brokering the next CISO’s introduction into the peer network is one of the most valuable things the outgoing CISO can do. The peer network is hard to break into from outside; an introduction from a respected peer accelerates it significantly.

The mechanics of handover for these relationships is usually a joint call (outgoing and incoming CISO with the external party) followed by a direct relationship between the incoming CISO and the external party. Both pieces matter; either alone produces a weaker transition.


The open-incidents problem

If the CISO is leaving while incidents are open — active investigations, active disputes with vendors, active regulatory matters, active customer audits — the handover gets more complex.

The right approach is to triage the open items into three categories:

Items that should close before exit. Incidents where the close is days away, audit findings that are days from remediation, disputes that the outgoing CISO has the most context to resolve. Push to close these before leaving; do not hand off a stale-by-a-week incident to the next CISO.

Items that need to transfer with full context. Incidents that are weeks or months from close, regulatory matters that have a long tail, ongoing investigations. These need a structured handover document specific to each item: timeline, parties involved, current status, next step, decision points pending, the outgoing CISO’s view on likely outcome. The handover document is read into the formal record so that the next CISO inherits the institutional memory in writing.

Items where the outgoing CISO needs to stay engaged briefly post-exit. Some matters cannot be transferred clean. Specific regulatory inquiries where the regulator wants the original CISO’s testimony, specific litigations where the outgoing CISO is named, specific incident investigations where the outgoing CISO’s continued involvement is required by the engagement letter. The outgoing CISO should agree to a defined post-exit engagement period (typically 30-60 days, sometimes longer for litigation) at a defined rate, formalised in a consulting agreement.

The post-exit engagement is sometimes uncomfortable to negotiate but is much better than the alternative, which is the outgoing CISO refusing to engage and the organisation losing the institutional memory that the matter required. A clean consulting agreement protects both sides.


What to take with you

The outgoing CISO has built up artefacts and knowledge over their tenure. Some of it belongs to the organisation; some of it belongs to them. The line is not always obvious.

Belongs to the organisation, leave behind: All policies, procedures, runbooks, configuration data, the risk register, the control inventory, the vendor contracts and assessment data, audit reports, the actual security tools and their configurations, customer data and customer security questionnaire responses, the regulatory correspondence.

Belongs to the CISO, take with: Personal learning notes, public-facing presentation materials the CISO authored, the CISO’s external network and contact list (LinkedIn is portable), generic templates the CISO developed (anonymised), the CISO’s understanding and skills.

Grey zone, negotiate: Speech and conference materials developed while at the organisation, especially if delivered as the organisation’s CISO. Coaching notes from working with the team. Strategic plans the CISO drafted. The standard approach is that materials representing the organisation belong to the organisation; the CISO’s contribution can be referenced in future work as “I led the development of X at [previous employer]” without taking the artefact itself.

The grey-zone items are worth negotiating explicitly during the exit. A short conversation with HR and the GC produces a written understanding that protects both sides; the alternative is the outgoing CISO removing materials they think are theirs and the organisation discovering it months later and getting angry.

A useful discipline: the outgoing CISO should not download organisational files in the final two weeks. The audit trail is unflattering; the legal exposure is real. If something is needed for post-exit reference, it is acquired through the proper channel before the formal notice or requested formally during the notice period.


The first 30 days after leaving

The exit does not end on the last day. The CISO who has left has a 30-day window where they remain relevant to the organisation and where their conduct shapes how they are remembered.

Respect the confidentiality period. Most CISO exits include a confidentiality and non-disclosure agreement. Some include non-disparagement. The 30-day window is not the moment to test the limits of these agreements. Whatever frustrations existed in the role, the outgoing CISO is best served by exiting cleanly.

Be available for specific questions. The successor or the executive team will have questions. Specific questions about specific decisions, specific contacts, specific contexts. The outgoing CISO who takes those questions cleanly and quickly earns respect; the one who is unreachable creates the impression that they left chaos deliberately.

Do not actively manage the programme from outside. Even if friends remain in the team, even if the successor asks for “ongoing advice,” the outgoing CISO is no longer the CISO. Active management from outside undermines the successor and confuses the organisation. Be a resource on specific questions; do not be a shadow CISO.

Update your public profile carefully. LinkedIn is the natural place. The update should be respectful of the previous role and accurate. Announcements that read as critical of the previous employer create lasting reputational damage; announcements that are gracious about the previous employer tend to age well.

Decompress. Most outgoing CISOs underestimate how exhausted they are. The CISO role runs on adrenaline for years; the exit is often the first time the adrenaline drops. Take a real break. Avoid jumping into the next role for 30-60 days if the finances allow. The next role will be better for having had the gap.


What this guide does not cover

Three areas worth their own treatment:

  1. The involuntary exit specifically. If the CISO is being fired or pushed out, the dynamics are different. Some elements of this guide apply (the documentation, the team support); others do not (the board exit conversation, the deliberate handover pace). The involuntary exit deserves its own playbook focused on protecting the CISO’s interests while still leaving the programme in tolerable shape.

  2. The international relocation exit. When the CISO is leaving the country or relocating significantly, additional logistics apply — work authorisation, transition timing, family considerations. These add complexity not covered here.

  3. The CISO-to-founder transition. Some CISOs leave to start their own ventures, often in the security space. The transition has specific dynamics around non-compete clauses, customer relationships, and conflict of interest that warrant separate treatment.


This guide is a practitioner reference, not employment or coaching advice. It reflects what works across CISO transitions in India and internationally as of May 2026. Each exit is shaped by specific circumstances; the framework is portable, the playbook should be adapted.

ControlForge maps the operational controls and institutional knowledge that survive a CISO transition across ISO 27001, SOC 2, NIST CSF, RBI CSF, SEBI CSCRF, DPDPA, and other frameworks, and supports the documentation discipline that makes the handover possible.