Establish a Security Model

The Governance Portal features role-based security that supports user-definition of roles as well as the definition of business rules for each role. Establishing the security model is a two step process:

1. Define roles to be used - The system is installed with a set of default roles. New roles can be added to the system or existing roles can be modified based on the requirements of the organization. Typically, the roles used within a given organization correspond to the roles and responsibilities of individuals involved in the risk management program. For example, the risk management program may involve a single administrator responsible for security administration and maintenance of central system configurations; a central risk management team responsible for managing the core business frameworks; and globally disbursed process owners, risk owners, and control owners. If this is the case, then a role can be defined for each of these classes of individuals in the system. See Add a New Role for additional information.
2. Configure the business rules for defined roles - The default roles have pre-defined business rules that can be modified. Business rules can be defined for any new roles created as well. Configuration of a roles' business rules is a two-step process:
   1. Associate the role to Tab and Module Groups - Determines the roles' ability to interact with specified tabs and modules in the system. Tabs relate to the folders that are displayed to users in their left-hand navigation. Modules relate to the forms that are presented to a user in the content pane of the Governance Portal after having clicked on a given folder. Within a given folder, there are typically a collection of forms with which users may interact or drill into. A user is given permissions to certain areas of the system by connecting a role to one or more tab and module groups. See Add a Tab and Module Group to a Role for additional information.

   Notes: Roles can also be directly associated with tabs and / or modules. However, it is generally recommended to always associate roles via Tab and Module Groups for consistency. See Link Roles Directly to a Tab or Link Roles Directly to a Module for additional information. Tab and Module Groups that do not begin with an asterisk primarily mimic the folders that appear in the left-hand navigation tree. The forms found within these tab and module groupings are specifically associated with a direct navigation originating from a particular folder on the left-hand navigation tree. Associating a role with one of these tab and module groups will make left-hand navigation folders (and their associated forms) available to users assigned to a given role. The default Tab and Module Groups that begin with an asterisk primarily represent forms (i.e. modules) such as the RCM forms that can be accessed from multiple entities (e.g. organizational units, processes, IT systems, Projects and Events). Since these forms may be accessed from multiple origination points, they are grouped independent of any left-hand navigation folder as denoted by the asterisk. Because the ability to interact with these forms within a given entity is governed more specifically by a role's association to a given Permission Type, the All Users role is given default view, edit, add, and delete access to these types of forms. Thus, all users of the system will, by default, have an ability to interact with these forms. However, to truly view, edit, add, or delete a specific data element (e.g. control) housed by one of these forms, the user must also be associated to a role with the appropriate permission type as described below. The addition of new Tab and Module Groups is only necessary if new tabs and modules are added to the system (and, thus, need to be added to a Tab and Module Group) or if the default tab and module groupings don't satisfy unique security requirements. It is generally recommended to not make changes to existing Tab and Module Groups. See Manage Tabs and Module Groups, Edit Tabs or Sub Tabs and for additional information.

   1. Associate the role to Permission Types - Determines the roles' permission as it relates to specific content in the system. Tabs and modules house data, or content within the Governance Portal. While a role's connection to a Tab and Module Group makes certain folders display in the system and allows a user to interact with specified forms (e.g. the Control List form), Tab and Module Groups do not determine the specific content with which a user should be able to interact (e.g. the specific controls that would be displayed within the control form). A role's connection to permission types determines how users assigned to the role will be able to interact with specific content presented through a given form. See Add a Permission Type to a Role for additional information.

   Notes: Permission Types only pertain to the following data elements of the system: Action plans, audits, audit activities, controls, documents, document groups, findings, IT applications, objectives, projects & events, risks, risk event categories, risk matrices, tasks, tests, work papers. For these data elements, permissions are governed by a role's association to the tabs and modules that house the data (i.e. via a Tab and Module Group or via direct linkage to tabs and modules) AND the role's association to the permission types related to each of the above data elements. For all other data elements, permissions are exclusively governed by a roles' association to a tab and module (i.e. via a Tab and Module Group or via direct linkage to tabs and modules). Data elements that do not have associated permission types (e.g. financial element) reflect data elements where permission is always applied enterprise-wide (i.e. based solely on the role's tab and module permissions). For example, if a user is assigned to a role that can edit one financial element (via association to the appropriate tabs and modules), this user will be able to edit all financial elements. On the other hand, assignment to a role that can edit controls does not necessarily mean that the user can edit all controls. Configurable forms contained within the system (e.g. the Control form) employ field-level security through the Visible Only property. It should only be necessary to update field-level security to address specific security concerns. See Configure Field Level Security for additional information.

Example: In the screenshot below, the roles' association to a given tab and module group determines the folders (e.g. My Portal / My Lists / Controls) that users connected to the role are able to see. The roles' association to a given tab and module group also determines the user's permissions with respect to the collection of forms resident within a given folder (e.g. this users' role is giving them the ability to view the Owned Controls list resident within the My Portal / My Lists / Controls folder). It is the roles' association with a set of permission types that establishes users' ability to interact with specific content contained within a form. For example, this particular organization may have thousands of controls across the enterprise, but the user is only able to view their specific controls.