A Vulnerability Operations Center (VOC) is the function that turns vulnerability findings into verified risk reduction. It combines an operating model, a team and usually a platform. It aggregates findings from scanners and other security tools, adds asset, business and threat context, prioritizes what is exploitable and important, routes each fix to an accountable owner and measures whether exposure actually went down.

A VOC sits between detection and verified remediation. It does not replace scanners, the Security Operations Center (SOC) or IT's ticketing tools; it connects them, so that the vulnerabilities that matter are fixed first, by the right people, with proof.

The model matters now because the arithmetic of vulnerability management has changed:

• Volumes keep climbing. The CVE (Common Vulnerabilities and Exposures) Program published 40,077 CVE records in 2024 and 48,244 in 2025 (CVE Program metrics). By September 18, 2026, over 67,000 new CVEs had already been published that year, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned that rising volumes strain triage and remediation workflows (CISA, September 2026).
• AI is accelerating discovery. In May 2026, Anthropic reported that about 50 Project Glasswing partners had found more than 10,000 high- or critical-severity vulnerabilities with its Claude Mythos Preview model. It added that the limiting factor had become how quickly those vulnerabilities could be verified, disclosed and patched (Anthropic).
• Exploitation is the leading way in. Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities is now the most common initial access vector for breaches (31%). In the organizations whose vulnerability data it analyzed, only 26% of vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) catalog were fully remediated in 2025, with a median of 43 days to full resolution (Verizon DBIR 2026).
• Only a small share is ever exploited, and it is hard to spot. Google Threat Intelligence Group found that only 0.23% of vulnerabilities disclosed in 2026 had been observed exploited so far (GTIG, September 2026). Spotting them in the output of many tools, across on-premises, cloud and application environments, is the real work.
• Government policy has shifted to risk-based deadlines. In June 2026, CISA's Binding Operational Directive (BOD) 26-04 superseded BOD 22-01 and BOD 19-02 for U.S. federal civilian executive branch agencies (CISA). It sets maximum remediation timelines of 3, 14 or 60 days, or a fix at the next system upgrade, depending on public exposure, KEV status, exploit automation and technical impact.

Detection keeps scaling; remediation capacity does not. A VOC helps organizations narrow that gap by focusing limited remediation capacity on the exposures that matter.

What Is a Vulnerability Operations Center?

Short answer: A Vulnerability Operations Center (VOC) is the function that runs vulnerability remediation as a continuous operation. It combines an operating model, a team and usually a platform. Together they aggregate findings from scanners and other security tools, prioritize them by real risk, assign each fix to an accountable owner, track it against deadlines and verify that exposure actually went down.

A VOC is to vulnerability remediation what a Security Operations Center (SOC) is to threat detection and response: a standing function with defined processes, roles, tools and metrics. Its work starts when a scanner, a cloud security tool, a code analyzer or a penetration test reports a weakness. It ends only when the fix has been verified, or when the residual risk has been formally accepted by someone with the authority to accept it.

Vulnerability Operations (sometimes called VulnOps) is the practice a VOC runs: the continuous, cross-team execution of vulnerability management that turns findings into prioritized, assigned, tracked and verified remediation work.

Is a VOC a platform, a team, or an operating model?

A VOC is all three, and the order matters:

1. An operating model. The rules that define what gets fixed first, by whom, by when, and what happens when a deadline is missed or a risk is accepted.
2. A team. The people who run that model every day, typically a VOC lead and analysts within the security organization, working with remediation owners in IT, cloud, infrastructure and engineering.
3. A platform. The technology layer that collects and normalizes data from existing tools, applies the prioritization logic and orchestrates remediation workflows.

A platform without an operating model only produces a better-looking backlog. An operating model without a platform rarely scales once findings from several tools run into the thousands. Some organizations run their VOC in-house; others rely on a managed service from an MSSP. In smaller organizations, the “center” may be one or two people supported by automation.

Objectives and scope

A VOC typically pursues four objectives:

• Reduce exploitable exposure, not just the number of open findings.
• Shorten the time between detection and remediation for the vulnerabilities that matter most.
• Ensure that every priority finding has an accountable owner and a deadline.
• Keep reliable evidence of what was fixed, deferred or accepted, and why.

Its scope should cover every asset type through which the organization is exposed: servers, endpoints, network devices, cloud workloads and configurations, containers, applications and code dependencies, operational technology (OT), identity infrastructure such as Active Directory, and internet-facing assets. Findings are not limited to CVEs. Misconfigurations, exposed secrets, weak protocols and penetration-test findings belong in the same queue.

Who works in a VOC?

A VOC combines a small core team inside security with remediation owners across IT and engineering:

• VOC lead or Head of Vulnerability Management: owns the operating model, service-level agreements (SLAs), escalation rules and reporting.
• Vulnerability analysts: triage, validate, enrich and prioritize findings, and manage exceptions.
• Security engineers or platform administrators: maintain integrations, data quality and automation rules.
• Remediation owners (outside the VOC): IT operations, infrastructure, cloud and platform, application and DevOps teams that apply fixes.
• Stakeholders: the CISO (risk appetite, executive reporting), the SOC and threat intelligence team (exploitation signals), governance, risk and compliance (GRC) and audit teams (evidence), and business owners (asset criticality, risk acceptance).

