How do you open policy violations monitoring?

Open the view from the application menu: Menu -> Monitoring -> Violations. It shows events where the agent recognized a policy violation and tried to run the assigned response, such as blocking an application, a website, a software installation or access to USB storage. In the panel and table you can review Policy Violations, High Severity, Failed Actions, Policy Rule, Policy Area, Violation Type, Action Success, affected subjects and Policy Status.

Use this view when you need to see which rules are actually triggered on employees' computers, whether enforcement actions are completing correctly and whether a violation is an isolated incident or a repeating pattern. Policy violations monitoring is especially useful after new blocking rules are enabled, because it shows both detection and the agent's execution result.

The page is built from the Analytics Panel, a records table and a details section. The panel organizes totals, top rules, result distributions, daily charts, period comparisons, detected anomalies, hourly activity and data-quality messages. A row in the table is the policy-violation summary for one computer on one monitored day. Opening it reveals that day's workstation and employee context, with violations grouped by subject, rule, type, policy area, action and enforcement status.

Daily table in policy violation monitoring

The daily table lets you quickly verify whether violations appeared on a given computer and how the agent handled them. Read the event count together with action result, because detecting a violation does not automatically mean that the block was completed successfully.

The first columns show:

  • Violations - the number of policy violation events saved in the record.
  • High Severity - violations marked as important from the policy perspective.
  • Failed Actions - enforcement actions that did not finish successfully.
  • Rule - the rule most often connected with the record.
  • Policy Area - the part of policy that the violation belongs to.

After expanding the columns, you can inspect Violation Type, Action Success, Action Attempts, Successful Actions, Medium Severity, Low Severity, Info Severity, the last subject, the last action, Policy Status and Resolved Drive. Search covers Active Hours, areas, violation types, rules, severity levels, actions, details, statuses and text stored in detail items.

Analytics panel in policy enforcement monitoring

The analytics panel summarizes policy violations from the selected period. Sum mode helps you assess the full number of events, while Daily average makes it easier to compare date ranges of different length or periods with a different number of active computers.

The key metrics are Policy Violations, High Severity, Failed Actions, Action Success, Affected subjects, Rules triggered, Computers and Employees. When violations increase but action success remains high, the policy is probably being enforced, although the source of events should still be checked. When Failed Actions grow, you should move into enforcement details.

In this view it is worth separating two questions: who or what triggers violations, and whether the agent can execute the planned response. The panel answers that at period level, while record details show concrete subjects, rules and actions.

Rule rankings in security violation monitoring

Rankings help identify which rules and subjects generate the most violations. They are a good starting point when the event volume is high and it is not yet clear whether the cause is a specific application, website, USB device, user behavior or a rule configured too broadly.

The ranking panel includes, among others:

  • Policy Rules - rules triggered most often in the analyzed period.
  • Violation Subjects - applications, websites, devices or other subjects linked to events.
  • Violation Types - event classes such as Blocked application, Blocked website, Software install blocking or USB storage.
  • Policy Severities - the distribution of events by severity level.
  • Policy Action Results and Policy Actions - what the agent attempted and how the action ended.
  • Policy Areas - policy parts where violations appeared most often.

If one rule dominates the ranking, review its definition in the profile. If one violation subject is dominant, open details and check whether the issue is real user behavior or whether the rule covers too wide a range.

Policy violation trends in computer monitoring

Trends show how policy violations changed from day to day. You can analyze charts for Policy Violations, High Severity, Failed Actions, Action Success, Affected subjects and Rules triggered.

When reading trends, check:

  • whether the increase appeared after a new rule was enabled or after a profile change,
  • whether High Severity grows together with the total number of violations,
  • whether Failed Actions appear only for one violation type,
  • whether Action Success drops on a day with more enforcement attempts,
  • whether the number of triggered rules grows faster than the number of computers.

The Hourly Policy Violation Presence chart shows in which local hours the agent noticed violations across the analyzed days. It is not an hourly event counter. A marked hour only means that a violation was present in that time slot.

