WORKFORCE PLANNING AND CAPACITY MODEL

Staffing Methodology · Workload Drivers · Scaling Guidance

Table of Contents

1. Purpose and Scope
2. The Capacity Problem
3. Workload Drivers by Pillar
4. The Staffing Methodology
5. Engineering Pillar: Capacity Model
6. Risk Pillar: Capacity Model
7. Governance Pillar: Capacity Model
8. The Scaling Map: From 5 to 60+
9. Validating the Model
10. Document Control

1. Purpose and Scope

A CISO walks into a budget meeting and says “I need three more Cloud Security Engineers.” The CFO asks “why three, and why Cloud Security Engineers specifically?” The CISO who cannot answer that question with a methodology will get zero, or one, or a contractor for six months with no renewal path. The CISO who produces a capacity model built on workload drivers, not headcount comparisons, will get a conversation about which assumptions the CFO disagrees with. A conversation about assumptions is a negotiation. A conversation without assumptions is a request.

This document provides the methodology. It defines the workload drivers for each pillar, translates them into staffing formulas, and provides the scaling guidance that supports a headcount request from a 5-person startup CERG to a 60-person enterprise function. It is designed to be a live tool: organizations plug in their numbers and get a recommended staffing range with documented rationale.

It applies to every CERG role. It does not prescribe exact headcount; it prescribes the method for arriving at a defensible headcount. The output is a range, not a single number, because judgment about organizational context, team composition, and automation maturity always matters.

Headcount Without Methodology Is a Wish

Every CISO has a wishlist. The capacity model turns wishes into requests and requests into negotiations. It will not eliminate the budget conversation. It will make the conversation about the model’s assumptions, not about whether the CISO is credible. That is a better conversation to have.

2. The Capacity Problem

2.1 Why Cybersecurity Staffing Is Hard to Model

Most corporate functions have stable workload-to-headcount ratios. Accounts payable: X invoices per clerk per month. IT support: Y tickets per technician per day. Cybersecurity does not work this way for three reasons:

1. Workload is adversary-driven, not business-driven. A new ransomware variant can multiply the detection engineering workload overnight. A zero-day in a widely deployed platform can turn every Cloud Security Engineer’s week into emergency response.
2. Work is invisible when done well. A Cloud Security Engineer who prevents a misconfigured S3 bucket from reaching production has done some of the highest-value work in the organization. The work produced no ticket, no finding, and no metric other than the absence of a breach. Capacity models that measure only tickets undercount security engineering by design.
3. Regulatory scope changes the workload non-linearly. Adding NERC-CIP to an organization’s compliance scope does not add one FTE of Governance work. It adds a compliance manager, an evidence librarian, OT engineering support, and a new audit cycle. Frameworks multiply; they do not add.

2.2 The Capacity Model’s Answer

This model addresses the capacity problem by defining workload drivers that are:

• Observable. An organization can count its projects, assets, vendors, and frameworks.
• Predictive. The relationship between the driver and the staffing need is grounded in how CERG roles actually spend their time.
• Ranged. Every formula produces a range (minimum, target, maximum), not a point estimate. The range accounts for organizational context, automation maturity, and team experience.
• Calibratable. Organizations that track actual time allocation can refine the model’s coefficients. An organization that discovers its Cloud Security Engineers spend 40% of their time on architecture review rather than the model’s assumed 30% can adjust the formula for its next cycle.

3. Workload Drivers by Pillar

3.1 Engineering Pillar Drivers

3.2 Risk Pillar Drivers

3.3 Governance Pillar Drivers

4. The Staffing Methodology

4.1 The Base Formula

For each role, the recommended staffing range is calculated as:

Headcount = ⌈(Driver1 / Throughput1) + (Driver2 / Throughput2) + ...⌉ × Complexity Factor × Automation Discount

Where: - Driver is the workload driver value for the organization (e.g., 45 active projects) - Throughput is the number of driver units one FTE can handle at target quality (e.g., 8-12 active projects per Cloud Security Engineer) - Complexity Factor adjusts for organizational complexity beyond the baseline (1.0 = baseline; 1.3 = highly complex; 0.8 = low complexity) - Automation Discount reduces headcount for mature automation (1.0 = no automation; 0.85 = moderate automation; 0.70 = high automation)

