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

# Record privacy and consent

Record why you process personal data and under what authority, keep an auditable consent ledger with point-in-time answers, and deliver consent changes to the systems that need them.

## What this is, and when you need it

The **Privacy module** is where you record *why* your organization processes personal data, *under what authority*, and *what each person has agreed to* — with an evidence trail built to be shown to a regulator.

It answers the questions an IT-policy acceptance cannot. Not "did this person accept the acceptable-use text", but "which purposes do we process this person's data for, on what lawful basis, what did they consent to, when did that change, and can you prove it".

New in **2026.8.1**, delivered by its own `privacy-manager` microservice with its own `privacy` database, and managed from five screens in the Webconsole.

{% hint style="warning" %}
**This section is an orientation, not a procedure set.** It is written from the shipped code — the data model, the REST surface and the screens that exist. The step-by-step pages for each screen are not written yet, and nothing here has been walked through against a running instance. Confirm behaviour on your own deployment before you build a control on it.
{% endhint %}

## How it differs from IT-policy consent

OpenIAM has two consent features and they are not the same thing. Choosing the wrong one is the most expensive mistake available here, because the data lives in different databases and neither reads the other.

|                  | [Consent and policy acceptance](/administration-guide/consent.md) | This section                                                        |
| ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------- |
| **The question** | Did this person accept our acceptable-use policy?                 | What do we process, why, on what basis, and what did they agree to? |
| **Shape**        | One text, one acceptance, one re-acknowledgement period           | A register of purposes and activities, each separately consentable  |
| **Lawful basis** | Not modelled                                                      | A first-class register with its own lifecycle                       |
| **History**      | Per-user consent history                                          | An append-only event ledger with point-in-time queries              |
| **Storage**      | The `openiam` schema                                              | Its own `privacy` schema                                            |

If your requirement is "everyone must accept the AUP before they reach the portal", that is the consent section. If it is Article 30 — a record of processing activities, purposes and lawful bases — it is this one.

## The five screens

| Screen             | What it is for                                                                                  |
| ------------------ | ----------------------------------------------------------------------------------------------- |
| **Dashboard**      | The module's summary view                                                                       |
| **Registry**       | Authoring purposes, processing activities, lawful authorities and privacy notices               |
| **Consent lookup** | Finding a subject's consent state, its history, and the state as it stood on a given date       |
| **Operations**     | The event outbox — what has been delivered to downstream systems, what failed, and replaying it |
| **Health**         | Service metrics and verification of the evidence chain                                          |

## What the model holds

Verified from the shipped entities rather than from a screen:

* **Purposes** — why you process data. Each carries a lifecycle, so a purpose can be drafted, made active and retired rather than edited in place.
* **Processing activities** — what you actually do with the data, attached to the purposes that justify them. Also lifecycled.
* **Lawful authorities** — the basis you rely on. A separate register with its own lifecycle, so the basis is recorded as a governed object rather than a free-text field.
* **Privacy notices**, versioned — the text a subject was shown.
* **Subjects**, with identity links and relationships — how a data subject maps onto the people and records you hold.
* **A consent ledger** — consent *events* appended over time, and consent *state* derived from them. It answers "what is true now" and "what was true on this date" separately.
* **Consent receipts** — the artefact you hand a subject as proof of what they agreed to.
* **An evidence chain**, segmented and verifiable, with a retention sweep that erases whole segments while keeping the remainder verifiable.
* **Retention policies**, and an **outbox/inbox with webhook endpoints** for pushing consent changes to systems that need to honour them.

## What it still does not do

There is **no data subject request case object** — nothing here accepts, tracks or routes a subject access, erasure or portability request as a workflow. The erasure in this module is the retention sweep over its own evidence, not a response to a subject's request. To run data subject requests as a tracked process, model them as a request type under [Configure requests and approvals](/administration-guide/requests.md).

## Related

* [Consent and policy acceptance](/administration-guide/consent.md) — the other consent feature, and how to tell which one you need
* [Configure requests and approvals](/administration-guide/requests.md) — where a data subject request workflow would live
* [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — how long audit records naming a person survive, which is a separate decision from anything here
* [Find audit evidence](/administration-guide/operations/find-audit-evidence.md) — the platform-wide audit trail

*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/privacy.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.