VOC roles and responsibilities: a practical RACI
Who does what in a Vulnerability Operations Center: core roles, a full RACI across the lifecycle, and how the VOC works with the SOC, IT and developers.
A Vulnerability Operations Center succeeds or fails on clarity of ownership. The technology is rarely the bottleneck; the bottleneck is the moment when a finding lands and nobody is sure who must act, who decides whether it can wait, and who will be told if it does not happen. This guide describes the roles involved in running a VOC, gives a complete RACI across the lifecycle, and explains the interfaces with other teams that most often cause friction.
The roles below are roles, not job titles. In a small organization one person may hold three of them; in a large one each may be a team. What matters is that every activity has exactly one accountable role.
Core VOC roles
VOC lead. Owns the program: policy, tiers and SLAs, metrics, escalations, and the relationship with leadership. Chairs the monthly risk review and presents the quarterly report. Has the authority, granted by the charter, to require remediation and escalate breaches.
Vulnerability analyst. Runs daily triage: reviews new findings and newly exploited CVEs, validates questionable results, applies prioritization, and routes work. Analysts are the people who know whether a scanner result is real, what the vendor advisory actually says, and whether a mitigation is adequate. They also verify closures and handle the first review of exception requests.
Platform (scanner) engineer. Owns the discovery and data pipeline: scanner and agent deployment, credentials for authenticated scanning, cloud and container integrations, KEV/EPSS enrichment, the connection to the ticketing system, and data quality. In small teams this is often an analyst with an engineering bent; in larger ones it is a dedicated role, because the pipeline becomes a product in its own right.
Threat intelligence liaison. Not always a separate person, but someone must feed the VOC with exploitation evidence that goes beyond public catalogs: vendor advisories, intelligence reports, and what the SOC is seeing.
Roles outside the VOC
Asset owner / service owner. Accountable for a system or application, including its vulnerabilities. They decide how to remediate within the SLA and request exceptions when they cannot.
Remediation engineer. The system administrator, platform engineer or developer who actually applies the patch, changes the configuration or upgrades the dependency.
Risk owner. The business leader who accepts residual risk when a vulnerability cannot be fixed. This is typically the executive who owns the business process, not the IT manager who runs the server.
CISO. Sponsors the VOC, arbitrates disputes between security and delivery teams, and approves high-risk exceptions or escalates them further.
Change manager / CAB. Controls when changes can be deployed. The VOC needs an agreed fast path for emergency (P1) changes.
GRC / compliance. Maps VOC evidence to regulatory and audit requirements, such as PCI DSS vulnerability scanning obligations or ISO/IEC 27001 Annex A 8.8, and consumes the exception register.
SOC / incident response. Consumes VOC data during investigations and feeds exploitation signals back.
The RACI
R = Responsible (does the work), A = Accountable (one per row, owns the outcome), C = Consulted, I = Informed.
| Activity | VOC lead | Analyst | Platform eng. | Asset owner | Remediation eng. | Risk owner | CISO | SOC |
|---|---|---|---|---|---|---|---|---|
| Define prioritization and SLA policy | A/R | C | C | C | I | C | I | C |
| Maintain asset ownership and criticality | C | I | R | A | I | C | – | – |
| Operate scanners, agents and integrations | I | C | A/R | C | – | – | – | – |
| Measure and close coverage gaps | A | C | R | R | – | – | I | – |
| Daily triage and prioritization | A | R | C | – | – | – | – | C |
| Route findings and create tickets | A | R | R | I | I | – | – | – |
| Remediate within SLA | I | C | – | A | R | – | – | – |
| Emergency (P1) response to exploited CVEs | A | R | C | R | R | I | I | C |
| Verify remediation (rescan/evidence) | A | R | R | I | I | – | – | – |
| Request an exception | C | C | – | A/R | C | C | – | – |
| Approve an exception (low risk) | A | R | – | C | – | I | – | – |
| Approve an exception (high risk) | C | C | – | C | – | A | R | – |
| Escalate SLA breaches | A/R | R | – | I | I | I | C | – |
| Monthly risk review | A/R | R | C | C | – | C | I | I |
| Executive / board reporting | R | C | C | – | – | I | A | – |
A few rows deserve comment. Remediate within SLA is accountable to the asset owner, not to the VOC: the VOC cannot patch its way to success, and making it accountable would remove the incentive for owners to act. High-risk exceptions are accountable to the risk owner, because accepting risk is a business decision. And asset ownership data is accountable to the owners themselves — the platform engineer only maintains the tooling that collects it.
Interfaces that cause friction
VOC and IT operations
The most common complaint from operations teams is noise: tickets for every CVE on every host, duplicates, and findings that were already fixed. The remedy is to route fixes, not findings — one ticket per patch, upgrade or configuration change per owning team — as described in remediation workflow and ticketing. Agree maintenance windows and the emergency change path in advance, not during a crisis.
VOC and development teams
Developers experience vulnerability management mainly through dependency and container findings. Integrate results into the tools they already use (pull requests, CI pipelines, their issue tracker) rather than sending spreadsheets. Respect their prioritization vocabulary, and give them the context they need: is the vulnerable function actually reachable, is there a fixed version, does a VEX statement from the supplier say the product is not affected?
VOC and the SOC
Establish two feeds. From VOC to SOC: a list of exposed, unremediated high-priority vulnerabilities so detection engineers can add monitoring. From SOC to VOC: indicators of exploitation attempts against specific CVEs, which should immediately raise those findings to the top tier. A short weekly sync is usually enough.
VOC and change management
Emergency remediation of an actively exploited vulnerability must not wait for the next change advisory board. Pre-agree a standard or emergency change type for P1 fixes with a lightweight approval, and record it in the SLA policy.
Staffing without invented ratios
You will find numbers online claiming a VOC needs one analyst per so many thousand assets. Treat them with suspicion: workload depends on factors that vary enormously between organizations. Estimate from the work instead:
- Triage load: new findings and newly exploited CVEs per day that need human review after automation.
- Owner count: how many distinct teams you meet weekly; each needs preparation and follow-up.
- Exception volume: how many requests per month, and how much analysis each needs.
- Pipeline complexity: number of scanners, cloud accounts, registries and integrations to keep healthy.
- Reporting: time spent assembling metrics, which shrinks sharply once it is automated.
Track where analysts actually spend their time for a month. That data will justify headcount far better than any external ratio, and it will show which automation to build first.
Checklist
- Every activity in the lifecycle has exactly one accountable role.
- Every asset in scope has a named owner, and unowned assets are tracked as findings.
- Risk acceptance is signed by the business, not by the VOC.
- There is a pre-agreed emergency change path for P1 fixes.
- The VOC and SOC exchange exploitation and exposure data at least weekly.
- The RACI is published where owning teams can find it, and reviewed annually alongside the SLA policy.