Most remediation work is done outside the VOC. Its value lies in coordinating other teams, which is why governance and workflows matter more than headcount. For a practitioner's view of this coordination work, see a day in the life of a VOC.

Which tools does a VOC connect to?

A VOC sits on top of tools the organization already owns, from vulnerability scanners and application security testing to configuration management databases (CMDBs), threat intelligence and IT service management (ITSM) platforms. The data sources section details what each contributes.

What a VOC is not

A VOC is often confused with the tools it connects to. The table shows how each one differs.

What Does a VOC Do? The Vulnerability Operations Cycle in 10 Steps

A VOC runs a closed loop that takes raw findings from many tools and turns them into verified fixes. The ten steps below describe that loop; in practice, several run in parallel and continuously.

The cycle runs continuously, and several steps often run in parallel.

1. Aggregate vulnerability and asset data

The VOC collects findings and asset records from every detection tool and inventory into a single repository, through APIs or scheduled imports.

• Problem solved: findings scattered across consoles, spreadsheets and PDF reports, with no single view of exposure.
• Data used: scanner, cloud, AppSec, endpoint, attack surface and penetration-test findings; CMDB and cloud inventories.
• Expected result: one consolidated inventory of assets and findings, with the history of each source.
• Teams involved: VOC analysts, platform administrators, owners of the source tools.
• Possible metrics: number of connected sources, share of assets covered by at least one scanner, data freshness.

2. Normalize and deduplicate findings

Each tool uses its own severity scale, product names and asset identifiers, so the same vulnerability on the same server often appears several times.

• Problem solved: inflated backlogs, duplicate tickets and conflicting severities.
• Data used: CVE and CWE identifiers, CPE product names, asset identifiers such as hostname, FQDN, IP address, MAC address, cloud instance ID or agent ID.
• Expected result: one record per vulnerability per asset, with every reporting source preserved.
• Teams involved: VOC analysts, platform administrators.
• Possible metrics: share of duplicates removed, share of findings matched to a known asset.

3. Enrich findings with asset, business and threat context

A finding without context cannot be ranked meaningfully. A Common Vulnerability Scoring System (CVSS) base score does not know whether a server is internet-facing, supports payments or sits in a test lab.

• Problem solved: prioritization that ignores business impact and the threat landscape.
• Data used: asset criticality, business service, data sensitivity, environment, ownership; threat intelligence such as known exploitation, exploit code availability and exploitation probability.
• Expected result: each finding carries business and threat context.
• Teams involved: VOC analysts, asset and service owners, IT asset management, threat intelligence.
• Possible metrics: share of assets with a criticality rating, enrichment delay after a new threat signal.

4. Assess exploitability and exposure

The VOC asks whether a vulnerability can realistically be exploited in this environment, not just in theory.

• Problem solved: time spent on vulnerabilities that are unreachable or already mitigated, while exploitable ones wait.
• Data used: internet exposure, network reachability, compensating controls (segmentation, WAF, EDR), exploit maturity, validation results from penetration tests or automated checks.
• Expected result: an evidence-based view of which exposures an attacker could actually use.
• Teams involved: VOC analysts, security engineering, penetration testers or red team, SOC and threat intelligence.
• Possible metrics: number of exploitable internet-facing exposures, share of top-priority findings validated.

5. Prioritize remediation actions

The VOC ranks remediation actions, not just findings: a single patch can close hundreds of findings at once.

• Problem solved: more findings than remediation capacity, with no explicit order.
• Data used: combined severity, threat, exposure and business-impact signals; policy rules; regulatory deadlines.
• Expected result: a ranked list of actions, each with a priority tier and a due date.
• Teams involved: VOC lead and analysts; the CISO sets the risk appetite.
• Possible metrics: time to prioritize, distribution of findings by priority tier.

6. Assign ownership

Every action needs a named team or person accountable for it.

• Problem solved: findings stalled because nobody knows who owns the asset or the application.
• Data used: CMDB ownership fields, cloud tags, application-to-team mappings, routing rules.
• Expected result: each remediation action assigned to an accountable owner.
• Teams involved: VOC, IT asset management, service and application owners.
• Possible metrics: percentage of findings with an owner, time to assign, reassignment rate.

7. Orchestrate remediation workflows

The VOC delivers work into the tools remediation teams already use, rather than sending spreadsheets.

• Problem solved: manual ticket creation, missing context and no feedback on progress.
• Data used: priority, owner, remediation guidance such as vendor advisories and patch details, workflow rules.
• Expected result: tickets or backlog items created automatically, grouped into remediation campaigns, with status synchronized in both directions.
• Teams involved: VOC, IT operations, cloud, infrastructure and engineering teams, change management.
• Possible metrics: automation rate, share of actions handled as campaigns.

8. Track SLAs and remediation progress

Deadlines only work if breaches are visible and escalated.

• Problem solved: silently missed deadlines and undocumented exceptions.
• Data used: SLA policy by priority tier, ticket status, exception and risk-acceptance records.
• Expected result: SLA dashboards, automatic escalations and a register of exceptions with expiry dates.
• Teams involved: VOC, remediation managers, the CISO.
• Possible metrics: SLA compliance, overdue critical exposures, backlog aging.

9. Validate closure

A closed ticket is not proof of a fix. Patches fail, roll back or apply only partially.

