The First 180 Days as a CISO

Your first job is to listen, and to be seen listening. People will form a view of you in the first fortnight, and the view they form is mostly about whether you understood their world before you tried to change it.

Who to meet, roughly in this order

1. Your boss. Ask what made them hire for this role now, and what would make them say in six months that it was the right call.
2. Your own team, one at a time. Ask what they are proud of, what keeps breaking, and what they were told to stop raising.
3. The CFO or finance lead. Ask how security spend is approved and who signed the last big security purchase.
4. General counsel or the legal lead. Ask who decides whether an incident has to be reported, and how fast they expect to hear from you.
5. The CIO or head of engineering. Ask where the systems are that would hurt most if they stopped for a day.
6. Two or three business unit heads. Ask what security has made harder for them, and whether they think it was worth it.
7. The person who did your job before you, if they are reachable and the parting was civil.

Write down what each person says in their own words. Later, when you present your plan, you can show that the plan answers what they told you. That is the fastest way to earn trust you have not had time to build.

What not to say yet

• "At my last company we did it this way." Say it once and people stop telling you how things work here.
• A verdict on the previous security leader. You do not know what they were allowed to do.
• A list of tools you plan to buy. You do not know the problems yet.
• A promise with a date on it. Every date you give in week one becomes a test you did not choose.

You will see things that worry you in the first week. Some of them will be real. If something is actively dangerous, like a public storage bucket full of customer data or an admin account with no second factor, act on it now and say so. Everything else goes on a list. Most first-week alarms turn out to have a history you do not yet know.

Rule of thumb:Rule of thumb: in the first two weeks, ask three questions for every opinion you give.

Most CISO trouble in year one comes from a gap between what you think the job is and what others think it is. You close that gap by finding four facts and writing them down where your boss can see them.

1. Your mandate

What are you accountable for, and what are you only advising on? The two are very different. If you own the outcome but cannot change the systems, you have responsibility without authority. Find out which parts of security sit with you, which sit with IT, engineering, privacy or a parent company, and who settles a disagreement between you.

2. Your budget line

Find the actual number in the actual ledger. Ask what is already committed: licences that renew, contracts with notice periods, salaries. What is left is the money you can move this year, and it is usually much smaller than the headline. Also ask who can spend on security outside your budget. Engineering teams often buy security tools you will later be asked to run.

3. Who owns risk

You do not own the business's risk. You help the people who own it understand it and decide. A product leader who chooses to ship with a known weakness owns that choice. Your job is to make sure the choice was informed, written down and made by someone with the authority to make it.

4. What was promised before you came

Ask your boss, the auditors and the sales team what has been promised in your name. Look for audit findings with due dates, customer contracts with security clauses, a certification someone told a big client was coming, and board minutes that mention security. These promises are now yours, whether or not you agree with them.

Rule of thumb:If two people give you different answers to the same fact, you have found your first real piece of work.

The org chart shows reporting lines. It does not show who gets listened to, who holds the passwords nobody else has, or whose quiet no ends a project. You need that second map, and nobody will hand it to you.

Three questions that draw the real map

• "When something important breaks at night, who gets called?" The names you hear are your real operations team, whatever their titles say.
• "Whose sign-off does a big change really need?" Sometimes it is a committee. Often it is one respected engineer.
• "Who here has been around long enough to know why things are the way they are?" Find these people early and treat them well.

Draw the map yourself, privately. Note who people go to for advice, who blocks and who unblocks. Update it as you learn. It will be wrong in places, and that is fine.

Turn the map into an incident roster

Your map pays off when something goes wrong. For each kind of incident you can imagine, write down who decides, who must be told, who does the work and who speaks outside the company. If a name appears only because of the org chart and not because they actually know the system, fix it now, while it is calm.

1. List your five most likely incidents: ransomware, a lost laptop with data, a compromised admin account, a supplier breach, a leak of customer data.
2. For each one, name the decision maker and a deputy.
3. Check every name with the person named. Many will be surprised.
4. Put phone numbers somewhere that still works when email and chat are down.

