Every new CISO inherits a program built by someone else, measured by metrics someone else chose. The board is not watching for the next incident so much as watching for a sign the program is actually changing, not just continuing under new management.
The instinct is to keep the lights on for the first quarter and save the bigger changes for later. That instinct is usually wrong. The real opportunity in the first ninety days is not to run the inherited program well. It is to show, early and visibly, that the program is becoming something different: one built on evidence instead of activity.
Human risk is one of the fastest places to make that case. It does not require a new architecture, a new budget cycle, or a year-long RFP. It requires an audit, a narrative, and a demonstration, in that order.
Days 1 to 30: audit what the program actually proves
Before proposing anything new, find out what the current program can and cannot show. Pull twelve months of awareness data and sort it into two piles: activity, meaning who finished what, and outcome, meaning what changed. Most legacy programs have plenty of the first and almost none of the second.
Ask the incumbent vendor three pointed questions. What behavior changed. Can results be segmented by role. What happens after someone fails a test. The answers, or the absence of them, tell you more about the program’s actual maturity than any dashboard will.
Ownership is worth mapping too. Human risk sits awkwardly between security, HR, and compliance in a lot of organizations, and the gaps in that ownership are usually where the real exposure lives.
One small, visible pilot goes a long way here. A targeted vishing test on the service desk is a good choice: cheap to run, easy to explain, and tied to a pattern that is already showing up in the wild (Scattered Spider has run this exact playbook against Okta, Twilio, Workday, and Google). By day thirty, you want one concrete result to point to, not a plan for one.
Days 31 to 60: build a narrative the board will trust
This is where most new CISOs lose the thread, because it is tempting to present the audit itself as the update. Boards do not want an audit. They want a story about where risk sits and what is being done about it.
Training completion rates are a credibility trap. They measure whether people showed up, not whether the organization is safer, and any board member who has sat through a few of these updates has learned to discount them. The alternative is behavioral evidence: which risky behaviors declined, which cohorts improved, and how the trend is moving over time. When Bill.com made this shift, the resulting drop in exposed PII data, sixty percent, translated into a forty-three times return on the investment. That is the kind of number a board remembers.
Mapping exposure into a small number of reportable categories helps too. Authentication and access, data and app access, device posture, awareness, and now AI are a reasonable starting set. Segment employees into real risk cohorts instead of one blended average, since the average almost always hides the group that matters most.
Days 61 to 90: make the change visible
By the final phase, the goal shifts from analysis to demonstration. Present the plan to the board or the executive team with a clear before and after. Launch one modern intervention publicly inside the company, whether that is an AI usage policy or a live vishing test, so employees see the program changing too, not just hear about it.
Lining up two or three peer CISOs who have already made this shift is worth the effort. Reference conversations do more to build internal confidence than another internal memo, though an internal “state of human risk” update showing measurable change since day one is still worth having in hand.
A program either changes behavior or it doesn’t. Ninety days is enough time to find out which, and enough to bring the board something better than a completion rate.