• Problem solved: vulnerabilities reported as fixed that are still present.
• Data used: rescans, agent data, retests and configuration checks after remediation.
• Expected result: findings marked as verified fixed, or reopened.
• Teams involved: VOC analysts, scanner owners, remediation owners.
• Possible metrics: verified closure rate, reopen rate.

10. Measure risk reduction and report outcomes

The VOC shows whether exposure is going down and feeds lessons back into the process.

• Problem solved: reporting based on activity (scans run, tickets closed) rather than outcomes.
• Data used: finding history, priority tiers, SLA status, verification status, risk scores over time.
• Expected result: executive, operational and audit reports; root-cause actions for recurring weaknesses, such as fixing a base image instead of patching every instance.
• Teams involved: VOC lead, CISO, GRC and audit, executive leadership.
• Possible metrics: risk trend, exposure window, mean time to remediate by priority tier, recurring vulnerabilities.

The loop is continuous: what step 10 reveals refines the scoring rules, ownership data and SLAs used in steps 3 to 8.

VOC vs. SOC: What Is the Difference?

A Security Operations Center (SOC) detects and responds to attacks that are under way. A Vulnerability Operations Center (VOC) reduces the weaknesses attackers could exploit before an incident happens. The two functions use different data, work at different speeds and are measured differently, but each makes the other more effective.

One naming trap: “MTTR” means mean time to respond in a SOC and mean time to remediate in a VOC. Dashboards that mix both should spell the metric out.

How the SOC and the VOC work together

The SOC and the VOC are complementary, and the hand-offs between them are where much of the value lies:

• From the SOC to the VOC: exploitation attempts observed in telemetry, incident root causes (for example, an unpatched edge device used as the entry point) and threat intelligence on actively exploited CVEs. Each of these should raise remediation priority immediately.
• From the VOC to the SOC: the list of critical exposures that cannot be fixed right away, so the SOC can tighten monitoring, and the compensating controls applied in the meantime. For the most severe exposures, the VOC can ask the SOC to check for signs of prior compromise, because patching a system that has already been breached does not evict the attacker.
• Shared foundations: asset inventory, threat intelligence and post-incident reviews.

Some organizations place both functions under a single security operations leader; others keep them separate. What matters is shared data and explicit hand-offs, not the org chart. For a deeper discussion, see why vulnerability management needs its own operating model.

VOC vs. Vulnerability Management: How Do VM, RBVM, Exposure Management, and CTEM Relate?

Vulnerability management (VM) is the discipline; a VOC is the function that runs it continuously, with the emphasis on execution. Risk-based vulnerability management (RBVM) describes how priorities are set. Exposure management and continuous threat exposure management (CTEM) widen the scope beyond software flaws and frame the effort as a continuous program. A VOC is where these ideas are put to work every day.

Gartner describes CTEM as a “pragmatic and systemic approach” to evaluating the accessibility, exposure and exploitability of an enterprise's assets (Gartner, October 2023). It also defines exposure assessment platforms as tools that continuously identify and prioritize exposures and help direct mobilization toward the teams that remediate (Gartner). Analysts make the same point: as Forrester's Erik Nost put it in September 2026, “a prioritized vulnerability that nobody fixes is still a vulnerability” (Forrester). A VOC is the organizational answer to that gap. For a short primer on the framework, see CTEM explained in five minutes.

Vendors also use adjacent labels for overlapping ideas, such as unified vulnerability management, risk operations centers (ROC) and remediation operations (RemOps). The names differ; the shared goal is to turn exposure data into fixes.

Detection-centric vs. remediation-centric programs

The difference lies less in the tools than in what counts as success:

Detection-centric programs are not wrong; they are incomplete. Detection remains the foundation, but at today's volumes the limiting factor is the capacity to decide, coordinate and verify.

Why Do Organizations Need a VOC?

Organizations need a VOC when the bottleneck in vulnerability management is no longer finding vulnerabilities but fixing the right ones quickly and proving it. Each benefit below answers a specific operational problem.

1. Less vulnerability noise. Overlapping scanners report the same weakness several times, which inflates backlogs and tickets. Cross-tool deduplication leaves one record per vulnerability per asset.
2. Better prioritization. Sorting by CVSS puts a large share of findings in the “critical” band. Combining severity with exploitation evidence, exposure and business criticality produces a short list that reflects real risk.
3. Faster remediation of what matters. Urgent fixes otherwise wait in the same queue as routine ones. Priority tiers with deadlines move the most dangerous exposures first, and grouping findings that share a fix reduces the work.
4. Clear ownership. Findings stall when nobody knows who owns the asset. A VOC maps assets to accountable teams using CMDB data, cloud tags and routing rules.
5. Better coordination between Security and IT. Spreadsheets of unprioritized findings create friction. Tickets delivered in IT's own tools, with context and a deadline, are far easier to act on.
6. More consistent SLA management. Deadlines often exist on paper while breaches stay invisible. Continuous tracking, escalation and documented exceptions make SLA compliance measurable.
7. Improved visibility into exposure. Few organizations have one view across on-premises, cloud, applications and internet-facing assets. A unified inventory shows where exposure concentrates and which assets no tool covers.
8. Better executive reporting. Boards receive finding counts that say little about risk. A VOC reports risk trends, critical exposure windows and SLA performance by business unit.
9. More reliable audit evidence. Auditors and regulators ask how technical vulnerabilities are handled. ISO/IEC 27001:2022 includes a control dedicated to their management (8.8), and the EU NIS2 Directive lists vulnerability handling among required cybersecurity risk-management measures (Article 21). A VOC keeps a traceable record of decisions, owners, deadlines, exceptions and verified fixes.
10. Measurable reduction of cyber risk. Activity metrics such as scans run or tickets closed do not show whether exposure fell. Verified closure and risk-trend metrics do.

