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

# Governance design

The programme decisions behind governance — what a role is for and how deep the catalogue goes, which mechanism grants which access, which rules belong at request time instead, what a certification pr

## What this is, and when you need it

Part 4 is about four decisions that are made once, defended for years, and are expensive to reverse: **what shape the role catalogue takes, which mechanism grants each kind of access, what a certification programme is asked to prove, and where segregation of duties starts.** None of them is a configuration question. All four are answered in a design document, agreed with a compliance or audit function, and then implemented — and the implementation is the Administration Guide's job, not this part's.

You need this part when someone has asked how many roles you are going to build, when an auditor has asked how often access is reviewed and by whom, or when a sponsor has asked whether OpenIAM will "do SoD". Those three questions have defensible answers that differ by organization, which is exactly why they belong here.

The reader who arrives at this part having skipped Part 2 will make decisions that do not survive contact with the data. Governance inherits whatever identity foundation was laid: a campaign can only attest to accounts that were correlated to a person, a business rule can only condition on attributes a feed actually delivers, and an SoD policy can only detect a conflict between entitlements OpenIAM knows about. If the correlation key is still open, close it before designing any of this.

## The decisions in this part

| The question in front of you                                                                                                            | Page                                                                                                                                                  | What it turns on                                                                                                             |
| --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Which object carries which idea, how deep the hierarchy goes, and when the answer is "do not build a role at all"                       | [Designing the role model](/solution-architecture/governance/role-model.md)                                                                           | How much of the estate has a stable job structure, and how much evidence you have about who currently holds what             |
| Birthright, role-derived, rule-driven or requested — which mechanism owns each entitlement's population, and what each one costs to run | [How access gets granted](/solution-architecture/governance/how-access-is-granted.md)                                                                 | Whether the deciding data is governed and present on every record, and who is prepared to own a scheduled sweep              |
| What campaigns exist, on what cadence, over what scope, reviewed by whom — and what the resulting evidence must prove                   | [Designing a certification programme](/solution-architecture/governance/certification-programme.md)                                                   | Which axis the obligation runs along, and whether the catalogue carries owners                                               |
| Where segregation of duties starts, how it moves from reporting to blocking, and who is accountable for a violation                     | [Designing a segregation-of-duties programme](/solution-architecture/governance/sod-programme.md)                                                     | How many conflicts you can actually remediate, and whether the business can absorb a blocked provisioning call               |
| Whether any access rule belongs at request time rather than in the entitlement model, and what accepting that costs                     | [Deciding access at request time](https://github.com/openiam-platform/gitbook-docs/tree/main/solution-architecture/governance/request-time-policy.md) | Whether the condition can be expressed as a population at all, and whether the control needs evidence a campaign can produce |

Read the first four in that order the first time. The role model constrains everything downstream: certification scope is expressed in roles and applications, SoD segments are expressed in entitlements, and every grant mechanism writes the same membership rows.

## The one thing to carry through all four

> **Every governance mechanism in OpenIAM reads and writes the same memberships.** A business rule, an approved request, a synchronization, a certification revoke and an administrator's direct grant all produce rows of the same kind, distinguishable only by the tag recorded on them.

That has two consequences worth stating before any of the pages. First, **two mechanisms granting the same entitlement is the most common self-inflicted governance failure**, and it presents as "my change was reverted overnight" or "access keeps coming back" rather than as anything an audit would catch. Pick one authoritative mechanism per entitlement and write it down.

Second, **the tag on a membership is the only record of why a person holds it**, and it is therefore the measurement your programme runs on. A catalogue where most memberships were created by an administrator by hand is not governed, whatever the process document says, and the tag is how you find that out without asking anyone.

## What this part does not cover

It does not describe OpenIAM's governance objects. *The certification model* and *The access model* in the Administration Guide do that, and this part links to them rather than restating them. It contains no procedures: how to create a campaign, activate a rule set, build a business rule or retrofit an owner across a catalogue are all Administration Guide tasks, and they are good ones.

It also does not cover risk scoring as a subject in its own right, beyond the two places it decides a governance outcome — which access grants a risk-filtered campaign selects, and which segregation-of-duties policies block rather than report. *Risk scoring* in the Administration Guide owns the mechanism.

## Related

* [Designing the role model](/solution-architecture/governance/role-model.md) — the decision the other three inherit.
* [How access gets granted](/solution-architecture/governance/how-access-is-granted.md) — the mechanism decision, per entitlement.
* [Deciding access at request time](https://github.com/openiam-platform/gitbook-docs/tree/main/solution-architecture/governance/request-time-policy.md) — the smaller decision behind it: which rules cannot be an entitlement at all.
* *The certification model* and *The access model* in the Administration Guide — the objects these decisions are made in.
* Part 2, *Identity foundation* — the correlation and population decisions this part assumes are closed.
* Part 5, *Coexistence and migration* — what changes when a second platform governs part of the estate.

*Applies to OpenIAM 2026.8.1. Last reviewed 28 August 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/solution-architecture/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.