# Checks Tab

### Overview

The Checks tab in the User 360 shows a detailed view of all of a user's current check failures/observations, the reasons a user has failed a particular check, and other information related to the user's check history. Understanding the various checks a user is failing at once, or in close succession, can make it more obvious to identify an active attack or possible compromise on a given user's account. \
\
The Checks tab is the last tab of the User 360. You can also see the number of checks a given user is currently failing next to the tab name. In this article, we will go through the data and functionality available on the Checks tab including:

* [Different types of Checks](#different-types-of-checks)
* [The elements in the Failing Checks table and Resolved checks table](#checks-table-elements)
* [How to access a check failure's explainability](#diving-deeper-into-a-check-failure)
* [How to triage a check failure](#how-to-triage-checks)

{% hint style="info" %}
The Checks tab is not visible if a given user is **not** part of the protected population. 
{% endhint %}

<figure><img src="/files/SuUHqfoLg8qoWdnSeP7F" alt=""><figcaption></figcaption></figure>

### Different Types of Checks

When looking at the available checks in the platform, you may notice that some checks are marked as Identity **Posture** Insight checks, while others are marked as Identity **Threat** Insight checks. Behind the scenes, Identity Intelligence also categorizes checks as either **state based** or **event based** to retain and display a user's check history.&#x20;

State based checks and event based checks have different [triaging](#how-to-triage-checks) capabilities, but also slightly different interaction experiences within the Checks tab of the User 360 because event based checks store **Observations**, or a history of check failures for a specific check for a given user. &#x20;

To learn more about the different types of checks within Identity Intelligence in general, refer to our [Understanding Check failures ](/understanding-check-failures.md)documentation. More information about the Observations UI and functionality specifically within the User 360 Checks tab can be found below throughout this article.&#x20;

### Checks table elements&#x20;

On the Checks tab, there are 2 different tables - the first table displays the checks that a given user is currently failing. The second table shows the given user's resolved checks, which are checks that the user is no longer failing. If the user does not have any resolved checks you will only see the Failing Checks table. If the user is not currently failing any checks, you will only see the Resolved Checks table.&#x20;

Below, we will explain the fields that appear in each table, as well as the definition of each field.

### **Failing Checks**

<table><thead><tr><th width="201">Element</th><th>Definition</th></tr></thead><tbody><tr><td>Name</td><td>The name of the failed check</td></tr><tr><td>Result</td><td>Failed check status. Always listed as <code>Failure</code></td></tr><tr><td>Times Excluded</td><td>The total number of times a given user has been excluded from a particular check</td></tr><tr><td>First Reported (UTC)</td><td>The date and time of the first failed observation for a particular check for a given user</td></tr><tr><td>Last Reported (UTC)</td><td>The most recent date and time of a failed observation for a particular check for a given user</td></tr><tr><td>User/Manager Notified</td><td>The number of times a given user or their manager has been notified about a particular check failure, and an icon representing the method used to notify (Email, Slack, Teams, etc) <br><br>If a notification target is <em>not</em> set for a particular check, a message prompting you to configure the notification is shown in this column<br><br><strong>Note</strong>: Only some checks support notifying end users or managers. For checks that <strong>do not</strong> support notifying end users or managers, this column will say 'Not Supported'. If notifications are supported, but have not been sent to end users or mangers, the column will say 'Not Notified'</td></tr><tr><td>Admin Notified</td><td>The number of times an admin has been notified about a given using failing a particular check, and an icon representing the method used to notify<br><br>If a notification target is <em>not</em> set for a particular check, a message prompting you to configure the notification is shown in this column</td></tr></tbody></table>

#### Failing Check Observations

If there has been more than one observation for a check failure, the row can be expanded using the arrow to the left of the check name, so that you can see the history of observations.&#x20;

Up to 5 observations will be displayed by default, but you can click the 'See More' button under the last observation to see additional events if they exist. Observations are displayed in order from newest (top) to oldest (bottom).

<figure><img src="/files/dUohl5tCjALQS8ICy3Jo" alt=""><figcaption></figcaption></figure>

The fields available for observations are:

<table><thead><tr><th width="195">Element</th><th>Definition</th></tr></thead><tbody><tr><td>Observed At</td><td>The date and time a given observation was recorded</td></tr><tr><td>Source</td><td>The identity source associated with a given failing observation</td></tr><tr><td>Feedback provided</td><td>The user who provided feedback on a given observation, if applicable. If there has been no feedback, the value is N/A. </td></tr><tr><td>Feedback date </td><td>The day and time a user provided feedback on a given observation, if applicable. If there has been no feedback, the value is N/A. </td></tr></tbody></table>

### **Resolved Checks**&#x20;

The fields available in the Resolved Checks table are:&#x20;

<table><thead><tr><th width="207">Element</th><th>Definition</th></tr></thead><tbody><tr><td>Name</td><td>The name of the resolved check</td></tr><tr><td>Result</td><td>Resolved check status <br><code>Expired</code><br><code>Mitigated</code><br><code>Excluded</code> - includes email of Identity Intelligence User who excluded and comment, if present </td></tr><tr><td>Total Handling Time</td><td>The number of days elapsed between the first date a check/observation failed and the date it was resolved</td></tr><tr><td>Resolved Date (UTC)</td><td>The date and time that a check/observation was no longer failing for a given user</td></tr></tbody></table>

#### Resolved Check Observations

Similarly to failed check observations, if there has been more than one resolved observation for a check failure, the row can be expanded using the arrow to the left of the check name, so that you can see the history of resolved observations.&#x20;

Up to 5 observations will be displayed by default, but you can click the 'See More' button under the last observation to see additional events if they exist. Observations are displayed in order from newest (top) to oldest (bottom).

<figure><img src="/files/slY7GOYVg5t2Clbkr5ng" alt="" width="563"><figcaption></figcaption></figure>

#### **Resolved check widgets**

Under or next to the two checks tables are also two small widgets with the number of mitigated checks a given user has, the number of checks a given user has been excluded from, and the median count per user for your tenant.

<figure><img src="/files/3I427myU9iaUALbY5Nq7" alt="" width="322"><figcaption></figcaption></figure>

### Diving deeper into a check failure

For each failing check, you can click in and view more information about that particular failing check, along with the most important context, such as the actions that contributed to the user failing a given check and high level context about that user. This is called the 'check explainability'.&#x20;

To review the check explainability, click on any blank space in the row related to the specific check or observation you'd like to dig into. This will open a slide panel from the right side of the page. \
\
To access an observation's explainability, you can also click the button on the right side of the observation row, outlined in blue in the screenshot below. To close the slide panel, click the X in the top right corner of the panel, or click anywhere outside of slide panel.&#x20;

<figure><img src="/files/E5j8ov0Iwu4Fc2QS86JQ" alt=""><figcaption></figcaption></figure>

The explainability available will vary from check to check based on what information or context is most relevant for a particular check, and can include information such as such as user title, failing data source, factor type, application accessed, IP address used, etc.&#x20;

For event based checks, within the explainability panel you can get more information from the given user's [Activity](/understanding-your-users/user-360/activity-tab.md) tab by either clicking the **View in Activity** button to navigate to the Activity tab pre-filtered on all events related to that check failure, or clicking on a **See in Context** button which takes you to the Activity tab pre-filtered on events that occurred in the hour directly before and after the check failure.

**Resolved check explainability**

Resolved checks also have explainability if the check failure was **observed** **7 days ago or less**. If the check is less than 7 days old, you can access the explainability in the same was as actively failing checks - by clicking in the blank space. \
\
If the check failure was **observed more than 7 days ago**, the slide panel will appear with the recommended actions only. You can still access the check failure explainability of these older observations by clicking the 3-dot button on the right hand side of the row, and selecting **View Logs.** This will take you to the User's [Activity](/understanding-your-users/user-360/activity-tab.md) tab, pre-filtered on the check failure. Then, find the desired failing 'Observation Added' event and click the blank space of that row to open the side panel with the check explainability.&#x20;

### How to triage a user's check failure&#x20;

Once you have looked into a user's failing check(s) to understand more about the user and/or complete an investigation, you can then take action in a few different ways. To learn more about the available actions, how to use the different actions, or any additional permissions needed to use certain remediation actions, read our [Remediation Actions](/understanding-your-users/remediation-actions.md) documentation \
\
To respond to a specific check failure for a specific user, you can use the 3-dot button on the right hand side of each row, you can submit [feedback](/understanding-your-users/remediation-actions.md) for each unique observation:&#x20;

* **Exclude a user** - Removes the user from the list of check failures and stops them from being evaluated against a given check for a specified time frame. You can also leave a comment explaining why this user has been excluded from this check for that amount of time. Check will appear in **Resolved Checks** table in Checks tab of User 360
* **Mark as Normal Behavior** - Note: O*nly available for event based checks.* Remediates the failed check for that occurrence and moves it to the Resolved table in the User360 Checks tab. User is not evaluated against this check for the specific context that caused the given observation for 30 days. If Identity Intelligence notes that user has the same exact behavior again tomorrow, the user will not fail the check again, *unless* an observation is logged for that check with new context (new IP address, device, etc). Read more about this on the [Triaging Alerts and Remediation Actions](/understanding-your-users/remediation-actions.md) docs
  * Identity Intelligence team compiles this data to determine if customers find the detection accurate or not, so logic improvements can be made if needed
* **Mark as Suspicious** - Note: O*nly available for event based checks.*  Remediates the failed check for that occurrence and moves it to the Resolved section of the User360 Checks tab. User is not evaluated against this check for the specific context that caused the given observation for 30 days. If Identity Intelligence notes that user has the same exact behavior again tomorrow, the user will not fail the check again, *unless* an observation is logged for that check with new context (new IP address, device, etc).&#x20;
  * Identity Intelligence team compiles this data to determine if customers find the detection accurate or not, so logic improvements can be made if needed

There are also additional remediation actions, such as **Reset MFA**, **Log out User**, **Delete User**, **Quarantine,** etc, that can be taken on a given user's account, depending on the sources associated with a given user and the permissions configured at the data source.&#x20;

These actions can be found in the **Actions** button to the right of the User360 Tab names for a given user. The [Remediation Actions](/understanding-your-users/remediation-actions.md) documentation has more information about the different actions available, the permissions needed, compatible sources and how to use them.&#x20;


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.oort.io/understanding-your-users/user-360/checks-tab.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.