> 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/introduction/how-data-protection-works.md).

# How Data Protection Works

Data protection in eAuditor operates on the basis of **DLP policies and rules**.

The administrator determines:

1. who or what the protection should apply to,
2. which event should be detected,
3. how the system should respond to it,
4. whether anyone should be notified about the event.

In practice, the configuration is based on the following model:

**Policy -> Rule -> Trigger -> Action -> Notification**

Understanding this relationship makes it easier to create and later maintain the DLP configuration.

### Policy and rule - what is the difference?

#### Policy

**Policy** is a set of DLP rules that can be assigned to protected users or devices.

For example, you can create separate policies for:

* office employees,
* accounting department,
* IT administrators,
* shared computers,
* a selected group of devices.

Therefore, the policy primarily defines **where and for whom the specified protection rules are to apply**.

#### Rule

**Rule** defines the system's specific behavior.

It may contain:

* triggers,
* actions,
* notifications.

An example rule can detect an attempt to use a specified USB device, block the unauthorized operation, and notify the administrator.

{% hint style="info" %}
The same rule can be used in more than one policy. This eliminates the need to create a separate copy of the same configuration for each group of users or devices.
{% endhint %}

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FI3R8qa1Xsnfvm5oLNHaV%2Fimage.png?alt=media&amp;token=fc38a9d4-383c-4c8f-8c3a-157892eea271" alt="Widok polityk ochrony danych w eAuditor Cloud z rozwiniętą polityką i przypisanymi do niej regułami." width="375"><figcaption><p><em>The policy groups DLP rules applied to assigned users or devices.</em></p></figcaption></figure>

### How does the system respond to an event?

The operation of a rule can be understood as a simple sequence of events.

{% stepper %}
{% step %}

#### An event occurs

A controlled event occurs on the user's computer.

This may include, for example:

* connecting a device,
* using USB storage,
* copying data,
* sending a file,
* launching an application,
* accessing a specified website.
  {% endstep %}

{% step %}

#### The system checks the trigger

**Trigger** defines the conditions under which the rule is to be activated; the trigger will be specific events.

Depending on the type of trigger, additional parameters can be configured, such as a specific device type, application, website, or other criteria related to the controlled event.
{% endstep %}

{% step %}

#### The action is performed

If the rule conditions are met, the system performs the configured action.

Depending on the configuration, this may include:

* blocking the operation,
* displaying a message,
* taking a screenshot,
* starting recording,
* starting the configured task.
  {% endstep %}

{% step %}

#### A notification is sent

If a notification is configured in the rule, information about the event can be sent to the appropriate recipient.

Notifications are an independent configuration element and do not have to be used in every rule.
{% endstep %}

{% step %}

#### The event is logged

Information related to rule activity can be analyzed in the DLP log.

Go to:

**Data Leakage Protection -> DLP Logs**
{% endstep %}
{% endstepper %}

### Example

Suppose the organization wants to restrict the use of unauthorized USB storage devices.

The configuration may look as follows:

| Element          | Sample configuration                                    |
| ---------------- | ------------------------------------------------------- |
| **Policy**       | Employee computers + all employees.                     |
| **Rule**         | USB storage control                                     |
| **Trigger**      | Connection of a USB device meeting specified conditions |
| **Action**       | Blocking the unauthorized operation                     |
| **Notification** | Information for the administrator                       |

After the policy is assigned to the appropriate users or devices, the rule will apply to all objects covered by that assignment.

{% hint style="info" %}
Trigger **Connecting a USB device** allows for more detailed control of USB storage, including identifying specific media. It should not be confused with the trigger **Device connection**, which is used to control other categories of peripheral devices.
{% endhint %}

### Assigning policies

Creating a policy alone does not yet define where it should apply.

The policy must be assigned to the appropriate users or devices.

Each object covered by the policy receives the rules that were configured and activated in it.

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FEvvmBw8PVgUbLgyDrNxJ%2Fimage.png?alt=media&amp;token=fc46207d-4361-41b7-bb15-8c74958af313" alt="Widok przypisywania polityki ochrony danych do użytkowników lub urządzeń w eAuditor Cloud." width="375"><figcaption><p><em>The assignment determines which users or which devices will be covered by the rules of the given policy.</em></p></figcaption></figure>

{% hint style="warning" %}
Before changing a rule, check which policies use it. If the same rule has been assigned to multiple policies, changing it may affect more users or devices.
{% endhint %}

### Active and inactive rules

A rule assigned to a policy can be enabled or disabled.

* **Active rule** - can be applied to devices covered by the policy.
* **Inactive rule** - remains in the configuration, but is not applied until it is re-enabled.

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2Fxt2z8Ivlewzhf57qpZ3i%2Fimage.png?alt=media&amp;token=2a79d9ab-a154-4771-89ed-b7dc77cebcd7" alt="Aktywne i nieaktywne reguły" width="375"><figcaption><p><em>Active and inactive rules.</em></p></figcaption></figure>

This allows a specific protection mechanism to be temporarily disabled without removing its configuration.

{% hint style="info" %}
Disabling a rule is useful during testing or a temporary suspension of a specific control. If the configuration is to be used again, the rule does not have to be created from scratch.
{% endhint %}

### When do the changes take effect?

Changing the configuration in the console does not automatically mean that eAgent is already using its latest version.

After making changes, use the option:

**Update policies**

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FJbOjazGfzPTE6P3OflVy%2Fimage.png?alt=media&amp;token=0887b625-1be0-4163-9915-b3bf19a10e14" alt="Przycisk aktualizujący polityki bezpieczeństwa na PC" width="375"><figcaption><p><em>Button used to update security policies on the PC.</em></p></figcaption></figure>

Until the new configuration is delivered, eAgent operates according to the last received policy version.

You can check the date of the last update next to the button **Update policies**.

{% hint style="warning" %}
After changing the policy, rule, trigger, action, or assignment, remember to use the option **Update policies**. Otherwise, devices may continue to operate according to the previous configuration.
{% endhint %}

### Best practices for creating policies

Before deploying a new configuration to a larger number of devices:

1. create or modify the rule,
2. assign it to a test policy,
3. apply the policy to a limited number of devices,
4. update the policies,
5. perform a controlled test event,
6. check the result and the entry in DLP Logs,
7. only after confirming proper operation, expand the assignment.

{% hint style="warning" %}
Blocking rules require special caution. A misconfigured rule can restrict a user's access to a device, application, or operation required to perform their work.
{% endhint %}

### FAQ

<details>

<summary><strong>Can one policy contain many rules?</strong></summary>

Yes. A policy can group multiple rules related to different types of events and methods of data protection.

</details>

<details>

<summary><strong>Can one rule be used in several policies?</strong></summary>

Yes. The same rule can be assigned to more than one policy.

Remember that a later change to such a rule may affect all policies in which it is used.

</details>

<details>

<summary><strong>Does disabling a rule remove its configuration?</strong></summary>

No. Disabling a rule causes it not to be applied, but its configuration remains saved and can be reused.

</details>

<details>

<summary><strong>Does the rule start working immediately after the changes are saved?</strong></summary>

No. After changing the configuration, you need to use the option **Update policies**, so that the latest version is delivered to eAgents.

Until then, the device may operate according to the previous configuration.

</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/introduction/how-data-protection-works.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.