Join our Newsletter — 33% off our NHI Course
Home› Guides› Security Workforce Planning Guide: Size Teams and Map…
Guide Security Leadership & Governance

Security Workforce Planning Guide: Size Teams and Map Roles to NICE

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 15 min read
On this page

Most security functions are sized by last year's headcount plus whatever the budget round allows, not by the work the organisation actually needs done. The result is a team that is permanently short in some capabilities, over-invested in others, and dependent on one or two people for critical systems. This guide sets out a repeatable workforce planning method: model demand from workload drivers, inventory current capability against NICE Framework work roles, quantify the gap, and choose between building, buying and borrowing the missing capacity. It is written for CISOs, heads of security operations and the HR business partners who support them. For hiring tactics and the labour market itself, see the Cybersecurity Skills Gap and Hiring Guide.

Key takeaways

  • Plan from work, not titles. NIST SP 800-181 Rev. 1 states that work role names are not synonymous with job titles, so map tasks to NICE work roles first and design positions afterwards.
  • Demand is driven by countable things. Assets, identities, applications, alerts, suppliers and change volume drive security workload; model headcount from these drivers with your own measured effort rates, not from industry ratios.
  • Coverage and resilience are separate from capacity. A 24/7 rota, on-call duty and key-person cover add headcount that pure workload maths will not show.
  • Build, buy and borrow are a portfolio. Most organisations combine internal hires, managed services and contractors; decide per capability based on how core, how continuous and how specialised the work is.
  • Review the plan every year and after major change. Acquisitions, cloud migrations, new regulation and AI adoption change demand faster than annual hiring cycles assume.

Why workforce planning belongs in the security strategy

NIST CSF 2.0 makes resourcing an explicit governance outcome: GV.RR-03 requires that adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities and policies, and GV.RR-04 requires that cybersecurity is included in human resources practices. NIST SP 800-53 Rev. 5 has a matching programme management control, PM-13 Security and Privacy Workforce, which calls for a workforce development and improvement programme. In practice these outcomes are hard to evidence without a written plan that links headcount to the risk strategy.

The external market makes planning more important, not less. The UK government's Cyber Security Skills in the UK Labour Market 2025 report found that 49% of businesses had a basic cyber skills gap and 30% had an advanced skills gap, while estimating the UK cyber workforce at about 143,000 people at the end of 2024. Where hiring is slow, the plan has to say which work will be covered by other means while vacancies are open. For more figures, see the Security Workforce and Skills Gap Statistics Guide.

Step 1: define the services the function delivers

Before counting people, list what the security function delivers to the organisation. A service catalogue gives every later step a stable unit of work. A typical catalogue has 15 to 30 services grouped by NIST CSF 2.0 function:

CSF 2.0 functionExample servicesTypical output
Govern (GV)Policy and standards, risk management, third-party risk, security reporting, workforce managementApproved policies, risk register, supplier assessments, board reports
Identify (ID)Asset and identity inventory, vulnerability management, threat intelligence, risk assessmentInventories, prioritised findings, threat briefs
Protect (PR)Identity and access management, secrets and key management, security architecture, awareness and training, secure configurationAccess decisions, design reviews, hardened builds, training completions
Detect (DE)Security monitoring, detection engineering, threat huntingTriaged alerts, new detections, hunt reports
Respond (RS)Incident response, digital forensics, crisis communications supportContained incidents, forensic reports, lessons learned
Recover (RC)Recovery testing, backup assurance, post-incident improvementTest results, restored services, improvement actions

For each service record the owner, the customers, the service level (business hours, extended hours or 24/7), and whether it is delivered internally, by a provider or jointly. The Security Operating Model and Organisation Design Guide covers how the services are organised; this guide covers how many people of which kind they need.

Step 2: map the work to NICE Framework work roles

