> 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/roles-rights-and-permissions.md). # Rollen, rechten en machtigingen CERRIX gebruikt een op rollen gebaseerd toegangsmodel om te bepalen wie informatie binnen het platform kan bekijken, bewerken en goedkeuren. Zo heeft elke gebruiker alleen toegang tot de functies en gegevens die hij nodig heeft voor zijn verantwoordelijkheden, wat zowel de gegevensbeveiliging als efficiënte samenwerking ondersteunt. ## Rollen en machtigingen in CERRIX Elke gebruiker krijgt een of meer rollen toegewezen, die hun toegangsniveau bepalen. Rollen sluiten aan op veelvoorkomende verantwoordelijkheden in governance, risico, compliance, audit en incidentbeheer. Machtigingen geven aan wat een rol binnen een module kan doen. ## Rolgroepen en hoe rollen worden toegewezen Rollen kunnen afzonderlijk aan gebruikers worden toegewezen, of in bulk via rolgroepen. Een rolgroep bundelt een set rollen en een set gebruikers: elke gebruiker in de groep krijgt alle rollen die aan de groep zijn toegewezen. ### Rollen toewijzen aan een individuele gebruiker Ga voor een klein aantal gebruikers naar **Gebruikersbeheer**, selecteer de gebruiker en open **Rollen**. Vink de rollen aan die je wilt toekennen en klik op **Gebruiker opslaan** om de wijziging toe te passen. ### Rollen toewijzen via een rolgroep Om in één keer rollen voor een groep gebruikers te beheren: 1. Ga naar **Gebruikersbeheer** en open **Workspace-hulpmiddelen** in de rechterbovenhoek van het scherm. 2. Selecteer **Rolgroepen** en open de rolgroep die je wilt bewerken. Er verschijnt een wizard. 3. In het **Toegewezen rollen** stap, selecteer de rollen die de groep moet toekennen. 4. Doorloop de overige stappen één voor één — selecteer de gebruikers die bij de groep horen en de dashboards die ze nodig hebben — en sla je wijzigingen op in de laatste **Samenvatting** stap.
Adding a role group: name and description
### Automatische roltoewijzing voor geprovisioneerde gebruikers Wanneer gebruikers via SCIM worden geprovisioneerd, worden groepen uit je identity provider gesynchroniseerd naar CERRIX als rolgroepen. Alle rollen die je in CERRIX aan zo'n rolgroep toewijst, worden automatisch toegekend aan de geprovisioneerde leden van de gekoppelde groep — nieuwe gebruikers krijgen ze zodra provisioning hen aan de groep toevoegt. De rollen zelf worden altijd in CERRIX beheerd: zoek de rolgroep die gekoppeld is aan je identity-providergroep (onder **Gebruikersbeheer** > **Workspace-instellingen**) en wijs de gewenste rollen eraan toe. Let op dat groepsnamen moeten overeenkomen: als een gesynchroniseerde groep bij de eerste synchronisatie qua naam niet overeenkomt met een bestaande rolgroep, wordt in CERRIX een nieuwe rolgroep aangemaakt. ### Handmatig aangemaakte gebruikers Voor handmatig aangemaakte gebruikers is er geen automatische roltoewijzing: een nieuwe gebruiker wordt niet automatisch gekoppeld aan een rolgroep. Om in één keer een rol toe te kennen aan veel bestaande gebruikers, open je de hierboven beschreven rolgroepwizard en gebruik je de **alles selecteren** knop in stap 3 om alle gebruikers in één handeling aan de groep toe te voegen. Als alternatief kunnen rollen in bulk worden toegewezen via een gebruikersimportbestand — neem contact op met CERRIX support als je een import wilt gebruiken. {% hint style="info" %} Voor het automatisch aanmaken van gebruikers en het koppelen ervan aan rolgroepen, zie [Gebruikersprovisioning met SCIM](/cerrix-documentation-nl/cerrix-functionaliteiten/admin-settings/authentication-and-user-provisioning/user-provisioning-with-scim.md). {% endhint %} ## Machtigingsmatrices per module CERRIX biedt voor elke kernmodule een machtigingsmatrix. Deze matrices zijn de gezaghebbende referentie voor het configureren en valideren van gebruikersrechten. In het matrixblad: * Elke rij vermeldt een specifieke actie (bijv. *Nieuwe incidenten melden*, *Risico's verwijderen*). * Elke kolom staat voor een rol (bijv. Risico Onbeperkte beheerder, Incidentbeoordelaar). * De cellen geven aan of de rol machtiging heeft, en wat de reikwijdte van die machtiging is (*Onbeperkt*, *Beperkt*, of *Toegewezen*). * Onbeperkt betekent dat een gebruiker rechten heeft binnen alle organisaties * Beperkt betekent dat een gebruiker rechten heeft voor een specifieke organisatie ## Incidenten-machtigingmatrix | Rol | Beschrijving | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Gebeurtenis Onbeperkte beheerder | Volledige toegang tot alle gebeurtenisgerelateerde functionaliteit en zichtbaarheid binnen alle organisaties. | | Gebeurtenis Beperkte beheerder | Vergelijkbaar met de Onbeperkte beheerder, maar beperkt tot hun eigen organisatie (en dochterorganisaties) en zonder toegang tot Basisgegevens. | | Gebeurtenisbeoordelaar | Volledige bewerkingsrechten (in statussen: Wachten op acceptatie en Klaar voor beoordeling) voor gebeurtenissen die aan hen zijn toegewezen | | Gebeurtenis Verantwoordelijke | Bewerkingsrechten (in status Wachten op verbeteringen) voor toegewezen gebeurtenissen, behalve voor gebruikerstoewijzingen. | | Gebeurtenismelder | Kan nieuwe gebeurtenissen melden voor elke organisatie in CERRIX. | | Gebeurtenis Geïnformeerde | Alleen-lezen toegang tot gebeurtenissen waaraan de gebruiker is toegewezen. | | Gebeurtenis Onbeperkte Viewer | Alleen-lezen toegang tot alle gebeurtenissen, binnen alle organisaties. | | Gebeurtenis Beperkte Viewer | Alleen-lezen toegang tot gebeurtenissen binnen de eigen organisatie van de gebruiker (en dochterorganisaties) | Je kunt in deze machtigingsmatrix zien welke machtigingen deze rollen hebben: {% file src="/files/338e122f0849654b128d0b2a88db2c44c7e0edff" %} ### Incidenten gebruiken de rollen van Gebeurtenis De Incidentenmodule heeft geen eigen set rollen: deze hergebruikt de rollen van de Gebeurtenissenmodule. Daarom heten de rollen hieronder "Gebeurtenis …" en vind je geen aparte tab Incidenten in Gebruikersbeheer — incidentmachtigingen worden beheerd onder **Gebeurtenissen**. Om in het bijzonder een nieuw incident te maken (melden) heb je de **Gebeurtenismelder** rol nodig. Zonder deze rol wordt de knop **Nieuw incident toevoegen** niet getoond in de Incidentenmodule. Alleen beheerdersrechten zijn niet voldoende — ook gebruikers met een Gebeurtenisbeheerder- of platformbeheerderrol moeten Gebeurtenismelder hebben om incidenten te melden. Een gebruiker moet ook de rol Gebeurtenismelder hebben om als Melder van een incident selecteerbaar te zijn. Om de rol toe te wijzen, ga naar **Gebruikersbeheer**, selecteer de gebruiker, open **Rollen**, en vink onder **Gebeurtenissen** aan **Gebeurtenismelder** (je kunt dit ook via een rolgroep toekennen). Vraag de gebruiker om CERRIX te vernieuwen of uit en weer in te loggen, zodat de wijziging van kracht wordt. ### Rechten nodig om risico's, beheersmaatregelen en MoI's aan een incident te koppelen Een bestaand object aan een incident koppelen — een risico, een beheersmaatregel of een MoI — hangt tegelijk van twee dingen af: 1. **Bewerkingsrechten op het incident zelf.** De gebruiker heeft een rol nodig die bewerken van het incident in de huidige status toestaat: **Gebeurtenisbeoordelaar** (statussen Wachten op acceptatie en Klaar voor beoordeling), **Gebeurtenis Verantwoordelijke** (status Wachten op verbeteringen), of een van de **Gebeurtenisbeheerder** rollen. 2. **Rechten in de module waar het object vandaan komt.** Om een risico of een beheersmaatregel te kunnen selecteren, heeft de gebruiker ook een rol in die module nodig. Een viewerrol is voldoende: **Risico Beperkte Viewer** en **Beheersmaatregel Beperkte Viewer** maken objecten uit de eigen organisatie van de gebruiker (en dochterorganisaties) selecteerbaar, en de onbeperkte varianten maken koppeling van objecten over organisaties heen mogelijk. Zonder een rol in die module blijft de selectielijst leeg, zelfs wanneer de gebruiker het incident kan bewerken. Beheerdersrechten op de Incidentenmodule zijn hiervoor niet vereist. Een tweedelijnsrol die incidenten verrijkt met bestaande risico's, beheersmaatregelen en MoI's laat zijn incident-workflowrollen doorgaans zoals ze zijn en voegt **Risico Beperkte Viewer**, **Beheersmaatregel Beperkte Viewer** en de MoI-rol die bij de taak past toe — zie *MoI's en BIM-machtigingsmatrix* hieronder voor wat elke MoI-rol toestaat. ### Welke incidenten een gebruiker kan zien De zichtbaarheid van incidenten volgt de rollen en toewijzingen van de gebruiker. Workflowrollen zien de incidenten waaraan ze werken; beheerder- en viewerrollen zien incidenten binnen hun organisatieruimte: | Rollen | Zichtbare incidenten | | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Gebeurtenisbeoordelaar, Gebeurtenis Verantwoordelijke, Gebeurtenismelder, Gebeurtenis Geïnformeerde, Beschermingsfunctionaris | Alleen de incidenten die zij hebben aangemaakt of waaraan zij zijn toegewezen | | Gebeurtenis Beperkte beheerder, Gebeurtenis Beperkte Viewer | Alle incidenten van hun eigen organisatie (en dochterorganisaties) | | Gebeurtenis Onbeperkte beheerder, Gebeurtenis Onbeperkte Viewer | Alle incidenten, binnen alle organisaties | Door deze rollen te combineren kun je de toegang nauwkeurig afstemmen: gebruikers die betrokken zijn bij de afhandeling van een specifiek incident zien alleen dat incident, terwijl coördinerende rollen het overzicht behouden. #### Leesrechten voor de hele organisatie zonder rechten op basisgegevens Wanneer een team elk incident binnen de organisatie moet monitoren — bijvoorbeeld een team dat toezicht houdt op datalekken — wijs dan de **Gebeurtenis Onbeperkte Viewer** rol toe. Deze biedt alleen-lezen zichtbaarheid op alle incidenten, terwijl basisgegevens door je beheerders beheerd blijven. Combineer deze rol met workflowrollen voor de incidenten die het team actief afhandelt. #### Een rolgroep voor melders met volledige toegang tot eigen incidenten Om incidentcoördinatoren in staat te stellen incidenten te registreren en volledige schrijfrechten erop te behouden — en op de onderliggende MoI's — zonder beheerdersrechten toe te kennen, maak je een rolgroep met deze drie rollen: * **Gebeurtenismelder** * **Gebeurtenisbeoordelaar** * **Gebeurtenis Verantwoordelijke** Bij het melden van een incident wijst de gebruiker zichzelf aan als zowel de Beoordelaar als de Verantwoordelijke. Daarna kunnen ze hun incident door elke workflowstap volgen, alle velden bewerken en de gekoppelde MoI's beheren, terwijl incidenten van collega's buiten scope blijven. ## Risico-machtigingsmatrix
RollenBeschrijving
Risico Onbeperkte beheerderDe Onbeperkte beheerder heeft onbeperkte lees- en schrijfrechten en kan items toevoegen aan catalogi.
Risico Beperkte beheerderDe Beperkte beheerder heeft beperkte lees- en schrijfrechten voor zijn eigen organisatie.
Risico Onbeperkte schrijverDe Onbeperkte schrijver heeft schrijfrechten voor de hele organisatie.
Risico Beperkte schrijverDe Beperkte schrijver heeft schrijfrechten voor zijn eigen organisatie.
Risico Onbeperkte ViewerDe Onbeperkte Viewer heeft weergaverechten voor de hele organisatie.
Risico Beperkte ViewerDe Beperkte Viewer heeft leesrechten voor zijn eigen organisatie.
Je kunt in deze machtigingsmatrix zien welke machtigingen deze rollen hebben: {% file src="/files/7c05e5b4d71228bffd12619afb827ef801fc4b33" %} ## Beheersmaatregelen-machtigingsmatrix
RollenBeschrijving
Beheersmaatregel Onbeperkte beheerderDe Onbeperkte beheerder is verantwoordelijk voor het opzetten en onderhouden van een compleet overzicht van de Beheersmaatregelmodule binnen alle organisaties. Deze rol geeft volledige zichtbaarheid en bewerkingsrechten op alle beheersmaatregelen, evenals toegang tot alle basisgegevens in de module. De gebruiker kan ook aan elke rol binnen toetsingsactiviteiten worden toegewezen.
Beheersmaatregel Beperkte beheerderDe Beperkte beheerder kan ook het overzicht van de beheersmaatregelen opzetten en onderhouden. De Beperkte beheerder is echter beperkt tot de beheersmaatregelen van zijn eigen organisatie. Ook kan de Beperkte beheerder binnen zijn eigen organisatie in elke rol in de toetsing worden geselecteerd.
Beheersmaatregel Onbeperkte schrijverDe Onbeperkte schrijver heeft volledige schrijfmachtigingen voor de Beheersmaatregelmodule binnen alle organisaties. Hij kan beheersmaatregelen aanmaken, bewerken en verwijderen, maar heeft geen toetsingsgerelateerde machtigingen.
Beheersmaatregel Beperkte schrijverDe Beperkte schrijver kan beheersmaatregelen aanmaken, bewerken en verwijderen binnen zijn eigen organisatie. Net als de Onbeperkte schrijver bevat deze rol geen enkele toetsingsmachtiging.
Beheersmaatregel Onbeperkte ViewerDe Onbeperkte Viewer kan alle beheersmaatregelen binnen alle organisaties openen en bekijken in alleen-lezenmodus. Deze rol heeft geen bewerkings- of toetsingsmachtigingen.
Beheersmaatregel Beperkte ViewerDe Beperkte Viewer kan beheersmaatregelen alleen binnen zijn eigen organisatie openen en bekijken in alleen-lezenmodus. Deze rol heeft geen bewerkings- of toetsingsmachtigingen.
BeheersmaatregelbewijsuploaderDe bewijsuploader kan worden toegewezen in testplannen voor zowel Ontwerp & Implementatie als Effectiviteitstoetsing. Deze rol is verantwoordelijk voor het uploaden en onderhouden van ondersteunend bewijs dat tijdens de toetsing van beheersmaatregelen wordt gebruikt.
BeheersmaatregeltesterDe tester is verantwoordelijk voor het uitvoeren van zowel Ontwerp & Implementatie als Effectiviteitstoetsing. Deze rol voert beheersmaatregeltests uit en documenteert de testresultaten.
Beheersmaatregel ReviewerDe Reviewer beoordeelt en keurt de resultaten van Effectiviteitstoetsing goed. Deze rol is verantwoordelijk voor het beoordelen van het werk van de tester en het zorgen dat de beheersmaatregelbeoordelingen volledig en nauwkeurig zijn.
Beheersmaatregel Testplan CreatorDe Testplan Creator is verantwoordelijk voor het ontwerpen en onderhouden van testplannen voor zowel Ontwerp & Implementatie als Effectiviteitstoetsing. Deze rol kan ook de bijbehorende testcatalogi beheren.
BeheersmaatregeluitvoerderDe Beheersmaatregeluitvoerder is verantwoordelijk voor het operationeel uitvoeren van beheersmaatregelen zoals gedefinieerd in het systeem. Deze rol legt de uitvoeringsresultaten vast en kan relevant bewijs uploaden dat aantoont dat de beheersmaatregel volgens plan is uitgevoerd.
Je kunt in deze machtigingsmatrix zien welke machtigingen deze rollen hebben: {% file src="/files/f0ffea087444318468e90f55d4286ac4c6bfdbfa" %} ### Toegang tot beheersmaatregelen en testdocumenten Rondom de rollen voor Beheersmaatregelen komen regelmatig twee vragen terug: * **Wie kan de documenten openen die aan een testscore zijn gekoppeld?** Een gebruiker met een Beheersmaatregel Viewer- of Beheersmaatregel Writer-rol — beperkt of onbeperkt — die toegang heeft tot de beheersmaatregel zelf, kan de Ontwerp & Implementatie-test van die beheersmaatregel openen, het regelitem openen en de documenten bekijken en downloaden die aan de testscore zijn gekoppeld. Toegang tot die documenten volgt de toegang tot de beheersmaatregel, dus er hoeft geen apart documentrecht te worden toegekend. * **Waarom zien deelnemers aan een testplan nog steeds beheersmaatregelen van een gearchiveerde organisatie?** Een gebruiker die in een testplan aan een rol is toegewezen, behoudt toegang tot de beheersmaatregelen die aan dat testplan gekoppeld zijn, ook wanneer de organisatielaag van die beheersmaatregelen is gearchiveerd en de gebruiker geen rechten op het archief heeft. De rol in het testplan is wat de toegang verleent, en die blijft bestaan totdat die rol wordt verwijderd. ## Machtigingsmatrix voor Effectiviteitstoetsing van Beheersmaatregelen De rolbeschrijvingen voor Effectiviteitstoetsing van Beheersmaatregelen zijn dezelfde als die voor de [Beheersmaatregelen](#controls-permission-matrix). Je kunt in deze machtigingsmatrix zien welke machtigingen deze rollen hebben: {% file src="/files/f31621d8e03dcb857fa7b6f6fe315da1296a71ae" %} ## MoI's en BIM-machtigingsmatrix Verbetermaatregelen (MoI's) zijn altijd gekoppeld aan een bovenliggend object zoals een risico, beheersmaatregel, incident of bevindingenrapport. De rechten die een gebruiker nodig heeft, hangen daarom van twee dingen af: de MoI-rollen zelf, en de rechten van de gebruiker in de module waartoe de MoI behoort. {% hint style="warning" %} **Alleen MoI-rechten zijn niet voldoende.** Omdat MoI's tot een bovenliggende module behoren, heeft een gebruiker ook de juiste rechten in die module nodig (bijvoorbeeld schrijfrechten voor Risico of Beheersmaatregel) om MoI's aan te maken of als reviewer op te treden. Een gebruiker aan wie alleen MoI-rollen zijn toegewezen, kan geen MoI's aanmaken. {% endhint %} ### MoI-workflowrollen De MoI-rollen in Gebruikersbeheer bepalen aan welke workflowrollen een gebruiker kan worden toegewezen: | Rol | Beschrijving | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MoI Verantwoordelijke | Geeft het recht om als Verantwoordelijke voor elk type MoI te worden geselecteerd. Het recht om een managementreactie aan te passen of te geven, is specifiek voor de MoI Verantwoordelijke. | | MoI Gedelegeerde | Geeft het recht om als Gedelegeerde te worden geselecteerd. De Gedelegeerde heeft niet dezelfde rechten als de Verantwoordelijke en kan de managementreactie niet bewerken. | ### Rechten nodig om een MoI aan te maken Welke rechten nodig zijn om een MoI aan te maken, hangt af van het type MoI (d.w\.z. de bovenliggende module): | MoI-type | Benodigde rechten om aan te maken | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Risico-MoI | Risico Beperkte schrijver of Risico Onbeperkte schrijver | | Beheersmaatregel-MoI | Schrijfrechten voor Beheersmaatregelen; de rol Beheersmaatregeltester maakt het ook mogelijk om Beheersmaatregel-MoI's aan te maken | | Incident-MoI | De rol Gebeurtenis Verantwoordelijke maakt het mogelijk om Incident-MoI's aan te maken | | Bevindingenrapport-MoI | BIM-bevindingenrapport bewerkingsrechten; viewerrollen zoals BIM Bevindingenrapport Rapporttype Beperkte Viewer geven leesrechten op bevindingenrapporten maar staan het aanmaken van MoI's niet toe | {% hint style="info" %} Wil je dat gebruikers MoI's voor bevindingenrapporten kunnen registreren zonder hen bredere BIM-bewerkingsrechten te geven? Het onderliggende recht **Business IM | Verbetermaatregel | Maker** kan als maatwerkaanpassing binnen een viewerrol worden geactiveerd (bijvoorbeeld BIM Bevindingenrapport Beperkte Viewer). Dit is een aangepaste configuratie voor je omgeving — neem contact op met CERRIX support om dit te laten instellen. Op dezelfde manier kan het recht om Risico-MoI's aan te maken als maatwerkwijziging worden toegevoegd aan de rol Risico Beperkte Viewer. Houd er rekening mee dat iedereen met leesrechten op risico's dan ook Risico-MoI's kan aanmaken voor de risico's die ze mogen zien. {% endhint %} ### Rechten nodig om een MoI-reviewer te zijn Om reviewer op een MoI te zijn, moet een gebruiker schrijfmachtigingen hebben voor de module waartoe de MoI behoort. Voor een Beheersmaatregel-MoI is bijvoorbeeld de rol Beheersmaatregel Beperkte schrijver vereist. Zonder schrijfrechten in de bovenliggende module: * de gebruiker **kan niet worden geselecteerd** als reviewer op de MoI. * Een gebruiker die al als reviewer is toegewezen **ziet de workflowknoppen niet** (MoI accepteren, weigeren en sluiten), zelfs wanneer de MoI de status "Klaar voor acceptatie" heeft.
The Accept, Reject and Close MoI workflow buttons, visible to reviewers with write rights in the parent module
{% hint style="info" %} Als een reviewer meldt dat de knoppen MoI accepteren, weigeren en sluiten ontbreken, controleer dan of diegene schrijfrechten heeft in de module waartoe de MoI behoort. {% endhint %} ### MoI's bevestigen en de rol BIM-beheerder Nadat een MoI is aangemaakt, moet deze worden bevestigd voordat hij de fase "In uitvoering" bereikt. Met de **BIM-beheerder** rol kunnen gebruikers: * Bevindingenrapport-MoI's bevestigen of afwijzen * Alle bevindingenrapporten bekijken en bewerken, evenals alle gekoppelde MoI's * Basisgegevens wijzigen, BIM-periodes aanmaken, MoI-e-mailberichten aanpassen en verwijderde bevindingenrapporten herstellen * Voorinstellingen aanpassen in zowel de Workspace van het Bevindingenrapport als de MoI-Workspace {% hint style="warning" %} De BIM-beheerder **kan** Risico- of Beheersmaatregel-MoI's niet bevestigen of afwijzen. Het bevestigen van die MoI's kan alleen worden uitgevoerd door de Verantwoordelijke of de Applicatiebeheerder. {% endhint %} Bepaalde submachtigingen van de rol BIM-beheerder kunnen worden aangepast, bijvoorbeeld om toegang tot basisgegevens te beperken. Dit is een aangepaste rolconfiguratie — neem contact op met CERRIX support om de opties te bespreken. Houd er rekening mee dat elke aanpassing van de rol generiek geldt voor alle gebruikers die eraan zijn toegewezen. ### Wie MoI-vervaldata kan wijzigen De mogelijkheid om de vervaldatum van een MoI te wijzigen wordt beheerd door een specifieke **Vervaldatumwijziger** machtiging. Standaard is deze machtiging gekoppeld aan de volgende rollen: * BIM-beheerder * MoI Verantwoordelijke * MoI Gedelegeerde De MoI Verantwoordelijke kan de vervaldatum alleen wijzigen zolang de MoI de status **In behandeling**. Er zijn twee afzonderlijke onderliggende rechten, afhankelijk van het type MoI: | Recht | Van toepassing op | | ---------------------- | ------------------------------------------------------------------------------------ | | `ImMoiDueDateChanger` | MoI's gekoppeld aan risico's, beheersmaatregelen en andere MoI's voor verbeterbeheer | | `BimMoIDueDateChanger` | MoI's gekoppeld aan bevindingenrapporten | **Wijzigingen in vervaldata beperken** Als je wilt voorkomen dat Verantwoordelijken en/of Gedelegeerden vervaldata verplaatsen, kan de machtiging Vervaldatumwijziger uit die rollen worden verwijderd, zodat alleen andere rollen (bijvoorbeeld de Applicatiebeheerder of de BIM Reviewer) vervaldata kunnen wijzigen. Bij het beperken van deze machtiging is het verstandig om deze beschikbaar te houden voor de Applicatiebeheerder. Houd rekening met het volgende: * Dit is een **wijziging op rolniveau**: het verwijderen van de machtiging uit een rol heeft gevolgen voor **alle gebruikers met die rol**, onafhankelijk van rolgroepen. De machtiging kan niet per rolgroep of per gebruiker worden beperkt. * Wijzigen welke rollen deze rechten hebben is een **op maat aangevraagde service uitgevoerd door CERRIX** — neem contact op met CERRIX support om het te laten instellen. * Het wordt aanbevolen de wijziging eerst toe te passen in je **acceptatieomgeving** en deze in verschillende scenario's te valideren (verschillende MoI-types, verschillende rollen en verschillende MoI-statussen) voordat je deze in productie toepast.
The Improvement management roles in User Management
### Welke MoI's een gebruiker kan zien De zichtbaarheid van MoI's wordt bepaald door specifieke viewerrollen, naast de hierboven beschreven workflowrollen: | Rol | MoI's zichtbaar voor de gebruiker | | -------------------- | ---------------------------------------------------- | | MoI Gedelegeerde | Alleen de MoI's die aan hen zijn gedelegeerd | | MoI Viewer Beperkt | Alle MoI's van de eigen organisatie van de gebruiker | | MoI Viewer Onbeperkt | Alle MoI's, binnen alle organisaties | Daarnaast tonen leesrechten in de bovenliggende module de MoI's van objecten binnen die scope. Een gebruiker met bijvoorbeeld leesrechten voor Beheersmaatregelen of Risico's op een organisatie ziet ook de MoI's die aan de beheersmaatregelen en risico's van die organisatie zijn gekoppeld. Het bezit of beheren van het bovenliggende object breidt de zichtbaarheid van MoI's op zichzelf niet uit over organisaties heen. Een eigenaar van een beheersmaatregel die MoI's wil opvolgen die aan een andere organisatie zijn toegewezen, kan de **MoI Viewer Onbeperkt** rol krijgen. Evenzo zijn de rollen schrijver en beperkte beheerder van beheersmaatregelen gericht op het beheren van beheersmaatregelen binnen hun scope en garanderen ze niet de zichtbaarheid van elke gekoppelde MoI — wanneer gebruikers een volledig MoI-overzicht nodig hebben, wijs dan een van de bovenstaande MoI-viewerrollen toe in plaats van hun beheersmaatregelrechten te verruimen. {% hint style="info" %} Als een gebruiker meldt minder MoI's te zien dan verwacht, controleer dan welke van de bovenstaande rollen diegene heeft: het MoI-overzicht laat precies zien wat de combinatie van MoI-viewerrollen en module-lezrechten dekt. {% endhint %} ### Incident-MoI's Incident-MoI's volgen hetzelfde machtigingsmodel als de andere MoI-types. MoI-Verantwoordelijken zien alleen de incident-MoI's die aan hen zijn toegewezen en kunnen de details van het gekoppelde incident openen; MoI-Gedelegeerden zien de incident-MoI's die aan hen zijn gedelegeerd; MoI Viewer Beperkt ziet de incident-MoI's van de eigen organisatie en diens dochterorganisaties, en MoI Viewer Onbeperkt ziet ze allemaal. Het aanmaken van incident-MoI's vereist de rol Gebeurtenis Verantwoordelijke (zie *Rechten nodig om een MoI aan te maken* hierboven). ### Waarom een MoI-verantwoordelijke ook de reviewstappen kan voltooien Wanneer de verantwoordelijke van een MoI de volledige workflow zelfstandig kan doorlopen — inclusief de stappen die voor de reviewer bedoeld zijn, terwijl de reviewer wel de meldingen ontvangt — is dat het gevolg van de **BIM Rapporttype Beperkte beheerder** rol. Die rol verleent in twee situaties beheerdersrechten op bevindingenrapporttypes: * Elk bevindingenrapporttype dat gekoppeld is aan de eigen organisatie van de gebruiker. * Elk bevindingenrapporttype dat **helemaal niet aan een organisatie gekoppeld is**. Beheerdersrechten op een bevindingenrapporttype dekken de workflowstappen van de MoI's daaronder, dus een gebruiker die deze rol heeft en ook de Verantwoordelijke van zo'n MoI is, kan zijn eigen maatregel bevestigen en accepteren. {% hint style="info" %} Om de reviewstap bij de reviewer te laten, koppel je elk bevindingenrapporttype aan de organisatie waartoe het behoort — een rapporttype zonder organisatiekoppeling staat open voor elke BIM Rapporttype Beperkte beheerder in de omgeving. Rapporttypes worden beheerd in [BIM-basisgegevens](https://docs.cerrix.com/cerrix-functionalities/module-overview/business-improvement-management/bim-standing-data). {% endhint %} ## Benodigde rechten om items tussen modules te koppelen Het koppelen van twee items begint altijd bij een van de twee, en de rechten die je nodig hebt zijn die van het item waarmee je koppelt **van**. In heel CERRIX gelden twee regels: * Je hebt **schrijfrechten** nodig op het item waarvanuit je koppelt. Beheerder- en schrijversrollen van die module kunnen koppelingen maken; viewerrollen kunnen bestaande koppelingen zien maar niet toevoegen of verwijderen. * Koppelen is beperkt tot de **organisatie van het item**. Een beperkte rol kan items koppelen binnen de eigen organisatie; een onbeperkte rol kan items koppelen over organisaties heen. Voor het item waaraan je koppelt **op**, zijn leesrechten voldoende: een Beheersmaatregel Writer kan bijvoorbeeld een risico aan een beheersmaatregel koppelen zonder een Risico-writerrol te hebben, zolang de organisatie van de beheersmaatregel dit toestaat. | Koppelen vanuit | Rollen die koppelingen kunnen maken | Koppelingen die ze kunnen maken | | ------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Risico | Risico Onbeperkte/beperkte beheerder, Risico Onbeperkte/beperkte schrijver | Beheersmaatregelen, MoI's en gegevensverwerkingsrecords van de organisatie van het risico | | Beheersmaatregel | Beheersmaatregel Onbeperkte/beperkte beheerder, Beheersmaatregel Onbeperkte/beperkte schrijver | Risico's, MoI's en gegevensverwerkingsrecords van de organisatie van de beheersmaatregel | | Beheersmaatregel | Beheersmaatregeltester, Beheersmaatregel Reviewer | MoI's van de beheersmaatregel; risico's en gegevensverwerkingsrecords zijn alleen-lezen | | Incident | Gebeurtenis Onbeperkte/beperkte beheerder, Gebeurtenisbeoordelaar, Gebeurtenis Verantwoordelijke | Risico's, beheersmaatregelen en MoI's van de organisatie van het incident (de Verantwoordelijke terwijl het incident in de beoordelings-, verbeter- of reviewfase zit) | | MoI | BIM-beheerder | Beheersmaatregelen en gegevensverwerkingsrecords van de organisatie van de MoI | | MoI | Auditor | Risico's, beheersmaatregelen en gegevensverwerkingsrecords van de organisatie van de MoI | | MoI | MoI Verantwoordelijke, MoI Gedelegeerde | Alleen bekijken | | Gegevensverwerkingsrecord | Data Management Onbeperkte/beperkte beheerder, Data Management Onbeperkte/beperkte schrijver | Risico's, beheersmaatregelen en MoI's van de organisatie van het record | De viewerrollen van elke module (Onbeperkte Viewer en Beperkte Viewer) kunnen gekoppelde items binnen hun scope openen maar kunnen koppelingen niet wijzigen. Voor de rechten rondom incidenten in het bijzonder, zie [Rechten nodig om risico's, beheersmaatregelen en MoI's aan een incident te koppelen](https://docs.cerrix.com/cerrix-functionalities/roles-rights-and-permissions#rights-needed-to-link-risks-controls-and-mois-to-an-incident). --- # 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/roles-rights-and-permissions.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.