A VOC does not eliminate every vulnerability, and it cannot guarantee that a breach will never occur. What it improves is the speed, accuracy and accountability of remediation decisions, which is what many programs lack.

What do regulations and standards expect?

No regulation requires a “VOC” by name, but many require what a VOC delivers: documented, prioritized, tracked and verified handling of vulnerabilities.

What Are the Core Capabilities of a VOC?

A VOC needs capabilities in four areas: data (collect and clean), decision (prioritize and explain), execution (assign, orchestrate, verify) and governance (measure, control, prove). Not all of them are needed on day one. The table separates what is essential, what becomes necessary at scale, and what depends on the organization's maturity or constraints.

Three further capabilities usually come later in a VOC's maturity: exploitability validation (testing whether a vulnerability can actually be exploited in the environment), attack-path analysis, and AI assistance. A practical rule applies to all of them: automation amplifies whatever data quality you have. Automate routing and ticketing once asset identity, ownership and prioritization rules are reliable, not before.

What Data Sources Feed a VOC?

A VOC ingests findings from vulnerability scanners, cloud and application security tools, endpoint agents, attack surface management, penetration tests and bug bounty programs, plus context from asset inventories, threat intelligence and ITSM platforms. It does not need a scanner of its own: it relies on the scanners and security tools already in place, then adds the context, prioritization and orchestration they lack on their own.

More mature programs also ingest software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange) statements, which tell the VOC whether a vulnerable component is actually affected in a given product.

Three data properties determine whether a VOC can be trusted: identity (stable identifiers to recognize the same asset across tools), ownership (who is accountable for fixing it) and freshness (how recent the evidence is). A finding from a scan that is three months old is a hypothesis, not a fact. Most identity and ownership problems start in the asset inventory.

How Does a VOC Prioritize Vulnerabilities?

A VOC prioritizes by combining independent signals (technical severity, evidence and likelihood of exploitation, exposure and business impact) into an explainable priority tier with a deadline, rather than sorting findings by CVSS base score. The aim is to find the small share of vulnerabilities that create real risk and fix those first.

Why CVSS alone is not enough

CVSS measures severity, not risk. FIRST (the Forum of Incident Response and Security Teams), which maintains the standard, states that base scores “are not risk, and should not be used alone for patch prioritization” (FIRST CVSS v4.0 FAQ), and asks consumers to enrich base metrics with threat and environmental values (CVSS v4.0 specification). Three limits matter in practice:

• A base score does not change when a vulnerability starts being exploited in the wild.
• It ignores context: an internet-facing payment server and an isolated test machine get the same score.
• Severity bands are coarse: many vulnerabilities share the same “critical” label, which gives teams little basis to sequence their work.

CISA has acted on this: its BOD 26-04 implementation guidance no longer requires federal civilian executive branch agencies to use CVSS for vulnerability prioritization (CISA). For a deeper discussion, see why CVSS is necessary but not sufficient.

A simple example shows the difference. Finding A scores CVSS 9.8 on an isolated lab server holding no sensitive data, with no known exploitation. Finding B scores CVSS 7.5 on an internet-facing VPN appliance and is listed in the CISA KEV catalog. A CVSS-sorted queue puts A first; a risk-based VOC fixes B within days and schedules A.

The dimensions of risk-based, context-aware prioritization

A risk-based, context-aware model combines these dimensions into a priority tier and a due date. The combination can take the form of a decision tree or a score, but it must stay readable: the people asked to fix must understand why.

Public frameworks a VOC can build on

• CVSS v4.0 (Common Vulnerability Scoring System, FIRST, November 2023): severity, which can be enriched with threat and environmental metrics.
• EPSS (Exploit Prediction Scoring System, FIRST): the probability of exploitation in the wild in the next 30 days. FIRST has published EPSS v5 scores since June 15, 2026 (FIRST). It describes EPSS as “not a complete risk score” and recommends layering it with asset context.
• CISA KEV catalog: vulnerabilities with reliable evidence of active exploitation and a clear remediation action, 1,739 entries as of October 8, 2026. CISA recommends using it as an input to a prioritization framework (CISA).
• SSVC (Stakeholder-Specific Vulnerability Categorization): a decision tree created by Carnegie Mellon University's Software Engineering Institute in collaboration with CISA, which published its own guide in November 2022. It uses exploitation status, automatability, technical impact and mission and well-being impact, and leads to four outcomes: Track, Track*, Attend and Act (CISA). See also why SSVC is the missing piece.
• BOD 26-04 (CISA, June 2026): for U.S. federal civilian executive branch agencies, four variables (public exposure, KEV status, exploit automation and technical impact) set maximum remediation timelines of 3, 14 or 60 days, or a fix at the next system upgrade (CISA). Forensic triage is also required in some cases where a known-exploited vulnerability gives an attacker total control of the asset. In an initial analysis at one large civilian agency, CISA found that only 1% of vulnerability instances fell into the three-day category, while over 60% could be deferred to the next system upgrade (CISA). Read more on what BOD 26-04 means for vulnerability operations.

