Vulnerability Programme Staffing and Throughput Economics

Staffing is a sized question, not a backlog reaction

The headline backlog number is a lagging indicator. It records the cumulative outcome of every staffing, cadence, scope, and routing decision the programme made in the prior windows. Treating the backlog as the staffing question conflates the cause (per-role throughput, per-stage cycle time, per-team coordination shape) with the effect (the number on the dashboard). Programmes that argue staffing from the backlog usually end up understaffed at one binding constraint and overstaffed at an adjacent stage, because the backlog cannot tell the leadership reviewer which stage to invest in.

The sized question reads per-role throughput against per-stage inflow. Triage analyst capacity is sized to the new-state arrival rate. Remediation capacity is sized to the assignment-state arrival rate the triage stage produces. Retest capacity is sized to the in-retest arrival rate the remediation stage produces. Governance and compliance capacity is sized to the conversion-and-renewal volume. The senior responsible role is sized to the operating cadence, the leadership report, the audit interface, and the staffing plan itself. Each role pair is sized to the upstream stage that feeds it rather than to the headline closure target. The ingest-versus-capacity research covers the queue-level ratio side that this staffing frame produces capacity against.²⁴

The framing throughout this research treats staffing as a deliberate plan against measurable inflow and measurable role throughput, not as a percentage uplift on last year. The plan reads per-role and per-stage on a cadence that lets leadership see whether the staffing curve is holding, where it is approaching its break, and which role to invest in next. Read alongside the state-machine decomposition research, the staffing frame names the binding constraint at the role layer the way the state-machine frame names the binding constraint at the transition layer.²³

Six named role classes inside the programme

A defensible programme runs with six named role classes. Smaller programmes collapse adjacent classes into one named person; larger programmes split each class into multiple specialised roles. The class definitions stay the same across sizes; what changes is how many FTE land in each class and how the class boundaries are drawn against the engineering organisation the programme routes work to.^2,3,4

Reading the six classes against the lifecycle states (the named-owner column above) is what lets the programme see which class owns which transition. The state machine throughput decomposition names the binding constraint at the transition layer; the six-class staffing frame names the role that sits on that transition and the per-FTE throughput envelope at that role. The two surfaces read together answer both "which transition is slow" and "which role do we add capacity at".²³

Per-FTE throughput envelopes at acceptable quality

The per-FTE envelope is the steady-state throughput one named FTE produces in the named role at acceptable quality (full severity record, asset binding check, evidence capture, identifier preservation, framework mapping where applicable). The envelopes vary with finding mix, scanner noise, lifecycle maturity, and the engineering organisation shape the programme routes to. The default ranges below describe what enterprise programmes observe in practice when the scanner noise is tuned, the asset register is reasonably complete, and the engineering teams the programme routes to are responsive.^3,5,6,12,15

The envelopes describe what one FTE produces inside the named role at the named quality bar, not what the role can produce under emergency conditions or with quality reductions. Programmes that benchmark staffing to emergency throughput build plans that hold for a quarter and then fail; programmes that benchmark to steady-state throughput build plans that hold across the inflow shape the cadence and scanner-coverage decisions produce. The remediation economics by finding source archetype research covers how finding source class shifts the per-FTE cost of remediation and complements the per-role throughput envelopes above.²⁸

Where the staffing curve becomes non-linear

The staffing curve is linear for the first one to three FTE in each role class because the role can absorb its own coordination overhead and the per-FTE envelope holds. Past that, the curve bends. The three structural effects that bend it are coordination tax, queue starvation upstream, and scope-design constraints downstream. Each shows up in the per-stage cycle time before it shows up in the headline closure rate.^3,7,10,12

The leadership read on which effect is bending the curve at any given moment is the per-role utilisation against envelope, paired with the per-stage cycle time. Falling utilisation at one stage with rising cycle time at the prior stage is queue starvation upstream; rising utilisation at one stage with rising cycle time at the next stage is scope-design constraint downstream; falling utilisation at one stage with rising coordination overhead is intra-role coordination tax. Reading the three signatures lets leadership distinguish "we need more FTE in this role" from "we need to fix the upstream routing first" without running the entire staffing argument as anecdote.

Pairing role classes to lifecycle states