The ceiling brackets ⌈…⌉ indicate rounding up to the nearest whole person. A calculation that produces 2.3 FTEs means 3 people; the 0.7 surplus is absorbed by management overhead, surge capacity, and the reality that cybersecurity work does not divide evenly.

4.2 The Role Consolidation Rule

The scaling map in CERG-GOV-RAC-001 §8 shows how 27 canonical roles consolidate onto as few as 5 people. This model respects that consolidation. When the formula produces less than 1.0 FTE for a role, the role is consolidated onto an adjacent role rather than fractionalized:

• If the model says 0.4 Detection Engineers and 0.6 Threat Intelligence Analysts, both roles consolidate onto one person who splits their time, or the Detection Engineering work is absorbed by the Exposure Management Lead
• Pillar Leader roles consolidate downward: in a 5-person CERG, the CISO directly manages all pillars, and the senior-most practitioner in each pillar operates as a player-coach at S3-S4

The model reports both the unconsolidated headcount (what the formula says) and the consolidated headcount (how roles combine for organizations below a certain scale).

4.3 The Management Overhead Factor

Every IC headcount carries a management overhead. The overhead is not linear (a 3-person team does not need 0.3 Managers; it needs zero) but emerges at certain thresholds:

5. Engineering Pillar: Capacity Model

5.1 Cloud Security Engineer

Primary driver: Active projects requiring cloud security engagement.

Formula:

CE = ⌈(Low_Projects / 14) + (Med_Projects / 7) + (High_Projects / 2.5)⌉ × CF × AD

Additional drivers: - +0.5 CE for every distinct major cloud platform beyond the first (AWS + Azure = 0.5 additional) - +0.5 CE if the organization operates SaaS security posture management separately from IaaS security - +1.0 CE if the organization has a dedicated cloud security engineering function for OT/ICS environments

5.2 Identity Engineer

Primary driver: Identity platform complexity and integration surface.

Formula:

IE = Base(Org_Size_Tier) + Federation_Count × 0.3 + PAM_Program × 0.5 + CIAM_Program × 0.5

Where Base(Org_Size_Tier) is: Small = 0.5, Medium = 1.0, Large = 1.5, Enterprise = 2.0.

5.3 OT Security Engineer

Primary driver: OT environment count and complexity.

OT Security Engineers are rarely filled below S2. The minimum staffing for any organization with an OT environment is 1.0 FTE; below that, the role consolidates onto a Cloud Security Engineer with OT training (and the risk of that consolidation should be explicitly acknowledged).

5.4 Application Security Engineer

Primary driver: Development team count and deployment frequency.

Formula:

AppSec = ⌈Dev_Teams / 8⌉ + (CI_CD_Maturity × 0.5)

Where CI_CD_Maturity = 0 (quarterly/manual), 1 (monthly), 2 (continuous).

5.5 Endpoint Engineer

Primary driver: Endpoint count and platform diversity.

5.6 Cryptography Engineer

Primary driver: PKI scale and regulatory crypto requirements.

6. Risk Pillar: Capacity Model

6.1 Exposure Management Lead / Analyst

Primary driver: Assets under management and scan frequency.

Formula:

VM = ⌈(Assets / 8000) × Scan_Freq_Factor⌉ + OT_Assets × 0.3

Where Scan_Freq_Factor = 0.8 (weekly), 1.0 (daily), 1.3 (continuous). OT_Assets is in thousands.

6.2 Adversarial Testing Lead

Primary driver: Testing cycles and scope breadth.

6.3 Threat Intelligence Analyst

Primary driver: Intelligence production volume and source diversity.

6.4 Vendor Risk Analyst

Primary driver: Vendor portfolio size weighted by tier.

Formula:

VRA = ⌈(Critical_Vendors / 30) + (High_Vendors / 60) + (Medium_Vendors / 100) + (Low_Vendors / 200)⌉

6.5 Detection Engineer

Primary driver: Detection surface (log sources and use cases).