These frameworks are complementary: CVSS describes severity, EPSS estimates likelihood, KEV confirms exploitation for the vulnerabilities it lists (absence from KEV is not proof of safety), and SSVC or BOD 26-04 turn those signals into decisions and deadlines. Even outside the U.S. federal government, BOD 26-04 is a useful public reference for tiered SLAs.

What makes prioritization trustworthy

• Explainable: each priority shows the factors that produced it.
• Transparent: weights, rules and data sources are documented, not hidden in a black box.
• Auditable: score changes, overrides and exceptions are logged with who, when and why.
• Adaptable: the organization can encode its own risk appetite, asset context and regulatory deadlines.
• Understandable by Security and IT: every priority comes with a plain-language reason that the team asked to fix can accept or challenge.

NIST's Cybersecurity Framework 2.0 describes the target outcome: threats, vulnerabilities, likelihoods and impacts are used to understand inherent risk and inform risk response prioritization (ID.RA-05) (NIST CSF 2.0).

How Does AI Fit into a VOC?

AI affects a VOC in two ways: it raises the volume and speed of vulnerability discovery the VOC must absorb, and it can take over much of the repetitive work inside the VOC. The second only helps if decisions that change the organization's risk posture stay explainable and under human control.

Why AI raises the stakes

AI-assisted discovery is moving from research into production. Google's Big Sleep agent found an exploitable memory-safety flaw in SQLite in 2024; Google said it believed this was the first public example of its kind (Google Project Zero). In the final round of DARPA's AI Cyber Challenge (AIxCC) in August 2025, competitors' systems found 54 synthetic vulnerabilities and 18 real ones (DARPA). In May 2026, Microsoft said it expected patch releases to keep trending larger for some time and advised customers to triage “by exposure and impact, not raw count” (Microsoft MSRC).

Attackers use the same technology. In May 2026, Google Threat Intelligence Group reported the first threat actor it had seen using a zero-day exploit that it believed was developed with AI (GTIG). CISA's BOD 26-04 also warns that attackers' use of AI may further narrow the time defenders have between a patch release and exploitation (CISA).

More findings do not mean proportionally more risk. In June 2026, FIRST projected about 66,000 CVEs for the year, a total already passed by mid-September, and told organizations to “plan for a doubled patching workload.” FIRST also found that the burden of exploitable or high-risk vulnerabilities (CISA KEV entries or EPSS scores above 10%) had not materially increased (FIRST). Finding that small subset quickly is exactly the VOC's job. For a vendor perspective, see Hackuity's analysis of AI-driven vulnerability discovery.

Practical AI use cases in a VOC

AI assistance, AI automation, and autonomous decision-making

• AI assistance: the AI suggests, summarizes or drafts, and a person decides. This is the lowest-risk level and the easiest place to start.
• AI automation: the AI executes predefined, reversible tasks within guardrails that people set, such as enriching, deduplicating, or drafting and routing tickets by rule. Every action is logged and can be overridden.
• Autonomous decision-making: the AI decides and acts on its own, for example accepting a risk, changing priority policy or patching production systems. It should be limited to narrow, low-impact, reversible actions, if allowed at all.

The rule of thumb: use AI where it removes repetitive work, and keep any decision that changes the organization's risk posture explainable, controllable and owned by a person.

Governance rules for AI in vulnerability operations

1. Least privilege for AI agents. Grant only the data and actions each task requires. The OWASP Top 10 for LLM Applications 2025 lists “Excessive Agency” (excessive functionality, permissions or autonomy) as a top risk (OWASP LLM06:2025).
2. Treat external content as untrusted. Penetration-test reports, scanner output, tickets and advisories can carry indirect prompt injection (LLM01:2025 in the same list).
3. Require human approval for consequential actions: risk acceptance, changes to prioritization policy, production changes and active exploit validation.
4. Keep a full trail of inputs, outputs and approvals, so every AI-assisted decision can be audited.
5. Demand explainability: every recommendation should cite the data it relies on.
6. Define data boundaries: which data may be sent to which model, under which contractual and residency terms.
7. Use an established framework. The NIST AI Risk Management Framework organizes this work into four functions (govern, map, measure and manage) and calls for defined roles for human oversight of AI systems (NIST AI RMF). Article 14 of the EU AI Act, which requires human oversight of high-risk AI systems, is a useful design benchmark even where it does not legally apply.

How Do You Build a Vulnerability Operations Center?

Build the operating model before choosing tools: agree on who decides, who fixes and by when, then connect data, prioritization and workflows to that model and improve it from measured results. It helps to phase the work: start with one business unit or technology domain, then expand. Hackuity's guide A CISO Guide to Building a Vulnerability Operations Center covers the organizational side in more depth.

1. Define the operating model

• Objective: set the VOC's mission, scope, decision rights and position in the organization, for example under the CISO alongside the SOC.
• Common mistakes: starting with a tool selection; copying SOC processes unchanged; leaving risk-acceptance authority undefined.
• Deliverable: a VOC charter covering mission, scope, a responsibility matrix (RACI), decision rights and risk-acceptance policy.
• Success indicators: charter approved by the CISO and IT leadership; remediation owners named for each scope.

