Human Risk Command Center - Event Exclusion from HRCC Scoring - FAQ

This article contains information on Event Exclusion in the Human Risk Command Center (HRCC), allowing administrators to mark false or benign events, apply bulk criteria, view audit logs, and understand how exclusions affect Human Risk Scores.

Overview

Event Exclusion allows HRCC administrators to manually flag individual risk events as either a false positive or ignored (benign), removing them from contributing to a user's Human Risk Score. This allows administrators to correct inaccurate scoring caused by events that are safe, expected, or irrelevant to their organization's risk posture.

Why is this feature needed?

The Human Risk Score depends on the quality of the signals ingested from connected security solutions. Even well-tuned third-party systems can generate events that are benign in the context of a specific organization or are outright false positives. When users are penalized for safe actions, it erodes trust in the platform. This feature allows administrators to correct those cases directly from the HRCC UI, complementing the automatic remediation already in place for Mimecast-native solutions.

Which platforms support this feature?

Event Exclusion is available to HRCC customers using the Email Security - MX & API platform and/or Engage. It does not affect the Cloud Integrated platform's appearance or functionality.

Which behavior types are supported?

All behavior types currently tracked by HRCC are supported:

• Actual Phishing
• Simulated Phishing
• Training
• Malware
• Sensitive Data Handling
• Identity

Dashboard behavior cards with a See [behavior] events log link now navigate to the Event Logs tab with the relevant behavior filter and date range pre-applied.

Can an administrator exclude events in bulk?

Yes. When excluding a single event, the administrator can optionally select fields from that event's additional details to match against similar events in the last 90 days. Any event sharing the same value for every selected field will receive the same exclusion mark in a single operation. The UI shows a preview count of how many events will be affected before confirming.

Are there restrictions on which fields can be used for bulk matching?

Yes. To prevent accidently excluding large populations of legitimate events, only fields that are discrete, meaningfully specific, and descriptive of the nature of the event are available for selection. Fields such as user identity fields (email, username), timestamps, numeric scores, free-text narratives, and per-event unique identifiers are not available.

What is a conditional field?

Some fields, notably the event type field (e.g. clicked, overdue, downloaded), are conditional. They can only be used for bulk matching in combination with at least one other selected field. Event type alone is too broad and could unintentionally exclude a very large number of events. If only a conditional field is selected, the Confirm button is disabled and an error message is displayed.

Can an administrator exclude an event that has already been excluded?

Not directly, the Exclude Event button is disabled for already-excluded events. However, an already-excluded event can still be used as a template for a bulk exclusion by selecting one or more additional fields on that event, the administrator can apply exclusion criteria to other matching events. This accommodates the fact that Event Logs search capabilities are limited, making it difficult to find a non-excluded event to use as a starting point.

Can an exclusion be reversed?

No. Event Exclusion is a one-way action and cannot be undone. The underlying remediation implementation does not support reversal. Administrators should review their selections carefully before confirming, particularly when using bulk matching criteria.

Audit and Traceability

Are Exclusion actions logged?

Yes. All exclusion actions generate an audit log entry that can be viewed like any other audit log in the Mimecast Administration Console. Each log entry captures:

• The user who performed the exclusion.
• The time of the request.
• The classification (false positive or ignore).
• Any comment provided.
• The matching criteria used (or the event ID if no additional criteria were selected).
• The associated behavior type.
• An exclusion request identifier (for support and engineering traceability).

What are the new audit log types?

UI Label	Action ENUM	Legacy Type
Mark as false positive	FALSE_POSITIVE_EXCLUDED	False Positive Excluded
Ignore	EVENT_EXCLUDED	Event Excluded

Both log under the Human Risk category.

How can support or engineering trace which events were excluded together in a single request?

Every exclusion request generates a unique exclusion request identifier (analogous to a job ID) that is included in the audit log and associated with all remediation events created as part of that request.

Post-Exclusion Behavior

What does the administrator see after an event has been excluded?

For excluded events, the Additional Details drawer displays a Remediation subsection showing:

• Classification: False positive or Ignore.
• Marked by: The identity of the administrator who applied the exclusion.
• Reason: The comment, if one was provided.
• Criteria matched: A human-readable summary of the fields used for bulk matching, if applicable.

What happens if an event was already remediated before an administrator tries to exclude it in bulk?

Events that have already been remediated, by any mechanism, manual or automatic, will not be remediated again. The preview count shown before confirming may therefore be higher than the number of events ultimately affected. This discrepancy is expected behavior.

See Also...

• Human Risk Command Center - Overview