How Do You Set a Sustainable Workload for a Security Team?

Start with the services the team must sustain, measure the work those services generate, and compare that demand with the relevant skills and available time. Reserve capacity for interruptions and improvement, limit how much work starts at once, and require an explicit decision when a new commitment exceeds the operating envelope. A list of funded projects is not proof that the organization can operate the capabilities those projects create.

I would not begin with a universal number of security employees per business employee. The same headcount can support very different work depending on service scope, technology, automation, specialist coverage and authority. A staffing ratio can describe an organization without explaining whether its commitments are feasible.

The question here is how to govern the flow of work through an existing security program. It differs from deciding which tool to buy, prioritizing a remediation project or testing whether a SOC detects a particular threat. Those decisions create demand. This paper examines whether the operating model can absorb that demand without concealing deferred work, relying on perpetual overtime or losing the capacity to respond when something important changes.

Define the service before counting the tickets

A security service needs an identifiable customer, an outcome, a scope and a responsibility boundary. “We own vulnerability management” is too broad to size. It could mean maintaining discovery, interpreting findings, deciding priorities, coordinating remediation, implementing fixes, verifying closure or all of those activities. Each interpretation creates different work for different people.

I would describe a service through the decisions and outputs it must deliver. For an architecture review, define the kinds of changes reviewed, the evidence expected from the requester, the reviewer's authority and the conditions for completion. For incident support, identify coverage hours, escalation and the actions the team can authorize. A nominal service without those boundaries is an invitation to unlimited demand.

CSF 2.0 connects cybersecurity responsibilities and authorities with resources commensurate with the organization's strategy and policies (National Institute of Standards and Technology [NIST], 2024, GV.RR-02–03). It does not supply a universal staffing formula. The useful management question is whether the responsibilities being assigned have resources consistent with their scope.

Also record work that belongs elsewhere. A security reviewer may identify an application defect without owning the engineering change. That boundary should include the handoff and acceptance responsibility, not simply a disclaimer that another team must act. Otherwise the security queue becomes a warehouse for work it cannot complete.

Distinguish a shared control from work that disappeared

A centrally provided capability can support several systems, but inheritance does not mean zero operating effort. The provider still needs to maintain the common capability, while consuming teams may retain configuration, integration, monitoring or exception responsibilities. I would identify these responsibilities before treating consolidation as a capacity saving.

The Risk Management Framework explicitly identifies organization-wide common controls available for inheritance and distinguishes common-control provider responsibilities (Joint Task Force, 2018, Task P-5; Appendix D). That provides a useful accountability structure. It does not establish that a managed service or shared team absorbs every task associated with a security outcome.

For example, centralizing an access-review platform may reduce repeated platform administration while leaving business owners responsible for deciding whether access remains appropriate. Security may still handle unresolved identities, disputed ownership and evidence quality. Count the work that remains at each interface; do not book the same saving in both the provider's and consumer's plans.

A service catalogue should therefore include its dependency contract. State which team supplies which input, who resolves missing information and who can change the service scope. The purpose is not to build a large administrative catalogue. It is to reveal the obligations that a budget line or product name otherwise conceals.

Measure demand in more than one unit

Ticket count is useful for flow, but it is not a universal unit of effort. One access clarification and one investigation into a compromised privileged account can each produce a single record. Treating them as interchangeable makes a rising closure count look like greater capacity even when the team has merely changed its case mix.

I would retain at least three views: arrivals by service and work class, effort by the skills consumed, and elapsed time to an accepted outcome. Add the source of demand: scheduled obligation, business request, incident, failed change, recurring defect or internally generated improvement. This identifies whether growth comes from valuable expansion, rework or a failing upstream process.

Keep planned and observed demand separate. An estimate for a new service is a hypothesis. A month's records describe the population and conditions actually observed. Neither should silently replace the other. Record excluded channels such as informal messages or executive requests so that the measured queue does not become a convenient fraction of the real workload.

