Database Reference
In-Depth Information
Note the following points:
• The data migration process supports only an initial
load, and it is a one-time process. Data load cannot
be run iteratively.
• Imported data will not go through the review and
approval process.
• Imported records appear immediately in the
application. Their state is defined in the import
template.
• The imported data log is associated with the
username of the user who ran the report.
Setting up user profile for regional roles
eGRCM GRC security employs a standard Role-based Access Control ( RBAC )
model. You can combine security components—privileges, data roles, duty roles,
and job roles—to define who can do what on which set of data. Within the job role,
two types of duty role, (which ultimately invoke sets of privileges) determine what
set of data, and data roles determine which set of data.
This structure supports reusability. In order to define new job roles, you can use
a given functional-access definition (set of duty roles) over and over again with
varying data-access definitions (sets of data roles). Likewise, you can use a given
data definition with any number of functional definitions. Keep the concept of
reusability in mind as you build out duty and data roles.
GRC assigns individual users distinct combinations of rights to data and functionality.
In order to define access to functionality, it uses the following components:
• A privilege is a specific feature that GRC can make available to users.
• A duty role is a set of privileges. Each duty role defines one or more tasks
that a user can complete in the application. For example, creating controls or
approving changes to them.
• A job duty role is a set of duty roles. It encompasses the functionality
that a user needs to do a large-scale job such as Control Manager or
Risk Manager.
 
Search WWH ::




Custom Search