> 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/controls/design-and-implementation-d-and-i-testing.md). # Testing for design og implementering (D\&I) CERRIX støtter en strukturert tilnærming til å teste utformingen og implementeringen av interne kontroller. Denne prosessen sikrer at kontrollene både er hensiktsmessig definert og effektivt implementert for å redusere tilknyttede risikoer. Denne veiledningen beskriver trinnene for å starte, gjennomføre og dokumentere D\&I-tester i CERRIX. *** ## Formålet med D\&I-testing Design- og implementeringstesten (også kjent som Opzet & Bestaanstest på nederlandsk) hjelper med å fastslå: * Om kontrollen er godt utformet (tydelig, komplett og i tråd med Risiko). * Om kontrollen er implementert og fungerer som beskrevet. * Om tilstrekkelig bevis støtter utformingen og gjennomføringen. *** ## Slik setter du opp en D\&I-test ### Naviger til en eksisterende kontroll Begynn med å velge kontrollen du vil starte en D\&I-test for. ### Start en design- og implementeringstest 1. Gå til D\&I-testseksjonen. 2. Velg en testmal. Maler inkluderer vanligvis et sett med standardspørsmål og forventninger til bevis.
### Definer vurderingskriterier Hver D\&I-test inkluderer vanligvis følgende nøkkelspørsmål: * Vurdering av design: Er kontrollen definert i samsvar med din retningslinje og metodikk for risikostyring (f.eks. modellen «5W1H»: Hvem, Hva, Når, Hvor og Hvordan)? * Forventet dokumentasjon: Definer hvilke typer dokumentasjon som kreves (f.eks. LMS-rapporter, oppfølgingsaktiviteter knyttet til opplæringsgap). * Kontroll av implementering: Kan testeren verifisere, basert på dokumentasjonen, at kontrollen er implementert i samsvar med beskrivelsen? *** ### Felter i D\&I-Testplanen Før en dokumentasjons- og implementeringstest starter, må testplandata fylles ut. Når en katalog (mal) er valgt, fylles dataene automatisk fra denne katalogen. Følgende elementer kan fylles ut: * **Testere** — personen(e) som vurderer testene for dokumentasjon og implementering i denne katalogen. * **Opplaster(e) av dokumentasjon** — personen(e) som leverer dokumentasjon for dokumentasjon og implementering i denne katalogen. * **Innledende testdato** — starten på den første testperioden. * **Opplastingsfrist** — antall dager før neste testdato som dokumentasjonsopplasteren skal være ferdig med å laste opp dokumentasjonen. * **Tilknyttede standarder** — rammeverk som CobIT eller ISAE 3402. * **# testprøver** — antall prøver som må testes i testperioden. * **Kvalitetsaspekt** — fokus for testen, for eksempel tilgjengelighet, integritet, ytelse eller pålitelighet. * **Testfrekvens** — daglig, ukentlig, månedlig, kvartalsvis, halvårlig, årlig, hvert annet år eller hvert tredje år. * **Testaktivitet** — den nøyaktige aktiviteten som må utføres av testeren: hvilke dokumenter dokumentasjonsopplasteren må levere, og hva testeren må fokusere på. * **Testnorm** — fastsetter krav til fullstendighet, nøyaktighet og aktualitet for dokumentasjonen. ## Roller og ansvarsområder ### Førstelinje: dokumentasjonsopplaster * Laster opp støttedokumentasjon knyttet til kontrollen. * Mottar en oppgave og en automatisk påminnelses-e-post om å laste opp dokumentasjon innen en bestemt dato. * Laster opp filer direkte via oppgavekoblingen eller D\&I-testsiden. ### Andrelinje: tester * Gjennomgår den opplastede dokumentasjonen. * Vurderer om kontrollen er hensiktsmessig utformet og implementert. * Poengsetter testen og legger til kommentarer ved behov. *** ## Opplasting av dokumentasjon 1. Dokumentasjonsopplasteren mottar en oppgave (og e-post) som ber dem sende inn dokumentasjon. 2. De kan klikke på oppgaven eller e-postlenken for å gå direkte til testen. 3. Klikk på fanen Dokumentasjon. 4. Last opp én eller flere filer (f.eks. LMS-rapporter, logger over korrigerende tiltak). 5. Klikk Bruk endringene og bekreft for å sende inn. *** ## Fullføring av testen Etter at dokumentasjonen er sendt inn: * Testeren vurderer kontrollen basert på de forhåndsdefinerte kriteriene. * Testpoengene og kommentarene lagres og er synlige i kontrolloversikten. * Alle poeng oppdateres automatisk i Workspace for kontrollen for full revisjonssporbarhet. *** ### Workflow-statuser og testresultater Dokumentasjons- og implementeringstesting består av to trinn som kan gjentas kontinuerlig: statusen **Venter på dokumentasjon**, etterfulgt av statusen **Klar for Vurdering**. Mens testplanen venter på dokumentasjon, kan dokumentasjonsopplasteren se testinformasjonen (testaktivitet og testnorm) i skrivebeskyttet modus og legge til dokumentene. Dokumentasjonen kan også redigeres eller fjernes: velg dokumentasjonsoppføringen og bruk blyanten til å endre dokumenttype eller beskrivelse, eller sletteknappen for å fjerne den. Når all nødvendig dokumentasjon er lastet opp, klikker dokumentasjonsopplasteren **Klar for Vurdering**. Deretter kontrollerer testeren dokumentasjonen og legger til et testresultat via **Legg til testpoeng**. Testresultatdatoen, dokumentasjonspoeng og implementeringspoeng er påkrevd; poengene hentes fra Grunndata og kan skrives inn eller velges. En kommentar kan legges til Funn, og etter lagring kan dokumenter legges ved testresultatet (dobleklikk på testresultatet og klikk **Legg til dokument**). Hvert testresultat i oversikten viser testresultatdatoen, dokumentasjonspoeng, implementeringspoeng, bruker, kommentarer, dokumenter, versjon og den historiske versjonen. ### Endring av testdetaljer og versjonering Når testplandetaljene ikke lenger er tilstrekkelige for testingen, kan de endres når som helst av Kontroll-uavhengig administrator, Kontroll-begrenset administrator, Testplanoppretter eller Kontrolltester — på samme måte som ved utfylling av testdetaljene, etterfulgt av **Lagre**. Hver gang detaljene i en Testplan endres, økes versjonen av Testplan; gjeldende versjon vises ved siden av lagre-knappen. Når et nytt Funn legges til, registreres den gjeldende versjonen av Testplan automatisk, og historiske versjoner kan åpnes fra oversikten over testpoeng. ## Workflow-integrasjon * Oppgaver og e-postvarsler opprettes og sendes automatisk. * Alle handlinger loggføres i systemet for gjennomsiktighet. * Frister for dokumentasjon og ansvar er tydelig definert og fulgt opp. --- # 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/controls/design-and-implementation-d-and-i-testing.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.