The CISO's First 100 Days: Decisions Before Tooling

A new CISO’s first hundred days are better spent on seven decisions than on a tool roadmap. Tools can wait until those decisions are made. Bought earlier, they usually lock in the previous leader’s assumptions and consume the budget the new leader needs for what they actually find.

The pull toward tooling

The pressure to show action arrives in the first week. The board wants a plan. Vendors have already noticed the new title. Visible purchases feel like momentum.

The trouble is sequence. A tool selected before the leader knows who decides, what the business depends on and what has already been promised will be judged against nothing. It adds an operating burden to a team that has not been assessed. And it makes it harder, politically and financially, to change course when the picture becomes clear.

Seven decisions

1. Mandate and authority

What can you decide alone, and what needs someone else’s approval? Settle your reporting line, your budget authority, and your authority in an incident: who can order a system isolated, a release stopped or access revoked. Frameworks treat this as foundational. NIST CSF 2.0 expects roles, responsibilities and authorities for cybersecurity risk management to be established (GV.RR-02), and ISO/IEC 27001 requires top management to assign and communicate them. Where NIS2 or DORA applies, the management body also carries formal responsibility for approval and oversight, so the authority lines need to be agreed with leadership, not assumed.

2. What the organization is protecting

Not a full asset inventory. Start with the five to ten business services and data sets whose failure would hurt most, and who owns each. That list shapes everything after it. The organization’s mission and its dependencies are the first thing CSF 2.0 asks leaders to understand (GV.OC).

3. The risk position

What will the organization accept, and where is that written? If a stated appetite and tolerance exist (CSF GV.RM-02), learn whether anyone uses them. If they do not, propose provisional thresholds and label them provisional. You cannot prioritize without them.

4. Inherited commitments

Open audit findings, regulatory undertakings, contractual security obligations, risk exceptions with expiry dates, and projects already in flight. Sort them into binding, negotiable and obsolete. A regulator’s deadline does not move because the leadership changed.

5. What stops

Every leader inherits reports nobody reads, tools nobody operates, exceptions nobody revisits and projects that survive on momentum. Decide early what to retire. It is the cheapest way to create capacity and it signals how you will make trade-offs.

6. Operating model

Which capabilities stay inside, which are partner-led, and who is accountable for each regardless? Decide this after you have seen the work, not before. Reorganizing a team you have not yet understood is the most common early mistake.

7. What leadership will see

Agree the first leadership narrative: where we are, what we found, what we need decided. One page, plain language, with the risk scenarios first. A metrics pack comes later. A shared picture of the problem has to come before shared numbers about it.

How the hundred days can run

This is a planning aid, not a researched benchmark. A live incident or a regulatory deadline will compress it, and a large organization may stretch it.

Window	Decisions	Evidence to gather	Output
Days 1 to 30	Mandate and authority; what is being protected; inherited commitments	Conversations with business service owners, IT operations, engineering, legal, risk and internal audit; audit reports; regulator correspondence; the exception list; recent incident reviews; contracts and budget	Authority statement; top services list; commitments register
Days 31 to 60	Risk position; what stops	Scenarios for each top service; exposure and control evidence; cost of running existing tools and reports	Provisional risk position; top risk scenarios; stop list
Days 61 to 100	Operating model; leadership view; then tooling	Capability and capacity assessment; leadership feedback on the first narrative	Operating model proposal; funded priorities, including tool decisions; leadership reporting rhythm

Tooling appears last on purpose. Each tool decision depends on at least three of the earlier ones: what is being protected, what risk is acceptable and what can be retired. Tool choices made after those decisions are easier to defend, easier to measure and easier to explain.

Common early mistakes

Promising a maturity uplift too soon. A target set before the baseline exists is a commitment made blind.
Treating the board as the only audience. The people who will operate your decisions sit in IT, engineering and the business. If they hear about changes second, they will resist them.
Letting the first big purchase be reactive. A purchase triggered by someone else’s incident or a vendor’s timing sets the tone of the whole tenure.
Reorganizing before understanding. Teams that look inefficient from outside often carry duties nobody wrote down.
Inheriting the previous leader’s reporting. If the metrics were built to defend a previous position, they will describe the previous position.

**** Put the seven decisions on one page and mark each as decided, drafted or open. Share it with your executive sponsor at the thirty-day point, and use it to agree what happens before the first tool is approved.

The CISO's First 100 Days: Decisions Before Tooling

Fractional CISO

Keep reading

What Should a CISO Actually Measure?

The CISO Operating Model: What Should Be Internal and What Can Be Partner-Led?

How CISOs Should Prioritize Security Debt