> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/ensure-privacy-and-compliance/define-your-privacy-and-compliance-framework.md).

# Define your privacy & compliance framework

Decide with your legal team what the platform enforces, and what other tools do.

## Your goal

Decide, before configuring anything, which parts of your compliance the platform enforces and which parts other tools handle - and agree the list of processing activities that everything else keys off.

## Expected outcome

A documented list of processing activities with their legal bases, a clear division of responsibility between the platform and your other tools, and a team that understands both.

## What the platform is, and is not

mediarithmics acts as a **data processor** under the GDPR, and is designed to help you comply with data privacy regulations and practices. Concretely, it can help by:

* **Preventing the storage** of personal data for users with non-compliant choices.
* **Preventing the segmentation** of users with non-compliant choices.
* **Storing proofs of consent** for audit purposes, including change history.

{% hint style="warning" %}
User choices are **not**:

* **A guarantee of GDPR compliance.** As data controller you must make sure the legal basis used is valid, that user consents contain enough information to prove their validity, and that processing activities are rightfully associated with data sources and operations on the platform.
* **A front-end solution.** Integration with a front-end consent management platform must be considered.
* **A choice hub for sharing choices with third parties.**

The feature can integrate with any market CMP - automatically if the CMP is IAB-registered - but it is **not a registered IAB CMP**, because the platform does not provide the user interface that captures the choice.
{% endhint %}

It is likely that other tools play a role in your overall compliance: a front-end CMP capturing choices and triggering trackers accordingly, a back-end repository storing proofs of consent, and so on. Deciding which does what is the point of this page.

## The preparatory work

This work is done **with your legal department**, not by the team configuring the platform.

{% stepper %}
{% step %}

### Define your processing activities

Processing activities legitimise the fact that you capture and store personal data on the platform. Each one needs a **purpose** and a **legal basis**.

The user choices you capture should relate to those processing activities, and it is these activities that appear in the dropdown lists your platform users see later.

{% hint style="info" %}
Use the **same framework** as the one shown to your end users when their choice is captured - on your CMP, typically. A mismatch between the two is what makes an audit difficult.
{% endhint %}

<details>

<summary>A worked example</summary>

You track online activity - viewed pages, online purchases - in order to do **targeted advertising**, relying on consent, and **analytics**, relying on your legitimate interest.

Your front-end CMP asks for consent to targeted advertising, and offers the ability to object to analytics.

If you use mediarithmics for both purposes, create **two processing activities**, one per purpose, and track user choices accordingly. The platform will then allow the storage of personal data for users who have either given consent to targeted advertising, or not objected to analytics. Your platform users will be asked which purpose justifies the processing they trigger - creating a segment, for instance.

</details>

{% hint style="info" %}
If you are integrated with a compliance solution implementing the IAB Transparency & Consent Framework, ask your account manager about defining your processing activities.
{% endhint %}
{% endstep %}

{% step %}

### Decide what you must collect to prove a valid consent

If you use consent as a legal basis, decide what information proves it - a consent string with metadata, a privacy policy version, a website code version. This becomes the custom properties of your user choices, which is why it has to be decided before you start capturing them.
{% endstep %}

{% step %}

### Identify your choice sources

A front-end CMP, settings in a logged-in environment, CRM files. If several sources can set a choice for the same processing, you will also need to decide which one wins - see [choice sources](/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md#when-several-sources-set-the-same-choice).
{% endstep %}

{% step %}

### Decide which platform features you activate

Given what your other tools do, choose which of the platform's compliance features you need: privacy walls on channels, on compartments, on segments, or a subset.
{% endstep %}

{% step %}

### Train your platform users

The feature puts compliance settings in front of your users: creating a segment asks them for the processing activities that legitimise it. That requires them to understand the purpose, legal basis, and scope of the processing activities they perform.

Organise a short compliance training with your legal department. Your account manager can attend and introduce the platform's compliance settings.
{% endstep %}
{% endstepper %}

## Choosing a legal basis

The legal basis is not just documentation: it **changes what the platform does**. Five are available, and `VITAL_INTERESTS` is deliberately not among them.

| Legal basis                                         | What the user can express | What the platform does                                                                                  |
| --------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------- |
| `CONSENT`                                           | Accept or refuse          | Processing is **allowed only if** the user has a choice with the value `true`. No choice means blocked. |
| `LEGITIMATE_INTEREST`                               | Object only               | Processing is **allowed unless** the user has objected.                                                 |
| `PUBLIC_INTEREST_OR_EXERCISE_OF_OFFICIAL_AUTHORITY` | Object only               | Processing is **allowed unless** the user has objected.                                                 |
| `CONTRACTUAL_PERFORMANCE`                           | Nothing                   | No user choice is stored. Processing is **always allowed**.                                             |
| `LEGAL_OBLIGATION`                                  | Nothing                   | No user choice is stored. Processing is **always allowed**.                                             |

{% hint style="danger" %}
The difference between `CONSENT` and the objection-based bases is the **default**: with consent, silence blocks; with legitimate or public interest, silence allows. Choosing the wrong one either loses data you were entitled to keep, or keeps data you were not.

And the legal basis **cannot be modified** once the processing activity is created, because choices may already have been captured against it.
{% endhint %}

## What is not covered

Worth knowing before you promise a scope:

* **Privacy walls on activities** cover `SITE_VISIT` and `APP_VISIT` upserts. `TOUCH`, `EMAIL`, and `DISPLAY_AD` activities are **not covered yet**.
* **User choices are not supported** for the User Activation, User Lookalike, and Edge segment types.

## Then do this

{% stepper %}
{% step %}

### Register the processing activities and capture choices

[Manage consent & Processing activities](/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md)
{% endstep %}

{% step %}

### Load the choices you already hold

[Import user consent](/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch/import-user-consent.md)
{% endstep %}

{% step %}

### Decide your retention

[Data retention](/setup-and-monitor/plan-and-integrate/set-up-the-environment/manage-data-retention.md) and [Cleaning rules](/setup-and-monitor/collect-and-manage-your-data/clean-and-delete-data/cleaning-rules.md)
{% endstep %}

{% step %}

### Document your browser footprint

[Audit our tag's browser footprint](/setup-and-monitor/ensure-privacy-and-compliance/audit-our-tag-s-browser-footprint.md)
{% endstep %}

{% step %}

### Prepare for individual requests

[Exercise rights of the user](/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md)
{% endstep %}
{% endstepper %}

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Manage consent &#x26; Processing activities</strong></td><td>Registering activities, capturing choices, enforcing walls.</td><td><a href="/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md">Manage consent &amp; Processing activities</a></td></tr><tr><td><strong>Audit our tag's browser footprint</strong></td><td>The cookies and storage the tag uses.</td><td><a href="/setup-and-monitor/ensure-privacy-and-compliance/audit-our-tag-s-browser-footprint.md">Audit our tag's browser footprint</a></td></tr><tr><td><strong>Exercise rights of the user</strong></td><td>Access and erasure requests.</td><td><a href="/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md">Exercise rights of the user</a></td></tr></tbody></table>


---

# 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.mediarithmics.io/setup-and-monitor/ensure-privacy-and-compliance/define-your-privacy-and-compliance-framework.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.