The pairing reads from state to role rather than from role to state because each lifecycle state has one or two named owners, and the audit citation reads the named-owner field on each finding rather than the org chart that produces it. Programmes that document the pairing on the record (rather than only on a policy artefact) see the routing in the activity log and can identify the binding constraint without interviewing teams.^2,3,4,17,18

Reading the pairing on the live record (the named-owner field on the finding, the timestamped chain in the activity log, the role assignments in the workspace user catalogue) lets the programme see which role is the binding constraint at any moment between cycles. The cross-team ownership transfer latency research covers how long the finding spends in transit when ownership moves between roles or between teams; the staffing frame and the transfer-latency frame read together identify both the per-role envelope and the per-handoff cost.^26,27

Sizing the staffing ratio against inflow

The defensible staffing ratio reads inflow per severity band against per-role throughput envelopes rather than against the headline closure rate. Each role is sized to the upstream stage that produces its work and to the long-tail reserve the programme needs for KEV-promotion spikes, pentest engagement intake, and disclosure surges. Adding role-specific reserve at the front of the queue protects every downstream role from the inflow bursts the headline-level plan does not anticipate.^5,7,11,15,24

• Triage capacity sizing. Triage analyst FTE is sized to the new-state arrival rate at the programme's steady-state inflow plus a 25 to 50 percent reserve for KEV promotion, pentest engagement intake, and disclosure surges. A programme ingesting 200 weekly findings at the high-and-above bands plans for one analyst envelope of 300 plus reserve of 50 to 100, which lands the requirement at one FTE for the steady state with on-call cover for the surge.
• Remediation capacity sizing. Security engineer and AppSec engineer FTE is sized to the assignment-state arrival rate the triage stage produces (typically 60 to 80 percent of triaged volume), broken down by finding class (infrastructure or platform versus code-side) so the capacity lands at the right role. Code-side capacity is sized against the responsive-engineering ceiling rather than the analyst-only envelope because AppSec throughput is coordination-bound at scale.
• Retest capacity sizing. Retest engineer FTE is sized to the in-remediation closure rate the remediation stage produces, with a reserve for batched retests at quarter-end and audit fieldwork. Programmes that under-size retest produce a fix-deployed metric that overstates the actual remediation throughput because the verified-closure step waits in a retest queue rather than landing in the period.
• Governance capacity sizing. Governance and compliance analyst FTE is sized to the conversion volume plus the renewal cycle volume across the per-band cadence. The conversion gate research covers the conversion-volume side and the renewal cadence research covers the renewal-cycle side; the staffing frame sizes the capacity that runs both.
• Lead capacity sizing. The vulnerability management lead role is sized to programme work rather than per-finding throughput. The lead absorbs operational work only when the adjacent roles are under-resourced; sizing the lead as a triage-or-remediation FTE is one of the seven failure modes named below.

The pattern is to size each role to the upstream stage that produces its inflow, not to the headline backlog. A programme whose triage stage is correctly sized but whose remediation stage is undersized still sees the backlog grow; a programme whose remediation stage is correctly sized but whose triage stage is undersized still sees the backlog grow; a programme whose two adjacent stages are sized but whose retest stage is undersized produces fix-deployed without fix-verified. The defensible staffing plan reads through every stage in sequence and sizes each against its specific upstream signal.

Seven staffing failure modes

The failure modes below are predictable and recognisable. Each shows in the per-state cycle time first and in the leadership report later. Reading the per-state cycle time and the per-role utilisation against envelope lets the programme catch the failure mode at the operational layer before it surfaces in the audit committee read.^3,4,7,9,12