The NICE Workforce Framework for Cybersecurity (NIST SP 800-181 Rev. 1) describes cyber work as Task, Knowledge and Skill (TKS) statements grouped into work roles and competency areas. The components are versioned separately from the publication: NIST lists v2.2.0 as the current components release, which added the Cybersecurity Supply Chain Risk Management (C-SCRM) work role (OG-WRL-017). Version 2.0.0 removed the Cyberspace Effects and Cyberspace Intelligence categories, which now sit in the DoD Cyber Workforce Framework (DCWF), and added Operational Technology (OT) Cybersecurity Engineering (DD-WRL-009). Download the current components in JSON or XLSX and record the version in your plan.

  1. Break each service into tasks: use NICE task statements where they fit and write local tasks where they do not, for example non-human identity attestation or AI agent permission reviews.
  2. Assign each task to a primary work role: SP 800-181 Rev. 1 notes that one work role can cover many job titles and several roles can combine into one job, so expect many-to-many mapping.
  3. Choose top-down or bottom-up: section 3.5 of SP 800-181 Rev. 1 describes building teams top-down from the work to be done, or bottom-up from competencies when the tasks are not yet known. Use top-down for established services and bottom-up for new capabilities such as AI security.
  4. Set a proficiency level per role: the framework itself does not define proficiency levels. NIST's NICE resource centre publishes guidance on identifying proficiency; agree one scale (for example entry, practitioner, expert) and use it consistently.
  5. Keep the mapping as data: a table of service, task, work role ID, proficiency and current owner is reusable for hiring, training and succession planning.

The NICE Workforce Framework Guide covers the framework's structure in depth; Europe-based teams can apply the same method with the ENISA ECSF Skills Framework Guide.

Step 3: model demand from workload drivers

There is no authoritative ratio of security staff to employees or to IT staff, and published survey ratios vary too widely to plan against. Build a driver-based model instead: for each service, pick the countable driver that best predicts effort, measure or estimate the effort per unit, and multiply.

ServiceWorkload driverEffort rate (measure your own)Annual hours
Security monitoringAlerts escalated for human triage per year[20] minutes per alertAlerts x rate
Vulnerability managementAssets in scope, critical findings per month[x] hours per 1,000 assets plus [y] hours per critical findingSum
Identity and access managementJoiner, mover and leaver events; access requests; access review items[x] minutes per event; [y] minutes per review itemSum
Non-human identity governanceService accounts, API keys, certificates and agents under management[x] hours per 100 NHIs per quarter for ownership attestation and rotation follow-upSum
Security architectureDesign reviews per year by size (small, medium, large)[4 / 16 / 40] hours per reviewSum
Third-party riskNew suppliers by tier and annual reassessments[x] hours per Tier 1 assessment, [y] per Tier 2Sum
Incident responseIncidents by severity[x] hours per major incident, [y] per minorSum
Policy and audit supportAudits, regulatory returns, policy reviews[x] days per auditSum

Values in square brackets are placeholders: replace them with rates measured from your ticketing system, time sampling over four to six weeks, or provider invoices. Then convert hours to full-time equivalents (FTE):

  • Productive hours: start from contracted hours per year and subtract leave, public holidays, sickness, training and internal meetings. Many organisations land between [1,400] and [1,600] productive hours per FTE; calculate yours with HR rather than assuming.
  • Utilisation target: plan at [75 to 85]% of productive hours for operational roles, leaving slack for surges, improvement work and training. Planning at 100% guarantees backlog.
  • Growth factor: apply the forecast change in each driver over the plan period, for example cloud workloads, NHIs or suppliers expected next year.

Coverage and resilience adjustments

Workload maths gives capacity. Three adjustments add headcount on top:

  • Coverage: a seat staffed 24 hours a day, 7 days a week needs several people per seat once leave and shift rules are applied. The SOC Staffing and Shift Models Guide works through the arithmetic.
  • On-call: on-call rotas for incident response, PKI and identity platforms need enough people that nobody is on call more than [one week in four].
  • Key-person cover: every critical system (identity provider, PAM vault, HSM, SIEM) needs at least two people able to operate and recover it. If only one person can, the plan should fund a second, regardless of workload.

Step 4: inventory supply and quantify the gap