2. Identify stakeholders and owners

• Objective: map who owns assets, applications and remediation in each business unit or scope.
• Common mistakes: assuming the CMDB is accurate; involving IT only once tickets arrive.
• Deliverable: an ownership map and escalation chain per business unit and technology.
• Success indicators: share of assets with a named owner; written agreement from IT, cloud and engineering leads.

3. Inventory data sources and assets

• Objective: list every detection tool, inventory and report source, with its coverage and refresh frequency.
• Common mistakes: forgetting penetration tests, bug bounty and manual reports; not measuring coverage gaps.
• Deliverable: a source inventory and a list of assets no tool currently covers.
• Success indicators: share of assets covered by at least one detection source; number of sources integrated.

4. Establish a common data model

• Objective: define how assets and findings are identified, normalized and deduplicated.
• Common mistakes: matching assets on IP addresses alone; discarding source details during normalization.
• Deliverable: a data model with correlation rules, identifier precedence and severity mapping.
• Success indicators: duplicate rate, share of unmatched assets, data freshness.

5. Define prioritization criteria

• Objective: agree on the factors and thresholds that define each priority tier.
• Common mistakes: relying on CVSS alone; adopting a score nobody can explain to IT; defining a top tier larger than remediation capacity.
• Deliverable: a documented prioritization policy with tiers, worked examples and the public frameworks it uses.
• Success indicators: top-tier volume within capacity; IT teams accept the rationale; time to prioritize.

6. Create remediation workflows

• Objective: design how actions move from priority to fix, including grouping, routing, approvals and exceptions.
• Common mistakes: one ticket per finding; no path for systems that cannot be patched.
• Deliverable: workflow definitions, automation playbooks and an exception process with compensating controls and expiry dates.
• Success indicators: share of actions handled through standard workflows; number and age of open exceptions.

7. Integrate ITSM and operational tools

• Objective: deliver work into the tools remediation teams already use and synchronize status in both directions.
• Common mistakes: one-way ticket pushes with no status feedback; asking IT teams to work in a security console.
• Deliverable: integrations with the ITSM, CMDB, patch management and collaboration tools.
• Success indicators: share of tickets created automatically; remaining manual hand-offs.

8. Define SLAs and escalation rules

• Objective: set remediation deadlines for each priority tier and the path a breach follows.
• Common mistakes: SLAs based only on CVSS bands; deadlines that exceed real capacity; exceptions that never expire.
• Deliverable: an SLA policy approved by Security and IT, plus an escalation matrix.
• Success indicators: SLA compliance by tier; number of overdue critical exposures.

9. Establish reporting and governance

• Objective: give each audience the view it needs and set a governance rhythm, such as a weekly operations review, a monthly steering committee and a quarterly executive report.
• Common mistakes: reporting raw finding counts; one dashboard for every audience.
• Deliverable: a KPI set, audience-specific dashboards, a governance calendar and an audit evidence pack.
• Success indicators: decisions recorded in governance meetings; audit observations on vulnerability handling.

10. Measure and continuously improve

• Objective: use results to adjust scoring rules, SLAs, ownership data and automation, and fix the root causes of recurring weaknesses.
• Common mistakes: freezing the model after launch; patching the same weakness again and again without fixing its source.
• Deliverable: an improvement backlog and a periodic review of prioritization rules.
• Success indicators: downward risk trend, lower recurrence rate, improving time to remediate by tier.

Which Metrics and KPIs Should a VOC Track?

A VOC should track outcome metrics first (critical exploitable exposures, exposure window, mean time to remediate by priority tier, SLA compliance and verified closure rate) and activity metrics second. NIST makes the same point: SP 800-40 Rev. 4 calls simple counts of vulnerabilities and patch percentages “not actionable” (NIST SP 800-40r4), and SP 800-55 distinguishes implementation measures from effectiveness and efficiency measures (NIST SP 800-55). Every metric below is useful, and every one can mislead when read alone.

MTTR deserves particular care. Define its start point explicitly (first detection, escalation to a higher priority or reopening after a failed fix) and treat each reopening as a new remediation episode, so regressions stay visible instead of disappearing into an average. This guide to calculating MTTR and mean time open (MTO) details the method.

Why closed tickets do not prove risk reduction

The number of closed tickets measures activity, not exposure:

• A ticket can be closed while the fix was never applied, or applied only partly.
• Tickets carry unequal risk: closing 1,000 low-risk tickets can reduce less exposure than fixing one exploited vulnerability on an internet-facing system.
• New vulnerabilities and assets keep appearing, so a falling ticket queue can coexist with rising exposure.
• Exceptions and risk acceptances are sometimes counted as closures.
• Vulnerabilities that come back are often counted as new findings, which hides regressions.

Report verified, risk-weighted closures together with exposure trends. That combination is what an executive team, a board or an auditor can rely on.

What Should You Look for in a VOC Platform?

Look for a VOC platform that works with the tools you already own and proves itself on your data: broad and deep integrations, cross-tool normalization and deduplication, explainable risk-based prioritization, two-way ITSM orchestration, verified closure and full audit trails. The best VOC platform for an enterprise is the one that fits its existing tools, data and operating model, not the one with the longest feature list.

