First Time Security Manager Guide: Leading a Team

Most security managers are promoted because they were the best analyst or engineer on the team, and then discover that the skills that got them the job are not the ones the job needs. This guide covers the move from individual contributor to first line manager of a security team: what changes, a practical first 90 days, running one-to-ones and delegation, protecting the team from overload, hiring and growing skills, managing upward, leading during incidents and measuring whether you are doing it well. It is written for new team leads and managers in any security function (operations, engineering, GRC, identity, application security), and for the senior leaders who promote them. For the SOC-specific version of the role see the Security Operations Manager Career Guide; for the step after this one see the Path to CISO Career Guide.

Key takeaways

Your output is now the team's output. Success is measured by what the team ships, detects and fixes, not by the tickets you close yourself.
Listen before you change things. Spend the first month learning people, systems, commitments and risks; early fixes made without context usually break trust or a hidden dependency.
One-to-ones and delegation are the core tools. A regular, protected one-to-one with each report and deliberate delegation of real work do more for performance and retention than any process change.
Workload is a security risk. Overloaded, interrupted teams miss alerts and make errors; the HSE Management Standards give a practical frame for spotting demand, control and support problems early.
Translate up, protect down. Explain risk to your own manager in business terms, negotiate priorities openly and shield the team from churn without hiding bad news from them.

What actually changes when you become a manager

The technical work does not disappear, but it stops being your main job. The table shows the shifts most new security managers find hardest.

As an individual contributor	As a first line manager	What to do about it
Measured on your own tickets, findings or code	Measured on team delivery, quality and retention	Agree with your own manager, in writing, the three or four outcomes you will be judged on
Deep focus time on hard problems	Fragmented days of meetings, decisions and interruptions	Block two or three focus slots a week for planning and review, and keep them
Fastest way is to do it yourself	Doing it yourself starves the team of growth and you of time	Delegate the work you are best at first; coach rather than take it back
Peers are friends and fellow complainers	You now hold information you cannot share and make decisions that affect them	Be open about the change; keep friendships, but stop venting about the organisation to reports
Feedback arrives from code review or a lead	Little feedback reaches you, and what does is filtered	Ask for upward feedback directly and act visibly on some of it
Technical depth is your credibility	Judgement, fairness and follow-through are your credibility	Keep enough hands-on contact to judge quality, not to be the hero

Player-coach roles: many first security managers still carry a technical workload, especially in teams of three to six. That is workable if the split is explicit (for example 50 percent management, 50 percent delivery), the technical work is not on the critical path, and you drop it first when people need you.

The first 90 days

The CISO Guide: First 90 Days covers the executive version; this plan is for a manager of a single team.

Days 1 to 10: meet everyone. Hold a first one-to-one with each report (their work, what frustrates them, what they want next, how they like feedback). Meet your own manager to agree expectations, and meet the two or three teams you depend on most (IT operations, engineering, service desk, risk).
Days 10 to 30: map the work. List every recurring duty, open project, commitment made to other teams, on-call rota, tool and vendor contract the team owns. Note which tasks depend on one person. Read the last few incident reviews, audit findings and risk register entries for your area.
Days 30 to 45: find the real problems. Combine what people told you with what the data shows: backlog age, alert volume per analyst, overtime, missed SLAs, open audit actions. Pick two or three problems that matter to both the team and the business.
Days 45 to 60: agree priorities. Write a one-page plan: what the team owns, what it will stop doing, the top priorities for the next quarter and the risks you are carrying. Review it with your manager and with the team before you publish it.
Days 60 to 90: deliver one visible improvement. Choose something that removes pain for the team (retiring a noisy alert rule, automating a manual report, fixing a broken handover) and finish it. Set up the operating rhythm you will keep: weekly team meeting, regular one-to-ones, monthly metrics.
Day 90: review. Ask your manager and each report what is better and what is not. Adjust the plan. If a change you made is causing harm, roll it back openly and explain why.

Running the team week to week

One-to-ones

Cadence: weekly or fortnightly, 30 minutes, at a fixed time. Cancelling them first when you are busy tells people they are the lowest priority.
Agenda: the report's agenda first (blockers, concerns, ideas), then yours (feedback, priorities), then growth for a few minutes most sessions.
Notes: keep brief shared notes of actions so neither of you relies on memory, and so performance conversations rest on a record.

