> For the complete documentation index, see [llms.txt](https://eaclouddoc.eauditor.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/dlp-policies-and-rules/risk-levels.md).

# Risk Levels

The risk level allows you to determine **how significant, from a security perspective, the event controlled by a given DLP rule is**.

This makes it possible to classify rules for events of different significance accordingly, for example, to mark access to a specific website differently from an attempt to copy a file containing protected data.

The risk level is defined by the administrator during rule configuration.

{% hint style="info" %}
The risk level does not determine whether the rule will be executed. The rule's behavior results from its triggers and actions. The risk level is used to define the significance of the event and facilitates its later assessment.
{% endhint %}

### Risk level scale

The risk level is defined numerically and can be assigned to one of three ranges:

| Level                                           |  Range | Example meaning                                                                                    |
| ----------------------------------------------- | -----: | -------------------------------------------------------------------------------------------------- |
| <mark style="color:$success;">**Low**</mark>    |   1-33 | Events with low significance for security                                                          |
| <mark style="color:$warning;">**Medium**</mark> |  34-66 | Events requiring greater administrator attention                                                   |
| <mark style="color:$danger;">**High**</mark>    | 67-100 | Events of high significance, related, for example, to the possibility of disclosing protected data |

For example:

* **low risk level** can be used for access to a site belonging to the social media category,
* **medium risk level** may apply to access to a site belonging to the elevated-risk category,
* **high risk level** can be assigned to an attempt to copy a file containing personal data.

{% hint style="info" %}
The examples above do not prescribe how events should be classified. The risk level should be aligned with the security policies in force within the organization.
{% endhint %}

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FXe2CvWhLRjLeT8TqAwsh%2Fimage.png?alt=media&amp;token=b4712a91-49a2-46a4-915c-fb59f698422e" alt="Konfiguracja poziomu ryzyka reguły DLP w eAuditor Cloud z suwakiem umożliwiającym określenie wartości ryzyka." width="375"><figcaption><p><em>The risk level allows you to determine the significance of the rule in the context of the organization's security.</em></p></figcaption></figure>

### How do you set the risk level?

The risk level is set during rule configuration.

{% stepper %}
{% step %}

#### Go to rule configuration

Create a new rule or open an existing rule for editing.

Configure the required triggers, actions, and notifications.
{% endstep %}

{% step %}

#### Go to risk level

In the rule configuration, go to the section **Risk level**.

A slider will be displayed to define the risk value.
{% endstep %}

{% step %}

#### Set the value

Move the slider and select the value corresponding to the significance of the given rule.

When determining the value, consider among other things:

* the type of controlled event,
* the type of data the event may involve,
* the possible consequences of a violation,
* the security policies in force within the organization.
  {% endstep %}

{% step %}

#### Check the risk level

Based on the selected value, the rule will correspond to one of the levels:

* low,
* medium,
* high.
  {% endstep %}

{% step %}

#### Assign the rule to a policy

After completing the configuration, click:

**Assign to policy**

The rule will be saved and assigned to the selected policy.
{% endstep %}
{% endstepper %}

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FCV0Ek5QhSuD7Ug4Td863%2Fimage.png?alt=media&amp;token=be17ba2a-6958-4beb-87cb-dbf433051555" alt=" Przycisk Przypisz do polityki widoczny po skonfigurowaniu poziomu ryzyka reguły DLP." width="375"><figcaption><p><em>After completing the configuration, the rule must be assigned to the appropriate policy.</em></p></figcaption></figure>

### How do you choose the risk level?

Not every organization should classify the same events in the same way.

When determining the risk level, it is worth answering a few questions:

1. Can the event lead to data loss or disclosure?
2. What type of data may it involve?
3. Is the user performing a standard action or an unusual operation?
4. What may be the consequences of the event for the organization?
5. Does the event require a rapid administrator response?

On this basis, you can adopt your own classification method.

#### Example

The organization may establish the following rules:

| Event                                               | Example level  |
| --------------------------------------------------- | -------------- |
| Access to a site from the monitored category        | Low            |
| Launching an unauthorized application               | Medium         |
| Connecting an unauthorized USB device               | Medium or high |
| Attempting to copy a protected document             | High           |
| Attempting to send a file containing protected data | High           |

{% hint style="warning" %}
Do not treat the table above as a mandatory classification. The levels should reflect the actual risk resulting from the security policies and operating model of the organization.
{% endhint %}

### Consistent rule classification

When you have a large number of rules, it is worth establishing internal rules for assigning risk levels.

For example:

* **low** - events that are primarily informational,
* **medium** - events requiring analysis or potentially indicating a policy violation,
* **high** - events that may lead to data loss, disclosure, or unauthorized use of data.

This approach makes it easier to maintain consistency among rules created by different administrators.

{% hint style="info" %}
It is worth documenting the adopted classification method in the organization's internal documentation. This ensures that new rules are assessed according to the same criteria.
{% endhint %}

### Changing the risk level

The configured risk level can be changed later.

To do this:

{% stepper %}
{% step %}

#### Open the rule

Go to the policy view, expand the appropriate policy, and open the rule for editing.
{% endstep %}

{% step %}

#### Change the risk value

Go to the section **Risk level** and set a new value.
{% endstep %}

{% step %}

#### Save the configuration

Save the changes to the rule.
{% endstep %}

{% step %}

#### Update policies

After changing the configuration, use the option:

**Update policies**

so that the latest configuration can be delivered to the eAgents.
{% endstep %}
{% endstepper %}

### FAQ

<details>

<summary><strong>Does the system automatically set the rule's risk level?</strong></summary>

No. The risk level is defined by the administrator during rule configuration.

This allows the classification to be aligned with the security policies in force in the organization.

</details>

<details>

<summary><strong>Does a high risk level mean the event will be automatically blocked?</strong></summary>

No. The risk level defines the significance of the event.

Whether the operation will be blocked or another response will be executed depends on the configured triggers and actions of the rule.

</details>

<details>

<summary><strong>Can the risk level be changed later?</strong></summary>

Yes. Open the rule for editing and set a new risk level value.

After saving the change, remember to update the policies.

</details>

<details>

<summary><strong>What risk level should I set?</strong></summary>

The level should be selected based on the significance of the event in the given organization.

Consider the type of data, the possible consequences of the event, and the required response method.

</details>

<details>

<summary><strong>Can two similar rules have different risk levels?</strong></summary>

Yes. The risk level is part of the configuration of a specific rule and can be adjusted to its purpose and scope of operation.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/dlp-policies-and-rules/risk-levels.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.