Ensuring compliance requirements

Compliance requirements originate in different areas, for example:

• Legislative requirements

  Legislative requirements stem from laws such as national data privacy laws or financial laws. These requirements must be fulfilled at a national level.

• Requirements from authorities

  Requirements from authorities can sometimes be as strict as legislative requirements, for example, financial supervision rules. In other cases, the rules may have a more of an advisory character.

• Company’s internal rules

  A company or organization’s internal rules must be followed, however, exceptions based on a risk-analysis may lead to Omada Identity implementations that are increasingly company-specific, which is not easy to standardize as an Omada Identity product feature.

• Contracts

  Contracts with partners, customers, and other stakeholders are additional binding rules which must be fulfilled.

Categories

From the perspective of Omada Identity, most of the compliance requirements, no matter where they originate, can be grouped into one of the following categories:

• Requirements addressing the process flow (for example: two managers approving an assignment)

• Requirements addressing actual process data (for example: logging processes for later evaluation)

• Requirements addressing transparency (for example: Are there assignments without a valid ID?)

• Requirements addressing reporting (for example: ability to report the change of assignments of an ID in the past)

• Requirements to validate data and rules (for example: Is X role still correct?)

  note

  In the requirements to validate data and rules category, it should be noted that this applies to requirements which are to be fulfilled by the machine. Omada Identity cannot be fully compliant as the rules which are formulated must also be configured.

  Only some of the rules can be verified by a survey, for example, Omada Identity follows an SoD rule, but the accuracy of the rule is checked outside Omada Identity.

• Requirements for SoD (for example: Which toxic role combinations are enabled and why?)

The methods highlighted in the sections that follow – in combination with a well-defined governance – can help in ensuring compliance, some parts of which are performed outside Omada Identity.

Methods to ensure compliance

There are several methods in Omada Identity to ensure compliance. Some of these methods work as an integral part of the solution, such as logging mechanisms, while others might require configuration. All of the listed methods that follow are available out of the box.

Requirements addressing the process flow

Requirements addressing the process flow must be addressed by the configuration of the processes. The standard implementation of the IGA processes, as described in the Omada Process Framework section, allows for enough configuration (governance, filters, and others) to fulfill the standard requirements Omada sets with its customers.

The processes are built to follow compliance rules. They can be traditional build workflows or surveys.

Requirements addressing actual process data

In Omada Identity, every action and process step is logged. This ensures the transparency and data pool to evaluate what has happened in the past. Filters and rules act during the actual process flow and as such, minimizing incorrect and non-compliant results. The rules applied can be subject to an attestation through a survey.

Requirements to validate data and rules

The processes perform tasks and are controlled by rules and data. The Omada Identity surveys are used to run attestation and certifications of this rule and data. In addition, Omada Identity allows to configure new surveys or adjust existing ones without writing custom code.

Requirements addressing transparency

There are many compliance requirements that address the transparency of the results in an application. Omada Identity stores all important data in its databases, including rules and configurations. All data can be easily made available to entitled stakeholders, which is considered as maximal transparency.

In addition, there is an Auditor role which gives read access to all master data. By default, the menu items are not available to Auditors. The organization needs to decide which master data is relevant for the auditors to access.

Requirements addressing reporting

As all data is available in the Omada Identity databases, every needed report can be created. Omada Identity comes with several default reports and built-in dashboards as well as a toolkit to build additional reports. The following is a list of all dashboards and reports:

Dashboards and reports	Description / Remarks
All contexts	All contexts are shown. By opening the context details, you can see the owner’s name, list of assignments for the relevant context and other relevant information.
All identities	All identities are shown. The temporary change is shown in a time series graph.
All systems	All systems are shown. Shows details of a specific system, including the number of resources, accounts, and resource assignments associated with the system.
Audit trail	The audit trail shows information concerning assignments such as: - Accounts and identities belonging to a resource - Resource assignments
Multiple assignments	Multiple resource assignments per system.
Empty group	Empty group is shown.
Orphan accounts	Orphan accounts, or accounts without an assigned identity are shown.
Orphan groups	Orphan groups without an assigned identity are shown.
Not used account	Accounts which were not used during a specific time period are shown.
Omada risk check report	This report summarizes the following information regarding all systems: - Identities - Contexts - Accounts The following is the report structure for every system you may have available: - Systems - Identities, contexts and accounts - Resources and Resource assignments - Orphan objects - Account usage - Data quality - System activities (within a defined period of time) - Summary for target systems
Compliance workbench	The compliance workbench shows the status of the Resource assignments for each system and delivers detail by drilling down.
SoD conflicts	Overview of all SoD conflicts.
Manager view identities	Each manager sees the identities and their resource assignments with all data for which they are responsible.
Managed resources	Resources that an ID manages.
Managed systems	Systems that an ID manages.
Identities with pending evaluation	List of identities where an escalation due to violating rules is pending.
Identities with warning	List of identities where the calculation of assignments causes warnings.
Identities with errors	List of identities where the calculation of assignments causes errors.
My requests	Each ID sees their own requests with their status.
Provisioning status	The provision tasks are tracked, and the status is reported.