Supply is the capability you already have. Record every person in the function, and any staff outside it doing security work, against the same work role map.

  1. Capture current allocation: for each person, the percentage of time spent on each service, from time sampling or manager estimates.
  2. Record proficiency: self-assessment calibrated by managers against the agreed scale, plus relevant certifications.
  3. Add provider capacity: FTE equivalents delivered by managed services and contractors, with contract end dates.
  4. Flag risk: single points of knowledge, staff with known retirement or exit dates, and roles with long vacancies.
  5. Compute the gap: demand FTE minus supply FTE per work role and proficiency level. A positive capacity gap and a proficiency gap are different problems: the first needs people, the second needs development or senior hires.
Work role (NICE)Demand FTESupply FTEGapKey-person riskProposed action
[Security monitoring role, Protection and Defense category][8.0][6.5][1.5]Low[Hire 1, extend MDR scope by 0.5]
[Identity and access role, local or mapped][3.0][1.5][1.5]High: one engineer runs the PAM vault[Hire 1 senior, cross-train 1]
Cybersecurity Supply Chain Risk Management (OG-WRL-017)[1.5][0.5][1.0]Medium[Develop GRC analyst, automate tiering]
OT Cybersecurity Engineering (DD-WRL-009)[1.0][0][1.0]High[Specialist contractor, then hire]

The figures are illustrative placeholders. Use the exact work role names from the components version you downloaded.

Step 5: decide build, buy or borrow

Closing a gap does not always mean hiring. Decide per capability.

OptionBest forTrade-offsLead time
Build: develop existing staffProficiency gaps; adjacent skills (IT operations into security operations, developers into application security)Slower; needs senior mentors and training budget; increases retention6 to 18 months
Buy: permanent hireCore, continuous capabilities that need organisational context: architecture, identity, risk, incident commandRecruitment time and cost; salary market pressure; best long-term retention of knowledge3 to 9 months including notice periods
Borrow: managed serviceContinuous, standardised work at scale: 24/7 monitoring, vulnerability scanning operations, email securityLess context; contract and exit management; you keep accountability1 to 3 months
Borrow: contractor or consultancyTime-bound projects, specialist peaks (OT, cloud migration, forensics), cover for vacanciesExpensive per hour; knowledge leaves with them unless documentedWeeks
AutomateHigh-volume repetitive tasks: enrichment, access request routing, certificate renewal, questionnaire triageEngineering effort up front; needs owners to maintain automation1 to 6 months

Small organisations (a security team of one to five) should keep governance, risk ownership, identity administration and incident command in house and buy most continuous operations. Large organisations can justify specialist internal teams for detection engineering, threat intelligence and identity, and use providers mainly for surge and niche skills. In both cases, the organisation retains accountability for outsourced services and must staff the oversight of them, typically [0.2 to 0.5] FTE per major provider contract.

Where identity fits

Identity work is often under-counted because it is spread across IT service desks, platform teams and security. Non-human identity work is the most frequently missed: service accounts, API keys, certificates, workload identities and AI agents each need owners, attestation, rotation and decommissioning, and the effort grows with cloud adoption, not with employee headcount. Count NHIs as a workload driver in Step 3 and assign their governance tasks to a named role. The Identity Team Operating Model and Workforce Planning Guide goes deeper on sizing the identity team, and the NHI and Machine Identity Engineer Career Guide describes the role.

Step 6: turn the gap into a funded plan

  1. Prioritise by risk: rank gaps by the risk they leave untreated, using the risk register. A gap in identity or incident response usually outranks a gap in a lower-priority assurance activity.
  2. Phase over the plan period: a typical plan covers [three] years, with year one fully costed and later years indicative.
  3. Cost each action: fully loaded salary, recruitment fees, training, provider fees and tooling for automation. Link the plan to the budget; see the Security Budget and Investment Planning Guide.
  4. Agree with HR: job families, grades, career paths and retention measures. GV.RR-04 expects security to be part of HR practices, including screening (SP 800-53 PS-3) and position risk designation (PS-2) for sensitive roles.
  5. Plan development: role-based training (SP 800-53 AT-3; CSF PR.AT-02) tied to the proficiency gaps, with protected time.
  6. Plan succession: name a successor or deputy for each critical role and each key system, with a documented runbook.
  7. Approve and publish: the plan should be approved by the executive who owns the security budget and reviewed by the risk committee.