Delegation

Match the level of delegation to the person's experience with that specific task, not to their seniority overall.

Level	What you say	Use when
1. Do as instructed	"Run the access review using this checklist and bring me the exceptions."	New starter, high-risk task, first time
2. Recommend	"Look into the options for replacing the scanner and recommend one."	Capable person, decision still needs your sign-off or budget
3. Decide and tell me	"Tune the noisy detection rules; tell me what you changed."	Experienced person, reversible decisions
4. Own it	"You own vulnerability reporting to the infrastructure teams."	Proven owner; you check outcomes at the monthly review

Feedback and performance

Specific and timely: describe the situation, the behaviour and its effect, close to the event, in private for anything critical.
Underperformance: raise it early and informally, agree what good looks like and by when, and check whether the cause is skill, clarity, workload or something outside work. Involve HR before anything becomes formal, and follow your organisation's policy.
Recognition: credit the team publicly for prevented incidents and quiet improvements, not only for heroics during an outage.

Protecting the team from overload

Security work combines high stakes, interruptions and out-of-hours response, and an exhausted team is a control failure waiting to happen. The UK Health and Safety Executive's Management Standards for work-related stress give managers six areas to check. See the Burnout in Security Teams guide for the full programme; the table applies the six areas to a security team.

HSE area	What it covers	Security team warning signs	Manager actions
Demands	Workload, schedules and work environment	Alert queues growing, constant overtime, unplanned work above half of capacity	Cut low-value alerts and reports, set work in progress limits, say no with evidence
Control	Autonomy over how tasks are done	Every change needs your approval; people wait on you	Delegate decisions (see the table above), agree standards instead of approvals
Support	Encouragement and resources from managers and colleagues	Single points of knowledge; no one to cover leave	Pair people, document runbooks, budget for training
Relationships	Constructive working, conflict handled	Blame after incidents; friction with IT or developers	Blameless reviews, address poor conduct quickly
Role	Clear responsibilities without conflicting duties	Unclear ownership between security, IT and engineering	Publish a RACI for the team's services and escalations
Change	How change is managed and communicated	Reorganisations and new tools announced without consultation	Explain why, consult early, phase tool changes

On-call: make the rota fair and visible, give time off in lieu after night call-outs, and review pages monthly to remove any that did not need a human.

Hiring and growing skills

Hiring is the decision with the longest consequences you will make in your first year. The Cybersecurity Skills Gap and Hiring Guide covers the market; at team level:

Describe the work, not a wish list: write roles from the tasks the team actually does. The NICE Workforce Framework for Cybersecurity (NIST SP 800-181 Rev. 1, components version 2.2.0 as of April 2025) gives a shared vocabulary of task, knowledge and skill statements and work roles; see the NICE Workforce Framework Guide.
Baseline the team's skills: the NCSC board toolkit advises a baseline of current cyber expertise to find gaps, reviewed at least annually. A simple skills matrix (people against the team's key tasks, scored 0 to 3) shows single points of failure.
Practical development: NCSC notes that training alone does not create experts and that staff need chances to build hands-on skills. Rotate people through incident lead, tooling and project roles; budget lab time.
Structured interviews: use the same questions and a scoring guide for every candidate, include a realistic work sample, and involve the team.
Track retention: NCSC suggests tracking retention in key cyber roles, since frequent departures can signal systemic problems.

Managing upward and across

Know your manager's goals: learn what they are measured on and how your team helps. Bring problems with options and a recommendation.
Speak in risk and outcomes: "unpatched internet-facing servers above 30 days are down from 42 to 9" lands better than tool names. See the Security Metrics and KPIs Programme Guide.
Negotiate priorities openly: when new work arrives, show the current list and ask what drops. Record risk acceptances in the Risk Register Template rather than absorbing them silently.
Build peer relationships early: the managers of IT operations, engineering and the service desk control most of the fixes you need.
Model the culture you want: NCSC's culture guidance stresses that leaders set the tone, that avoiding blame is not avoiding accountability, and that people must be able to raise issues without fear of reprisal. See the Security Culture guide.

Leading during incidents

Your first serious incident as a manager tests whether you can stop being the best responder in the room.

