> 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/governance.md).

# Govern access

OpenIAM's identity governance surface — access certification campaigns and segregation of duties, two independent subsystems that share a data model only at the edges.

## What this is, and when you need it

This is OpenIAM's **identity governance** (**IGA**) surface. This section is for the administrator who has to prove that the access people hold is the access they should hold — to an auditor, a regulator or an internal control owner.

Governance in OpenIAM is **two independent subsystems**, plus risk scoring alongside them. You can adopt one without the others.

| Subsystem                            | What it answers                                                                                                                              | Where                                                                     |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Access certification**             | *Is the access people already hold still justified?* Periodic review campaigns, which reviewers meet in SelfService                          | [Access certification](/administration-guide/governance/certification.md) |
| **Segregation of duties**            | *Does anyone hold a combination they should not?* Toxic-combination detection, policies, rule sets, exemptions                               | [Segregation of duties](/administration-guide/governance/sod.md)          |
| **Risk scoring**                     | *Which access deserves attention first?* A 0–100 score per entitlement, membership and identity                                              | [Risk management](/administration-guide/risk.md)                          |
| **Caddie — Access Review Assistant** | *What does a reviewer need to know to decide this line?* A read-only context panel beside each review row, and the audit trail of every item | [Caddie — Access Review Assistant](/administration-guide/caddie.md)       |

They meet in exactly two places. A campaign can narrow its scope by **membership risk score**, and a reviewer sees the SoD violations attached to an item through `ACCESS_REVIEW_ITEM_SOD_VIOLATION` — which can block that item's decision until the violation is resolved. Everything else is independent.

Read [Change configuration safely](/administration-guide/start/change-safely.md) once before your first change.

## Where to start

| If you need to…                                              | Go to                                                                     |
| ------------------------------------------------------------ | ------------------------------------------------------------------------- |
| Run a periodic access review and produce evidence for it     | [Access certification](/administration-guide/governance/certification.md) |
| Detect and work toxic combinations of access                 | [Segregation of duties](/administration-guide/governance/sod.md)          |
| Score access by risk, and feed that into either of the above | [Risk management](/administration-guide/risk.md)                          |

## Three shipped defaults that decide whether governance works

{% hint style="warning" %}
**Nothing chases a reviewer.** `REQUEST_REMINDERS` and `REQUEST_ESCALATION` both ship with `ENABLED='N'`. Reminder cadence configured on a reviewer step is stored but never acted on until you enable those two batch tasks. Confirm it before you blame the campaign: open **Administration → Batch Tasks**, find both task IDs, and read the enabled column. This is the single most common "the campaign just sat there" case — see [Configure the review workflow](/administration-guide/governance/certification/configure-the-review-workflow.md).

**Reviewers are not notified unless you pick a template.** Launch notifications are sent only when the certification's **Email Template** field is set (`CERTIFICATION.MAIL_TEMPLATE_ID`). A campaign saved with that field blank launches silently — no error, no audit record of a mail, and no reviewer mail in the notification log.

**A revoked entitlement is end-dated, not removed.** `org.openiam.workflow.termination.access.remove` ships `false`, so a revocation decision sets an end date on the membership rather than deleting it. You will see this on the user's entitlement list: the row stays, with a past end date. See [Operate a live campaign](/administration-guide/governance/certification/operate-a-live-campaign.md).
{% endhint %}

## Where the objects live

**Certification has its own database.** `CERTIFICATION`, `CERTIFICATION_REVIEWER`, `CAMPAIGN`, `CAMPAIGN_STEP`, `CAMPAIGN_REVIEWERS`, `CAMPAIGN_PREVIEW_EXCLUSION`, `ACCESS_REVIEW_ITEM` and its child tables live in a database of their own, reached over `jdbc.certification.url` and named `certification` unless your deployment overrode it. Risk and SoD objects stay in the `openiam` schema. A join across the two in a hand-written report is a cross-database join — plan for it. The Webconsole never shows you which database it is reading from, so if you need the live connection string, ask the deployment owner.

Details in [The certification model](/administration-guide/governance/certification/certification-model.md) and [Certification database tables](/administration-guide/reference/certification-tables.md).

*Applies to OpenIAM 2026.9.1. Last reviewed 14 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/governance.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.