> 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/control-design-and-implementation-execution-and-effectiveness-testing-whats-the-difference.md).

# Kontrollutforming og implementering, utførelse og Effektivitetstesting: Hva er forskjellen?

Kontroller er bare verdt noe hvis du kan vise at de er godt utformet, at de faktisk utføres, og at de fortsetter å fungere over tid. CERRIX støtter hvert av disse tre spørsmålene med egen funksjonalitet, og navnene ligner nok til å kunne forveksles.

Denne veiledningen forklarer hva **Testing for design og implementering (D\&I)**, **Kontrollutførelse** og **Effektivitetstesting** hvert svar er, hvordan de henger sammen, og hvor du finner dem i CERRIX.

***

## De tre spørsmålene i korte trekk

| Aktivitet                                       | Spørsmål det svarer på                                                   | Hvem som deltar i CERRIX                                       |
| ----------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------- |
| **Testing for design og implementering (D\&I)** | *Er kontrollen godt beskrevet, og eksisterer den slik den er beskrevet?* | Bevisopplaster (førstelinje), tester (andre linje)             |
| **Kontrollutførelse**                           | *Ble kontrollen utført denne gangen, i tide, med bevis?*                 | Ansvarlig (utfører av kontrollen), valgfri Reviewer            |
| **Effektivitetstesting**                        | *Fungerte kontrollen effektivt gjennom hele Periode?*                    | Opplaster av kildedokumenter, bevisopplaster, tester, Reviewer |

Kort sagt: D\&I-testing ser på kontrollen **slik den er utformet**, kontrollutførelse er kontrollen **blir utført**, og Effektivitetstesting ser tilbake på en Periode med utførelser for å vurdere om kontrollen **fungerer pålitelig**.

***

## Testing for design og implementering (D\&I)

**Hva det er**\
En test av om kontrollen er riktig definert og faktisk er tatt i bruk. Den svarer på to spørsmål samtidig: er beskrivelsen komplett og i tråd med risikoen (utforming), og kan testeren se av bevisene at kontrollen finnes og utføres slik den er beskrevet (implementering)? På nederlandsk er dette kjent som *Opzet & Bestaanstest*.

**Eksempel**\
En tester sjekker om beskrivelsen av en kontroll for godkjenning av kjøp følger 5W1H-modellen, og ber om bevis (for eksempel et skjermbilde av Workflow-konfigurasjonen) som viser at forespørrer og godkjenner faktisk er forskjellige personer.

**I CERRIX**\
D\&I-testing settes opp i **D\&I Testing** delen av kontrollen. En Testplan fylles ut, vanligvis fra en **dokumentasjons- og implementeringskatalog** (en gjenbrukbar mal), med en tester, én eller flere bevisopplastere, en innledende testdato, en testfrekvens, testaktiviteten og testnormen.

Workflow har to trinn som gjentas for hver testsyklus:

1. **Venter på dokumentasjon**: bevisopplasteren (førstelinje) mottar en oppgave og laster opp de forespurte dokumentene, og klikker deretter **Klar for Vurdering**.
2. **Klar for Vurdering**: testeren (andre linje) gjennomgår bevisene og legger til et testresultat med en **dokumentasjonsscore** og en **implementeringsscore**.

Poengene vises i **Testskårer** panelet for kontrollen som utformingsscore og implementeringsscore, og den **Neste testdato (D\&I)** avledes fra den innledende testdatoen og testfrekvensen.

{% content-ref url="/pages/769fd10aac759bc5f6d27347682d256ade1eb6b9" %}
[Testing for design og implementering (D\&I)](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/design-and-implementation-d-and-i-testing.md)
{% endcontent-ref %}

***

## Kontrollutførelse

**Hva det er**\
Kontrollutførelse er ikke en test. Det er selve kontrollen som utføres av den ansvarlige personen eller teamet, med den frekvensen og på den måten kontrollbeskrivelsen foreskriver, og det å registrere at dette skjedde.

**Eksempel**\
En IT-administrator gjennomgår brukeraksesslisten den første mandagen i hver måned, legger ved eksporten og markerer oppgaven som fullført.

**I CERRIX**\
Kontrollutførelse registreres gjennom **Oppgaver for Kontrollutførelse**. Aktiver **Kontrollutførelse** bryteren på kontrollen, og opprett deretter enten en **Oppgaveserie** (gjentakende oppgaver basert på kontrollfrekvensen, for eksempel månedlig) eller en **hendelsesutløst** oppgave for kontroller som utløses av en hendelse i stedet for av en tidsplan.

Hver oppgave går til én eller flere **ansvarlige**, som legger til bevis, eventuelt gir en score og en kommentar, og markerer oppgaven som fullført. Hvis en **Reviewer** er tildelt, går oppgaven først til **Ready for review**, og Reviewer godkjenner eller avviser den. Oppgavene vises i den ansvarliges kalender og i oppgave-Workspace, med automatiske varsler.

Fordi hver utførelse logges med bevisene sine, bygger kontrollutførelse opp populasjonen som Effektivitetstesting senere trekker sine utvalg fra (se nedenfor).

{% content-ref url="/pages/6e614d0068dd3f75efdf14e61a4e7bef6fead90a" %}
[Oppgaver for Kontrollutførelse](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-execution-tasks.md)
{% endcontent-ref %}

***

## Effektivitetstesting

**Hva det er**\
En test av om kontrollen fungerte effektivt over en Periode. I stedet for å se på én utførelse trekker testeren et utvalg fra alle utførelser i testperioden og kontrollerer hver av dem opp mot testtrinnene. På nederlandsk er dette *werkingstest*.

