> For the complete documentation index, see [llms.txt](https://doc.dastra.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.dastra.eu/en/features/notifier-les-violations-de-donnees/incidents-as-data-processor.md).

# Incidents as a Data Processor

Manage data breach incidents in which your organisation acts as a Data Processor under the GDPR.

Dastra's data breach module adapts to your **organisation's role** in the incident: Data Controller (DC) or Data Processor (DP). This role determines the applicable obligations and which steps are displayed in the form.

***

## Declaring your role at creation

When creating a new incident, a selector lets you choose between:

* **Data Controller** — standard flow: supervisory authority notification, communication to data subjects, risk analysis.
* **Data Processor** — adapted flow: the obligation to notify the supervisory authority directly does not apply; it is the Data Controller's responsibility to notify.

<figure><img src="https://2697025545-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LvBxs22wUMicv9uWp6C-1972196547%2Fuploads%2Fgit-blob-4a096a2ed7fb53a1c4f4a4fca7809fe2838ff302%2Fviolations-create-subprocessor.png?alt=media" alt="Create incident dialog with the Data Processor selector (Yes/No)"><figcaption><p>When creating an incident, indicate whether your organisation acts as a Data Processor</p></figcaption></figure>

{% hint style="info" %}
**Regulatory basis — GDPR Art. 33(2)**

The Data Processor is required to notify any personal data breach to the Data Controller **without undue delay** after becoming aware of it. There is no obligation for the Processor to notify the supervisory authority directly — that obligation rests with the Data Controller.
{% endhint %}

***

## Form differences in Data Processor mode

When the **Data Processor** role is selected:

| Element                                          | DC mode       | DP mode                            |
| ------------------------------------------------ | ------------- | ---------------------------------- |
| Supervisory authority notification step          | ✅ Shown       | ❌ Hidden                           |
| Communication to data subjects section           | Standard      | Replaced by DP section (see below) |
| Communication to Data Controller clients section | ❌ Not present | ✅ Present                          |

***

## Communication to Data Controller clients

In Data Processor mode, a dedicated section replaces the standard communication section. It allows you to:

* **Associate the Data Controller clients** involved in the incident — the list can be automatically synchronised from the processing activities linked to the incident
* **Track the notification status** of each DC (notified / pending)
* **Export the list** of involved DCs for your compliance file

<figure><img src="https://2697025545-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LvBxs22wUMicv9uWp6C-1972196547%2Fuploads%2Fgit-blob-ccc7ed991fb9e03442a3b421d154ca78f89defcd%2Fviolations-subprocessor-communication-dc.png?alt=media" alt="Communication to Data Controllers section in a Data Processor incident"><figcaption><p>The Data Controllers tab lists the DCs to notify, with the Attach, Sync, and Export buttons</p></figcaption></figure>

### Automatic synchronisation of DCs from linked processing activities

If processing activities are associated with the incident, Dastra can automatically identify the relevant Data Controller clients from those activities and add them to the notification list. Click **Sync Data Controllers** in the dedicated section to trigger this synchronisation.

***

## Best practices

* Notify your DC clients **without undue delay** as soon as you become aware of the incident — the GDPR does not set a fixed deadline for the Processor's notification to the Controller (unlike the 72-hour deadline imposed on Controllers towards the supervisory authority), but prompt action is essential.
* Document the date and time of each notification sent to DCs in the dedicated section.
* Keep a record of acknowledgements or responses from DCs in the incident attachments.


---

# 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://doc.dastra.eu/en/features/notifier-les-violations-de-donnees/incidents-as-data-processor.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.