> 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/controls/design-and-implementation-d-and-i-testing.md).
# Testen voor ontwerp & implementatie (D\&I)
CERRIX ondersteunt een gestructureerde aanpak voor het testen van het ontwerp en de implementatie van interne Beheersmaatregelen. Dit proces zorgt ervoor dat Beheersmaatregelen zowel passend zijn gedefinieerd als effectief geïmplementeerd om de daarmee samenhangende Risico’s te beperken.
Deze handleiding beschrijft de stappen voor het starten, uitvoeren en documenteren van D\&I-tests in CERRIX.
***
## Doel van D\&I-testen
De test voor ontwerp en implementatie (ook bekend als Opzet & Bestaanstest in het Nederlands) helpt bepalen:
* Of de Beheersmaatregel goed is ontworpen (duidelijk, volledig en afgestemd op het Risico).
* Of de Beheersmaatregel is geïmplementeerd en functioneert zoals beschreven.
* Of voldoende bewijs het ontwerp en de uitvoering ondersteunt.
***
## Een D\&I-test instellen
### Navigeer naar een bestaande Beheersmaatregel
Begin met het selecteren van de Beheersmaatregel waarvoor je een D\&I-test wilt starten.
### Start een Design & Implementation-test
1. Ga naar de D\&I-testsectie.
2. Selecteer een testsjabloon. Sjablonen bevatten doorgaans een reeks standaardvragen en verwachtingen voor bewijs.
### Definieer beoordelingscriteria
Elke D\&I-test bevat doorgaans de volgende kernvragen:
* Ontwerp Assessment:
Is de Beheersmaatregel gedefinieerd in overeenstemming met je risicobeheerbeleid en -methodologie (bijv. het “5W1H”-model: Wie, Wat, Wanneer, Waar en Hoe)?
* Verwacht bewijs:
Definieer de soorten bewijs die vereist zijn (bijv. LMS-rapporten, vervolgacties voor opleidingshiaten).
* Implementatiecontrole:
Kan de tester op basis van bewijs verifiëren dat de Beheersmaatregel is geïmplementeerd volgens de beschrijving?
***
### D\&I Testplan-velden
Voordat een Documentatie- & Implementatietest begint, moeten de gegevens van het Testplan worden ingevuld. Wanneer een catalogus (sjabloon) wordt gekozen, worden de gegevens automatisch vanuit die catalogus ingevuld. De volgende items kunnen worden ingevuld:
* **Tester(s)** — de persoon/personen die de tests voor documentatie & implementatie binnen deze catalogus beoordelen.
* **Bewijsuploader(s)** — de persoon/personen die bewijs leveren voor documentatie & implementatie binnen deze catalogus.
* **Initiële testdatum** — het begin van de eerste testperiode.
* **Uiterste upload-datum** — het aantal dagen vóór de volgende testdatum waarop de bewijsuploader klaar moet zijn met het uploaden van bewijs.
* **Gekoppelde standaarden** — raamwerken zoals CobIT of ISAE 3402.
* **# testsamples** — het aantal samples dat binnen de testperiode moet worden getest.
* **Kwaliteitsaspect** — de focus van de test, zoals toegankelijkheid, integriteit, prestaties of betrouwbaarheid.
* **Testfrequentie** — dagelijks, wekelijks, maandelijks, per kwartaal, halfjaarlijks, jaarlijks, elke twee jaar of elke drie jaar.
* **Testactiviteit** — de exacte activiteit die door de tester moet worden uitgevoerd: welke documenten door de bewijsuploader moeten worden aangeleverd en waarop de tester zich moet richten.
* **Testnorm** — bepaalt de vereisten voor volledigheid, juistheid en tijdigheid van het bewijs.
## Rollen en verantwoordelijkheden
### Eerste lijn: Bewijsuploader
* Uploadt ondersteunend bewijs met betrekking tot de Beheersmaatregel.
* Ontvangt een taak en een geautomatiseerde herinneringsmail om bewijs vóór een specifieke datum te uploaden.
* Uploadt bestanden rechtstreeks via de taakslink of de D\&I-testpagina.
### Tweede lijn: Tester
* Beoordeelt het geüploade bewijs.
* Beoordeelt of de Beheersmaatregel passend is ontworpen en geïmplementeerd.
* Geeft de test een score en voegt indien nodig opmerkingen toe.
***
## Bewijs uploaden
1. De bewijsuploader ontvangt een taak (en e-mail) met het verzoek bewijs in te dienen.
2. Zij kunnen op de taak- of e-maillink klikken om rechtstreeks naar de test te gaan.
3. Klik op het tabblad Bewijs.
4. Upload een of meer bestanden (bijv. LMS-rapporten, logs van corrigerende maatregelen).
5. Klik op Wijzigingen toepassen en bevestig om te verzenden.
***
## De test afronden
Nadat het bewijs is ingediend:
* De Tester beoordeelt de Beheersmaatregel op basis van de vooraf gedefinieerde criteria.
* De testscores en opmerkingen worden opgeslagen en zichtbaar in het Beheersmaatregeloverzicht.
* Alle scores worden automatisch bijgewerkt in de Beheersmaatregel Workspace voor volledige Audit-traceerbaarheid.
***
### Workflow-statussen en testresultaten
Documentatie- & implementatietesten bestaan uit twee stappen die continu kunnen worden herhaald: de status **Wachten op bewijs**, gevolgd door de status **Klaar voor Assessment**.
Terwijl het Testplan wacht op bewijs, kan de bewijsuploader de testinformatie (testactiviteit en testnorm) in alleen-lezenmodus zien en voegt hij de bewijsdocumenten toe. Bewijs kan ook worden bewerkt of verwijderd: selecteer de bewijsvermelding en gebruik het potlood om het documenttype of de beschrijving te wijzigen, of de verwijderknop om het te verwijderen. Zodra al het benodigde bewijs is geüpload, klikt de bewijsuploader op **Klaar voor Assessment**.
De tester controleert vervolgens het bewijs en voegt een testresultaat toe via **Testscore toevoegen**. De datum van het testresultaat, de documentatiescore en de implementatiescore zijn vereist; de scores komen uit de Basisgegevens en kunnen worden getypt of geselecteerd. Er kan een opmerking aan de Bevinding worden toegevoegd en na het opslaan kunnen documenten aan het testresultaat worden gekoppeld (dubbelklik op het testresultaat en klik op **Document toevoegen**). Elk testresultaat in het overzicht toont de datum van het testresultaat, documentatiescore, implementatiescore, gebruiker, opmerkingen, documenten, versie en de historische versie.
### Testdetails wijzigen en versiebeheer
Wanneer de details van het Testplan niet langer voldoende zijn voor de test, kunnen ze op elk moment worden gewijzigd door de onbeperkte beheerder van de Beheersmaatregel, de beperkte beheerder van de Beheersmaatregel, de maker van het Testplan van de Beheersmaatregel of de tester van de Beheersmaatregel — op dezelfde manier als het invullen van de testdetails, gevolgd door **Opslaan**.
Elke keer dat de details van een Testplan worden gewijzigd, wordt de versie van het Testplan verhoogd; de huidige versie wordt naast de knop Opslaan weergegeven. Wanneer een nieuwe Bevinding wordt toegevoegd, wordt automatisch de huidige versie van het Testplan vastgelegd, en historische versies kunnen worden geopend vanuit het overzicht van testscores.
## Workflow-integratie
* Taken en e-mailmeldingen worden automatisch aangemaakt en verzonden.
* Alle acties worden in het systeem gelogd voor transparantie.
* Bewijsdeadlines en verantwoordelijkheden zijn duidelijk gedefinieerd en worden bijgehouden.
---
# 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/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.