**Eksempel**\
For testperioden FY 2026 trekker testeren ut 12 av de månedlige tilgangsgjennomgangene og verifiserer for hver prøve at gjennomgangen ble utført i tide, var komplett, og at oppfølgingshandlinger ble iverksatt.

**I CERRIX**\
Effektivitetstesting settes opp i **Effektivitetstesting** fanen for kontrollen. Du definerer først **testperioder** (for eksempel kvartaler eller et helt år), og deretter legger du til en **Testplanen** med roller, omfang og instruksjoner. CERRIX genererer oppgaver og påminnelser for alle involverte. Den avanserte Testplanen følger disse trinnene:

1. **Kildedokumenter**: opplasteren av kildedokumentet laster opp populasjonen (for eksempel hele listen over tilgangsgjennomganger i testperioden).
2. **Utvalg**: utvalg genereres etter nummer, etter dato eller fra et regneark ved hjelp av [Randomizer](https://docs.cerrix.com/cerrix-functionalities/module-overview/controls/control-advanced-effectiveness-testing/randomizer).
3. **Bevis**: bevisopplasteren legger frem bevis per utvalg, eller markerer et utvalg som uten bevis med en forklaring.
4. **Testing**: testeren scorer hvert testtrinn per utvalg og gir en endelig konklusjon.
5. **Revisjon**: Reviewer godkjenner eller avviser konklusjonen (når Reviewer-trinnet er aktivert i innstillingene for Kontrollmodulen).

Planens status går fra **Last opp kildedokumenter for å starte Workflow** til **Venter på dokumentasjon**, **Kontrolltesting** og **Klar for Vurdering** til **Fullført**. Bare når en plan er fullført, blir de **Effektivitetsskår** og **Dato testet (Effektivitetstesting)** fylt inn på kontrollen.

{% content-ref url="/pages/4a95b3f4bbe6b739f3bcbf6a572b2a5054a5c845" %}
[Kontroll Avansert Effektivitetstesting](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing.md)
{% endcontent-ref %}

***

## Hvordan de tre henger sammen

Se på dem som en sekvens snarere enn tre separate funksjoner:

1. **D\&I-testing** bekrefter at kontrollen er verdt å utføre: den er godt beskrevet og virkelig finnes.
2. **Kontrollutførelse** er den daglige utførelsen av kontrollen, med bevis samlet underveis.
3. **Effektivitetstesting** ser tilbake på en Periode med utførelser og konkluderer med om kontrollen fungerte.

Koblingen mellom trinn 2 og 3 er eksplisitt i CERRIX. Med **utførelsesbasert kontrolltesting**, aktiverer du **Bruk kontrollutførelse** på Testplanen, og CERRIX bruker automatisk alle oppgaver for kontrollutførelse i testperioden som populasjon. Bevis som er knyttet til disse oppgavene kopieres inn i utvalgene, slik at bevisopplasteren ikke trenger å samle dem inn på nytt. Hvis det ikke finnes noen utførelsesoppgaver i Periode, antar CERRIX at kontrollen ikke fant sted.

{% content-ref url="/pages/ddecb4677f3ace640d9dd8b3ad42a8185ebf65b2" %}
[Gjennomføringsbasert kontrolltesting](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing/execution-based-control-testing.md)
{% endcontent-ref %}

***

## Vanlige forvekslingspunkter

**Kontrollfrekvens kontra testfrekvens**\
Den **kontrollfrekvens** på kontrollen (for eksempel månedlig) er hvor ofte kontrollen blir *utført*. **testfrekvens** på en D\&I-testplan, og **testperioder** i Effektivitetstesting beskriver hvor ofte kontrollen blir *testet*. En månedlig kontroll blir vanligvis testet én gang eller noen få ganger i året.

**Krever overvåking**\
Den **Krever overvåking** avkrysningsboksen på kontrollen markerer kontroller som testes formelt. Testdatoer og poeng i Workspace og forhåndsinnstillinger fylles bare ut for overvåkede kontroller, så huk den av for hver kontroll du har tenkt å teste.

**Eier versus ansvarlig versus tester**\
Den **Eier** av en kontroll er ansvarlig for den som helhet. Den **Ansvarlig** på en oppgave for kontrollutførelse utfører kontrollen. Den **tester** i D\&I- eller Effektivitetstesting vurderer den, ideelt sett fra andrelinjen. Å holde disse adskilt er det som gir testingen din uavhengighet.

**Poeng**\
Poengene du kan velge (for eksempel Effektiv, Delvis effektiv, Ineffektiv) kommer fra Grunndata for kontroller, så de kan variere mellom organisasjoner. Bli enige om betydningen før du starter testingen.

***

## Beste praksis

* Aktiver **kontrollutførelse** på kontroller du vil teste med Effektivitetstesting, og be de ansvarlige om å legge ved bevis til hver oppgave. Dette gjør utførelsesbasert Effektivitetstesting mulig og fjerner behovet for å samle inn populasjoner manuelt.
* Tildel **tester** og **Reviewer** rollene til personer som er uavhengige av den ansvarlige som utfører kontrollen.
* Angi **testperioder** som passer med testfrekvensen din, og bruk samme navnekonvensjon (for eksempel Q1 2026, FY 2026) på tvers av alle kontroller.
* Bruk **Kopier fra eksisterende testplan** for å rulle Testplaner over i en ny Periode, slik at rollefordelinger og instrukser overføres.
* Koble hver kontroll til **Risikoene** den reduserer, og til de relevante **rammeverksdimensjonene**, slik at testresultatene er sporbare i dashbord og Revisjonsrapporter.


---

# 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/control-design-and-implementation-execution-and-effectiveness-testing-whats-the-difference.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.