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

# Consent and policy acceptance

Capture, version and evidence a user's consent to a policy or privacy notice, gate access on it, and let the user withdraw it — plus what OpenIAM does and does not give a privacy officer handling a da

## What this is, and when you need it

Consent is the record that a person was shown a specific version of a policy and agreed to it, on a date you can prove. OpenIAM holds the policy text, versions it, localizes it, shows it at the point of access, and keeps the acceptance history as evidence. Use this section when a regulator, a customer contract or an internal control requires that agreement — an acceptable-use policy before an employee reaches an application, a privacy notice before a customer completes registration, a re-acknowledgement each year.

This is a distinct concern from authentication and from entitlements. Consent does not decide *who* someone is or *what* they may do; it decides whether they may proceed until they have agreed, and it produces the record that says they did. If you need to block access on an attribute rather than an agreement, that is an authentication rule or an access policy instead.

**Consent can be withdrawn, by the person who gave it.** A user revokes their own acceptance on **SelfService → Self Service Center → Consent history**, is signed out immediately, and is asked to accept again at their next sign-in; an administrator can reset another user's consent from the same screen on the user's record. Both actions are audited. Withdrawal is a first-class operation here, not an afterthought — see [Test revocation, both ways](/administration-guide/consent/consent-and-it-policy.md#test-revocation-both-ways).

## If you arrived here from a privacy or GDPR requirement

Be clear about the boundary before you commit to a control, because the words "consent" and "privacy" promise more than this section delivers.

**What OpenIAM gives you.** A versioned, localized privacy notice or acceptable-use text; proof that a named person was shown a specific version and agreed to it on a date; the same proof for a *refusal*; per-user consent history the person can read for themselves, including the exact text they accepted; consent withdrawal by the subject and reset by an administrator, both audited; and a re-acknowledgement period so agreement expires rather than standing forever.

**What it does not give you.** There is **no data subject request object, screen or workflow** — nothing in OpenIAM accepts, tracks, routes or reports a subject access request, an erasure request or a portability request as a case.

{% hint style="warning" %}
**This page describes the IT-policy consent feature only. Since 2026.8.1 there is also a separate Privacy module, and it does provide a purpose and lawful-basis register.**

`privacy-manager` ships with its own database and five Webconsole screens — a dashboard, consent lookup, a registry, operations and health. Its registry lets you author **purposes**, **processing activities** and **lawful authorities**, each with its own lifecycle, alongside versioned privacy notices, retention policies and an evidence chain. That is the Article 30 material this page used to say OpenIAM did not have.

**It is not yet documented.** Until it is, treat the boundary described here as covering IT-policy consent, not the Privacy module — and confirm what the module does against your own instance before you build a control on either. The two are separate features with separate data.
{% endhint %}

An IT policy is one text with one acceptance, not a set of separately consentable purposes; if you need per-purpose consent, that is the Privacy module rather than this page.

**What to build the response out of instead.** The material a privacy officer needs does exist, in pieces you assemble yourself: the shipped `USER_REPORT`, `USER_ACCESS_REPORT` and `USER_LIFE_CYCLE_ACTIVITIES` reports answer *what do you hold about me and what can I reach*; consent history answers *what did I agree to*; the audit log answers *what was done to my record*; and the ordinary removal path under [Manage identities](/administration-guide/identities.md) is what an erasure request ends in. Audit records naming the person are governed by [audit retention](/administration-guide/reference/audit-actions-and-retention.md), which is a separate decision from removing the user and needs to be made deliberately. If your obligation is to run data subject requests *as a tracked process*, model them as a request type under [Configure requests and approvals](/administration-guide/requests.md) — OpenIAM will route and record the case, but the fulfilment steps are yours.

## Choose your outcome

| I want to…                                                                   | Go to                                                                                                             |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Create a policy, version it, localize it and gate a content provider with it | [Consent and IT policy](/administration-guide/consent/consent-and-it-policy.md)                                   |
| Decide whether a change needs a new version or an in-place edit              | [Consent and IT policy](/administration-guide/consent/consent-and-it-policy.md#update-in-place-or-new-version)    |
| Read who accepted what, and when, as evidence                                | [Consent and IT policy](/administration-guide/consent/consent-and-it-policy.md#verification)                      |
| Let a user withdraw consent, or reset somebody else's                        | [Test revocation, both ways](/administration-guide/consent/consent-and-it-policy.md#test-revocation-both-ways)    |
| Work out what OpenIAM can and cannot do for a GDPR data subject request      | [If you arrived here from a privacy or GDPR requirement](#if-you-arrived-here-from-a-privacy-or-gdpr-requirement) |
| Query the acceptance history directly, or report over it                     | [Consent data model and audit actions](/administration-guide/consent/consent-and-it-policy/consent-reference.md)  |
| Look up the tables, columns and audit actions behind a consent record        | [Consent data model and audit actions](/administration-guide/consent/consent-and-it-policy/consent-reference.md)  |

## Related

* [Change configuration safely](/administration-guide/start/change-safely.md) — the change, test and rollback standard this section assumes
* [Configure platform services](/administration-guide/platform.md) — mail, localization and the services consent depends on
* [Content providers and URI patterns](/administration-guide/access/content-providers-and-uri-patterns.md) — the object a consent policy is attached to
* [Secure sign-in and credentials](/administration-guide/security.md) — where acceptance is enforced during sign-in

*Applies to OpenIAM 2026.8.1. Last reviewed 17 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/administration-guide/consent.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.