Do not grab the keyboard: your job is coordination, decisions, communication and people. If you are the only person with a skill, that is a gap to fix after the incident.
Know the roles: confirm in advance who is incident commander, who talks to executives and who logs decisions. See the Incident Commander Guide.
Watch fatigue: rotate responders on long incidents and send people home; tired people make irreversible mistakes.
Run a blameless review: focus on causes and improvements, track actions to closure and share what changed.

Where identity fits

New managers inherit their team's access as well as its work. Security teams usually hold some of the most privileged accounts in the organisation, plus service accounts and API keys for scanners, SIEM connectors and automation. In your first month, review who on the team has which privileged roles, remove access left over from old projects, confirm leavers' accounts and any shared credentials were rotated, and make sure tool service accounts have named owners. See the Service Account Security Guide.

Decision guidance by team size

Situation	Typical shape	Where to focus
Team of 2 to 4, player-coach	You still carry technical work; no deputy	Explicit time split, documented runbooks, cross-training to cover leave
Team of 5 to 8	Full-time manager; mixed seniority	One-to-ones, delegation levels, a skills matrix, a clear quarterly plan
Team of 9 or more	Too many direct reports to coach well	Appoint leads or split into sub-teams; your one-to-ones move to the leads
Promoted over former peers	Existing relationships and history	Acknowledge the change openly, be consistent, avoid favouritism
External hire into an existing team	No context, team may have wanted an internal candidate	Longer listening phase, early credibility through removing pain, not grand plans

For how security teams are structured across an organisation, see the Security Operating Model and Organisation Design Guide.

Measuring whether you are doing it well

Delivery: percentage of quarterly priorities completed, and age of the team's oldest backlog items.
Load: unplanned work as a share of capacity, out-of-hours pages per person per month, and overtime hours.
Resilience: number of key tasks that only one person can do (from the skills matrix), trending down.
People: regretted attrition over 12 months, one-to-ones held as planned, and training days per person.
Feedback: a short anonymous team survey each quarter on clarity, workload and support, with actions reported back.

Common failure patterns

Staying the top engineer. The manager takes the hardest technical work, becomes the bottleneck and has no time for people.
Changing everything in month one. Rewriting processes and tools before understanding why they exist breaks trust and dependencies.
Cancelling one-to-ones. They are the first thing dropped under pressure, and problems then surface only as resignations.
Absorbing every request. Saying yes to all new work without trading priorities leads to burnout and missed commitments.
Avoiding hard conversations. Delayed feedback on performance or conduct turns small issues into formal cases and frustrates the rest of the team.
Blame after incidents. Singling people out stops reporting; NCSC notes that reviews which single out individuals indicate an immature culture.

Framework mapping

Manager responsibility	NIST CSF 2.0	ISO/IEC 27001:2022	Other reference
Clear roles and authorities for the team	GV.RR-02	Clause 5.3 Organizational roles, responsibilities and authorities	RACI for team services
Hiring, skills and development	GV.RR-04, PR.AT-01	Clause 7.2 Competence; A.6.3 Information security awareness, education and training	NIST SP 800-181 Rev. 1 (NICE Framework)
Priorities tied to business goals	GV.OC-01, GV.RM-01	Clause 6.2 Information security objectives	NCSC Board Toolkit, Strategy principle
Joiner, mover and leaver handling in the team	GV.RR-04	A.6.1 Screening; A.6.5 Responsibilities after termination or change of employment	Service account ownership review
Wellbeing and workload	GV.RR-04	Clause 7.1 Resources	HSE Management Standards

Practitioner checklist

Agree in writing with your manager the three or four outcomes you will be judged on.
Hold a first one-to-one with every report in the first two weeks, then set a fixed recurring slot.
Map every duty, project, commitment, rota, tool and contract the team owns, and flag single points of knowledge.
Publish a one-page team plan by day 60, including what the team will stop doing.
Assign a delegation level to each recurring task and move at least two tasks up a level each quarter.
Build a skills matrix against the team's key tasks and review it at least annually.
Check the six HSE areas with the team and act on the worst one first.
Review the team's privileged access, shared credentials and tool service account owners.
Confirm incident roles in advance and run blameless reviews with tracked actions.
Run a short anonymous team survey each quarter and report back what you changed.

First Time Security Manager Guide: Moving From Analyst or Engineer to Leading a Team