> For the complete documentation index, see [llms.txt](https://frameworks.greendealdata.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://frameworks.greendealdata.eu/governnace-frameworks/gdds-rulebook/conformity-framework-and-governance-enforcement/2.-compliance-monitoring-and-governance-enforcement.md).

# 2. Compliance Monitoring & Governance Enforcement

This part corresponds to Stage 4 of the participation lifecycle. Compliance monitoring confirms that participants continue to meet their obligations throughout their participation, and governance enforcement provides a proportionate, transparent response when they do not. The GDDS approach follows the iSHARE Trust Framework "Warnings, Suspension and Exclusion" and "Incident Management" processes. 

## 2.1 Scope of monitoring 

Monitoring covers continued adherence to: 

* this Rulebook and the agreements signed on admission (e.g. Data Space Participant Agreement); 
* applicable technical and security requirements, and the validity of any required certification; 
* conduct within data transactions, consistent with the data usage policies set by Data Providers. 

Monitoring responsibilities are suggested to be exercised by the governance authority responsible for compliance oversight, supported by the GDDS Operator for technical execution. Any participant may report suspected non-compliance, adapting the established practice in the iSHARE Trust Framework. Reported non-compliance is classified by the responsible compliance authority according to the severity model above, and the corresponding enforcement path is applied. 

{% hint style="warning" %}
*Note (open): The monitoring cadence, whether compliance is verified continuously, through periodic attestation, or on an event-driven basis, was not resolved. The proportionality of continuous monitoring and whether periodic evaluation would be sufficient were asked about; WP3 noted that the technical direction for monitoring features is not yet finalised. To be resolved with WP3 and the technical group. The identity of the formal compliance/enforcement authority (DSGA, the Compliance & Ethics Committee, or the Operator) also remains to be confirmed.* 
{% endhint %}

***

## 2.2 Reporting and roles 

Three roles participate, mirroring the iSHARE Trust Framework model: 

* Reporting party — any participant or body may report suspected non-compliance. 
* Participant concerned — responsible for acting in accordance with the Rulebook, especially after a notification or warning. 
* Designated compliance authority (the “steering” function) — assesses reports, classifies the non-compliance, and decides on enforcement action. 

At the time being, it is proposed that the GDDS governance body that performs the “steering” / compliance authority function is the DSGA, alongside the Compliance & Ethics Committee (which already manages escalation pathways for non-compliance); technical execution (e.g. registry status changes) is carried out by the GDDS Operator; and domain-level coordination is provided by the relevant DSG Orchestrator. 

***

## 2.3 Classification of non-compliance 

Non-compliance is suggested to be classified to ensure the response is proportionate to the severity: 

| Classification | Indicative criteria (non-exhaustive)                                                                                                                                 |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Minor          | Breach of admission criteria or service levels; an expired security certification; a minor data-security breach;                                                     |
| Major          | Recurring or combined minor breaches; a serious impediment to other participants; a reportable data breach; impact on confidentiality or integrity; suspected fraud. |
| Critical       | Recurring major breaches; a network-wide impediment; impact on the integrity of the trust framework.                                                                 |

{% hint style="info" %}
*Note: The table above is the first draft and it might be updated with additional points as criteria.*
{% endhint %}

{% hint style="warning" %}
*Note (decided, Co-Creation Session 10, 11 June 2026): The three-tier severity model (minor / major / critical) for non-compliance was formally adopted. A participant of WP4 and UC flagged that suspected fraud must not be treated as minor; such cases are to trigger an immediate critical response.* 

*The detailed mapping of concrete non-compliance scenarios to severity levels and operational response paths is to be developed in a dedicated incident-scenario matrix (action: WP4, with IT-security enforcement inputs from UC1 lead).*  

*Note: In WP4 Cocreation session 12, the following questions/ suggestions came up: In cases of major or critical breaches of EU law, should the Supervisory Board – possibly with support from the Compliance and Ethics Committee – notify the competent supervisory authority?*

*Should we introduce a form of voluntary self-reporting, allowing participants to acknowledge and correct breaches within a short timeframe – for example, within 15 days – possibly through a formal procedure?*
{% endhint %}

***

## 2.4 Related incidents 

Where non-compliance cause or coincides with an operational incident, the Incident Management process is initiated in parallel. Incidents are suggested to be classified as follows: 

| Classification | Indicative criteria (non-exhaustive)                                                                                     |
| -------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Minor incident | Limited unavailability; a contained (potential) data-security event; suspected fraud.                                    |
| Calamity       | Three or more participants involved; a serious impediment to others; a reportable data breach.                           |
| Crisis         | Ten or more participants involved; serious reputational or legal impact; a fundamental legal or technical vulnerability. |

{% hint style="info" %}
 *Note: The table above is the first draft and it might be updated with additional points as criteria.*
{% endhint %}

A clear distinction is suggested to consider between the formal non-compliance governance workflow described in this section and the operational response to IT-security and infrastructure emergencies. Security breaches, intrusions, and infrastructure failures require fast, decisive, and, where possible, automated damage-limitation responses; these are handled through a separate operational emergency-response process and are not subject to the notification-and-deadline sequence applied to governance non-compliance. The governance workflow may be invoked subsequently, where an emergency also constitutes participant non-compliance. 

{% hint style="warning" %}
*Note (decided, Co-Creation Session 10, 11 June 2026): The principle of separating emergency IT and security-breach response from the formal non-compliance governance workflow was agreed, to preserve decisive operational action. The detailed emergency-response procedure, its triggers, and its interface with the governance workflow are to be defined with WP2/WP3 and IT-security inputs  from UC1 Lead.* 
{% endhint %}

***

## 2.5 Enforcement ladder 

Enforcement follows a graduated, proportionate sequence: 

1. Non-compliance is reported and classified by the responsible compliance authority. 
2. The participant is notified of the non-compliance and, where rectification is possible, is given a defined deadline to remedy it. 
3. Persistent or unremedied non-compliance is upscaled to the next severity level; a final warning may be issued. 
4. Continued breach, or critical non-compliance, leads to suspension and, ultimately, to revocation or exclusion (see section[ 3 Suspension, Revocation & Voluntary Withdrawal](/governnace-frameworks/gdds-rulebook/conformity-framework-and-governance-enforcement/3.-suspension-revocation-and-voluntary-withdrawal.md)). 

The measures applied along this ladder are: 

* Warning — a cautionary notice stating the non-compliance, the rectification required, and the deadline. 
* Suspension — temporary deactivation of the participant’s credentials (the Participant Registry status is set to suspended) until the issue is rectified. 
* Exclusion / revocation — permanent deactivation of credentials, termination of the participation agreement, and a network-wide notice for information purposes. 

 It is suggested that enforcement measures are granular: rather than immediate full exclusion, the compliance authority may limit specific roles, credentials, or privileges of a participant to address the non-compliance while minimising the impact on downstream users who depend on that participant’s data or services. 

{% hint style="warning" %}
*Note (decided,  Co-Creation Session 10, 11 June 2026): A granular suspension approach was suggested, enforcement may restrict specific roles or credentials rather than removing a participant entirely, to protect downstream users. The triggers and timelines for upscaling between severity levels remain to be specified in the incident-scenario matrix.* 
{% endhint %}

***

## 2.6 Right to be heard 

Before a measure takes effect, the participant has a right to contest it. Adapting the iSHARE Trust Framework mechanism: the participant may communicate disagreement with a notification or warning within five working days; the compliance authority must reply within five working days; and the participant is given a further five working days to respond. This contest mechanism also informs the appeal route at onboarding (see [Trust & Participation Governance, Stage 2, 2.4 Rejection and Appeal Procedure](https://frameworks.greendealdata.eu/governnace-frameworks/gdds-rulebook/conformity-framework-and-governance-enforcement/pages/avGomnX3T3GqU5nalrhZ#id-2.3-rejection-and-appeal-procedure)).