Expect the map to change. People move, leave or lose interest, and a reorganisation can redraw the formal chart overnight while the real one stays the same. Look at your list again every quarter, and after every incident, because an incident is the moment the real map shows itself most clearly.

Rule of thumb:Rule of thumb: if a name on your incident list has never seen the list, it is not a list yet.

By week three you will have a list of problems far longer than your team can fix in a year. That list is not a plan. A plan is the three things you will do first, why those three, and what you are knowingly leaving for later.

How to choose the three

1. Group the list by what could actually hurt the business: stop it trading, leak what customers trusted you with, or break a promise to a regulator or client.
2. For each group, ask how likely it is in the next year given what you have seen, not what you fear.
3. Ask what it would cost and who else would need to help.
4. Pick three that together cover the worst harms and that you can show progress on within a quarter.

Three is not magic. It is small enough that you can say all of them in one breath to the CEO, and small enough that your team can hold them in their heads.

Quick wins vs long-term debt

A quick win is a change that removes real risk fast and is visible: turning on strong sign-in for admin accounts, closing an exposed service, fixing backups that have never been restored. Quick wins buy you trust, and you will need that trust for the slow work.

Long-term debt is the stuff that took years to build up: old systems nobody can patch, identity sprawl, an asset list nobody believes. You cannot fix it in 30 days. You can start measuring it, name an owner and agree a direction.

Saying no to the rest

Put everything else on a written list called something honest, like "known and not yet funded". Show it to your boss. Each item should say what the risk is and who owns the decision to wait. That turns a quiet worry into a shared, dated choice.

Rule of thumb:If everything is a priority, the attackers set your priorities for you.

Your first real incident will probably come before you feel ready. That is fine. Nobody is judged on whether they knew everything. People are judged on whether they stayed calm, made clear decisions and told the right people at the right time.

The first 24 hours

1. Name an incident lead. It does not have to be you. It does have to be one person.
2. Write down what you know, what you do not know and the time. Keep doing this every hour.
3. Contain before you investigate in depth. Stop the spread first.
4. Preserve evidence. Do not wipe and rebuild before someone has captured what is needed.
5. Tell legal early. They decide what must be reported and when. You give them facts.
6. Agree who speaks to staff, customers and the press. Nobody else does.
7. Set the next check-in time before each meeting ends.

If your company is listed in the United States, there is a clock to know about. The SEC requires a company to decide whether an incident is material without unreasonable delay after discovery, and if it is material, to file a Form 8-K under Item 1.05 generally within four business days of that decision. The clock runs from the materiality decision, not from the attack. Make sure you know who makes that decision before you need it.

Rule of thumb:Write it down as you go. Memory after a long night is not evidence, and it is not kind to you either.

The blameless review

A week or two after, hold a review. The aim is to learn how the system let this happen, not to find a person to punish. People who fear blame hide mistakes, and hidden mistakes come back bigger.

• Ask "what made this the reasonable thing to do at the time?" rather than "why did you do that?"
• Look for the conditions: missing alerts, unclear owners, tired people, confusing tools.
• End with a short list of changes, each with an owner and a date.
• Share what you learned more widely than feels comfortable.

Blameless does not mean consequence-free. Someone who deliberately ignored a rule is a different case. But that is rare, and treating every mistake as if it were deliberate guarantees you will hear about fewer of them.

You inherit tools you did not choose, contracts you did not sign and suppliers you have never heard of. Some are excellent. Some are paid for and switched off. A few hold more of your company's data than your own systems do.

Sort the tools first

Make a simple list of every security tool: what it is for, who runs it, when it renews and whether anyone looks at its output. You will find overlap and you will find tools nobody uses. Do not cancel anything in the first month. Find out why it was bought first. Sometimes the reason is a contract or an audit you have not seen yet.

Then find the suppliers that matter

Not every supplier is a security risk worth your time. Focus on the few that hold sensitive data, have access into your network, or would stop your business if they went down. A payroll provider, a cloud host, a managed IT firm with admin rights. Those are the ones you need a plan for.