NIST's measurement guidance emphasizes consistent, time-referenced and standardized data collection among the characteristics of useful measurement (Schroeder et al., 2024, §3.2). In this setting, that means preserving definitions when comparing periods. If the team begins logging previously invisible work, the increase should be reported as improved measurement coverage rather than automatically labeled a deterioration in productivity.

Calculate usable capacity, not paid hours

Paid hours are an upper accounting boundary, not the time available for every service commitment. Leave, training, meetings, management, coordination and other agreed responsibilities consume time. Establish which categories are already excluded from the capacity estimate before subtracting them again inside individual services.

I would distinguish capacity allocated to routine delivery, incident response, improvement and uncommitted flexibility. Those categories need not have fixed percentages across organizations. They need explicit definitions and a rationale based on the service obligations. The same hour cannot be promised simultaneously to a full project schedule and uninterrupted incident coverage.

Availability also varies over time. A monthly average can hide a week with no qualified reviewer, a shift transition or a maintenance window requiring several teams together. Model the period relevant to the decision. A plausible quarterly total does not establish that the required skills overlap when a critical change must occur.

Do not make routine overtime the unexplained balancing term. If the program depends on additional hours, record that dependence and the conditions under which it can be sustained or withdrawn. The capacity plan should remain intelligible when a person takes planned leave or an unusually demanding incident occurs. Otherwise, the apparent balance is a promise about personal endurance rather than an operating design.

Treat skills and authority as separate constraints

NICE describes work through tasks, knowledge and skills, and distinguishes work roles from job titles (Petersen et al., 2020, §§2–3.4). That makes it useful for describing the work a capacity estimate requires. Five people with “security” in their titles are not automatically five interchangeable units for every task.

I would maintain a small capacity view for material bottlenecks: for example, incident coordination, identity engineering, application review and authorized production approval. An individual may contribute to several categories, but their time must be allocated once. Equally, technical skill does not imply permission to approve a consequential action; authority can be the binding constraint even when an engineer is available.

A simple planning condition is that expected effort demanded from each relevant capability must fit within its available capacity over the chosen period. Passing that condition for total hours is necessary but insufficient if one specialty is overloaded. It is also insufficient when dependencies require work in an order the calendar cannot accommodate.

GAO's scheduling guidance warns that schedules without justified resource assignments can imply unlimited availability, and describes resource leveling to account for real constraints (U.S. Government Accountability Office [GAO], 2015, p. 57). For recurring security services, I would apply the same discipline to shared specialists rather than reserve it for formal projects. The adaptation is a planning method, not a claim that project scheduling predicts every operational interruption.

Separate incident capacity from spare time

Incident demand is not simply another neatly scheduled project. NIST's incident-response guidance calls for prioritization using scope, likely impact, time criticality and resource availability (Nelson et al., 2025, RS.MA-03). A program needs an explicit way to redirect capacity when those conditions change.

I would define the incident allocation together with its escalation rule. Which work can pause, who authorizes that pause, what minimum service remains, and how are affected commitments renegotiated? An incident reserve that exists only as a spreadsheet percentage cannot make those decisions when the same specialist is needed in two places.

Google's on-call chapter treats incident handling and follow-up as part of a sustainable duty assignment (Spadaccini, n.d.). Its numerical staffing and incident-load examples reflect Google's context, not a universal cybersecurity standard. The transferable point is that response includes investigation, remediation and follow-through; the first acknowledged page is not the end of the capacity demand.

Unused reserve may support explicitly interruptible work, but that borrowing must be visible. Do not promise the borrowed capacity as a reliable project completion date while still describing it as available for incidents. After a surge, account for the displaced work and recovery obligations. The reserve is a managed commitment under uncertainty, not a guarantee that all plausible incidents can be absorbed.

A fictional team exposes two different overloads

Consider an invented security team at Larch. All quantities below are stipulated planning inputs, not observations from a client or recommended staffing ratios. After agreed overhead and absences, the team has 120 person-hours available in a representative week. Its allocations are 70 hours of recurring services, 25 hours of incident capacity and 20 hours of improvement. That leaves 5 hours uncommitted.

