> 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/beste-praksiser-og-guider/implementation-guide.md).

# Implementeringsguide

På denne siden finner du omfattende instruksjoner og beste praksis for implementering av CERRIX-plattformen i din Organisasjon.

Dokumentet nedenfor er utformet for å hjelpe deg med å navigere gjennom hvert trinn i implementeringsreisen, fra innledende prosjektoppsett til go-live og løpende støtte. Det dekker:

* **Prosjektoppsett** – Definere implementeringsplanen, rollene og kommunikasjonsstrategien.
* **Konfigurasjon** – Strukturere og tilpasse CERRIX slik at det passer dine unike prosesser og rammeverk.
* **Datakvalitet og import** – Sørge for at dataene dine er korrekte, konsistente og klare til bruk i CERRIX.
* **Dashbord og rapportering** – Lage meningsfulle dashbord og rapporter for å overvåke ytelsen.
* **Akseptansetesting** – Teste systemet med dataene dine for å sikre at det oppfyller kravene dine.
* **Go live og støtte** – Forberede sluttbrukerne og sette opp støttestrukturer for en smidig lansering.
* **Evaluering** – Reflektere over implementeringsprosessen for å identifisere læringspunkter.

Enten du er prosjektleder, administrator eller interessent, vil denne guiden gi deg innsikten og strukturen du trenger for en vellykket CERRIX-implementering.

{% file src="/files/9c92d5b22ccfb5ddc2d8926578c6951637687945" %}

Hvis du har spørsmål eller trenger hjelp underveis, ikke nøl med å kontakte CERRIX-konsulenten din.

## Eksempler på konvensjoner og skåringsskalaer

Enighet om konvensjoner før de første Risiko og Kontrollene registreres holder registeret konsistent og sammenlignbart på tvers av avdelinger. Eksemplene nedenfor kommer fra CERRIX-implementeringer og kan tilpasses Organisasjonen din; legg inn de endelige skalaene i Grunndata slik at de tilbys for hver Risiko.

### Navngivning av Risiko og Kontroller

* **Risikonavn**: en negativ Hendelse pluss objektet den påvirker, for eksempel «Uautorisert tilgang til kundedatabasen».
* **Risikobeskrivelse**: «Risikoen for at \[Hendelse] inntreffer som følge av \[årsak], noe som resulterer i \[effekt]». Se [Bruk strukturen hendelse-årsak-virkning](https://docs.cerrix.com/cerrix-functionalities/module-overview/risks#use-event-cause-effect-structure).
* **Kontrollbeskrivelse**: svar på spørsmålene Hvem utfører Kontroll, Hva som sjekkes, Hvordan den utføres, Når og hvor ofte, Med hvilket input og output, og Hva som skjer når et avvik oppdages. Se [Kontrollkatalog](https://docs.cerrix.com/cerrix-functionalities/module-overview/controls/control-catalogue#description).

### Eksempel på sannsynlighetsskala

| Skår | Sannsynlighet    | Sannsynlighet |
| ---- | ---------------- | ------------- |
| 1    | Ubetydelig       | Under 10 %    |
| 2    | Begrenset        | 10 % til 50 % |
| 3    | Gjennomsnittlig  | Rundt 50 %    |
| 4    | Høy              | 50 % til 90 % |
| 5    | Svært sannsynlig | Over 90 %     |

### Eksempel på konsekvensskala

| Skår | Konsekvens      | Økonomisk tap                           |
| ---- | --------------- | --------------------------------------- |
| 1    | Svært liten     | Under EUR 50 000                        |
| 2    | Liten           | EUR 50 000 til EUR 100 000              |
| 3    | Gjennomsnittlig | EUR 100 000 til EUR 1 million           |
| 4    | Stor            | EUR 1 million til EUR 10 million        |
| 5    | Svært stor      | Over EUR 10 million, eller omdømmeskade |

Konsekvensskalaer kan også defineres per konsekvenstype, for eksempel finansiell, omdømmemessig og regulatorisk. Se [Egendefinerte konsekvensskalaer](https://docs.cerrix.com/cerrix-functionalities/module-overview/risks#custom-impact-scales).

### Eksempel på utfall av risikovurdering og tiltak

**Risikovurdering** (konklusjonen på nettoscoren):

* Godkjent
* Akseptabel
* Forbedring nødvendig over tid
* Ikke akseptert

**Risikobehandling**:

* Aksepter, og sett av budsjett for det potensielle tapet; noter hvorfor i kommentarene.
* Overfør eller forsikre.
* Reduser med Kontroller.
* Unngå ved å eliminere aktiviteten.

### Eksempel på Risikoområder og katalog

En to-nivå-taksonomi gjør rapporteringen håndterbar. Risikoområder grupperer katalogen på høyeste nivå, for eksempel Etterlevelse, Ekstern, Virksomhet, Kapital, Personer, Organisasjon, Prosesser og Systemer. Risikokatalogen under inneholder risikokategoriene, for eksempel integritetsrisiko, IT-risiko, juridisk Risiko, kredittrisiko, markedsrisiko, renterisiko, miljørisiko, operasjonell Risiko, outsourcingsrisiko, forsikringsrisiko og lover og regler.

### Eksempel på Workflow-roller

For enklere vedlikehold, gjør Risikoeieren eller prosesseieren til den **vurderer** som skårer og godkjenner Risikoen, og la Risikostyring fungere som den **Reviewer**. Dette holder første linje ansvarlig for innholdet, mens andre linje sikrer konsistens.


---

# 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/beste-praksiser-og-guider/implementation-guide.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.