1. One vulnerability lead carrying every role at small programme scale. Works at low inflow; collapses across every state when the lead is on leave, in audit prep, or absorbed by the leadership report cycle. Cure is to add a part-time triage analyst and a part-time governance analyst before the inflow grows past lead-only capacity, not after.
2. Triage analysts under-resourced relative to scanner inflow. Front of the queue grows; aged-queue debt accumulates; remediation FTEs sit underutilised because the queue feeding them is bandwidth-bound at triage. Symptom is rising new-state and triaged-state cycle time with stable or falling remediation utilisation. Cure is to add triage capacity or retune scanner cadence at the front of the queue.
3. Remediation FTEs under-resourced relative to triage throughput. Assigned-state queue grows; SLA breach rate climbs; exception conversion rate rises as a substitute for remediation closure. Symptom is rising assigned-state and in-remediation-state cycle time with stable conversion rate that then spikes as substitute closure. Cure is to add remediation capacity or restructure the routing to the engineering teams that absorb the finding load.
4. Retest FTEs under-resourced relative to remediation closure rate. Deployed fixes wait for verification; in-retest queue grows; programmes report fix-deployed without reporting fix-verified. Symptom is rising in-retest cycle time with otherwise healthy upstream metrics. Cure is to add retest capacity or restructure the retest evidence flow so retests run in parallel rather than serially.
5. Governance analyst under-resourced relative to conversion plus renewal volume. Conversion artefact is field-incomplete; renewal cycle slips; audit citation reads field-present and active-validity-empty. Symptom is rising closed-exception-state aging with conversion rationale quality scores falling on quarterly sampling. Cure is to add governance capacity or restructure the conversion gate to throttle inflow against the available capacity.
6. Lead absorbing operational work at scale. The vulnerability management lead becomes a triage analyst or a remediation engineer rather than a programme owner; operating cadence, leadership report, and audit interface degrade. Symptom is leadership report slipping, audit interface absorbing senior time, staffing plan not being maintained. Cure is to free the lead by adding capacity to the adjacent role that is currently absorbing lead time.
7. Programme assuming engineering teams produce remediation throughput without dedicated security engineering or AppSec FTE. Named-owner field is populated but cross-team routing produces aged remediation because no one role owns the remediation conversation end-to-end. Symptom is large per-finding cycle time variance at in-remediation depending on the receiving engineering team. Cure is to add dedicated security engineering or AppSec capacity that owns the remediation conversation with the receiving teams rather than just routing the finding to them.

Each failure mode is recoverable when caught at the per-state cycle time layer. The cost of catching it late (audit committee read, leadership escalation, KEV listing during an aged-queue event) is much higher than the cost of catching it on the operational dashboard. Pairing per-role utilisation with per-state cycle time on the same report is the discipline that surfaces the failure mode at the early stage.

Coordination overhead and the curve break

Coordination overhead is the share of role time spent on routing, handoff, cross-team coordination, and internal team coordination rather than on caseload throughput. It scales differently across role classes and across coordination types. Reading the three coordination components separately lets the programme size the realistic throughput envelope rather than the analyst-only envelope.^3,7,10