Rolling out and testing the plan

  • Pilot one service first: model a single service, such as vulnerability management, end to end to calibrate effort rates before scaling to all services.
  • Back-test: apply the model to last year's drivers and compare to last year's actual staffing and backlog. Large differences mean the effort rates are wrong.
  • Keep a fallback: if hiring stalls, the plan should state which provider or contractor capacity covers each critical gap and the trigger for using it, for example a vacancy open more than [90 days].

Retention as a planning input

Attrition is demand in disguise: every leaver creates a vacancy plus lost knowledge. The UK 2025 labour market report found that about 12% of cyber sector employees left their posts over an 18-month period, most of them voluntarily. Measure your own rate and plan replacements for it. Practical levers that sit inside a workforce plan include:

  • Career paths: visible progression from analyst to engineer to lead, mapped to the same work roles and proficiency scale.
  • Workload limits: utilisation targets and on-call limits written into the plan, not left to goodwill.
  • Development time: protected training days and certification support tied to the proficiency gaps.
  • Rotation: planned moves between operations, engineering and governance reduce burnout and spread knowledge.

Hiring itself carries security risk, including fraudulent candidates for remote technical roles. See the Hiring Fraud and Candidate Identity Verification Guide.

Measuring whether the plan works

MetricHow to measureWhat good looks like
Capacity coverageSupply FTE divided by demand FTE, per serviceAt or above [90]% for critical services
Critical roles with a trained deputyCritical systems and roles with two or more competent people100%
Time to fillDays from approval to start date, per role familyFalling, and inside the fallback trigger
Regretted attritionVoluntary leavers the organisation wanted to keep, per yearBelow your own baseline
Backlog trendOpen items per service (findings, requests, reviews) over timeStable or falling as drivers grow
Proficiency gap closurePositions meeting their target proficiency levelRising each review

Framework mapping

FrameworkReferenceHow workforce planning supports it
NIST CSF 2.0GV.RR-02, GV.RR-03, GV.RR-04, PR.AT-02Defined roles, adequate resources, security in HR practices, specialised training
NIST SP 800-53 Rev. 5PM-2, PM-13, AT-3, PS-2, PS-3, PS-7Programme leadership role, workforce programme, role-based training, personnel security including external staff
NIST SP 800-181 Rev. 1Work roles, competencies, team building (section 3.5)Common language for mapping work, positions and gaps
ISO/IEC 27001:2022Clause 7.1 Resources, clause 7.2 CompetenceDetermining and providing resources; evidencing competence

Common failure patterns

  • Benchmarking instead of modelling: setting headcount from a survey ratio produces a number nobody can defend when the budget is challenged. Driver-based models can be defended line by line.
  • Counting people, not capability: ten analysts with no one able to recover the identity provider is a gap that headcount totals hide.
  • Ignoring provider oversight: outsourcing monitoring without funding the internal staff to manage the provider leaves alerts escalated to nobody.
  • Planning at full utilisation: no slack for incidents, leave or improvement work means every surge becomes a backlog and every backlog becomes attrition.
  • Static plans: a plan written before a cloud migration or acquisition and never revisited underestimates identity, cloud and supplier work.
  • Missing non-human identities: sizing identity work by employee count misses the service accounts, keys and agents that now outnumber people in most estates.

Practitioner checklist

  • Publish a service catalogue for the security function with owners and service levels.
  • Download the current NICE Framework components and record the version used.
  • Map every service's tasks to work roles and a proficiency level.
  • Build a driver-based demand model with measured effort rates and a utilisation target.
  • Add coverage, on-call and key-person adjustments on top of workload FTE.
  • Inventory supply, including providers and staff outside the function, and compute gaps per work role.
  • Decide build, buy, borrow or automate per gap, with costs and lead times.
  • Name a trained deputy for every critical role and system.
  • Track the six metrics quarterly and refresh the plan annually and after major change.

Standards and references

Related NHI Mgmt Group resources: Cybersecurity Skills Gap and Hiring Guide · NICE Workforce Framework Guide · Security Operating Model and Organisation Design Guide · SOC Staffing and Shift Models Guide · Security RACI Matrix Template

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org