> 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-no/cerrix-funksjoner/module-overview/incidents/incidents-standing-data-and-emails.md).

# Avvik Grunndata & e-poster

Funksjonaliteten for Avvik Grunndata i CERRIX gjør det mulig for brukere å definere og administrere gjenbrukbare datakomponenter som brukes når avvik opprettes og håndteres. Denne funksjonen gir fleksibilitet, kontroll og tilpasning skreddersydd til Organisasjonens spesifikke behov for avvikshåndtering.

Denne dokumentasjonen forklarer hvordan du administrerer Avvik Grunndata, inkludert klassifiseringer, avvikstyper, egendefinerte felt og e-postvarsler i CERRIXs modul for avvikshåndtering.

{% hint style="info" %}
**Videoopplæring**

Foretrekker du å se i stedet for å lese? Ta en titt på vår [Videoveiledninger](/cerrix-documentation-no/beste-praksiser-og-guider/video-tutorials.md#incidents) Videoveiledninger
{% endhint %}

***

## Åpne Avvik Grunndata

Avvik Grunndata administreres i **Grunndata**.

1. Gå til **Grunndata** i hovedmenyen.
2. Åpne **Avvik**.
3. Velg **Klassifisering** eller **Avvikstyper**.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-5c8269cfd2b4f7ca63ee0e80f9e4d57d9152b008%2Fscreenshot%20incidents%20standing%20data.png?alt=media" alt=""><figcaption></figcaption></figure>

***

## Administrere klassifiseringer

Klassifiseringer definerer alvorlighets- eller hastegraden for et avvik (for eksempel: Lav, Middels, Høy).

#### Slik administrerer du klassifiseringer:

1. I **Grunndata** menyen velger du **Klassifisering**.
2. endre eller legge til nye klassifiseringer:
   * Endre navnet på eksisterende klassifiseringer.
   * Bruk en fargekode for raskt å visualisere alvorlighetsgraden.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-2af99ce008daa6ff9018cb2fd04d71da0bafa7fc%2Fimage%20(16).png?alt=media" alt=""><figcaption></figcaption></figure>

***

## Administrere avvikstyper

Avvikstyper lar deg definere og tilpasse datafeltene som trengs spesielt når brukere registrerer avvik.

#### Opprette en avvikstype

Slik oppretter du en ny avvikstype:

1. I **Grunndata**, klikk på **Avvikstyper**.
2. Velg **Legg til**.
3. Angi et beskrivende navn for tydelig å identifisere avvikstypen.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-2f7ba0e0e524f33a07f4af2987b7d9007705f95d%2Fimage%20(17)%20copy.png?alt=media" alt=""><figcaption></figcaption></figure>

### Legge til egendefinerte felt

Du kan legge til egendefinerte felt i enhver ny avvikstype:

1. **Opprett seksjoner** for å gruppere egendefinerte felt logisk:
   * Gi seksjonene navn og omorganiser dem enkelt.
   * Fjern felt og seksjoner etter behov.
2. **Legg til felt** innenfor seksjoner:
   * Felt kan konfigureres etter:
     * Felttype: Tekstfelt, tekstområde, dato, dato og klokkeslett, tall, avkrysningsboks, nedtrekksliste med enkeltvalg, nedtrekksliste med flervalg, økonomisk konsekvens.
     * Navn
     * Plassholder (valgfritt)
     * Veiledningstekst (valgfritt)
     * Synlighetsstatus (synlig/skjult)
     * Kravstatus (obligatorisk/valgfri)
   * Juster om feltene er obligatoriske eller valgfrie.

**Eksempler på å legge til egendefinerte felt:**

* **Tekstområdefelt:** Gi åpne tekstinntastinger.
* **Nedtrekksliste med enkeltvalg:** La brukerne velge fra en forhåndsdefinert liste. Farger kan eventuelt tilordnes hvert valg.
* **Økonomisk konsekvens:** Numeriske data eller spesifikke verdier tilpasset dine behov for avviksrapportering.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-a52be8dcb1447fecf486edc28278b0af5c562858%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

### Konfigurere e-postvarsler

Avvikstyper kan utløse varsler til bestemte mottakere ved opprettelse.

Slik konfigurerer du varsler per avvikstype:

1. Velg avvikstypen din.
2. Naviger til **Konfigurasjon** fanen.
3. Legg til e-postadresse(r) for mottakere som skal varsles når et avvik av denne typen opprettes.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-ea706f7e76b3010b67e224055ba1e49476613477%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

***

### Praktisk eksempel: legge til et ekstra datofelt i en avvikstype

Anta at mange av avvikene dine skjer hos tredjeparter, og at du ved siden av standarddatoene (for eksempel dato for hendelsen og dato for oppdagelse) også ønsker å registrere datoen da avviket ble meldt til deg av den eksterne parten. Du kan fange dette opp ved å utvide en av dine egne avvikstyper med et egendefinert **Dato** felt:

1. Logg inn som administrator og gå til **Grunndata** > **Avvik** > **Avvikstyper**.
2. Åpne avvikstypen du vil utvide, eller opprett en ny via **Legg til**.
3. I den aktuelle seksjonen legger du til et nytt felt og velger **Dato** som felttype.
4. Gi feltet et tydelig navn (for eksempel «Dato rapportert av ekstern part»), legg eventuelt til veiledningstekst, og angi om feltet er obligatorisk.
5. Lagre avvikstypen. Det nye datofeltet er nå en del av skjemaet hver gang et avvik av denne typen registreres.

De samme skjermbildene sørger for at avvikstypene dine er tilpasset endrede (regulatoriske) rapporteringskrav: når som helst kan du endre felt, gi et felt nytt navn eller legge til nye svaralternativer i et nedtrekksfelt i en avvikstype Organisasjonen din administrerer.

## Feltet for rotårsaks-kategori

På detaljfanen for hvert avvik finner du **Rotårsaks-kategori** feltet, en nedtrekksliste for å klassifisere den underliggende årsaken til avviket. Feltet deles med Risiko-modulen: begge modulene bruker nøyaktig det samme feltet og det samme nedtrekktreet for Grunndata, slik at én taksonomi kan brukes for både risikoene og avvikene dine.

Feltet het tidligere **Hendelseskategori**. Fordi de fleste organisasjoner faktisk bruker det til å registrere rotårsaks-kategorier, ble det omdøpt til Rotårsaks-kategori — først i Avvik-modulen, og deretter i Risiko-modulen, slik at begge modulene nå bruker samme navn for det samme feltet. Med navneendringen ble feltet også **flervalg**: du kan koble flere rotårsaks-kategorier til ett avvik eller én risiko, siden mer enn én rotårsak kan ligge til grunn.

### Bygge kategoritreet ditt

En vanlig måte å organisere treet på er en taksonomi for rotårsaker på to nivåer, for eksempel:

| Nivå 1    | Nivå 2 (eksempler)                        |
| --------- | ----------------------------------------- |
| Mennesker | Ondsinnethet, mangelfulle ansvarsforhold  |
| Prosess   | Designsvikt, endringsstyring              |
| Eksternt  | Regelverk / lovgivning, katastrofe        |
| Systemer  | Feilkonfigurasjon, utilstrekkelig testing |

Ved siden av dette kategoriske feltet på detaljfanen tilbyr fanen for operasjonelle avvik **Årsaksbeskrivelse** og **Sekundær årsak** feltene for å registrere årsaken til det spesifikke avviket, slik at kategoritreet kan forbli kompakt og gjenbrukbart.

### Bruke andre klassifiseringsordninger

Siden treet deles med Risiko-modulen, fungerer det best når det er dedikert til reelle rotårsaker. Klassifiseringsordninger som Basel II Hendelsestyper er bedre fanget opp et annet sted: modeller dem som **avvikstyper** i Avvik-modulen, og i Risiko-modulen som en **risikokatalog** (underkategorifeltet i katalogen kan inneholde detaljer på nivå 2, som *Operasjonell Risiko – intern svindel*, i tråd med oppsett som ORX-referansetaksonomien) eller som et dedikert **egendefinert felt**. Eksisterende kategoriverdier kan flyttes over som del av en slik endring — ta kontakt med CERRIX-brukerstøtte via servicedesken for å planlegge dette sammen.

## Standardiserte (innebygde) avvikstyper

CERRIX tilbyr to forhåndsdefinerte avvikstyper for vanlige brukstilfeller:

* **Operasjonelt avvik**
* **Personvernbrudd**

Disse innebygde avvikstypene:

* Kan ikke redigeres eller slettes.
* Sikrer kompatibilitet med forhåndsetablerte skjemaer og rapporteringsstrukturer.
* Beholder eksisterende datakoblinger og integrasjonspunkter.

> **Viktig:** Egendefinerte felt kan ennå ikke legges til standardtyper (f.eks. Personvernbrudd). Denne forbedringen vil imidlertid være tilgjengelig i fremtidige oppdateringer.

### DORA-avvikstyper

Som en del av CERRIXs støtte for Digital Operational Resilience Act (DORA) er det nå tilgjengelig et standardisert sett med DORA-spesifikke avvikstyper. Disse avvikstypene er tilpasset rapporteringsforpliktelsene under DORA og er utformet for å hjelpe organisasjoner med effektivt å spore og rapportere større IKT-relaterte avvik.

#### Oversikt

DORA-avvikstypene leveres som en forhåndsdefinert mal i systemet. Disse er separate fra dine egendefinerte avvikstyper og følger strukturen som kreves for DORA-kompatibel rapportering.

#### Tilgjengelig i følgende rapporttyper

DORA-avviksfeltene og strukturen er innebygd i tre forhåndsdefinerte rapporttyper:

* DORA første rapport
* DORA mellomrapport
* DORA sluttrapport

Disse malene sikrer at avviksrapporteringen er i tråd med regulatoriske forventninger gjennom hele avvikets livssyklus.

#### Nøkkelfunksjoner

* Standardisert struktur: Inkluderer alle feltene som kreves for DORA-rapportering (f.eks. avviksklassifisering, rotårsak, påvirkning, responstidslinje).
* Forhåndsutfylte feltetiketter: Bruker terminologi som er i tråd med regulatoriske retningslinjer for å sikre konsistens.
* Klar for integrasjon: Malene er strukturert for enkel integrasjon med eksterne DORA-rapporteringssystemer.

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-2841e12a051dd559520b173938fa177499240a54%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

## Sendte e-poster for avvik

Som administrator kan alle sendte e-poster vises via modulen «Mail Messages», under «Sendte e-poster» og deretter «Sendte e-poster for avvik».

<figure><img src="https://3330106213-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-7ad623061e292f57dfa0b6ece655143db1e2081c%2Fscreenshot%20incidents%20sent%20mails.png?alt=media" alt=""><figcaption></figcaption></figure>


---

# 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-no/cerrix-funksjoner/module-overview/incidents/incidents-standing-data-and-emails.md?ask=<question>&goal=<user_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.