• Intra-role coordination. Roughly with the square of team size for tightly coupled roles (AppSec engineers covering each other's engineering team relationships, triage analysts balancing the queue across each other), roughly linearly for loosely coupled roles (governance and compliance analysts running independent records). The break point sits where each FTE absorbs more than 25 to 30 percent of their time on intra-role coordination.
• Inter-role coordination. Roughly linearly with team size at each role and with the number of role classes in the chain. Each additional role in the lifecycle adds a handoff surface; each additional FTE adds a routing decision. The break point sits where each handoff between roles adds more than 5 to 10 percent of cycle time to the per-finding lifecycle.
• Cross-team coordination. Roughly linearly with the number of engineering teams the programme routes to and roughly logarithmically with the team size at each receiving team. Small engineering teams absorb more relative coordination cost per finding than large teams because they have less specialised remediation capacity. The break point sits where AppSec FTE time on cross-team coordination exceeds the time on actual finding closure.

The defensible operational read is to publish the coordination overhead ratio (share of role time spent on coordination versus on caseload work) on the same report as the per-role utilisation. Rising coordination overhead at a stable utilisation rate is the leading indicator of the staffing curve approaching its break, and the leading indicator that the next staffing investment will produce less throughput uplift than the previous one. The security engineering handoff latency research covers the related question of how long the finding waits between the security engineering layer and the receiving engineering team across the lifecycle.²⁷

Outsourced and managed capacity

Outsourcing shifts the staffing curve along three dimensions. Capacity (managed services or contracted analysts add envelope without growing the in-house headcount; the in-house curve break moves outward in proportion to the outsourced capacity). Quality (outsourced analysts work to documented runbooks; the per-FTE envelope holds when the runbooks match the operating model; quality drops when the runbooks lag the operating model or when finding context requires in-house judgement). Coordination tax (outsourced capacity adds a coordination surface between the in-house programme owner and the outsourced layer; the tax scales linearly with the volume of work routed and logarithmically with relationship maturity).^3,7,12

The defensible pattern outsources the high-volume low-context work (front-of-queue triage on well-tuned scanner output, retest verification on standardised closure evidence, governance reconciliation on documented framework crosswalks) and retains the high-context work (vulnerability management lead, AppSec engineer on application-specific decisions, security engineer on architectural fixes, conversion gate decisions, audit interface, leadership reporting).

Outsourcing the high-context work usually produces decay rather than throughput uplift, because the context cost moves to the in-house oversight layer instead of being eliminated. Programmes that outsource without distinguishing high-volume-low-context work from high-context work see initial throughput uplift followed by quality erosion that surfaces at the next audit cycle, the next KEV event, or the next material engagement; the in-house team then absorbs the context recovery work and the throughput uplift reverses. Distinguishing the two work classes at the contracting stage is the discipline that makes outsourced capacity actually expand the curve.

Five numbers for the leadership staffing report

Five numbers communicate staffing health to leadership without requiring operational depth. Reading the five together gives leadership the staffing question, the bottleneck identification, and the curve-break signal on one record.^2,3,4,7

Reporting the five numbers alongside the inflow-and-closure trend gives leadership the staffing question, the bottleneck identification, and the curve-break signal on one record. Programmes that report only the inflow and closure trend argue staffing from anecdote; programmes that report the five numbers argue staffing from data the audit committee can verify against the activity log on the live record.

Framework citations that read the staffing surface

Enterprise frameworks read the staffing surface at three points: the named senior responsible role, the documented role assignments across the programme, and the staffing review tied to the programme review. The framework expectations are below.^{1,2,3,4,8,9,10,12}

• ISO 27001:2022 Annex A 5.2. Information security roles and responsibilities with documented allocation; the staffing plan and the role definitions read against this surface.
• NIST SP 800-53 Revision 5 PM-2. Senior agency information security officer with documented authority; the vulnerability management lead reads against this surface where the lead is the named senior responsible role for the programme.
• NIST CSF 2.0 GV.RR. Roles, responsibilities, and authorities with documented separation of duties; the role definitions and the approver-authority pairing on the conversion gate read against this surface.
• PCI DSS v4.0 Requirement 12.5. Documented security responsibilities for cardholder data environment in-scope roles; the staffing plan reads against this surface where the programme covers cardholder data.
• DORA Article 5. ICT governance and organisational framework with named senior management responsibility; the vulnerability management lead reading into the wider ICT governance structure satisfies this surface for entities in scope.
• CIS Controls v8.1 Safeguard 17.1. Designated personnel for incident handling readiness; the staffing plan for the in-house programme reads against this surface where the safeguard binds incident-handling readiness to documented role assignments.
• OWASP SAMM Operations practices. Documented role allocation across operations practices, including Operational Management, with documented review; the staffing plan reads against this surface where AppSec maturity is being tracked across the operations domain.

The pattern across frameworks is that named roles, documented authority, and periodic staffing review all need to be present. Staffing economics is what prices the staffing plan honestly enough that the periodic review reads against a programme whose role assignments hold up at audit walkthrough and at the next material engagement.

How SecPortal supports the staffing surface

SecPortal keeps the per-finding lifecycle, the named-owner chain, and the activity log on one engagement record so the staffing measurements read against the same data the operating cadence runs against. The point of integration is not that the platform sets the staffing plan (it does not), but that every field the plan needs to verify, every cycle time the report needs to track, and every named-owner reference the audit needs to validate lives on the same record where the finding sits.^{16,17,18,19,20,21,22}

• Findings management holds the named-owner field, the severity record, the status across the lifecycle states, and the eight-field exception decision chain for the conversion-and-renewal surface. The operational view and the audit view read against the same record.
• Team management with RBAC supplies the workspace user catalogue (owner, admin, member, viewer, billing roles) that the named-owner field references. Departed staff surface as inactive references rather than as silent stale data; the role assignments support the separation-of-duties surface the staffing plan reads against.
• Activity log with CSV export captures the timestamped chain of every state transition by user with 30, 90, or 365 day retention depending on plan. The log supplies the per-role cycle time breakdown, the per-role aged-finding share, and the per-handoff latency the leadership staffing report reads.
• Engagement management binds the finding to the originating engagement so per-engagement throughput and per-engagement staffing impact are reproducible against the same record. The lead role can read the staffing impact of each engagement separately and compare across engagement classes.
• Retesting workflows pair the retest record to the original finding so the retest stage cycle time and the retest-FTE utilisation surface read against the same record. The fix-deployed metric and the fix-verified metric stay distinguishable.
• Compliance tracking maps the role-related framework citations (ISO 27001 A.5.2, NIST SP 800-53 PM-2, NIST CSF 2.0 GV.RR, PCI DSS 12.5, DORA Article 5) so the staffing review reads against the same crosswalk the audit interface uses.
• Notifications and alerts route assignment events to the named owner so the assignment-state arrival rate is observable in the lifecycle log and the per-role utilisation reading is verifiable.
• MFA TOTP enforcement on the workspace provides authentication assurance on the named-owner field that the audit citation reads against.
• AI reports can summarise the per-role utilisation, the per-state cycle time, and the per-role aged share for the leadership staffing read.

What the platform does not do is also part of the staffing design. SecPortal does not infer the right staffing level, does not enforce headcount, does not size the team for the programme, does not push to HR systems, does not run automated staffing recommendations, does not validate that the named owner is operationally available, does not connect to payroll, ATS, or workforce management platforms, and does not enforce coordination overhead ceilings. Those decisions and those validations belong to the security organisation operating the staffing plan. The platform keeps the per-finding ownership trail, the lifecycle evidence, and the activity log on one record so the staffing question is reproducible at any moment between cycles.

Read against the rest of the SecPortal research library, staffing economics is the resourcing layer of a wider operational discipline. The state machine throughput decomposition identifies the transition bottleneck; the ingest-versus-capacity research reads the queue-level ratio; this research prices the staffing curve that produces the capacity side; the remediation throughput research covers the cycle-time-and-quality side of closure. Reading the four layers together produces a programme whose staffing plan is sized against measurable inflow and measurable throughput at acceptable quality, and whose audit-committee answer to the staffing question reads against the same record the operational cadence runs against.^23,24,25

Frequently asked questions

Sources and further reading

1. ISO/IEC, ISO 27001:2022 Information Security Management Systems
2. ISO/IEC, ISO 27002:2022 Information Security Controls Annex A 5.2 Roles and Responsibilities
3. NIST, SP 800-53 Revision 5 Security and Privacy Controls (PM-2, PM-9, PM-12)
4. NIST, Cybersecurity Framework (CSF) 2.0 with GV.RR Roles, Responsibilities, and Authorities
5. NIST, SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
6. NIST, SP 800-137 Information Security Continuous Monitoring (ISCM)
7. NIST, SP 800-39 Managing Information Security Risk
8. PCI Security Standards Council, PCI DSS v4.0 Requirement 12.5 Security Responsibilities
9. European Union, Digital Operational Resilience Act (DORA) Article 5 ICT Governance
10. CIS, Critical Security Controls v8.1 (Implementation Groups and Safeguard 17.1 Designated Personnel)
11. CISA, Binding Operational Directive 22-01 Known Exploited Vulnerabilities (KEV) Catalog
12. OWASP, Software Assurance Maturity Model (SAMM) Operations Practices
13. FIRST, Common Vulnerability Scoring System (CVSS) Specification
14. FIRST, Exploit Prediction Scoring System (EPSS)
15. CMU SEI, Stakeholder-Specific Vulnerability Categorization (SSVC)
16. SecPortal, Findings Management
17. SecPortal, Team Management and RBAC
18. SecPortal, Activity Log
19. SecPortal, Engagement Management
20. SecPortal, Retesting Workflows
21. SecPortal, Compliance Tracking
22. SecPortal, AI Reports
23. SecPortal Research, Vulnerability State Machine Throughput Decomposition
24. SecPortal Research, Ingest vs Remediation Capacity
25. SecPortal Research, Vulnerability Remediation Throughput
26. SecPortal Research, Cross-Team Finding Ownership Transfer Latency
27. SecPortal Research, Security Engineering Handoff Latency
28. SecPortal Research, Remediation Economics by Finding Source Archetype