Do we need a separate team to have a VOC?

No. A VOC is a function with a clear mandate, cadence and metrics, not necessarily a new headcount line. Small organizations often run it with one or two people inside the security team; what matters is that someone owns the whole lifecycle and has the authority to hold remediation owners to agreed SLAs.

Should the VOC sit inside the SOC?

It can, and sharing tooling and threat intelligence with the SOC is valuable. The risk is that incident response always wins the fight for attention, so preventive work slips. If the VOC reports into the SOC, protect its capacity and give it its own metrics and governance forum.

Who fixes the vulnerabilities — the VOC or IT?

In almost every model, the asset and application owners fix; the VOC finds, prioritizes, routes, verifies and reports. A VOC that applies patches itself becomes a bottleneck and removes accountability from the teams who own the systems.

How to build a Vulnerability Operations Center (VOC)

Most organizations already "do" vulnerability management: a scanner runs on a schedule, a report lands in someone's inbox, and a spreadsheet of findings is forwarded to IT. What they lack is an operation — a function that owns the full lifecycle, runs on a predictable cadence, makes prioritization decisions with context, and can prove whether risk is going down. That function is what this site calls a Vulnerability Operations Center (VOC).

The term borrows deliberately from the Security Operations Center. A SOC turns a flood of alerts into a small number of incidents that people act on; a VOC turns a flood of findings into a small number of prioritized changes that owners deliver. This guide covers what a VOC is responsible for, how it relates to adjacent teams, how to write its charter, and how to get from "we run a scanner" to a working operation.

What a VOC is — and what it is not

A VOC owns the vulnerability lifecycle end to end: knowing what assets exist, discovering weaknesses on them, deciding which matter most, making sure the right people fix them within an agreed time, verifying the fix, and reporting on the whole system. It is not only a scanning team, which stops at discovery, and it is not the patching team, which executes one kind of fix.

Dimension	Scanning team	SOC	VOC
Primary input	Scan schedules	Alerts and telemetry	Findings, threat intel, asset context
Primary output	Reports	Contained incidents	Remediated, verified risk
Time horizon	Scan cycle	Minutes to days	Days to months
Success measure	Scans completed	Time to detect and respond	Time to remediate, SLA compliance, exposure
Relationship to IT	Hands over a report	Coordinates response	Owns routing, SLAs and escalation

The overlap with the SOC is real and useful. When the SOC sees exploitation of a vulnerability in the wild, the VOC should hear about it within hours; when the VOC finds a Known Exploited Vulnerability on an internet-facing system, the SOC should know to watch it. Many organizations put both under the same leader. The important point is that the VOC has its own mandate and metrics so preventive work is not permanently deprioritized behind incidents.

The lifecycle the VOC owns

Frameworks describe the lifecycle with slightly different words — CIS Controls v8 Control 7 calls it Continuous Vulnerability Management, ISO/IEC 27001:2022 Annex A 8.8 covers management of technical vulnerabilities, and NIST SP 800-40 Rev. 4 frames patching as preventive maintenance — but the loop is the same:

Inventory. Maintain a reconciled list of assets, each with an owner, a criticality tier and an exposure level. See asset inventory for vulnerability management.
Discover. Combine authenticated scans, agents, cloud and container assessment and dependency scanning, with measured coverage. See scanning strategy.
Prioritize. Turn severity, exploitation evidence and asset context into a few priority tiers. See risk-based prioritization.
Remediate. Group findings by fix, route them to owners, and track them against risk-based SLAs.
Verify. Close findings only on evidence — a rescan or fresh agent data — and manage exceptions explicitly.
Report. Measure flow and exposure, and tell leadership whether risk is shrinking. See metrics.

A useful test of maturity is to pick one random finding and follow it through all six steps. Where the trail goes cold is where the VOC should invest next.

Writing the charter

A charter prevents the two most common failure modes: a VOC with responsibility but no authority, and a VOC that quietly absorbs work that belongs to other teams. Keep it short enough that executives will actually read and sign it. The example below is a template, not a prescription.