Weekly planning item	Before the new service	After the proposed addition
Available team capacity	120 hours	120 hours
Recurring service effort	70 hours	82 hours
Incident allocation	25 hours	25 hours
Improvement allocation	20 hours	20 hours
Total committed allocation	115 hours	127 hours
Uncommitted capacity / shortfall	5 hours available	7 hours short

The proposed service adds 12 recurring hours each week. A one-time implementation budget cannot resolve the resulting 7-hour weekly shortfall. Larch could narrow the service, remove other work, change the delivery method or add appropriate capacity. Each option changes a named commitment; none is equivalent to asking the existing team to “be more efficient.”

There is a second constraint. Suppose the identity specialist has 16 usable hours within the team's total, of which 12 are already committed. The new service requires 8 identity-specialist hours within its 12-hour total. The specialist demand becomes 20 hours, exceeding the available 16 by 4. These hours are included in the aggregate figures, not added again. Solving the 7-hour pooled shortfall by moving unrelated administrative work may still leave the specialist constraint unresolved.

The example is an arithmetic feasibility check, not a complete forecast. It omits arrival variation, dependencies and uncertainty in the estimates. Its value is to expose two different decisions before approval: whether total commitments fit and whether the required capabilities are available. A credible plan must pass both and then examine timing and variation.

Test the allocation against a different week

The nominal balance should also be challenged with a scenario that changes one assumption. Suppose incident work actually consumes 40 hours instead of the allocated 25. Before the new service, recurring work, incident work and improvement now require 130 hours against 120 available. After the addition, the requirement becomes 142. The shortfalls are 10 and 22 hours respectively. These are alternative weekly scenarios, not extra hours to add to the original table.

Suspending all 20 improvement hours would cover the first shortfall but leave 2 hours unresolved after the new service. It would also remove the work intended to reduce future demand. That is a consequential operating choice, not a free reserve. If the incident needs the same identity specialist, the skill constraint must be recomputed independently; sufficient pooled hours still do not establish a feasible assignment.

This sensitivity check answers what changes under the stipulated demand, not how often that demand will occur. Estimating the frequency requires relevant observations and a defensible treatment of unusual incidents. Do not assign a confidence level to this example. A leader can instead make a conditional admission decision: the new service starts only when both the nominal allocation and an agreed surge response identify feasible work assignments and named displacement decisions.

Track the work that has started but has not finished

An intake list and active work are different populations. A request can be recorded without a commitment to start it immediately. If every accepted request becomes active work, the team may accumulate partially completed reviews and investigations without making the consequences of that choice visible.

The 2025 Kanban Guide defines work-in-progress, throughput, work-item age and cycle time relative to explicit start and finish points. It also calls for controlling started-but-unfinished work and making exceptions explicit (Coleman & Vacanti, 2025). Those definitions are useful here, but a board or software label does not establish that a security team has adopted a coherent workflow.

I would define completion as the agreed service outcome with the required evidence, not simply the analyst's last touch. A case awaiting an owner decision remains unresolved even if the security team's active effort has stopped. Show blocked work separately, with the reason and responsible dependency; hiding it outside the visible workflow changes the apparent performance without completing the obligation.

Limits should reflect the capabilities that actually constrain work. A single team-wide limit may conceal a queue at the only authorized approver. Conversely, too many finely divided limits can make the system unmanageable. Start with the material bottlenecks and review whether the limits expose a useful decision rather than create another administrative ritual.

Use Little's Law without turning it into a deadline promise

Little's Law relates the average number of items in a defined system, their effective arrival rate and their average time in that system: L = λW. Little's retrospective distinguishes long-run results from finite observation windows and explains the conditions and accounting needed to interpret measurements (Little, 2011, §§1–2). The boundaries and populations matter as much as the formula.

