Severity and Action for Risk-Adaptive Protection users

If you are using Risk-Adaptive Protection to determine actions according to the source's risk level, select an action plan for each one of the risk levels (1-5). For each severity level in a rule, you can also configure a Dynamic User Protection Severity value that impacts the risk score calculation for a user in Forcepoint Dynamic User Protection. The following severity levels are available:

None (Do not Report): DLP incidents are not reported to Forcepoint Dynamic User Protection.

None (Report as Informative): DLP incidents are reported as informative to Forcepoint Dynamic User Protection.

Low: DLP incidents are of low importance. The policy breach is minor.

Medium: DLP incidents are of medium importance. The policy breach is moderate.

High: DLP incidents are important and should be monitored. The policy breach is significant.

Critical: DLP incidents are very important and warrant immediate attention. The policy breach is severe.

If the severity value does not match the system default for the User-Risk Impact, a notification is displayed.

Dynamic User Protection Severity values can also be batch-configured. See Update rules of a current policy.

For more information on the Forcepoint Dynamic User Protection treatment of Dynamic User Protection Severity, see the Dynamic User Protection Help document on the Forcepoint Support site.

Click the Add button (

) to create a new action plan and add it to all risk-level action-plan lists. You can then select the new action plan for each risk level.

See Risk-Adaptive Protection and Analytics.


	Note The Risk-Adaptive Protection section only affects users that were defined as risk-adaptive users (see Custom user directory groups and Custom users pages on how to define such users.)

When the "Accumulate matches" option is selected, also configure:

How to count matches:

Count incident transactions as they accumulate for a given source, even though each incident can have multiple triggers.

Count unique matches to count violation triggers that accumulate for a source, but only triggers that are unique.

If, for example, there is a rule that does not permit 10 different credit card numbers to be sent within 1 hour:

If a user sends 1 message with 20 credit card numbers, 1 violation trigger is counted.

If the user sends 20 email messages with the same credit card number, no triggers are counted, because the numbers were not unique.

Note that case differences are counted separately in word-related classifiers. For example, word, Word, and WORD.

Count all matches (default) that accumulate for a source, even duplicates. In the example above, even if the user sent 20 messages with the same credit card number, 20 triggers are counted.

Matches and transactions are counted individually for each source, such as user name or IP address, and they are counted only on the policy engine that detects them. Incidents are generated only when the threshold is met on a single policy engine.

Select a time period for accumulating matches. The time period is a sliding window. It resets every time a match is detected.

Use the Where there are at least field to define the threshold for triggering an incident. For example, trigger an incident when there are at least 3 matches (3 or more).

If the threshold is not met, the match count is 0.

Use the The rate of matches should decline... field to specify how long the system should continue counting matches once the rate begins to decline.

As long as the system continues to detect the configured number of matches over the configured period, it continues to accumulate the matches in the same incident.