voc_charter:
  mission: >
    Reduce the likelihood and impact of exploitation of known vulnerabilities
    across the organization's technology estate, and report on that risk
    accurately to leadership.
  scope:
    in: [servers, endpoints, network devices, cloud accounts, containers,
         internally developed applications, third-party software, SaaS configuration]
    out: [penetration testing, incident response, secure code review]  # owned by other teams
  authority:
    - Define and publish the vulnerability prioritization and SLA policy
    - Require asset owners to remediate or request an exception within SLA
    - Escalate SLA breaches to the owning executive
    - Approve low-risk exceptions; recommend on higher-risk ones
  responsibilities_of_asset_owners:
    - Keep ownership and criticality data in the inventory accurate
    - Remediate findings within SLA or request a time-boxed exception
  governance:
    sponsor: CISO
    forum: Monthly vulnerability risk review (IT, engineering, risk)
    policy_review: Annually, or after a major incident
  success_measures: [time to remediate by tier, SLA compliance,
                     authenticated scan coverage, KEV exposure window]

The authority section is the heart of it. Without the explicit right to require remediation and to escalate breaches, the VOC can only publish reports and hope.

Operating cadence

A VOC is defined as much by its rhythm as by its tools. A cadence that works for many organizations looks like this:

Cadence	Activity	Participants
Daily	Triage new findings and newly exploited CVEs (KEV additions, vendor advisories); raise P1 emergencies	VOC analysts
Weekly	Remediation review of P1/P2 items and upcoming SLA breaches, per owning team	VOC + team leads
Monthly	Risk review: trends, exceptions due for renewal, escalations, coverage gaps	VOC lead, IT and engineering leadership, risk
Quarterly	Report to executives or the board; review policy, thresholds and tooling	CISO, executives

The daily step is the one teams most often skip. Exploitation of a newly disclosed vulnerability can begin within days of publication, so waiting for the next weekly scan report leaves a gap. The daily triage does not need to be long; it needs to be consistent.

Maturity stages

It helps to describe where you are and where you are going in plain terms rather than abstract levels. A pragmatic progression:

Stage 1 — Reactive. Periodic unauthenticated scans, reports emailed to IT, no SLAs, patching driven by vendor release cycles.
Stage 2 — Managed. Authenticated scanning of most servers and endpoints, a severity-based SLA, findings tracked in tickets, basic metrics.
Stage 3 — Risk-based. Reconciled inventory with ownership and criticality, prioritization using KEV and EPSS, fix-based grouping, exceptions with expiry, time-to-remediate reported by tier.
Stage 4 — Integrated. Cloud, containers and application dependencies in the same pipeline; automated routing; verification by rescan; metrics tied to business services; the VOC informs architecture and procurement decisions.

Do not try to jump stages. A risk-based model on top of an inventory nobody trusts produces confident-looking numbers that are wrong.

How to start: the first 90 days

Days 1–30: establish the baseline. Write and get sign-off on the charter. Inventory what scanning exists, what it covers, and who receives the output. Pull every open finding into one place, even a database or spreadsheet, and join it with the CISA KEV catalog. The list of KEV-listed findings on internet-facing systems is your first work queue.

Days 31–60: build the loop. Agree priority tiers and SLAs with IT and engineering. Fix the worst ownership gaps in the inventory — findings without an owner cannot be routed. Start the weekly remediation review. Switch the most important unauthenticated scans to authenticated ones.

Days 61–90: measure and report. Automate the KEV and EPSS enrichment. Start measuring time to remediate by tier and SLA compliance. Hold the first monthly risk review and produce a one-page summary for leadership, as described in reporting vulnerability risk to leadership.

Common pitfalls

Measuring findings instead of outcomes. Better coverage produces more findings; a program judged on raw counts will be punished for improving.
Owning remediation directly. A VOC that patches systems itself becomes a bottleneck and dilutes accountability.
No exception process. Without a legitimate way to defer a fix, teams simply ignore SLAs and the data loses meaning.
Tool-first design. Buying an aggregation platform before agreeing tiers, SLAs and ownership just automates confusion. Define the operating model first; the tooling landscape guide covers the rest.

The next guide in this area, VOC roles and responsibilities, turns the charter into a RACI that every team can agree to.