> 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/risk-score-logic.md). # Risk score logic The risk score for each user is based on comprehensive data collection, including data access patterns, user permissions, sensitive data sharing, policy violations, anomalous behavior, relevant business context from HRIS, shadow apps, events and inventory. In turn, risky identity scores are leveraged to enrich drive risk-based actions in DoControl: alerts, security posture, and workflows. The user risk score reflects the potential risk an internal user poses to the organization in terms of data loss or exfiltration. The arrow reflects the increase or decrease in risk score compared to the last 30 days:

Icon	Potential risk	Risk score	Example
	Critical	80-100
	High	50-79
	Medium	30-49
	Low	01-29

{% hint style="info" %} * **Archived users** - DoControl displays the user risk score for all Google users, both active and terminated (archived). * **SaaS app sources** - We retrieve data from all SaaS apps to calculate a user's risk score, except for these apps: Jira, GitHub, and Slack Enterprise. {% endhint %} ## Multiple sources of risk data To deliver a valid risk score, DoControl leverages enriched metadata from multiple sources. For each identity, the total risk score is based on [multiple risk elements](#weight-of-risk-elements) including: * **SaaS inventory** - For Google Drive and Slack, DoControl gauges the level of the user’s asset exposure from the most exposed to least exposed: public, external and internal, and analyzes the user metadata associated with the inventory. * **Shadow apps** - DoControl analyzes the number of risky apps installed for a specific user. * **DLP** - For Google Drive and Slack assets, DoControl analyzes sensitive data sharing patterns and their magnitude for a specific user. * **HRIS and IdP** - DoControl leverages data from HiBob, Workday and Okta to discover each user’s employment status, termination date, VIP role, job title, employment status, personal emails, and department. * **DoControl alerts and workflows** - DoControl examines each triggered alert and workflow for user involvement, when the user is an actor. ## Benchmarking DoControl compares the user with the department and the entire organization. This comparative analysis also takes the user’s role into account. The department behavior is used as a baseline when considering the contribution of each risk element to the total risk score: * The department risk score is based on active or about-to-leave users (not terminated users). * If the department is small, then the contribution of each risk element is compared to the baseline of the entire organization. * We compare active users to active or about-to-leave users, and exclude terminated employees. {% hint style="info" %} For example, a Marketing department usually exposes a large number of assets externally: * **Same as baseline** - A user who belongs to the Marketing department and externally exposes a **large number** of assets does not deviate from the department baseline. The user's exposure level is considered **the same** compared to the department. * **Higher than baseline** - A Marketing user externally exposes an **exceptionally high number** of assets that is even more than the department baseline. The user's exposure level is considered **high** compared to the department. * **Lower than baseline** - A Marketing user externally exposes a **low number** of assets that is much less than the department baseline. The user's exposure level is considered **low** compared to the department. {% endhint %} ## Weight of risk elements DoControl uses complex algorithms to calculate the effect of each risk element on the user's final risk score. {% hint style="info" %} * Each risk element has a different weight in calculating the final risk score. * All risk elements (except VIP and admin user) are comparative, since they're compared to the average for the user's department or company. {% endhint %}

Risk element	Effect on total risk score
Exposure level	When the user is the owner of Google My Drive assets or uploader of Slack files, the effect on the total risk score depends on how the assets are shared: Internal assets - Don't increase the user's total risk score External assets - Moderately increase the user's total risk score Public assets - Greatly increase the user's total risk score when the user is the owner of publicly shared assets
DLP exposure	The user's total risk score increases according to the number of Google or Slack assets that have highly sensitive file names.
VIP	If the user is a VIP, such as a head of department or director, the total risk score increases
Admin	If the user has at least one admin role in integrated SaaS apps, the total risk score increases
Alerts (last 30 days)	The more active alerts the user has as an actor, the higher the total risk score.
Workflows (last 30 days)	The more workflows triggered by this user (in comparison to other people in the department), the higher the total risk score
Risky shadow apps	The more risky shadow apps installed by this user, the higher the total risk score
Employment status	User's employment status as updated in Okta or an HR app: Active - No effect on total risk score About to leave - Increases the total risk score Terminated - Increases the total risk score
Employment type	User's employment type as updated in Okta or an HR app: Full-time/ advisor - No change in the user's total risk score Part-time/ Intern/ Hourly - Slightly increases the user's total risk score Contractor/ Outsourcer/ Contingent/ Temporary/ Freelancer - Significantly increases the user's total risk score. The reasoning is the user is potentially less loyal to the company and could be leveraged to exfiltrate information.

{% hint style="info" %} For a detailed description of all risk elements, see [Identity security posture](/docontrol-user-guide/risk-management/identities/identity-security-posture.md#user-risk). {% endhint %} --- # 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/risk-score-logic.md?ask=&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.