6.6 OT Risk Analyst and Identity Risk Analyst

These roles are additive to the Risk pillar based on specific organizational scope:

• OT Risk Analyst: +1.0 for any organization with an OT environment; +0.5 per additional OT site beyond the first; +1.0 if NERC-CIP regulated
• Identity Risk Analyst: +1.0 if the organization operates UEBA or identity threat detection; +0.5 if the organization has a dedicated identity security program; consolidates onto Detection Engineer or Threat Intelligence Analyst if below 1.0

7. Governance Pillar: Capacity Model

7.1 NERC-CIP / CMMC / SOX Compliance Managers

Each major regulatory framework that requires a dedicated compliance program generates its own staffing demand. The base staffing per framework is:

Frameworks with overlapping controls reduce the combined staffing need. Use the higher of two overlapping frameworks plus 30% of the lower, not the sum:

Combined_Staff = max(Framework_A, Framework_B) + 0.3 × min(Framework_A, Framework_B)

7.2 Evidence Librarian

Primary driver: Evidence volume and refresh frequency.

7.3 Policy & Standards Manager

Primary driver: Document count and review cycle complexity.

7.4 Risk Register Owner

Primary driver: Risk register size and exception volume.

8. The Scaling Map: From 5 to 60+

8.1 Illustrative Staffing at Different Scales

The table below applies the capacity model to four illustrative organization profiles. These are examples, not prescriptions. Every organization’s numbers will differ.

*In a 5-person organization, these roles are consolidated per the RACI scaling map (RAC-001 §8). The CISO manages all pillars directly. The senior-most practitioner in each pillar operates at S3-S4 level with expanded scope covering adjacent roles.

8.2 When to Split a Role

A role that reaches 2.5+ FTE in the model should be evaluated for a split:

9. Validating the Model

9.1 The First-Year Reality Check

The capacity model produces a theoretical headcount. The first year of tracking actual time allocation validates or refutes the model’s assumptions. Organizations should:

1. Track time allocation for at least one quarter. Use broad categories: project work, operational work, unplanned/incident work, administrative overhead. Do not ask for timesheets in 15-minute increments; ask for a weekly estimate by category.
2. Compare actual to modeled. If Cloud Security Engineers are spending 50% of their time on unplanned work, the model’s project-throughput assumptions are wrong for this organization. Adjust the model or fix the source of unplanned work.
3. Refine the coefficients. The throughput numbers in this model are baseline estimates. An organization that discovers its Engineers can handle 10 medium-complexity projects (not the model’s 7) should update its formula. The model improves with use.
4. Recalibrate before each budget cycle. An organization that is growing, adding platforms, adding regulatory frameworks, or maturing its automation should run the model fresh each year.

9.2 Automation Maturity Adjustment

Organizations with mature security automation should apply the Automation Discount (AD) factor from §4.1. Signs of automation maturity include:

9.3 The Experience Adjustment

A team of predominantly S3-S4 practitioners handles more throughput per person than a team of S1-S2 practitioners. An organization with a senior-heavy team may increase throughput coefficients by 15-25%. An organization with a junior-heavy team (common during rapid growth) should decrease throughput coefficients by 15-25% and budget for the mentoring overhead that junior practitioners require.

The Model Is Honest About Its Limits

This model will not tell you that you need exactly 2.3 Cloud Security Engineers. It will tell you that based on your project count, complexity mix, and automation maturity, your range is 2-3. The decision between 2 and 3 depends on factors no model captures: your risk appetite, your team’s current burnout level, your ability to hire, and whether you have a major platform migration coming in Q3 that is not yet on the project register. The model provides the range and the rationale. The CISO provides the judgment.

10. Document Control

Revision History

Review Triggers

• Before each annual budget cycle (re-run the model with current data)
• Material change to organizational scope: new platforms, new regulatory frameworks, major initiative launches
• Material change to automation maturity
• Feedback from time allocation tracking indicating model coefficients need adjustment
• Direction from the CISO

Related Documents

Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes.

Source: governance/CERG-GOV-WFP-001_Workforce_Planning_and_Capacity_Model.md · Download .md · View on GitHub