> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Tutorial: From Vulnerability to Control

> Prioritize a critical CVE, assign it, back it with a control and close it after implementation.

We handle a critical vulnerability from detection to closure: prioritize in
*CVE Analysis*, check the affected systems, assign a person, create a control in
the ISMS, track implementation and close the CVE.

**Prerequisite:** scanned systems with captured software. Matching against
known vulnerabilities runs in the background.

## Starting point

Docusnap Sports GmbH has finished scanning the Windows servers. Under *Analysis ›
CVE Analysis*, the list *By CVEs* shows at the top a CVE with *CVSS* 9.8 and
severity *Critical*. Affected: the web frontend of the ERP system.

## 1. Prioritize

The list *By CVEs* is sorted by *CVSS* descending. The most dangerous
vulnerability is at the top. We open it via the column *CVE ID*.

<Tip>
  *Analysis › Dashboard* shows the number under *Critical CVEs* and leads directly
  into this list.
</Tip>

The *Overview* tab shows the *CVSS* value, the severity and the metrics of the
rating. The *Remediation Deadline* in the section *General* follows from the CVSS
value: at 9.8 it is 7 days.

## 2. Check affected systems

The tab *Affected Assets* lists the systems, the tab *Affected Software* the
installations with version and host. Here: the web frontend, one installation.

<Note>
  Both tabs count installations. A system with two affected installations appears
  twice.
</Note>

## 3. Assign and rate

Tab *Assessment*, pencil icon.

| Field | Value |
| - | - |
| *Status* | *In Progress* |
| *Owner* | the administrator of the web frontend |
| *Due Date* | a date within the remediation deadline |
| *Category* | *Software* |

*Save*.

<Warning>
  Switching tabs leaves edit mode and discards the input without confirmation.
  Save before you switch tabs.
</Warning>

<Note>
  *Accepted* and *False Positive* require a *Justification*. An accepted CVE stays
  documented without a control.
</Note>

## 4. Create the control

Tab *Controls*, button *Control*, in the dialog *Create New*:

| Field | Value |
| - | - |
| *Name* | *Update web frontend to version 4.2* |
| *Status* | *Planned* |
| *Priority* | *High* |
| *Frequency* | *One-time* |
| *Owner* | the administrator of the web frontend |
| *Due Date* | the same date as *Due Date* on the CVE |

The control is linked to the CVE and also appears under *ISMS › Risk Management
› Controls*.

<Note>
  The *Controls* tab on the CVE is a view of the ISMS controls, not a separate
  management. The same control can treat a CVE and fulfil a regulation objective.
</Note>

## 5. Track implementation

Under *ISMS › Risk Management › Controls* the administrator sets the status to
*In Progress* and, after the update, to *Implemented*. The CVE's *Controls* tab
shows the progress: one of one control implemented.

## 6. Close the CVE

Tab *Assessment*: *Status* *Fixed*. After the next scan of the web frontend the
matching detects the new version; the CVE no longer appears under *Open CVEs* of
the asset.

<Tip>
  If remediation is not yet possible, the status stays *In Progress* with a new
  *Due Date*. The *Remediation Deadline* does not change — it is the default from
  the severity, *Due Date* your agreement.
</Tip>

## Result

* The critical CVE has an owner, a due date and a status.
* A control in the ISMS documents the remediation.
* The path from vulnerability to implementation is traceable — on the CVE and on
  the control.

## What's next

All statuses, deadlines and tabs: [CVE Analysis](/docs/en/analysis/cve). Controls in
the ISMS: [Tracking Controls](/docs/en/isms/controls).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.