For a separate fictional example, assume a stable review process with balanced flow, a time-average of 36 started-but-unfinished items and an effective start/completion rate of 12 items per week across a compatible observation basis. The implied average time from start to finish is 3 weeks. That does not mean a new urgent review will finish in 3 weeks, that every item takes 3 weeks or that an analyst spends 3 weeks working on each item.

A growing backlog, changed work mix or a measurement window that omits unfinished items can invalidate a naive interpretation. Do not divide a single end-of-month snapshot by last month's closures and present the quotient as a validated service forecast. The finite-period boundary terms and excluded work need examination; an apparently precise number can describe incompatible populations.

I would use the relationship as a consistency check and a prompt to investigate flow. Reducing active work can help reveal what must finish before more work begins, but deleting records does not increase service capacity. Likewise, a lower average can conceal an aging high-consequence case. Keep item age and class-specific outcomes beside any aggregate calculation.

Reconcile backlog changes before claiming improvement

A simple work ledger can distinguish arrivals, completions and other dispositions. Start with the unresolved population, add new accepted work and reopened cases, then subtract completed, transferred or explicitly cancelled items under consistent rules. The result should reconcile to the ending unresolved population. This is an accounting identity proposed for the workflow, not a risk model.

Completion, transfer and cancellation must remain different events. Transferring a case can remove it from one team's active responsibility without resolving the organization's exposure. Cancelling a duplicate may be legitimate; cancelling a difficult request merely to improve the dashboard is not evidence of a completed service. Preserve the reason and destination where relevant.

Classify waiting time too. Work can wait for an available specialist, missing evidence, an outside supplier, an authorization or a business decision. More headcount may address only one of those conditions. An intake process that repeatedly accepts incomplete requests may need a clearer readiness criterion rather than more downstream reviewers.

The management report should therefore state what moved and why. “The queue fell” is incomplete. Explain whether accepted outcomes increased, new demand fell, work was transferred, scope was narrowed or definitions changed. Those explanations lead to different decisions and prevent a local throughput improvement from masquerading as an enterprise security improvement.

Protect improvement from permanent interruption

A team can consume all its capacity sustaining current work and thereby lose the ability to reduce future demand. Google's discussion of toil distinguishes repetitive, automatable operational burden from work with enduring value and from ordinary administrative overhead (Rau, n.d.). The distinction helps identify candidates for redesign without pretending that every unpleasant task should be automated.

I would reserve improvement capacity against a named hypothesis: remove a recurring source of rework, simplify evidence collection, eliminate a duplicate approval or improve an upstream service. Define the expected reduction and what continuing maintenance the change will create. An automation that shifts exceptions to another team has changed the workload distribution, not necessarily reduced it.

Interruptions also complicate interpretation of productivity. In a laboratory study of 48 participants performing simulated office-email work, Mark and colleagues found faster interrupted task completion alongside increased reported stress and effort, without a significant difference in the measured error outcome (Mark et al., 2008). That study is not a cybersecurity staffing experiment and supplies no universal interruption penalty.

The implication I would carry into program management is modest: faster visible completion does not prove that a work pattern is sustainable. Examine interruptions, rework, quality and the preservation of improvement commitments together. Avoid importing a fixed percentage of “context-switching loss” without evidence from the relevant work. A useful operating model should not reward hidden strain simply because the ticket count remains acceptable.

Specify overload behavior before the queue becomes a crisis

Google's guidance on handling server overload uses explicit criticality and graceful degradation rather than assuming every request can always receive the same service (Forero Cuervo, n.d.). Human security work is not an RPC system, and the chapter's quotas do not translate into analyst targets. The useful design analogy is to decide which commitments change when capacity is exceeded.

For a security team, I would distinguish urgent response, fixed-date obligations, routine service and discretionary improvement, while recognizing that the categories need local definitions. Each needs an escalation path and a rule for displacement. A high-priority label must identify the consequence of waiting; it should not merely record the seniority of the requester.