Questions to ask vendors before choosing a VOC platform

1. Which of our current tools do you integrate with today, by which method (API or file), and in which direction?
2. How do you correlate the same asset across tools when identifiers differ? Can you show it on our data?
3. What happens to a finding's history when we add or replace a scanner?
4. Can an analyst see exactly why a finding received its priority, and can we adjust weights or override a score with an audit trail?
5. Which threat intelligence sources feed your prioritization, and how quickly does a new CISA KEV entry change a priority?
6. How do you verify that a fix actually worked, beyond the ticket status?
7. How do you handle exceptions and risk acceptance, including approval and expiry?
8. Which AI features are generally available today and which are in preview, what data do they access, and can every AI action be approved, logged and disabled?
9. Which deployment options exist, where will our data be stored, and which attestations or certifications cover the service?
10. What did comparable customers need to reach first value on an initial scope, and what does a typical implementation plan look like?

How Does Hackuity Support Vulnerability Operations?

Hackuity offers a vulnerability operations platform designed to sit on top of an organization's existing scanners and security tools rather than replace them. Hackuity describes this approach as vendor-agnostic: it does not sell scanners and treats every data source equally. The company was founded in 2020 and is headquartered in Lyon, France. According to Hackuity, its CEO and co-founder ran vulnerability operations for managed services at Orange Cyberdefense before creating the platform. Its capabilities map onto the VOC cycle described above:

• Aggregate and deduplicate. Hackuity connects to existing tools through APIs and file imports, with 130+ integrations, and normalizes findings into a common data model. An asset correlation engine reconciles the same asset reported by several tools, and findings are deduplicated per vulnerability and asset while each source's history is kept. Hackuity is not a scanner and does not install endpoint agents of its own (aggregation and deduplication).
• Enrich and prioritize. The True Risk Score (TRS) multiplies a vulnerability score, a threat score and an asset score into a 0–1,000 index. Its inputs include CVSS base metrics, CISA KEV status, EPSS, exploit maturity, asset criticality and exposure. Each factor is visible, so analysts can see why a finding was prioritized and adjust the context through rules.
• Automate and orchestrate. Playbooks route findings to owners derived from CMDB data, tags and organizational rules. Remediation groups bundle findings that share a fix, and two-way ITSM integrations, including ServiceNow, Jira and Azure DevOps, keep the ITSM as IT's system of record (remediation orchestration).
• Verify and measure. When a remediation is marked complete, Hackuity checks updated scanner data and marks the finding as verified, or keeps it open. Reporting covers risk trends, MTTR, SLA compliance, backlog aging and audit evidence (reporting and measurement).
• Deploy and govern. The platform is available as SaaS or on-premises, including air-gapped environments, with role-based access by scope. Hackuity holds a SOC 2 (System and Organization Controls 2) Type II attestation (Hackuity).

On AI, Hackuity's stated principle is “AI amplification, not AI replacement” (Hackuity). Since early 2026, a Model Context Protocol (MCP) server has let authorized AI assistants query platform data. Specialized AI agents are on the roadmap. Probe, an agent for exploit validation, enters feature preview with general availability planned for January 2027. Remediation Advisor (patch recommendations) is in feature preview, and Scout (penetration-test report ingestion) is available as a proof of concept through MCP: Hackuity states that agents propose and teams approve, with every action logged.

Hackuity lists ENGIE and Groupe BPCE among its customers, and Orange Cyberdefense among the partners that deliver its platform to their own clients.

Organizations evaluating a VOC can explore how Hackuity connects vulnerability intelligence, risk-based prioritization and remediation orchestration in one operating layer: see the platform overview or book a demo.

Frequently Asked Questions About Vulnerability Operations Centers

What is a Vulnerability Operations Center?

A Vulnerability Operations Center (VOC) is the function that runs vulnerability remediation as a continuous operation. It combines an operating model, a team and usually a platform to aggregate findings from scanners and security tools, prioritize them by real risk, assign each fix to an accountable owner, track deadlines and verify that exposure actually decreased. Its goal is less exploitable exposure, not more findings or more closed tickets.

What does VOC stand for in cybersecurity?

In cybersecurity, VOC stands for Vulnerability Operations Center. The term describes the function, combining people, processes and technology, that turns vulnerability findings into prioritized, assigned, tracked and verified remediation. It is modeled on the Security Operations Center (SOC) but focuses on preventive exposure reduction rather than incident response. Outside security, VOC can also mean “voice of the customer” or “volatile organic compounds,” so context matters.

Is a VOC the same as a SOC?

No. A SOC detects and responds to active threats such as intrusions and malware, typically within minutes or hours. A VOC reduces the vulnerabilities and misconfigurations attackers could exploit, working over days or weeks with IT, cloud and engineering teams. The two are complementary: the SOC shares exploitation signals with the VOC, and the VOC tells the SOC which critical exposures remain open and need closer monitoring.

What is the difference between a VOC and Vulnerability Management?

Vulnerability management is the overall discipline of identifying, evaluating, treating and reporting vulnerabilities. A VOC is the function that runs this discipline continuously and at scale, with an emphasis on execution: risk-based prioritization, ownership, remediation workflows, SLAs and verified closure. Many vulnerability management programs stop at scanning and reporting; a VOC is designed to carry each priority through to a confirmed fix.