1. Ask finance for a list of suppliers by spend, and IT for a list by access. The overlap is your shortlist.
2. For each one, know who your contact is when something goes wrong and what the contract says about telling you.
3. Decide what you would do in the first day if they announced a breach.

When you do decide to change something, change one thing at a time and tell the people who rely on it first. Replacing three tools in one quarter while learning a new company is how coverage quietly drops. Keep a short note of each decision and why you made it, so your successor does not have to rediscover it.

Rule of thumb:Rule of thumb: the supplier you worry about least is often the one with admin rights everywhere.

Most security dashboards report activity: emails blocked, alerts processed, training modules completed. Those numbers go up whether you are getting safer or not. A good metric changes when risk changes, and it would make you uncomfortable if it went the wrong way.

Five numbers worth having

Your five will depend on your business, but they usually look something like this:

• How fast we fix what matters. Time to fix critical weaknesses on internet-facing systems, measured from when you knew.
• How much of the estate we can see. Share of important systems sending logs you actually review.
• How well the keys are guarded. Share of admin and remote access protected by strong sign-in.
• Whether we can recover. Date of the last full restore test for your most important system, and whether it worked.
• How fast we notice. Time from first sign of an intrusion to someone acting on it, from real incidents and exercises.

How numbers lie

• Averages hide the worst case. One unpatched server facing the internet matters more than a good average.
• Coverage counts the easy systems. Ask what is missing from the count.
• A number that only goes up is decoration. If nothing could make it go down, it is not measuring risk.
• People optimise what you measure. If you reward closed tickets, you get closed tickets.

Make each one useful

For every metric, write down what it means, where the data comes from, what good looks like and what you will do if it goes the wrong way. If you cannot fill in the last part, it is not a metric you need.

Show each number as a trend over several months, not a single snapshot. One reading tells you very little. A line moving the wrong way for three months tells you a lot, and it gives you a reason to ask for help before something breaks rather than after.

Rule of thumb:Rule of thumb: if a number cannot change a decision, stop reporting it.

Your first board meeting feels like an exam. It is closer to a conversation with people who are responsible for the company and are trying to work out whether they can rely on you. They are not testing your technical knowledge. They are testing your judgement.

What directors usually need

• What are the few risks that could seriously hurt the company?
• Are we doing enough about them, and how would we know?
• What decisions do you need from us?
• If something happened tomorrow, who would do what?

In the United States, listed companies must describe in their annual report how the board oversees risks from cybersecurity threats, and management's role and expertise in managing them. That means directors have their own reason to care about how you report to them. If you work elsewhere, the framing still helps: NIST's Cybersecurity Framework 2.0 added a Govern function, which treats strategy, roles, policy and oversight as part of security, not something separate from it.

How to prepare

1. Meet the board chair or the chair of the relevant committee beforehand. Ask what they want to hear and what worried them last time.
2. Read past minutes that mention security. Know what was said before you.
3. Keep your material short. Three risks, what you are doing, what you need.
4. Bring one clear ask: a decision, a risk acceptance, or funding.
5. Practise the answers to the questions you hope they won't ask.

How technical to be

Use plain words. Translate every technical point into what it could do to customers, revenue, operations or the company's reputation. If you need a technical term, explain it in one sentence the first time. Directors are often experienced and sharp. They just do not share your vocabulary.

Afterwards, write to the chair with a short summary of what was asked, what you promised and when you will report back. Then keep those promises early. Your second meeting will go better if the board can see that what you said last time actually happened.

Rule of thumb:The board does not need you to be certain. It needs you to be clear about what you know, what you do not, and what you are doing about it.

A project has an end date. A program is how the organisation keeps doing something well, year after year. Some of your biggest areas will never be finished, because the technology and the threats keep moving. Treat those as programs: a named owner, a direction, a regular check-in and a budget line that renews.

Post-quantum cryptography

