> For the complete documentation index, see [llms.txt](https://docs.docontrol.io/docontrol-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docontrol.io/docontrol-user-guide/risk-management/identities/identity-faqs.md).

# Identity FAQs

To understand how a user's risk score is calculated, and the sources of data used in risk score calculations, see our frequently asked questions:

{% hint style="info" %}
Identities is available as a public beta module.
{% endhint %}

<details>

<summary>Q. What’s the source of data displayed in Identity Risk Management?</summary>

A. DoControl retrieves employee details from your organization’s HR system, such as HiBob, Deel HR, Workday, SAP SuccessFactors, BambooHR, and Okta. Integrating DoControl with Google Workspace, together with your HR system or Okta is a [prerequisite](/docontrol-user-guide/risk-management/identities.md#prerequisites) for using Identity Risk Management.

If a user does not exist in your HR system or Okta, s/he will **not** be created as an identity in DoControl’s Identity Risk Management solution.

Other apps such as Google Workspace, Slack, and Microsoft365 are leveraged to enrich identity metadata. For example, if a user doesn't have a department in the HR app, then their department is retrieved from Google Workspace.

In addition, DoControl retrieves data about asset exposure and shadow apps from your organization’s instance of Google Workspace.

</details>

<details>

<summary>Q. What kind of users does DoControl display? How often are these users updated?</summary>

A. DoControl displays all human, internal users in your HR system (HiBob, Workday, BambooHR) or Okta, including about-to-leave and terminated employees. User data is updated every 12 hours. We don’t display service accounts.

</details>

<details>

<summary>Q. How is the user risk score calculated?</summary>

A. The user risk score is based on multiple risk elements, such as the level of asset exposure, whether the user is about to leave the company, the number of triggered alerts, company violations exposed in workflows, etc. \
Each risk element is benchmarked against the department. If the department is small, the risk element is compared to the entire organization.\
For a full list of risk elements that contribute to the user’s total risk score, see [weight of risk elements.](#weight-of-risk-elements)

</details>

<details>

<summary>Q. Why are terminated users displayed in Identities?</summary>

A. Employees who are no longer employed at your organization pose a risk since they might still have access to your assets. This can happen if they were not terminated in Google Workspace, or if their personal email accounts still have access to assets, making them a super risky liability.

Terminated users are not included in the department risk score calculation, which reflects the current risk assessment of each team.

</details>

<details>

<summary>Q. How often is the risk score updated?</summary>

A. The risk score is updated every 12 hours.

</details>

<details>

<summary>Q. How do externally vs publicly shared assets affect a user’s risk score?</summary>

A. A user who has publicly shared assets gets a higher risk score than a user with externally shared assets.

</details>

<details>

<summary>Q. What does a risk score of 50 indicate?</summary>

A. A risk score of 50 indicates average risk in comparison to the user’s department or company (if the department is too small).

</details>

<details>

<summary>Q. What does a comparative risk element mean?</summary>

A. Some risk elements are compared to the department risk score.&#x20;

For example:

If a user's DLP exposure is **higher** than the average DLP exposure in the user's department, then the risk **increases**.&#x20;

If a user's DLP exposure is **lower** than the average in the user's department, then the risk **decreases**.

</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://docs.docontrol.io/docontrol-user-guide/risk-management/identities/identity-faqs.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.