> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-nl/cerrix-functionaliteiten/module-overview/incidents/incidents-standing-data-and-emails.md).
# Incidenten Basisgegevens & e-mails
De Incident Basisgegevens-functionaliteit in CERRIX stelt gebruikers in staat herbruikbare gegevenscomponenten te definiëren en te beheren die worden gebruikt bij het aanmaken en afhandelen van incidenten. Deze functie biedt flexibiliteit, Beheersmaatregel en maatwerk, afgestemd op de specifieke incidentbeheerbehoeften van uw Organisatie.
Deze documentatie legt uit hoe u Incident Basisgegevens beheert, inclusief classificaties, incidenttypen, aangepaste velden en e-mailmeldingen in de Incidentbeheermodule van CERRIX.
{% hint style="info" %}
**Videotutorial**
Wilt u liever kijken dan lezen? Neem eens een kijkje bij onze [Videotutorials](/cerrix-documentation-nl/best-practices-en-handleidingen/video-tutorials.md#incidents) Videotutorials
{% endhint %}
***
## Toegang tot Incident Basisgegevens
Incident Basisgegevens worden beheerd in **Basisgegevens**.
1. Navigeer naar **Basisgegevens** in het hoofdmenu.
2. Open **Incidenten**.
3. Selecteer **Classificatie** of **Incidenttypen**.
***
## Classificaties beheren
Classificaties definiëren het ernst- of urgentieniveau van een Incident (bijvoorbeeld: Laag, Gemiddeld, Hoog).
#### Om classificaties te beheren:
1. Binnen de **Basisgegevens** menu, selecteer **Classificatie**.
2. Wijzig of voeg nieuwe classificaties toe:
* Wijzig de naam van bestaande classificaties.
* Pas een kleurcodering toe om de ernst snel te visualiseren.
***
## Incidenttypen beheren
Incidenttypen stellen u in staat de gegevensvelden te definiëren en aan te passen die specifiek nodig zijn wanneer gebruikers incidenten registreren.
#### Een Incidenttype maken
Om een nieuw incidenttype te maken:
1. Binnen **Basisgegevens**, klik op **Incidenttypen**.
2. Selecteer **Toevoegen**.
3. Voer een beschrijvende naam in om het Incidenttype duidelijk te identificeren.
### Aangepaste velden toevoegen
U kunt aangepaste velden aan elk nieuw incidenttype toevoegen:
1. **Secties maken** om aangepaste velden logisch te groeperen:
* Geef secties eenvoudig een naam en herschik ze.
* Verwijder velden en secties indien nodig.
2. **Velden toevoegen** binnen secties:
* Velden kunnen worden geconfigureerd op basis van:
* Veldtype: tekstveld, tekstvak, datum, datum-tijd, getal, selectievakje, keuzelijst met één selectie, keuzelijst met meerdere selecties, financiële impact.
* Naam
* Plaatsaanduiding (optioneel)
* Instructietekst (optioneel)
* Zichtbaarheidsstatus (zichtbaar/verborgen)
* Verplichte status (verplicht/optioneel)
* Pas aan of velden verplicht of optioneel zijn.
**Voorbeelden van het toevoegen van aangepaste velden:**
* **Tekstvakveld:** Bied vrije tekstinvoer aan.
* **Keuzelijst met één selectie:** Laat gebruikers kiezen uit een vooraf bepaalde lijst. Aan keuzes kunnen optioneel kleuren worden toegewezen.
* **Financiële impact:** Numerieke gegevens of specifieke waarden, afgestemd op uw behoeften voor incidentrapportage.
### E-mailmeldingen configureren
Incidenttypen kunnen bij aanmaak meldingen activeren voor specifieke ontvangers.
Om meldingen per incidenttype te configureren:
1. Selecteer uw incidenttype.
2. Navigeer naar de **Configuratie** tabblad.
3. Voeg e-mailadres(sen) toe voor ontvangers die een melding nodig hebben wanneer een Incident van dit type wordt aangemaakt.
***
### Uitgewerkt voorbeeld: een extra datumveld toevoegen aan een incidenttype
Stel dat veel van uw incidenten bij derden plaatsvinden, en dat u naast de standaarddatums (zoals de datum van het incident en de datum van detectie) ook wilt vastleggen op welke datum het Incident door de externe partij aan u is gemeld. U kunt dit vastleggen door een van uw eigen incidenttypen uit te breiden met een aangepaste **Datum** veld:
1. Meld u aan als beheerder en navigeer naar **Basisgegevens** > **Incidenten** > **Incidenttypen**.
2. Open het incidenttype dat u wilt uitbreiden, of maak via **Toevoegen**.
3. Voeg binnen de juiste sectie een nieuw veld toe en selecteer **Datum** als veldtype.
4. Geef het veld een duidelijke naam (bijvoorbeeld "Datum gemeld door externe partij"), voeg desgewenst instructietekst toe en stel in of het veld verplicht is.
5. Sla het incidenttype op. Het nieuwe datumveld maakt nu deel uit van het formulier telkens wanneer een Incident van dit type wordt geregistreerd.
Met dezelfde schermen houdt u uw incidenttypen afgestemd op veranderende (regelgevende) rapportagevereisten: u kunt op elk moment velden wijzigen, een veld een nieuwe naam geven of nieuwe antwoordopties toevoegen aan een keuzelijstveld van een incidenttype dat uw Organisatie beheert.
## Het veld Categorie voor grondoorzaak
Op het detailtabblad van elk Incident vindt u het **Categorie voor grondoorzaak** veld, een keuzelijst om de onderliggende oorzaak van het Incident te classificeren. Het veld wordt gedeeld met de Risico-module: beide modules gebruiken exact hetzelfde veld en dezelfde Basisgegevens-keuzelijstboom, zodat één taxonomie zowel uw Risico's als incidenten bedient.
Het veld heette eerder **Gebeurteniscategorie**. Omdat de meeste Organisatie's dit veld feitelijk gebruiken om categorieën voor grondoorzaken te registreren, is het hernoemd naar Categorie voor grondoorzaak — eerst in de Incidenten-module en vervolgens in de Risico-module, zodat beide modules nu dezelfde naam voor hetzelfde veld gebruiken. Door de hernoeming werd het veld ook **meervoudige selectie**: u kunt meerdere categorieën voor grondoorzaken koppelen aan één incident of Risico, omdat er meer dan één grondoorzaak aan ten grondslag kan liggen.
### Uw categorieboom opbouwen
Een veelgebruikte manier om de boom te organiseren is een taxonomie voor grondoorzaken met twee niveaus, bijvoorbeeld:
| Niveau 1 | Niveau 2 (voorbeelden) |
| -------- | ------------------------------------------ |
| Personen | Opzet, Ineffectieve verantwoordelijkheden |
| Proces | Ontwerpfout, verandermanagement |
| Extern | Regelgeving / wetgeving, ramp |
| Systemen | Verkeerde configuratie, onvoldoende testen |
Naast dit categorische veld op het detailtabblad biedt het operationele incidenttabblad de **Omschrijving van de oorzaak** en **Secundaire oorzaak** velden om de oorzaak van het specifieke incident vast te leggen, zodat de categorieboom compact en herbruikbaar kan blijven.
### Andere classificatieschema's gebruiken
Omdat de boom wordt gedeeld met de Risico-module, werkt deze het best wanneer hij is gewijd aan echte grondoorzaken. Classificatieschema's zoals Basel II-Gebeurtenistypen kunt u beter op een eigen plek vastleggen: modelleer ze als **incidenttypen** in de Incidenten-module, en in de Risico-module als een **Risico-catalogus** (het veld voor catalogussubtype kan detail op niveau 2 bevatten, zoals *Operationeel Risico – interne fraude*, volgens opzetten zoals de ORX-referentietaxonomie) of als een toegewijd **aangepast veld**. Bestaande categoriewaarden kunnen als onderdeel van zo'n wijziging worden overgezet — neem via de servicedesk contact op met CERRIX-support om dit samen te plannen.
## Standaard (ingebouwde) incidenttypen
CERRIX biedt twee vooraf gedefinieerde incidenttypen voor veelvoorkomende use-cases:
* **Operationeel Incident**
* **Datalek**
Deze ingebouwde incidenttypen:
* Kunnen niet worden bewerkt of verwijderd.
* Garanderen compatibiliteit met vooraf vastgestelde formulieren en rapportagestructuren.
* Behouden bestaande datakoppelingen en integratiepunten.
> **Belangrijk:** Aangepaste velden kunnen nog niet worden toegevoegd aan standaardtypen (bijv. Datalek). Deze uitbreiding zal echter beschikbaar zijn in toekomstige updates.
### DORA-incidenttypen
Als onderdeel van CERRIX's ondersteuning voor de Digital Operational Resilience Act (DORA) is nu een gestandaardiseerde set DORA-specifieke incidenttypen beschikbaar. Deze incidenttypen sluiten aan bij de rapportageverplichtingen onder DORA en zijn bedoeld om Organisatie's te helpen grote ICT-gerelateerde incidenten effectief te volgen en te rapporteren.
#### Overzicht
De DORA-incidenttypen worden in het systeem aangeboden als een vooraf gedefinieerde sjabloon. Deze staan los van uw aangepaste incidenttypen en volgen de structuur die vereist is voor DORA-conforme rapportage.
#### Beschikbaar in de volgende rapportagetypen
De DORA-incidentvelden en -structuur zijn ingebed in drie vooraf gedefinieerde rapportagetypen:
* DORA-initiële rapportage
* DORA-tussenrapportage
* DORA-eindrapportage
Deze sjablonen zorgen ervoor dat incidentrapportage gedurende de gehele incidentlevenscyclus aansluit op de verwachtingen van de toezichthouder.
#### Belangrijkste kenmerken
* Gestandaardiseerde structuur: bevat alle velden die nodig zijn voor DORA-rapportage (bijv. incidentclassificatie, grondoorzaak, impact, responstijdlijn).
* Vooraf ingevulde veldlabels: gebruikt terminologie die aansluit bij de richtlijnen van toezichthouders om consistentie te waarborgen.
* Integratieklaar: sjablonen zijn zo gestructureerd dat ze eenvoudig kunnen worden geïntegreerd met externe DORA-rapportagesystemen.
## Verzonden incidentmails
Als beheerder kunnen alle verzonden mails worden bekeken via de module 'Mail Messages', onder 'Sent mails' en vervolgens 'Incident sent mails'.
---
# 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://docs.cerrix.com/cerrix-documentation-nl/cerrix-functionaliteiten/module-overview/incidents/incidents-standing-data-and-emails.md?ask=&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.
.png?alt=media)
%20copy.png?alt=media)
