> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/risk/overview.md).
# Risk management overview
What a risk score is, why certification needs one, how OpenIAM produces it, what it is attached to, where it appears, and what it is not.
This page is for anyone who has just heard that OpenIAM scores access for risk, from compliance owner to reviewer to administrator. It contains no settings; the other pages do.
**On this page**
* [What risk scoring is](#overview-what)
* [Why it matters](#overview-why)
* [How a score is produced](#overview-how)
* [What a score is attached to](#overview-subjects)
* [Where you see it and what it does](#overview-where)
* [What a score is not](#overview-not)
* [Where to go next](#overview-next)
## What risk scoring is
A risk score is a number from 0 to 100 that answers one question: **how much attention does this access deserve?** OpenIAM computes it from facts it already holds. How sensitive is the role? How was it granted, and how long ago? Does the grant have an end date, and has it passed? When did a reviewer last confirm it? Does the person still log in? The score puts those facts together into one number and one of four bands: Low, Medium, High or Critical.
## Why it matters
A certification campaign hands a reviewer hundreds of rows that all look the same: a name, an entitlement, a checkbox. `Payments-Admin` and `Finance-Reports-Read` sit side by side with nothing to tell them apart, so reviewers approve everything. The rows that need a decision get the same three seconds as the rest, and when an auditor asks why a contractor kept a money-moving permission for a year, "it was approved in the campaign" is true and worthless.
Risk scoring changes the shape of the work. The dangerous rows rise to the top. The routine rows can be handled in bulk, or approved automatically under rules you set and can defend. The campaign record shows why each item got the treatment it got.
## How a score is produced
```mermaid
flowchart LR
A[Signals
risk level, grant path, dates,
review history, logins] --> B[Factors
each scores 0 to 100]
B --> C[Policy
weights, strategy,
band thresholds]
C --> D[Score and band
on an entitlement,
a membership or a person]
D --> E[Certification scope,
auto-certification,
reviewer priority]
```
1. **Signals.** Facts OpenIAM already stores: the risk level on a role, how a membership was granted, start and end dates, the last certification decision, the last login.
2. **Factors.** A factor is a small rule that turns one kind of signal into a score from 0 to 100; "granted directly by an administrator" is worth 75. Eight ship with the product.
3. **A policy combines them.** It says which factors count, how much each weighs, how they combine, and where the four bands begin.
4. **The score lands on a subject** and is stored. It is refreshed when the subject changes, and nightly for everything.
5. **Something uses it.** A campaign filters on it, an automation rule acts on it, a reviewer sees it.
## What a score is attached to
OpenIAM scores three kinds of thing.
* An **entitlement**: a role or group, scored for how dangerous it is in anyone's hands. `Payments-Admin` scores 90 whoever holds it.
* A **membership**: one person's grant of one entitlement, scored for the context of that grant. Tom Becker's `Payments-Admin`, assigned directly by an administrator and never certified, scores 98. Maria Rossi's `Finance-Reports-Read`, a birthright grant held for three years, scores 37.
* An **identity**: a person, scored across all of their access. Tom's identity score is 99, Maria's 37.
The three connect in one direction: the entitlement score is the floor of each membership score, and a person's riskiest membership is the starting point of their identity score. The full explanation is on the [Risk factor reference](/administration-guide/risk/factors.md#levels).
## Where you see it and what it does
**In a campaign's configuration.** The Risk tab narrows a campaign to people and grants at or above a score, and an automation rule can approve low-scoring grants without a reviewer opening them. See [Access certification and risk](/administration-guide/risk/certification.md).
**On the reviewer screen.** A count shows how many risky items wait inside each row, a pill scores each item, and clicking it explains the risk in plain words. A priority view puts the worst first. See [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md).
**In the Webconsole.** An administrator reads any user's scores and tunes the factors and policies behind them. See [Risk factor reference](/administration-guide/risk/factors.md) and [Risk policies](/administration-guide/risk/policies.md).
## What a score is not
A risk score is a prioritization aid. Be precise about what that excludes.
* **It is not a decision.** A 98 means "look at this one first, and look properly". The right outcome may be "this is correct and necessary".
* **It is not a compliance verdict.** A campaign in which every row was Low did not pass. Its rows had few warning signs.
* **It is not a statement about a person.** Tom's 99 says nothing about his honesty or competence. It says his access has the shape that deserves a careful review: sensitive, granted outside the normal process, never confirmed. A model employee can carry that shape.
* **It knows nothing you have not told it.** A compensating control, a project ending next week, a misnamed role: you know those things, it does not.
Treating a high score as an accusation, or a low score as a clearance, is the misuse this section exists to prevent.
## Where to go next
* [Risk factor reference](/administration-guide/risk/factors.md) — the three subject levels and every built-in factor.
* [Risk policies](/administration-guide/risk/policies.md) — weights, strategies, toxic factors, thresholds, a starting configuration.
* [Access certification and risk](/administration-guide/risk/certification.md) — the Risk tab, the thresholds, the automation rule.
* [Reading risk on the reviewer screen](/administration-guide/risk/reviewer-experience.md) — the marks on the screen and the queue.
*Applies to OpenIAM 2026.9.1. Last reviewed 4 September 2026.*
---
# 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.openiam.com/administration-guide/risk/overview.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.