Future quantum computers are expected to break some of the public-key encryption in wide use today. NIST has published post-quantum standards, and in October 2026 it finalised NIST IR 8547, which describes how it expects organisations to move from quantum-vulnerable algorithms to quantum-resistant ones. Read the current version yourself for the dates that apply to you.

You do not need to replace anything this month. You do need to know where you use encryption, which systems would be hardest to change, and which suppliers you depend on for it. That inventory is slow, boring and the most valuable first step. It also helps with every other crypto change you will ever make.

AI security

Staff are already using AI tools, whether or not there is a policy. Start with what is in use, what data goes into it and who approved it. Then agree simple rules: which tools are allowed, what data must never go in, and who to ask. The ISO/IEC 27090 practice path is one way to build a shared vocabulary for AI-specific threats.

Identity

Many serious intrusions do not break anything. They log in. Accounts, passwords, tokens, service accounts and now AI agents with their own access are where much of your real risk sits. A program here means knowing every identity that can reach something important, removing what is not needed and protecting the rest well. The Identity Risk tool helps you think through human, service and AI identities together.

Rule of thumb:Rule of thumb: if it will still matter in five years, give it an owner, not a deadline.

Every CISO arrives from somewhere: operations, audit, engineering, consulting, the military, a different industry. You are deep in one area and thin in others. That is normal. The job does not ask you to be an expert in everything. It asks you to know enough to ask the right questions and to notice when an answer does not hold up.

What T-shaped means here

The vertical bar of the T is your depth: the area where you can check the work yourself. The horizontal bar is breadth: enough understanding of the other areas to have a useful conversation with the specialists who run them.

Finding time

1. Pick one area per quarter to widen, not five at once.
2. Spend an hour a week with the specialist who runs it. Ask them to walk you through a real problem.
3. Practise decisions, not just reading. Exercises show you where your judgement is thin.
4. Keep a short note of what you learned. Re-read it before the next board meeting.

Your depth still matters. In a crisis, people will look to you for judgement in your own area. Keep it current. Just do not let it become the only lens you look through.

Be careful with certifications as a shortcut. They can give you a useful structure for a new area, and some employers expect them. But a certificate shows you studied a subject, not that you can make a sound call in it under pressure. Practice and real conversations close that gap faster.

Rule of thumb:You do not need to be the smartest person in each room. You need to know which room to walk into.

Yes, hire people who are better than you at their job. Your team's strength is the limit of what you can deliver. A leader who only hires people they can outshine builds a team that needs them for everything, and that leader becomes the bottleneck in every incident.

Start with the team you have

Before you post a single job, understand the people already there. Some will have been waiting years for someone to listen. Some are in the wrong role. A few may be ready to leave. Changing the team too fast tells everyone that loyalty to the last leader counts against them.

1. Meet each person one to one, more than once.
2. Ask what they would work on if nobody stopped them.
3. Look at who others go to for help. That person may not be the most senior.
4. Only then decide what gaps hiring should fill.

Writing the role

Describe the problems the person will solve, not a wish list of every certification. Long lists of requirements filter out good people who read them literally and let in people who do not. Be clear about what is essential and what can be learned.

• What will this person own in their first six months?
• What decisions will they make without asking you?
• What does good look like at the end of year one?

What to look for

Curiosity, honesty about what they do not know, and the ability to explain a hard thing simply. Skills can be taught. Those three are much harder to teach.

Plan for how a strong person will grow, too. Good people leave when they stop learning. Give them room to own decisions, credit them in front of senior leaders, and talk openly about what their next step could be, even if it is somewhere else. A team known for growing people finds it easier to hire the next one.

Rule of thumb:Rule of thumb: if your team could not run the next incident without you, your next hire is a deputy.

Most security interviews test memory: what port does this use, what does this acronym mean. Memory is easy to look up. Judgement is not. The people you want are the ones who make sound decisions when they do not have all the facts.

Use a real scenario

Give the candidate a short, realistic situation and ask what they would do. Then change one fact and ask again. Watching how someone updates their plan when the situation shifts tells you more than any quiz.

