> 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/library/frameworks/create-custom-framework.md).
# Create a custom framework
#### Introduction
Creating a custom framework makes it possible to build a compliance framework **adapted to the organization's specific context**: internal policy, sector-specific framework, AI initiative, security, quality or governance.
A custom framework can be:
* built **entirely from scratch**,
* or serve as a **common foundation** for several compliance projects.
***
### Step 1 β Creating the framework
{% columns %}
{% column %}
When creating a custom framework, the user defines:
* **The framework name** (e.g. *Custom AI*, *AI ISSP β Demo*)
* **The framework language**, which will determine the default language of the requirements and controls
Once created, the framework is added to the Library, in a **draft** state.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
***
### Step 2 β Viewing and available actions
By default, a newly created framework is:
* **empty**
* **read-only**
#### Actions available as long as the framework has not been modified
* **Export**: retrieve the framework in JSON / Excel format
* **Duplicate**: create a copy of the framework
* **Move to trash**: delete the framework
π **No addition or modification is possible until the framework is in edit mode.**
***
### Step 3 β Switching to edit mode
{% columns %}
{% column %}
To enrich the framework (chapters, requirements, controlsβ¦), it is necessary to:
1. Click on **Edit**
2. Switch the framework to **edit mode**
In edit mode, the user can:
* Create **chapters**
* Add **requirements**
* Progressively structure the framework
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
***
## Creating and structuring requirements
Once the framework has been created and switched to **edit mode**, the user can begin structuring the framework using **chapters** and **requirements**.\
This step makes it possible to translate a regulatory, normative or internal framework into elements that can be used in Dastra.
***
### Structuring by chapters
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
Chapters make it possible to organize the framework in a readable and coherent way.
{% endcolumn %}
{% endcolumns %}
#### Structuring rules
Dastra allows:
* **root chapters**
* **sub-chapters**
π The depth is intentionally limited to a **maximum of two levels** in order to:
* guarantee the readability of the framework
* avoid overly complex structures
* make it easier to use the requirements in compliance projects
#### Fields to fill in
When creating a chapter:
* **Reference**: internal identifier of the chapter
* **Name**: functional title of the chapter
{% hint style="info" %}
*Best practice*: use chapters to structure by major themes\
(e.g. governance, security, operations, usesβ¦).
{% endhint %}
***
### Creating a requirement
{% columns %}
{% column %}
Requirements express the **compliance expectations** the organization must meet.\
They constitute the direct link between the framework and the operational controls.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
#### Available fields
* **Reference (required)**\
Unique identifier of the requirement within the framework
* **Name (required)**\
Concise formulation of the requirement
* **Description (optional)**\
Details of the expected content, scope and objectives of the requirement
***
### AI assistance for the requirement reference
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
When creating a requirement, Dastra offers **AI assistance** to automatically generate a reference consistent with:
* the name of the requirement
* the parent chapter
* the context of the framework
{% endcolumn %}
{% endcolumns %}
π This feature makes it possible:
* to harmonize naming conventions
* to avoid inconsistencies or duplicates
* to save time when creating custom frameworks
The user remains free to modify the proposed reference.
***
### Organizing and managing requirements
Once created, requirements can be:
* moved to another chapter
* deleted
* progressively enriched
Each requirement also displays summary indicators (links with controls, risks, tests), making it easier to understand its level of coverage.
***
### Associating controls with a requirement
{% columns %}
{% column %}
Controls are the **operational** elements that make it possible to demonstrate compliance with one or more requirements.
To associate controls with a requirement, two approaches are possible.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
***
#### Option 1 β Associate existing controls
{% columns %}
{% column %}
The user can select one or more controls already present in the Library and attach them to the requirement.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
π A single control can be associated with **several requirements**, promoting:
* sharing
* consistency of the framework
* better traceability
***
#### Option 2 β Create or associate controls with AI
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
Dastra offers an AI assistance feature that makes it possible to:
* automatically identify **relevant existing controls**
* propose the **creation of new controls** when necessary
The AI relies on:
* the content of the requirement
* the context of the framework
* the controls already present in the Library
{% endcolumn %}
{% endcolumns %}
π Controls created via AI can automatically include:
* their description
* their attachment to the requirement
* the associated tests
***
### Benefits of this approach
This approach makes it possible to achieve:
* a **progressive structuring** of the framework
* **intentional overlaps** between requirements
* the creation of cross-cutting controls covering several requirements
* a solid basis for risk management and compliance projects
---
# 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/library/frameworks/create-custom-framework.md?ask=&goal=
```
`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.