# Governance (/docs/features/governance) > The loop that keeps access correct over time, from measuring usage and mining roles to reviews, guardrails, terms of use, and self-service. Roles and bindings say who *may* do what on the day you set them up. Then people change teams, projects end, roles grow, and exceptions pile up. A year later nobody can say whether the access is still right, and auditors ask anyway. *Governance* is the loop that keeps access right over time. You measure which access is actually used, simplify how it is granted, have the people who know certify it, check each change before making it, hold lines no change may cross, get people to agree to the rules, and help them get what they need without an administrator. ## Questions and the features that answer them [#questions-and-the-features-that-answer-them] Each governance feature answers one question an administrator or auditor asks. Start from the question you have: | Question | Feature | API | | ----------------------------------------------- | ----------------------------- | ------------------------------------------------------ | | Which grants are redundant or could be simpler? | Role mining | `roleMining.suggest` / `apply` | | Who holds access unlike their peers? | Peer outliers | `roleMining.outliers` | | Which access is actually used? | Access usage and right-sizing | `accessUsage` option, `roleMining.usage` / `rightSize` | | Should this person keep this role? | Review recommendations | `roleMining.reviewRecommendations` | | What happens if I edit this role? | Change impact preview | `impact.preview` | | What must never (or always) be possible? | Access invariants | `invariants.*`, `iam.checkInvariants()` | | Have people accepted the rules? | Terms of use | `agreements.*`, `principal.pendingAgreements` | | How can I get access myself? | Self-service access paths | `accessPaths.find`, `useAccessPaths` | The administrator reads above each need a permission: `iam:analysis:read` (role mining, usage, recommendations), `iam:policies:simulate` (impact), `iam:invariants:read`, or `iam:agreements:read`. Access paths and a member's own agreements need only that person's session. The console's Organization section has a page for each feature. ## The loop [#the-loop] ### Measure [#measure] You cannot remove unused access until you know what is used. Turn on [access usage](/docs/features/governance/usage-and-mining#access-usage) once and let it run for a review period. Every allowed check is counted per person and action, so `roleMining.rightSize` can later show which grants nobody touched. ### Simplify [#simplify] Access granted one person at a time becomes hard to reason about. *Role mining* reads who holds what and proposes simpler grants: redundant bindings to remove, roles to bind to a group once, duplicate roles, and bundles of roles to grant together as an access package. [Peer outliers](/docs/features/governance/usage-and-mining#peer-outliers) show people whose access differs from their colleagues', often access that outlived a move. ### Review [#review] Auditors want proof that someone checks access regularly. A certification campaign is that check: it asks named reviewers, or each person's manager, to keep or revoke every role binding, and applies the decisions when it closes. [Certifications](/docs/features/governance/certifications) also suggest a decision for each item from usage evidence. ### Change safely [#change-safely] A role edit can give or take access from many people at once. An impact preview shows who gains and loses what before you make the change. An access invariant is a rule that must hold whatever roles say, such as "contractors never approve payments"; enforced invariants refuse any change that would break them. See [change safety](/docs/features/governance/change-safety). ### Agree [#agree] Some access should depend on people accepting rules first, such as an acceptable-use policy. [Terms of use](/docs/features/governance/agreements) are versioned agreements that members accept; an ordinary policy statement holds back access until they do. ### Help people help themselves [#help-people-help-themselves] "Access denied" sends people to an administrator even when they could fix it themselves. When your application refuses something, [access paths](/docs/features/governance/access-paths) tell the person what they could do about it: step up to MFA, accept terms, activate an eligible role, or request a package. Two related tools live with authorization: separation-of-duties rules, which name roles nobody may hold together, and the access analysis, a scan of a tenant's configuration for risky grants. See [separation of duties](/docs/authorization/separation-of-duties) and [access reviews](/docs/authorization/reviews). ## Setup, routes and storage [#setup-routes-and-storage] Only access usage needs a deployment option (`accessUsage`); every other governance feature is always available, and all of their collections are created by the ordinary migration (`npx better-iam migrate` or `iam.initialize()`). Every method is a `POST` route at `{basePath}/{group}/{method}`, so `iam.api.invariants.run` is `POST /api/iam/invariants/run` with the default base path. | Feature | API group(s) | Collections | Scheduled job | | ------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | Usage and mining | `roleMining` | `accessUsage`, `accessUsageTracking` | none (buffered writes) | | Certifications | `certifications` | `certificationCampaigns`, `certificationItems` | `iam.closeOverdueCertifications()` | | Change safety | `impact`, `invariants` | `accessInvariants` | `iam.checkInvariants()` | | Terms of use | `agreements` | `agreements`, `agreementAcceptances` | none | | Access paths | `accessPaths` | none | none | | Lifecycle workflows | `workflows` | `workflows`, `workflowRuns`, `workflowSubjects` | `iam.workflows.runDue()` | | Application catalog | `applications` | `applications`, `appAssignments`, `appLaunches` | none | | Compliance center | `compliance` | `complianceControls`, `complianceExceptions`, `complianceResults`, `complianceRuns`, `complianceCheckpoints` | `iam.compliance.evaluateAll()` | | Privacy and consent | `privacy` | `privacyPurposes`, `privacyConsents`, `privacyConsentEvents`, `privacyRequests`, `privacyExports`, `privacyHolds`, `privacyRestrictions`, `privacySettings` | `iam.privacy.sendDeadlineReminders()` | Each feature page lists its options, schema, routes and errors. ## In this section [#in-this-section] - [Usage and role mining](/docs/features/governance/usage-and-mining): Record what people use, right-size roles, mine suggestions, and find peer outliers. - [Certifications](/docs/features/governance/certifications): Campaigns, reviewer modes, reminders, recommendations, and auto-close. - [Change safety](/docs/features/governance/change-safety): Impact previews and access invariants that refuse changes breaking a guardrail. - [Terms of use](/docs/features/governance/agreements): Versioned agreements that members accept and policies can require. - [Access paths](/docs/features/governance/access-paths): Answer "how can I get access?" with options verified by simulation. - [Scheduling](/docs/features/governance/scheduling): The jobs, CLI commands, and cadences that keep the loop running. - [Lifecycle workflows](/docs/features/governance/workflows): Joiner, mover and leaver automation with the owner's rights checked at every step. - [Application catalog](/docs/features/governance/applications): A My apps launcher with assignments, requests, audited launches, and sign-in enforcement. - [Compliance center](/docs/features/governance/compliance): Automated checks mapped to SOC 2, ISO 27001, NIST 800-53 and GDPR, with signed evidence. - [Privacy and consent](/docs/features/governance/privacy): Purposes, consent receipts, data-subject requests on statutory deadlines, and legal holds.