Policy violation comparisons in monitoring rules

The comparisons tab places the current range next to a baseline period, so you can see whether violation activity grew, decreased or changed character. This helps evaluate rule changes and distinguish a one-time spike from a stable problem.

In comparisons, pay attention to:

  • the change in Policy Violations, because it shows the overall event volume.
  • growth in High Severity, which may point to violations that need faster review.
  • the difference in Failed Actions, because it exposes enforcement problems.
  • movement in Action Success, especially when it drops despite a similar number of violations.
  • Affected subjects and Rules triggered, to decide whether the issue is narrow or spread across many items.

If the current period differs from the baseline, start with Policy Area and Violation Type. Then move to individual computers, because in policy violation monitoring the source of change is often one rule rather than one workstation.

Anomalies in security violations monitoring

Anomalies highlight events that exceed thresholds or stand out against the comparison period. In this view they cover both growth in violation count and problems with policy enforcement.

The panel may show, among others:

  • Policy violations increased - when activity is much higher than in the baseline period.
  • High severity policy violation detected - when a computer has violations that deserve quicker review.
  • Repeated policy violations for the same subject - when the same subject triggers violations multiple times.
  • Policy enforcement action failures detected - when the agent tried to execute an action and it failed.
  • USB storage violations that require drive resolution, and violations found in a new Policy Area.

In anomaly evidence, review Current Policy Violations, Baseline Policy Violations, Policy Violation Increase, High Severity Count, Policy Area, Violation Type, Rule, Subject, Failed Actions, Action Attempts, Policy Status, Block Message and Resolved Drive. These fields help separate a behavior problem from a technical failure during action execution.

Record details in policy violation monitoring

After you click a record, the application shows violations grouped for one day and one computer. Details focus on the violation subject and the rule that was triggered, so they help move from a daily count to a specific cause.

The details table contains fields such as Subject, Rule, Violation Type, Policy Area, Severity, Action, Violations, Failed Actions and Details. Additional columns may show Policy Status, Action Success, Action Attempts, Successful Actions, Resolved Drive, Block Message, Rule ID, Item Key, Violation Share, First Seen, Last Seen and Active Hours.

Start by sorting by High Severity or the number of violations, then check Action and Policy Status. If the record contains Failed Actions, review Block Message and Resolved Drive, because some USB violations may require identifying the drive letter or access path before the policy can be fully enforced.

Data quality in violations monitoring

The data-quality section confirms whether the violation list exists and whether its numbers are consistent with the daily rollup. That check is important because the table shows aggregates, while cause analysis needs the list of subjects, rules, actions and statuses.

The quality panel can report missing details despite existing violations, invalid JSON structure, timestamps outside the day range, mismatch between detail items and summary numbers, an ongoing aggregation for the current day or a closed older record without a violation list.

If the issue concerns today's record, wait until aggregation finishes. For older data, check agent operation, the sending queue, availability of ItemsJson details and whether severity and action counts match the detail items. Only after that control is it worth judging policy effectiveness.

Policy violation monitoring settings

The main source for the Violations view is the editable blocking configuration in the agent profile. The Policy Violation Events option itself is marked as read-only in settings, but the administrator can influence which violations are created by configuring blocking rules.

The most important settings connected with this view are:

  • Application Blocking and Application Block Rules - define applications or matches that should be handled by policy when launched.
  • Application Family Blocking - extends enforcement to related application variants.
  • Software Installation Blocking - controls events connected with installation attempts.
  • Web Blocking and Web Block Rules - affect violations of the Blocked website type.
  • USB Storage Blocking, USB Storage Blocking Mode and Allowed USB Storage Devices - decide how USB storage violations are produced.

After changing rules, observe Policy Violations, Failed Actions and Action Success in the panel. A rule that is too broad can generate many violations, while a restrictive USB mode may require adding allowed devices. It is best to change one group of rules at a time and then check whether event growth matches the intended policy effect.