• "An alert fires at 6 p.m. on a Friday showing a finance account logging in from a new country. What do you do first?"
• "A product team wants to ship with a known weakness to hit a deadline. What do you say?"
• "You find that a colleague has been closing tickets without fixing the issue. How do you handle it?"

What good answers sound like

• They ask questions before acting.
• They say what they would not do yet, and why.
• They name who else needs to know.
• They admit what they are unsure of instead of bluffing.

Keep it fair

1. Ask every candidate the same core questions.
2. Agree what a strong, middling and weak answer looks like before the interviews start.
3. Have each interviewer score alone before anyone discusses.
4. Write down the reason for each decision.

Consistent questions and written scores reduce the pull of first impressions and of hiring people who remind you of yourself. They also make it easier to explain a decision to a candidate who asks.

Close each interview by letting the candidate ask about the hard parts of the job: the incidents, the budget, the board. What they choose to ask tells you what they care about. It also gives them an honest picture, which saves you both from a hire that ends badly six months later.

Rule of thumb:Rule of thumb: if a question can be answered with a search engine, it is not testing judgement.

Every function has habits that do not serve it. Security has three that come up again and again. Naming them is the first step to not repeating them.

1. Saying no too often

A security team that says no to everything gets routed around. People stop asking, and then you do not know what they are doing. That is worse than a yes with conditions.

Try "yes, if" instead. Yes, you can use that tool, if customer data stays out of it. Yes, you can ship, if this owner accepts the risk in writing and we fix it next sprint. You keep influence by staying in the conversation.

2. Too much policy

Policies feel like progress. They are easy to write and look good to auditors. But a policy nobody reads changes nothing, and a stack of them hides the few rules that matter.

• Can a new starter find and read the rules that apply to them in ten minutes?
• Does each policy say who checks it and how?
• When did someone last change their behaviour because of it?

Fewer, shorter policies that are actually followed beat a full library that is not.

3. Reporting activity, not outcomes

"We blocked a large number of attacks" says the team was busy. It does not say the company is safer. Leaders learn to tune out activity reports, and then they tune out the team. Report what changed: risk down, a gap closed, recovery tested and proven.

None of these habits come from bad intent. They come from a team that feels responsible for everything and in control of little. The fix is not to care less. It is to share ownership of risk with the people who make the decisions, and to judge your own team by what changed rather than by how hard it worked.

Rule of thumb:Rule of thumb: if your report would read the same in a bad month and a good month, it is reporting activity.

Sometimes you do everything in this book and it still does not work. A serious risk is ignored. The budget is cut after an incident. You are blamed for a decision someone else made. This chapter is for those weeks.

Escalating a risk properly

1. Write the risk down plainly: what could happen, how likely, what it would cost, what fixing it would take.
2. Give it to the person who owns the decision, and ask for a decision with a date.
3. If they accept the risk, record that they did. That is a legitimate outcome.
4. If they will not decide, or the risk is beyond their authority, tell them you will take it to the next level, then do.
5. Keep copies of what you sent and when.

Escalation is not betrayal. It is how organisations make sure the right person makes the big calls. Do it openly, never around people. Most companies have a route to the board or an audit committee for exactly this.

Noticing burnout

• You dread checking your phone, even on quiet days.
• Small problems feel like disasters.
• You have stopped caring whether a fix works.
• Sleep, health or relationships are taking the hit.

This job carries constant low-level alarm. Build in rest on purpose: a deputy who can cover, a real handover when you take leave, and someone outside work you can talk to. If you are struggling, talk to a doctor or a professional. It is a health matter, not a weakness.

When to leave

If you have escalated properly, the risk is serious, and the organisation has chosen not to act and not to own that choice, you may have reached the end. Leaving well means a clean handover and an honest record of the risks you raised. Your reputation is built on the decisions you can defend, including the decision to go.

Rule of thumb:You cannot protect a company that will not let itself be protected. You can make sure the choice was clear.