Part 3: First 90 Days as a CISO – Strategic Execution: From Planning to Action in Your Security Roadmap

Author - Sahil Chadha

As we enter the final stretch of our first 90 days as a CISO blog series, you've built a strong foundation of relationships and gained deep insights into your organization's security posture. Now comes the crucial phase where you'll leverage this knowledge into action, developing and beginning to execute a comprehensive security strategy that addresses the unique needs and challenges of your organization.

Also, you may have observed that although I suggested dividing the timeline into three 30-day segments (i.e., First 30 days, First 60 days, First 90 days), I am intentionally overlapping each segment with the previous one. This approach acknowledges that in real-world scenarios, some items will naturally carry over. The purpose of breaking it down into smaller chunks is to facilitate timely discussions, reviews, and execution while managing the ongoing backlog from prior segments.

So, what's next? 

Till now, you have been playing the role of an observer, reviewer, and auditor to understand the business operation and processes, security & compliance risks, and building a stack ranking of projects for review.

You may have gotten all the required support till now, as asking questions and learning about business most likely didn't impact any team/organization’s deliverable, but that will change the moment you propose new projects, processes, and investments in security technologies. So, it's critical to get the support of stakeholders, and buy-in from them on your strategy before you begin execution. Let's break down the strategies:

Stakeholder Alignment

People truly support a plan if they are asked for input and invited to collaborate. To have stakeholders championing your plan is a multi-step process:

1. Pre-Work: Complete the security review and assessment of unmitigated risks, and stack rank critical and high risks with rough estimates of how much time, effort, and resources it would take to fix each of these risks.

2. Stakeholder Discussion: I have often seen security executives struggle here due to mismatched expectations. The goal here is not to get support for your priority list of items but to build a priority list of items together with your stakeholders, with additional business context (this part gets missed often). 

For example, a critical security risk such as missing MFA to a large dataset containing PII data is not something that security teams may have overlooked, but most likely it would have been in the best interest of the business at that time to not mitigate it. This is why having stakeholder discussions to prioritize security risks with additional business context is very important. For every item on the priority list you may have to do one of the following:

• Compromising: Find a middle ground that works for both parties. This is useful when seeking quick resolutions or working with new or unfamiliar stakeholders. 

  
  

• Collaborating: Aim for a win-win solution. This is most effective when trust is already high, or when you need to establish trust with multiple stakeholders.

• Forcing: Stand your ground and push your narrative especially when it's critical for resolving long-term conflicts or when delaying action would negatively impact the business.

  
  

• Withdrawal:  Step back from the situation when more time is needed to gather information, or when preserving a valuable partnership is more important than resolving a trivial issue.

  
  

• Smoothing: Put others' concerns first when it’s in the best interest of the business overall.

3. Find your champions: During stakeholder discussion, identify stakeholders (preferably within the executive team) that are either security advocates or have a larger pull in driving the decision-making process. You should put additional effort into fostering relationships with these people in the long run, as their support may help sway the decision in your favor.

4. Discussion Aftermath: Recap the discussion and go through the notes to ensure you address all key outcomes and next steps. Specifically, focus on:

• Unanimous Agreement: Risks that got unanimous support to be fixed.

  
  

• Divisive Risks: Risks where you couldn’t build a consensus and weren't deemed huge risks to the business

  
  

• Identify Priority Changes: Assess which risks have been prioritized or deprioritized, and understand the business context influencing these changes. This may include factors such as legacy software slated for decommissioning or limited customer use. Understand which risks were prioritized/deprioritized, and the business context that affected reprioritization such as legacy software, marked for decommissioning, limited customer use, etc.

  
  

• Worth Fighting for? Are there any risks that are off-basis in the new priority list, and whether they warrant a follow-up discussion or a 1x1 chat? It’s important to remember that you are still new to the company, and building relationships may be more important than prioritizing risk mitigation by a quarter or two.

Project Planning

This is the time to break down risks into goals and milestones. A Security Executive has a lot of dependency on their engineering stakeholders for deliverables, so the timeline should be set in partnering with them and understanding their upcoming deliverables. Here’s a basic breakdown:

1. Quick Wins vs Lengthy Battles: In the priority list, you should estimate which risks can be quickly dealt with and which will take a long time to fix, and can span multiple quarters.

2. Facilitator vs Executor: Figure out which projects your organization can execute end-to-end and which projects will require other departments (mostly Engineering) to run with, and you would play a facilitator role (or a Program Manager)

3. Strategy Draft: Build your strategy draft with estimated timelines and resource requirements and now engage your stakeholders with the goal of how we can prioritize these projects. This would be a challenging task, as even though we may have their buy-in, stakeholders already would have their plates full with other projects. 

So, here, we must again apply the previously discussed model of compromising, collaborating, forcing, withdrawing, or smoothing (as outlined in the stakeholder discussion) to effectively balance priorities and reach agreements.

4. Communicate and Evangelize: Once the plan is semi-formalized, where you have agreements with key stakeholders, it is time to communicate the plan with the organization with the following goals in mind:

• Maturing Security: We want to let the organization know that with a dedicated security leader/executive, we are accelerating our security maturity journey

  
  

• Complete Coverage: We want to ensure there are no unknowns and/or we haven’t missed any interested party who would like to contribute to our plan. Also, if there is any resistance to this plan, we will discover it early and ensure we can bring the opposition party on board with our plan.

  
  

• Accountability and Ownership: Writing and sharing your plan broadly makes all stakeholders (including you) accountable for the success/failure of the plan and ensures we have informed broadly that project owners have already agreed to commit their resources to this plan, so any deviation would require a discussion.

  
  

• Continuous Roadshows/Update: Sharing your plan once in a blue moon will not have the desired results, and people will forget your plan, or worse some wouldn’t even know about it. Therefore, keep repeating your plan until it becomes boring or uninteresting to the audience, then only they will grasp or start understanding your plan.

Execution Begins

It’s time for all your hard work to pay off with more work (just kidding). But now the ball is in your court, where you have buy-in for a plan, and resources to support your plan, so now it's all about execution and execution risk. We all know things will not go smoothly, there will be some speed-breakers and roadblocks, but this is where you can rely on your cross-functional partners' support and help to execute. Always use metrics and/or OKRs to measure your success and alignment with the plan. Without measurements, it will be a wild West, and you could neither celebrate your success nor measure deviation from the plan.

Rinse and Repeat

So, we have reached the 90-day mark. What now? Well.. we should take our own advice that “Security is a journey, not a destination”, which means that as long as you are producing anything of value, there will always be risk associated with it. We need to persist in managing risks, continually conducting risk assessments, and addressing all active risks. I know this is not the happy ending that you may be hoping for but the life of a CISO is always filled with risks that need attention.

Final Thoughts

This 90-day framework may not be perfect, or may not apply to you at all, which is totally fine but this framework is something I have built over my decade of experience in the Security space, and have been iterating it through my 3x Head of Security roles. I would encourage you to either use this as a starting point or build your own framework and share it with the CISO community. I wish you the best of luck for your new CISO role and always remember we are here to help.