> For the complete documentation index, see [llms.txt](https://template.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://template.ishare.eu/business-and-organisational-building-blocks/governance-building-blocks/governance-design-layers.md).

# Governance Design Layers

Before defining the already mentioned governance building blocks, it is recommended to first establish a clear understanding of how governance needs to be structured and what it should enable. The suggested layered approach below supports the design of an evolving governance structure, capable of adapting as the data space matures while maintaining clear responsibilities for strategic direction, operational execution, stakeholder participation, and independent oversight.\
\
Governance frameworks are typically developed iteratively, based on existing best practices, example governance models and continuous input from stakeholders. For this reason, in this iSHARE Data Space Template, there is not only a suggested co-creation methodology, including some guiding questions that stakeholders can utilise, but also the below suggested design layers that you can follow. 

Layer One draws insights from governance models from other European data spaces, like GDDS, EMDS, CEEDS, ETDS, Catena-X, EBSI, ToIP/DC4EU, AgriDataSpace, DS4SSCC, Health-X, and EMREX. It concludes 9 main Design principles that Data Space Governance should follow when created. The second layer is derived from stakeholder input and from the requirements directly defined in the data space itself. This can differ per data space.

Applying a layered governance approach helps to:

* ensure alignment between stakeholders,
* support a successful governance design,
* reduce complexity,
* support a structured path towards implementation and scaling,
* and enable transparency and accountability, meanwhile.

Within iSHARE, this approach is supported as a practical way to design and implement governance. It provides a solid foundation that can be reused and adapted across different data spaces, while ensuring consistency with common principles and frameworks.

### **Layer 1 – Governance Design Principles**

This layer outlines the core principles that underpin any robust data space governance model.

{% tabs %}
{% tab title="1" %}

#### 01. Governance as the foundation 

The "soft infrastructure" that enables trust and balances interests. 

Governance acts as the defining element of a data space, enabling trust between participants, balancing public and private interests, and aligning legal, technical, business, and ethical dimensions.

* Enables trust between participants
* Balances public and private interests
* Supports scalability and sustainability
* Enables secure, sovereign data exchange
  {% endtab %}

{% tab title="2" %}

#### 02. Multi-layer governance structure 

Four nested layers from ecosystem to participant level.

Effective data spaces consistently apply a layered approach spanning from broad ecosystem alignment down to individual participant obligations.

* Ecosystem: cross-space alignment
* Data space governance: core rules
* Use case/domain: context-specific
* Participant: access, rights, obligations
  {% endtab %}

{% tab title="3." %}

#### 03. Role of governance authorities 

A facilitator and steward, not an overly centralised controller.

A governance authority is essential but should act as a facilitator or steward, often complemented by delegated or federated governance structures.

* Maintains and enforces the rule framework
* Defines participation conditions
* Ensures regulatory compliance
* Oversees trust and interoperability

It does not replace public enforcement authorities.
{% endtab %}

{% tab title="4." %}

#### 04. Subsidiarity and federation 

Decisions taken at the lowest appropriate level. 

Governance should follow the principle of subsidiarity, escalation occurs only when broader coordination is required, enabling flexibility and bottom-up feedback.

* Flexibility across domains
* Bottom-up feedback loops
* Coexistence of multiple models
  {% endtab %}

{% tab title="5." %}

#### 05. Trust as a core element 

Addressed both technically and organisationally.

Trust frameworks should combine technology (credentials, policies) with governance processes such as audits and accountability mechanisms.

* Identity and credential management
* Verification mechanisms
* Access control policies
* Trust registries and oversight
  {% endtab %}

{% tab title="6." %}

#### 06. Data Space Rulebooks as Key Instruments 

The primary governance artefact is modular and versioned.

Best practices include modular design and clear separation between baseline and domain-specific rules.

* Defines roles, rights, and obligations
* Mandatory vs optional rules
* Integrates legal requirements
* Evolves through structured versioning
  {% endtab %}

{% tab title="7." %}

#### 07. Separation of governance and operations 

Governing entity and operating entity are kept distinct.

A clear distinction between the governing entity (rules, oversight) and the operating entity (execution, daily operations) avoids conflicts of interest and enables scalability.

* Avoids conflicts of interest
* Enables scalability
* Supports outsourced operations
  {% endtab %}

{% tab title="8." %}

#### 08. Inclusivity and balance 

Fair representation, transparency, and accountability. 

Voting structures and board composition should prevent dominance by single actors and ensure fair representation of all stakeholders, including smaller participants.

* Fair stakeholder representation
* Inclusion of smaller participants
* Balance of public and private interests
* Transparency and accountability
  {% endtab %}

{% tab title="9." %}

#### 09. Evolution over time 

Designed as an evolving system, not a rigid structure. 

Governance typically progresses through formation, operation, improvement, and long-term sustainability. Overly rigid or premature structures should be avoided.

1. Initial formation phase
2. Operational phase
3. Continuous improvement
4. Long-term sustainability
   {% endtab %}

{% tab title="10." %}

#### Key implications and requirements

A governance framework should satisfy all of the following design requirements.

* Be multi-layered and federated
* Clearly define Governance Authorities and delegated scopes
* Embed a Trust Framework (technical + organisational)
* Separate governance from operations
* Enable subsidiarity and bottom-up feedback
* Use a modular, evolving Rulebook
* Ensure inclusive, balanced representation
  {% endtab %}
  {% endtabs %}

*Editor’s note: This section synthesises governance principles derived from analysis of existing European data space initiatives and reference frameworks. It informs the design of the Data Space Governance Framework but does not prescribe a fixed organisational structure.*

### **Layer 2 – Governance Capabilities (Operational Perspective)**

This layer defines what governance should enable within a data space from an operational perspective.

{% columns %}
{% column width="41.66666666666667%" %}
**Governance capabilities should be derived from:**

* the specific use cases,
* the needs of participating organisations,
* and the operational context of the data space.
  {% endcolumn %}

{% column width="58.33333333333333%" %}
**These capabilities may include, for example:**

* participant onboarding and offboarding,
* access and usage control,
* compliance monitoring,
* dispute resolution,
* lifecycle management of rules and policies,
* coordination across domains and stakeholders.
  {% endcolumn %}
  {% endcolumns %}

*Editor's Note: This section should be informed by the Data Space itself, including the use cases and the participants who are designing the data spaces. They can provide/ should provide their specific, governance related requiremnts here.*

### **Examples:**

{% stepper %}
{% step %}

### Trust and Assurance for Data Providers

The Governance Framework shall provide enforceable trust, control, and accountability mechanisms that allow Data Providers to confidently offer their data, retain data sovereignty, and rely on both Data Space–level and DSG-level governance arrangements.
{% endstep %}

{% step %}

### Clear Participation and Onboarding Paths

The Governance Framework shall define clear participation categories and onboarding paths, including Anonymous Users, pre-registered users, Participants, and cross-data-space users, enabling all users to understand what is required to participate (trust, governance and onboarding requiremnets) and what capabilities are available at each stage. This will also allow Cross- Data spcae accessibility, and Graduated Access for Non-Onboarded Users.
{% endstep %}

{% step %}

### Attribute- and Role-Based Access Governance

The Governance Framework shall support access control based on participant attributes, roles, group membership, and declared purposes, enabling fine-grained and policy-driven data access.
{% endstep %}
{% endstepper %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://template.ishare.eu/business-and-organisational-building-blocks/governance-building-blocks/governance-design-layers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.