> 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/compliance/projects/implement.md).

# Project implementation

It consists of **configuring the controls concretely**, defining the verification methods and preparing the collection of evidence.

At this stage, the project already has:

* its frameworks,
* its controls,
* its tests and risks initialized during the design phase.

***

### 🎯 Objective of the phase

The objective of the implementation phase is to:

* define **how the controls are verified**,
* configure the **tests (manual or automated)**,
* associate the **risks with the controls**,
* prepare the **collection of compliance evidence**.

***

### 1. Understanding the status of tests during the implementation phase

By default, all the project's tests are in the **"Missing evidence"** status.

This means that:

* the control exists,
* the test is defined,
* but **no evidence has yet been provided or collected**.

👉 As long as the project is not in the **monitoring** phase, modifying or validating the evidence is not recommended.

<figure><img src="/files/ZtJyvW30vmpNoqidqQLn" alt=""><figcaption></figcaption></figure>

***

### 2. Configuring compliance tests

Each control can be verified using one or more **tests**.

{% columns %}
{% column %}
A test allows you to define:

* a **verification procedure**,
* an **execution frequency** (e.g. monthly, quarterly, annually),
* a **test owner**.

Tests can be:

* **manual**, requiring a human action and evidence,
* or **automated**, via a Dastra or custom connector.
  {% endcolumn %}

{% column %}

<figure><img src="/files/oT0NlCMa8NLISESy9JOe" alt=""><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

***

### 3. Associating and assessing risks

Controls can be linked to one or more **risks** in order to measure their impact on risk reduction.

For each risk, you can:

* define an **initial assessment** (probability × impact),
* define a **residual assessment**, after the controls are applied,
* choose the **risk treatment** (reduction, acceptance, etc.).

This approach makes it possible to concretely visualize the effect of the controls on the risk posture.

<figure><img src="/files/tG7PVO0mQhs488ycQojL" alt=""><figcaption></figcaption></figure>

***

### 4. Linking threats, risks and controls

**Threats** represent the concrete scenarios that can trigger a risk\
(e.g. injection of malicious data, lack of supervision, information exfiltration).

A threat can be:

* linked to one or more **risks**,
* indirectly covered by the **controls** put in place.

This chaining allows complete traceability:\
**Threat → Risk → Control → Test → Evidence**

***

### 5. Installing a connector to automate evidence

For certain tests, it is possible to install a **Dastra connector** in order to automate the collection of evidence.

Connectors make it possible, for example, to:

* verify the presence of a policy or a contract,
* query a registry (AI systems, incidents, processing activities),
* automate recurring controls without manual action.

Each connector is configured with:

* an **execution frequency**,
* **collection parameters** adapted to the test.

<figure><img src="/files/dfpAun5wCMwW9npz1pmC" alt=""><figcaption></figcaption></figure>

***

### 6. Result of the implementation phase

At the end of the implementation phase:

* the **controls are configured**,
* the **tests are ready to be executed**,
* the **risks are assessed and linked**,
* any **connectors are installed**.

The project is then ready to enter the next phase: **Monitoring**, during which:

* the tests are executed periodically,
* the evidence is collected,
* and compliance is measured over time.


---

# 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://doc.dastra.eu/en/features/compliance/projects/implement.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.