The first 100 days in security leadership: what to establish before you are judged.
Every new security leader is judged before the plan is finished. The judgment forms around day 100, in the first board or executive session where someone asks what has changed, and it forms on whatever is in hand at that moment. This note is about what to have in hand. It runs in three gates: evidence and inventory by day 30, decisions and authority by day 60, and proof for the board by day 100. A companion note covers the artifacts the quarter should produce. This one covers the order in which to establish them, and what each gate has to survive.
What the first 100 days are actually for
The first 100 days are for establishing three things in sequence: what is true, what has been decided, and what can be shown. Each depends on the one before it. A decision made before the evidence is a guess with a signature on it, and a board presentation made before the decisions is a status report. The order is the discipline. Most first quarters fail not from lack of effort but from doing these three in the wrong order, usually by presenting first and inventorying last.
Days 0 to 30: evidence and inventory
The only job in the first month is to find out what is true, and to write down where you could not. Nobody will judge you on the elegance of the inventory. They will judge you, later, on whether the decisions rested on it. So the standard for this month is coverage and honesty, not polish.
Start with the things that already exist and are already binding. Every promise the company has made about its security is a commitment someone will eventually test: customer contracts, security questionnaires answered by sales, the trust page, the insurance application, the last audit report. Collect them before you collect anything else, because they define the gap between what has been represented and what is real, and that gap is the first thing a serious buyer or a regulator will find. Read the questionnaires with particular care. They were answered under deal pressure by people who wanted the deal, and they are where the most confident and least verified claims live.
Then inventory the four things an intruder would inventory: identities, exposure, data, and dependencies. Identities means every human and every workload account that can change something that matters, with the privileged set named individually. Exposure means what is reachable from the internet and from an ordinary employee laptop, verified by looking, not by asking. Data means where the material the company would be most embarrassed or most liable to lose actually sits, including the copies nobody remembers. Dependencies means the vendors and platforms whose compromise becomes your incident. Each of these has a document that describes it and a system that shows it. Where the two disagree, the system is right and the disagreement is a finding.
Two inventories matter more than the rest. The first is logging and retention: for each system that would matter in an investigation, what is recorded, at what level, for how long. Most companies discover during an incident that the log they need was never enabled or rolled off six weeks earlier. A leader who puts that gap in writing in month one has already changed the outcome of the next incident. The second is access that outlives people: service accounts, automation identities, and integrations created by staff who have since left. Offboarding disables a person. It rarely reaches what the person built.
By day 30 you should be able to answer, without notes, four questions: what have we promised, what is exposed, what would we be unable to reconstruct after an incident, and which identities could do the most damage. If any of the four is still an estimate, say so in the inventory. An honest gap at day 30 is a finding. The same gap discovered by an outsider at day 200 is a failure of the role.
Days 31 to 60: decisions and authority
The second month converts the inventory into a small number of explicit decisions, and establishes that you have the authority to make them stick. These are different problems. Many new leaders produce good decisions that nobody honors, because the authority question was never settled. Settle it in this window, while the executive team is still paying attention to the new role.
The first decision is the risk position: the handful of ways this company could be seriously hurt, ranked, with the reasoning visible. Keep it to a page. Its purpose is not to be complete. Its purpose is to be stated from memory by the chief executive when a board member asks. Everything on it should trace to the first month's evidence. Anything that traces only to an interview or a framework should be labeled as such.
The second decision is explicit acceptance. Some of the risks on that page will not be fixed this year, for reasons of cost, staffing, or product priority. That is a legitimate choice when it is made by the executive who owns the consequence, in writing. It is an unowned liability when it happens by default. The act of walking a risk to the person who owns the affected business and asking them to sign the acceptance does more to establish the role than any tool purchase. It also tends to produce budget, because executives who are asked to own a risk personally often decide they would rather fund the fix.
The third decision is ownership. For each of the areas the inventory touched, name who decides and who operates: customer commitments, access grants, vendor onboarding, incident declaration, disclosure. Where the honest answer is nobody, write nobody. An ownership map with blanks is useful. An ownership map with names inserted to avoid blanks is a document that will fail at the first real incident, when the named person learns of their role from the incident itself.
Authority is established by three specific things, and it is worth being concrete about them because they are easy to assume and hard to recover once assumed wrongly. First, the power to decline. A security leader who cannot refuse a customer commitment that the company cannot meet, or refuse a vendor that fails a basic review, has advisory influence and not authority. Get one refusal on the record in this window, with executive backing, and choose it carefully so that it is obviously correct. Second, the power to declare. Who can say that an incident is an incident, take a system offline, and engage counsel, and at what threshold. If the answer requires a meeting, the answer is nobody. Third, the reporting line. Where the role reports determines whose incentives shape it. If security reports into the function whose work it must sometimes stop, arrange a direct path to the chief executive or the board for the cases where that matters, and agree in advance what those cases are.
Test the escalation path in this window, on paper, against one plausible scenario drawn from the first month's evidence. A tabletop that runs against the company's real exposure, using the real logging gaps and the real ownership blanks, is worth more than a generic exercise. It also produces the second month's most persuasive artifact: a written record of where the path broke and what was changed as a result.
By day 60 you should hold a one-page risk position endorsed by the executive team, a short list of signed acceptances, an ownership map with its blanks visible, one refusal on the record, and a tested escalation path with known weak points. If the risk position exists but no acceptance has been signed and nothing has been refused, the second month produced analysis. Leadership is the part where something was ruled out.
Days 61 to 100: what to prove to the board
The board does not want to know what security has been doing. It wants to know what it is now able to decide that it could not decide before, and whether it can trust the person telling it. The last forty days are about proving those two things, and the proof is mostly assembled from the first sixty. What is new in this window is the selection: what to show, what to withhold, and what to ask for.
Show the risk position and the acceptances. A board that can state the company's three or four material security risks, and knows which ones it has consciously chosen to carry, has been given something it can be accountable for. That is the entire function of security reporting to a board, and most boards have never received it. Present the acceptances as decisions the executives made, with their names attached, not as findings security discovered. The difference is the difference between governance and audit.
Show the gaps between representation and reality, chosen carefully. The questionnaire that claimed encryption at rest for a system that has none. The insurance application that described controls that were never deployed. The board needs to know these exist, because they are the company's exposure in a dispute, and because fixing them requires decisions above the security function. Bring them with a recommended resolution and a cost, not as a list of embarrassments. Where a representation touches a contract or a regulator, counsel should see it before the board does.
Show one thing that changed as a result of the role existing. Not a program launched or a tool purchased, but an outcome: a customer commitment declined, an orphaned privileged identity removed, a logging gap closed before it was needed, a tabletop that found the break in the escalation path and fixed it. One concrete change with evidence behind it establishes more trust than a roadmap of forty items. Boards have seen roadmaps.
Withhold the metrics that do not carry a decision. Alert counts, patch percentages, and phishing click rates describe activity. If a metric is on the page, the sentence after it should say what the board is being asked to do about it. If there is no such sentence, it belongs in an operating review.
Ask for something specific. A board session that ends without a request has taught the board that security is informational. The request should follow from the risk position: the acceptance that needs a named owner above the executive team, the budget for the one fix that removes the largest ranked risk, the authority question that was settled at the executive level and should be ratified at the board level. Make the request small enough to be granted in the meeting and consequential enough to be remembered.
Then state what will be true by the next session, in terms the board can check without you. Not a maturity score. A short list: this acceptance will have been revisited, this representation will have been corrected with the customer, this exposure will have been closed and verified. The first hundred days end with a set of commitments a director could audit from the minutes. That is what being judged well looks like. It is not being liked, and it is not being impressive. It is having said things that turned out to be true, and having asked for things that turned out to matter.
What this sequence refuses
It refuses to buy tools before the risk position exists, because spending precedes prioritization and the tools then consume the team the strategy was meant to direct. It refuses to present before deciding, because a board given status instead of decisions learns to treat the role as informational. It refuses the encyclopedic assessment, the long framework-mapped document that scores everything and ranks nothing, because a document that decides nothing changes nothing. And it refuses to hide blanks. An honest gap in month one is the cheapest finding the company will ever receive.
Questions people ask
What should a new CISO do in the first 100 days?
Establish evidence and inventory in the first month, decisions and authority in the second, and proof for the board in the third. Commitments, exposure, data, identities, and logging come first. A one-page risk position, signed acceptances, and an ownership map come second. The board gets decisions and one concrete change, not activity metrics.
What should a security leader present to the board at 100 days?
The ranked risk position, the risks executives have explicitly accepted with their names attached, the gaps between what the company has represented and what is real, one outcome that changed because the role exists, and a specific request. Activity metrics without a decision attached belong in an operating review, not the board pack.
How is a new security leader judged?
On whether the things they said turned out to be true and the things they asked for turned out to matter. Concretely, whether leadership can state the material risks without the leader in the room, whether anything was refused or consciously accepted, and whether the escalation path was tested before it was needed.
Related: What the First 90 Days of Security Leadership Should Actually Produce · Boards Need Decisions From Security, Not Telemetry · Offboarding Disables a Person, Not the Access They Built · When a Company Actually Needs a Fractional CISO
If the company is between security leaders, or the new one needs the first month's evidence produced independently, the Security Leadership Sprint produces the inventory, the risk position, and the ownership map in seven to ten business days.