Overload responses can include narrowing discretionary scope, postponing a start date, obtaining missing input before acceptance, arranging qualified temporary support or escalating an unmet obligation. Do not silently discard incident reports, ignore binding deadlines or waive security requirements because a work-in-progress limit has been reached. The limit is a signal that an authorized tradeoff is needed, not permission to abandon responsibility.

Require the decision-maker to name what gives way. “Do this as well” is not an overload policy. Record the displaced commitment, its consequence, the temporary arrangement and the review date. This makes a resource shortfall visible to the people empowered to change scope or funding instead of leaving individual analysts to ration service informally.

Treat a new control as a recurring service commitment

Before adding a control, ask what operating work it creates after implementation. Detection rules require interpretation and tuning; access policies create exceptions and review; inventory integrations need reconciliation; evidence pipelines need maintenance. The exact burden must be estimated and tested locally, rather than assumed negligible because a vendor describes the feature as automated.

I would require a compact admission record: intended outcome, recurring demand, affected capabilities, dependencies, incident implications, maintenance obligations and the work it will replace or displace. Include a period for observing actual demand after introduction, with criteria for adjusting scope. A pilot with unusual expert support should state that support rather than imply ordinary staffing achieved the result.

The cost comparison belongs in Should You Buy a New Security Tool or Improve the Controls You Have?. The present question is whether the selected option's operating obligations fit the team's commitments. An economically attractive tool can still be introduced at an infeasible time or without the capability needed to use it responsibly.

Similarly, How Do You Turn a Cybersecurity Gap Assessment Into a Remediation Plan? develops executable remediation packages and dependencies. The service-capacity view should receive those packages' ongoing obligations. A remediation program and an operations plan need to agree on the handover; otherwise, project completion becomes the start of an unplanned queue.

Evaluate a change without moving the measurement boundary

If the team introduces intake limits or protects improvement time, define the evaluation before announcing success. Retain comparable start/finish definitions, service classes and observation periods. Record staffing changes, unusual incidents, support from other teams and work transferred elsewhere. These factors can explain apparent improvement without establishing that the intervention caused it.

I would inspect throughput and unfinished work together, then examine the age and consequences of the cases that remain. Pair faster routine delivery with evidence that important obligations were met and that quality did not deteriorate. A shorter average obtained by excluding difficult cases is not a better service promise.

Review the capacity assumptions after meaningful change: new technology, changed business scope, an absent specialist, a recurring incident pattern or a new contractual responsibility. A model is useful because it can be revised when its assumptions fail. It should not become a quota system used to blame people for demand the organization chose to accept.

No single observation proves sustainability. A quiet month may reveal little about incident coverage; a surge may be unrepresentative of normal work. Report the conditions and the remaining uncertainty. Where evidence is limited, use a provisional commitment with a defined review rather than a confident annual promise that the team has no basis to support.

What the model can and cannot decide

One objection is that security risk should determine priority regardless of capacity. Risk should inform which work matters, but it cannot make unavailable capability appear. A credible plan exposes the gap and seeks an authorized response. Leaving every high-priority item simultaneously active does not make the underlying risk disappear.

Another objection is that limiting intake encourages a security team to refuse business needs. That can happen if the team treats its boundary as a permanent entitlement. The proposed operating envelope must be challengeable: leaders can change scope, delivery methods or resources. What they cannot honestly do is retain every existing commitment and describe the new demand as costless.

This paper is a synthesis of governance guidance, flow theory, reliability practice and bounded human-factors evidence. It is not a validated staffing calculator or a study of a real security team. The mathematical examples use stipulated inputs; Google's practices are context-specific; the interruption experiment has limited generalizability. The sources do not establish a universal staffing ratio, incident reserve or work-in-progress limit.

A useful program review should leave you with a service boundary, a demand picture, a capability-specific capacity estimate and an explicit policy for accepting or changing work. If your roadmap keeps growing while the operating team has no credible room to deliver it, I can help review one team's commitments and identify the decisions needed before adding another service. Bring the service list, recent work records and the proposed additions; those are better starting evidence than another maturity score.