SOC to vulnerability management handoff
detections that surface a vulnerability class become structured findings on the same record

Detection telemetry confirms the exploit pattern of a CVE that matches a deployed version of a component on the estate. The vulnerability class is the unpatched component; the detection is the operational evidence. The handoff lands a vulnerability finding with the CVE reference, the affected asset binding, the auto-calculated CVSS 3.1 vector, and the exploitation evidence so the remediation owner reads the calibration without re-deriving it.

A SIEM rule or EDR alert fires on authentication anomalies that trace to a default credential, a vendor account that was not rotated, or a weak password that survived the policy. The vulnerability class is the credential discipline failure; the detection is the access attempt. The handoff lands a finding referencing the affected identity, the account discipline gap, the asset binding to the system, and the credential rotation requirement.

Detection signal confirms scanner probing or active exploitation of an admin interface or management service that was reachable from a network segment that should not have reached it. The vulnerability class is the exposure boundary, not the active connection; the handoff lands a finding against the affected interface, the network segment policy that allowed the reach, and the asset owner accountable for the exposure.

Detection signal traces an attacker action to a misconfigured cloud bucket, an over-privileged IAM role, a missing network restriction, or a logging gap on a platform resource. The vulnerability class is the configuration that allowed the action; the handoff lands a finding against the resource identifier, the source rule reference (if the configuration was previously surfaced by a posture scanner), the calibrated severity, and the named cloud owner of record.

Runtime detection observes behaviour consistent with a code-level vulnerability (an injection payload reaching a downstream service, an authorisation bypass evidenced by an unexpected resource read, an unsafe deserialisation pattern reaching the application). The vulnerability class is the code defect; the handoff lands a finding against the application service and the repository connection where the defect lives so the engineering owner picks up the work with the right provenance.

Detection signal confirms a payload that targets a known vulnerable version of a runtime dependency, a transitive package, or a library the application loads. The vulnerability class is the outdated dependency; the handoff lands a finding referencing the package identifier and version, the affected application service, the recommended upgrade path, and the named owner of the dependency lifecycle for that service.

Detection telemetry confirms exploitation of a behaviour that a missing control should have prevented (no rate limit on a sensitive endpoint, no signed-token requirement on a privileged API, no logging on a critical action, no MFA on a privileged path). The vulnerability class is the missing control; the handoff lands a finding against the control gap, the affected surface, the framework citation the control maps to, and the engineering owner accountable for closing the gap.

Brute force attempts blocked at the boundary, port scans rejected by the firewall, and reconnaissance traffic that did not lead to access do not become vulnerability findings on their own. They remain in the detection record as monitoring evidence. Where probe volume reveals an unintended exposure (an admin interface reachable from the wider internet, a service responding on an unexpected port), the underlying exposure crosses as a vulnerability finding; the probe itself does not.

Phishing attempts that mail filters rejected, attached payloads that endpoint defences blocked, and credential capture pages that DNS filtering refused do not become vulnerability findings. They feed the security awareness programme, the inbound mail control review, and the campaign-pattern detection tuning. Where a campaign reveals a deployed asset accepting a payload class it should not (a workstation running an outdated browser known to be exploitable by the campaign payload), the deployed asset crosses as a vulnerability finding.

A SIEM rule firing on benign behaviour, an EDR signature triggering on a known internal tool, or an MDR analyst flagging a non-event traces back to detection engineering work, not to vulnerability management. The handoff register treats these explicitly so the SOC operator does not feel obliged to manufacture a vulnerability finding to close a noisy alert; the detection record stays inside the detection cycle.

External threat intelligence about a new attacker campaign, a newly published CVE in a component the estate does not run, or a regional threat actor profile does not become a vulnerability finding on its own. The emerging vulnerability and CVE watch programme decides whether the intelligence maps to a deployed asset; only the mapped subset crosses into the vulnerability management record as findings.

The SIEM rule identifier, the EDR alert ID, the MDR ticket reference, the XDR correlation id, or the manual SOC ticket number that produced the signal. The provenance identifier is the link the audit lookback follows from the vulnerability finding back to the detection record without depending on the SOC operator memory.