Does a VOC replace vulnerability scanners?

No. A VOC depends on vulnerability scanners and other detection tools; it does not replace them. Scanners, cloud security tools, application security testing and penetration tests find weaknesses. The VOC consumes their output, removes duplicates, adds business and threat context, prioritizes and orchestrates remediation. Running several specialized scanners side by side is often easier with a VOC, because their findings end up in one consolidated queue.

What tools are used in a VOC?

A VOC uses three groups of tools. Detection tools supply findings: network scanners, cloud security, SAST, DAST and SCA, container security, EDR, attack surface management, penetration tests and bug bounty. Context tools supply assets and threats: CMDBs, asset inventories and threat intelligence such as the CISA KEV catalog and EPSS. Execution tools deliver and track fixes: ITSM, patch management and a VOC or RBVM platform that connects everything.

Who works in a Vulnerability Operations Center?

A VOC is usually run by a VOC lead or head of vulnerability management, with vulnerability analysts and security engineers who maintain integrations and automation. Most fixes, however, are applied by teams outside the VOC: IT operations, infrastructure, cloud, application and DevOps teams. The CISO sets risk appetite, the SOC and threat intelligence share exploitation signals, and GRC and audit teams rely on the VOC's evidence.

How does a VOC prioritize vulnerabilities?

A VOC prioritizes by combining several independent signals instead of sorting by CVSS alone. These include technical severity, evidence of exploitation such as the CISA KEV catalog, exploitation probability such as EPSS, exploit maturity, internet exposure, asset criticality, business impact and compensating controls. The result is a priority tier and a deadline for each remediation action. Good prioritization is explainable, so Security and IT can see and challenge why an item ranks high.

Why is CVSS alone not enough?

CVSS measures the technical severity of a vulnerability, not the risk it poses to a specific organization. FIRST, which maintains CVSS, states that base scores are not a measure of risk and should not be used alone for patch prioritization. A base score does not say whether a vulnerability is being exploited, whether the asset faces the internet or whether it supports a critical service. Sorting by CVSS alone also produces far more “critical” items than teams can fix.

How does AI help a VOC?

AI helps a VOC mainly with repetitive, text-heavy work: summarizing findings, correlating duplicates, extracting findings from penetration-test reports, drafting tickets and remediation guidance, answering natural-language questions about the backlog and preparing reports. It can also support exploitability analysis. Decisions with business impact, such as risk acceptance, prioritization policy or changes to production systems, should remain explainable, logged and approved by people.

What are the main benefits of a VOC?

The main benefits of a VOC are less vulnerability noise through deduplication, prioritization based on real risk and faster remediation of the exposures that matter. It also brings clear ownership, smoother coordination between Security and IT, consistent SLA management, better executive reporting and more reliable audit evidence. Together, they make cyber risk reduction measurable. A VOC does not eliminate every vulnerability and cannot guarantee that no breach will occur.

How do you measure VOC performance?

Measure a VOC by outcomes first: the number of critical exploitable exposures, the exposure window, mean time to remediate by priority tier, SLA compliance, verified closure rate, recurring vulnerabilities and the risk trend over time. Activity metrics such as tickets closed or scans run come second, because they do not show whether exposure actually decreased. Segment every metric by tier, business unit and owner to find bottlenecks.

How long does it take to implement a VOC?

Implementation time depends on scope, data quality and organizational readiness. A first scope, such as one business unit, can often become operational within weeks when detection tools expose APIs and asset ownership data exists. Extending the operating model across the enterprise, with agreed SLAs, mature workflows and automation, is usually a multi-quarter effort. Starting with one business unit or technology domain is generally faster than a big-bang rollout.

What should organizations look for in a VOC platform?

Look for a platform that works with your existing tools instead of replacing them. Key criteria include vendor-neutral ingestion, deep integrations, normalization and cross-tool deduplication, explainable risk-based prioritization, asset and threat context, and two-way ITSM orchestration. Flexible workflows, verified closure, audit trails, suitable deployment options and transparent governance of any AI features also matter. Test candidates on your own data and ask which features are generally available today.

How does Hackuity support Vulnerability Operations?

Hackuity provides a vulnerability operations platform that sits on top of existing scanners and security tools. It aggregates and deduplicates findings and assets, then prioritizes them with an explainable True Risk Score that combines vulnerability, threat and asset context. It routes remediation to owners through ITSM integrations and playbooks, verifies closure with updated scanner data, and reports on risk trends and SLAs. It is available as SaaS or on-premises.

Is a VOC relevant for small and mid-sized organizations?

Yes. A VOC is relevant to smaller organizations as an operating model, though rarely as a dedicated center. Smaller organizations face the same problem at a smaller scale: findings from several tools, limited staff and unclear ownership. A VOC function can be one or two people applying the same principles (consolidated findings, risk-based priorities, named owners, deadlines and verified fixes), supported by automation or a managed service from a managed security service provider (MSSP).

Three further capabilities usually come later in a VOC's maturity: exploitability validation (testing whether a vulnerability can actually be exploited in the environment), attack-path analysis, and AI assistance. A practical rule applies to all of them: automation amplifies whatever data quality you have. Automate routing and ticketing once asset identity, ownership and prioritization rules are reliable, not before.