Role-based security model

Typical security points are business entities, processes, or sub-processes (can also be set at lower security point levels if wanted).

Figure 1 shows how various users and groups can have different permissions set for accessing business entities (a defined security point in the object hierarchy) and objects that are under a specific hierarchy.

Based on the type of security context points defined in your security model, such as Business Entity, Process, Control Objective or Risk Assessment, you can use a role template to define a set of permissions for a set of object types.

For each role template that you define, you can set the following:

• Access control (Read, Write, Delete, Associate) for each object type included in that role. For details, see Role-based access control permissions.
  
• Application permissions for the role. For information about the various application permissions, see Defining application permissions.
  Important: These application permissions do not include administrative group and user security management permissions, such as resetting passwords, assigning roles, adding users, and so forth. To learn more about assigning group and user security management permissions to administrators, see Delegate administrator permissions.

By assigning a role (an instance of a role template) to a user or group at specific security context point in the object hierarchy, you can control access to objects. Roles represent the usual or expected function that a user or group plays within an organization. Some examples of roles are: Finance Reviewer, Tester, External Auditor, System Administrator, Control Owner, Risk Assessor.

When you assign a role to a group or user, the security settings of that role template are acquired by that group or user and permissions are automatically granted, per the role template definition, to all objects below the specified security point.

For example, if a role were assigned to a user for a business unit (security context point), access control for specific object types under that security point would be set in the object hierarchy. Object types that were excluded from the role would be hidden from view, object types that were included would be visible and could be accessed by users and groups assigned to that role.

So that you can have a clear and accurate understanding of which users and groups have access to what and with which permissions, and what access control modifications were made in the system, you can run a variety of reports to view this data. For details on the types of configuration audit and security reports available to you, see the section Audit Reports folder.