The first observation timestamp, the last observation timestamp, and the observation window the detection covered. Findings handed off from a single observation read differently from findings handed off after a sustained window because the calibrated severity and the urgency tier depend on whether the behaviour was a one-time event or a recurring exposure.

The named vulnerability class on the published handoff decision set (one of the seven crossing classes) and the recommended remediation action (patch, configuration change, credential rotation, segmentation change, code fix, dependency upgrade, control addition). The recommendation is the SOC analyst calibration of the engineering work, not a prescriptive ticket; the remediation owner still calibrates against the engineering context.

The host, application service, repository, cloud resource, or dependency package the vulnerability lives on, plus the named owner of record from the asset ownership mapping workflow. Assets that the SOC observed but cannot bind to an owner of record land on the unassigned-finding queue rather than on a default-assignee tail.

The auto-calculated CVSS 3.1 vector from the finding template, the source severity from the detection tool (recorded for provenance), and the calibrated severity the SOC operator and the receiving VM operator agreed on. Where the calibration diverges from the scanner default, the activity log captures the rationale so the audit lookback reads the calibration trail.

The packet capture excerpt, the log line citations, the host artefact references, the screenshot of the exploited surface, and any forensic artefacts the SOC produced. Documents land as versioned attachments on the engagement so the next reader follows the chain from detection signal to evidence to finding without rebuilding it from chat history.

A SOC analyst messages an AppSec lead in Slack with a one-line summary of the detection. The AppSec lead acknowledges in chat. The detection record closes; no finding is opened. Three months later the auditor asks for evidence the underlying vulnerability was tracked to closure and there is none. The fix is the handoff workflow that requires a finding record on the workspace before the SOC operator marks the detection closed, with the activity log capturing the named SOC operator, the receiving VM operator, the detection reference, and the finding identifier as the bridge event.

A SIEM rule fires at CRITICAL because the upstream tool defaults to CRITICAL for every authentication anomaly. An EDR alert fires at HIGH because the EDR tool calibrates against endpoint impact, not against the vulnerability class. The finding lands on the queue with an incoming severity that does not match the workspace severity policy and the triage cycle has to recalibrate everything. The fix is normalising at handoff: the source severity is recorded for provenance, the CVSS 3.1 vector is auto-calculated against the workspace template, and the calibrated severity drives the queue ordering.

The finding is opened with the description from the SOC summary but without the SIEM rule identifier, the EDR alert ID, or the MDR ticket reference. When the regulator inquiry or the audit lookback asks how the programme detected the underlying vulnerability and how long the vulnerability persisted on the estate before remediation, the chain cannot be reconstructed. The fix is requiring the detection provenance identifier and the detection timestamp on the finding record at the moment of handoff.

The SOC opens an incident engagement, lands the vulnerability finding on the incident record, and closes the incident. The finding inherits the incident lifecycle and closes with the incident without remediation evidence. The fix is the handoff that opens a separate vulnerability finding on the standing SOC to VM engagement or on the relevant VM engagement, with the incident engagement carrying the detection record and the VM engagement carrying the vulnerability lifecycle through to verified closure.

The vulnerability the SOC handed over is on the exception register with a documented risk acceptance and a target remediation date. The handoff workflow opens a new finding, the team re-debates the acceptance, and the named approver wonders why the decision is being revisited. The fix is the intake check that runs the new finding against the workspace exception register so an active acceptance, deferral, or false-positive suppression inherits the existing record and the existing expiry rather than producing a parallel ticket.

The finding closes with a self-reported done flag from the remediation owner. Two weeks later the original detection rule re-fires against the same surface because the fix did not land or did not address the underlying class. The closure evidence does not survive the re-firing. The fix is retesting paired to the original finding with the verifier, the verification method (re-run the detection rule, validate the configuration change, observe the absence of signal across a defined window), and the regression path that restores the original finding identity rather than minting a fresh one.