Days 31–60: Assess the Landscape and Build Your Roadmap

Blog Series: Your First 90 Days as a CISO

Post 2 of 4

A Plain-English Guide for New, Aspiring, and Future Security Leaders

---

The listening phase is behind you. You've spent your first month meeting people, asking questions, and building a mental model of the organization. Now it's time to put that knowledge to work.

Days 31 through 60 are the analytical heart of your first 90 days. This is when you move from gathering impressions to building a structured, evidence-based picture of where the security program actually stands. And critically — this is when you start translating that picture into a plan. A real plan. One with priorities, timelines, and a clear story about where you're taking the security program and why.

A word of warning before we dive in: this phase requires intellectual honesty. It's tempting to frame your assessment in whatever light makes the path forward easiest. Maybe you want to avoid bad news that might reflect poorly on your decisions in month one. Maybe you're already attached to a strategic direction you came in with. Whatever the temptation, resist it. The only assessment worth doing is an honest one. Bad news surfaced in month two is a problem you can solve. Bad news ignored until month eight is a crisis.

📋 ABOUT THIS SERIES

• Post 1: Days 1–30 — Listen, Learn, and Don't Break Anything
• Post 2: Days 31–60 — Assess the Landscape and Build Your Roadmap (you're here)
• Post 3: Days 61–90 — Start Executing and Show Early Wins
• Post 4: Winning the Room — How to Gain and Keep Executive Support

Conduct a Formal Security Assessment

A formal security assessment doesn't have to mean a six-figure engagement with a big consulting firm. What it does mean is a structured, documented review of your security program's current state across the three dimensions that matter most: people, processes, and technology.

Using a recognized framework to structure your assessment makes this significantly easier — and more credible. NIST CSF, CIS Controls, and ISO 27001 all provide ready-made structures you can assess against. The benefit of using one of these isn't just organizational convenience. It's that your findings will be expressed in language executives, board members, and auditors already understand. When you say "we're at a maturity level two across the Detect function of the NIST CSF," that communicates something meaningful to anyone familiar with the framework — which, in 2025, is a lot of people.

Assessing Your People

Start with your team. Not just their technical skills, but the full picture of who they are and how they're set up to succeed or struggle.

What does the org structure look like? Are the right roles filled? Are there critical capabilities missing — incident response expertise, cloud security knowledge, application security skills? What does morale look like? A burned-out, understaffed team that's been grinding without leadership or recognition is a different problem than a well-resourced team with skill gaps, and each requires a different response.

Look at how security responsibilities are distributed beyond your direct team as well. Are there security-adjacent roles in IT, Legal, or Compliance that effectively carry security responsibilities without formal recognition or coordination? This is common — and it's often where gaps live. When everyone thinks someone else owns a problem, nobody owns it.

Talk to your team members individually about where they feel confident and where they feel stretched. What do they wish they had more support on? What are they handling that they don't think falls within their expertise? These conversations are gold. Your team members know exactly where the program is strong and where it's held together with duct tape. Your job is to create enough trust that they'll tell you.

Assessing Your Processes

Process assessment is where many new CISOs encounter their first significant surprise: the gap between documented policy and actual practice. An organization can have an incident response plan, a patch management policy, and a vendor risk management program — all beautifully written, all sitting in a SharePoint folder no one has opened in eighteen months.

For each major security process, ask two questions: Does it exist? And is it actually being followed? Then add a third: Is it working? A process that exists and is followed but isn't effective is just as much a problem as a process that exists only on paper.

Key processes to assess include: vulnerability management and patch management, incident detection and response, access control and identity management, security awareness training, third-party and vendor risk management, business continuity and disaster recovery, and change management. For each one, document where the process currently stands and where it needs to go.

One practical tip: look at the exception logs and the variance reports. Processes that are functioning well tend to generate documentation of exceptions — cases where standard procedures weren't followed and why. Processes that are broken tend to have no exception documentation at all, because no one is tracking compliance consistently enough to notice.

Assessing Your Technology

The technology assessment is often where security leaders feel most comfortable, and where they can most easily lose the forest for the trees. Yes, you need to understand what tools are in place. But more important than the tool inventory is the question of whether those tools are actually configured, monitored, and maintained to the level that makes them effective.

Security tooling sprawl — having dozens of products that overlap in function and none of which are optimally configured — is one of the most common conditions you'll encounter. Organizations accumulate tools over time, often in response to specific incidents or audit findings, without ever stepping back to rationalize the portfolio. The result is significant cost and operational overhead with less coverage than a smaller, well-managed set of tools would provide.

For each major tool category — endpoint protection, network security, identity and access management, SIEM, vulnerability scanning, email security, and so on — document what you have, whether it's properly configured, who is responsible for maintaining it, and whether it's actually providing the coverage it's supposed to. You'll likely find at least a few tools that are technically deployed but effectively unused. Those are both a risk and an opportunity.

💡 Pro Tip

Structure your assessment against a recognized framework like NIST CSF or CIS Controls. It gives your findings a common language, makes it easier to communicate with executives and auditors, and positions you for regulatory conversations down the road. NIST publishes free crosswalk documents showing how the CSF aligns to most major compliance requirements — use them.

Map Your Regulatory and Compliance Landscape

Here is something that surprises a lot of new CISOs: regulatory risk is security risk. They are not separate conversations, and if your assessment only looks at technical controls and security posture, you're getting an incomplete picture.

Before you finalize your risk priorities, you need a clear map of every regulatory and compliance obligation that applies to your organization. This is not just an IT exercise. It requires input from Legal, Compliance, Finance, and the business teams that operate in regulated markets or handle sensitive data.

Ask your Legal and Compliance teams: What regulations govern how we handle data? Are there industry-specific requirements like HIPAA for healthcare, PCI DSS for payment card data, or NERC CIP for energy systems? Are there contractual security requirements from major customers or partners? Are there state-level privacy laws — like CCPA in California or similar laws in other states — that apply to our operations? Are there active regulatory examinations or audit findings that haven't been fully remediated?

The answers to these questions will directly shape your risk priorities. A critical technical vulnerability is serious. A critical technical vulnerability that also puts you out of compliance with HIPAA or GDPR is both a technical problem and a legal and financial one. Regulatory exposure can mean fines, enforcement actions, contract terminations, and reputational damage that dwarfs the cost of the security fix that would have prevented it.

Map your regulatory obligations explicitly, and then cross-reference them against your security assessment findings. Anywhere the two overlap — a security gap that also creates regulatory exposure — moves to the top of your priority list.

Identify and Prioritize Your Biggest Risks

Once your assessment is complete, you'll likely be looking at a long list of gaps and issues. This is normal. No organization's security program is perfect, and a thorough assessment will always produce more findings than you can immediately address. The question isn't whether you have gaps — you do. The question is which ones matter most.

Prioritization is one of the most critical skills a CISO can develop. The wrong framework for prioritization leads to teams spending months improving things that matter little while genuinely dangerous exposures go unaddressed. The right framework focuses your limited resources on the risks that could cause the most harm to the business.

Evaluate each finding through two lenses: likelihood and impact. How likely is this gap to be exploited, given the current threat landscape and the organization's specific profile? And if it were exploited, what would the actual business impact be — in terms of operations, revenue, reputation, regulatory exposure, and customer trust? The combination of high likelihood and high impact defines your critical priorities.

Ruthlessly prioritize the findings that could genuinely hurt the business most. Common areas that rise to the top in most organizations include: exposed or poorly segmented attack surface, weak identity and access controls, insufficient visibility into what's happening on the network and endpoints, absence of a tested incident response capability, and unmanaged third-party risk. Chances are several of these apply to your environment — and that's where your attention should go first.

💡 Pro Tip

When presenting risk findings to executives, resist the urge to list everything. Pick your top five to seven risks and present them clearly with the business impact of each. A focused, well-articulated risk picture gets attention and drives decisions. A 47-item risk register gets filed away and ignored.

Draft Your Security Roadmap

With your risk priorities in hand, you can now build your roadmap. A security roadmap is simply a structured plan that shows where the program is going, in what sequence, and why. It translates your assessment findings into a forward-looking agenda.

The best roadmaps are organized in phases. Your 90-day phase addresses immediate, high-priority risks and quick wins. Your six-month phase builds the foundational program elements that your longer-term strategy will rest on. Your twelve-month phase maps the strategic improvements that will take the program from reactive to proactive and mature.

Every initiative on your roadmap needs to be tied to a business outcome. Not a security outcome — a business outcome. This isn't just about how you present it to executives, though that matters enormously. It's about making sure that every investment of time, money, and organizational goodwill is directed at something that genuinely makes the business safer, more resilient, or better positioned to meet its obligations. If you can't articulate the business case for an initiative in one or two sentences, you either don't understand the initiative well enough or it shouldn't be on the roadmap.

Keep the roadmap readable. A one-page visual with color-coded phases and brief descriptions will be consulted regularly. A forty-page document will be read once and forgotten. Your roadmap should be something you can put in front of a business leader and have them understand within two minutes what the plan is and why it matters.

Start Building Your Business Case

A roadmap tells people where you're going. A business case tells them why it's worth the investment to get there. You'll need both, and month two is the right time to start building the business case for the resources and changes your program requires.

Business cases for security investments are most compelling when they speak the language of risk and business impact. What's the potential cost of a breach given your organization's size, data profile, and industry? What regulatory fines could result from the compliance gaps you've identified? What would business disruption from a ransomware attack cost in lost revenue and recovery expenses? What efficiency gains could the right security tools and processes deliver?

Collect benchmark data from your industry. Breach cost reports from IBM, Verizon's Data Breach Investigations Report, and sector-specific studies give you credible third-party data to support your risk quantification. When you can tell the CFO that the average cost of a breach for a company of your size and industry is X million dollars, and then show how your proposed investment in specific controls reduces that risk, you're speaking a language that resonates in budget conversations.

Also be realistic about what you can accomplish with existing resources versus what genuinely requires additional investment. Coming to leadership with a wish list is very different from coming with a prioritized business case that shows the ROI of targeted investments. The latter gets funded. The former gets skepticism.

End of Month Two: What You Should Have

By the end of day 60, you should have a completed assessment of people, processes, and technology. You should have a mapped regulatory and compliance landscape that's been validated with Legal and Compliance. You should have a prioritized list of your top risks with business impact clearly articulated for each one. And you should have a draft roadmap — phased, business-outcome-oriented, and readable — that you can begin socializing with key stakeholders before your formal 90-day presentation.

Start sharing your assessment findings informally with the stakeholders who helped you gather information in month one. This serves two purposes. First, it confirms your understanding of what you found and gives people the opportunity to correct misimpressions. Second, it builds investment in the solution. When people feel they've been part of shaping the security agenda, they're far more likely to support it when you need their cooperation to implement it.

Month two is also when you should be making your first tentative decisions about what needs to change and roughly in what order. You're not executing yet — that comes in month three. But you should be close enough to a complete picture that your top priorities are becoming clear and your planning is getting specific.

---

💭 Final Thought

A CISO without a roadmap is just reacting to the loudest alarm and the most recent crisis. A roadmap is your proof that you're leading — that you have a clear-eyed view of where the program is, a credible understanding of where it needs to go, and a realistic plan for getting there. It's what transforms you from a technically skilled operator into a strategic leader. Even if the plan changes the moment it meets reality — and it will — having one puts you in an entirely different conversation with your organization. Build the plan. Own it. And be ready to defend it and adapt it as you learn more.

Up Next in This Series

Post 3: Days 61–90 — Start Executing and Show Early Wins →