Why is that all the decisions taken following authorization assignments requests fall under the IT department?

Why should it be the IT who identifies which role to attribute?

The business should formulate a request so that the IT is able to process it without reiterations, or make available a tool for automatic authorization assignments provisioning, perhaps after an approval workflow.

What has just been described, unfortunately, almost never happens for several reasons, let’s see why!

• The business, in most cases, does not know the content of the technical roles requested to work on a certain task in the system:
  • The classic example might be the need to authorize a colleague from the purchasing department to the creation of purchasing requests. The manager of course knows what the colleague’s job will be, but they don’t know which technical role in the system permits to carry out this activity. Then, the IT involvement follows next, to translate the request in a “technical” format.
    This iter brings to a waste of time, especially when multiplied by the total number of users that ask for the same authorizations.

• Roles are unknown and too technical objects. Unfortunately, as already mentioned, it’s not enough to show to the various business departments a list of all roles in order for them to be able to translate a technical label in a functional one.
• In a company SAP Roles are most likely an IT related topic. Especially in small organizations, everything is delegated to the IT department, creating a degeneration of responsibilities.

But whose is the data present in the systems? It or Business?

Who are the owners?

Let’s say straight away that it’s not simply by sticking a label to someone that the problems mentioned above will magically disappear. It’s necessary to carry out a set of actions to make functions and processes more fluid over time.

Which would then be the owner concepts to adopt?

• Business area owner, they’re responsible for users in an organizational area. Every user must in fact be assigned to a business area owner (Manager)
• Business process owner, they define how organizational processes are built and by which activities they are formed
• Data owner, they are responsible of the most important part of processes: data. They have a particularly significant role regarding data accountability.
• Role owner, who is defined in two different figures:
  • Role owner content, they’re responsible for the roles technical content. Which are the authorizations and SAP transactions that a certain role contains and therefore the restrictions that it needs to have?
  • Role owner assignment, they decide which users can or cannot have a certain role assigned.
• SoD rule owner, they oversee physically modifying the Segregation of Rules rules.
• SoD Risk owner, they’re responsible for the risks' definition. Content and level of risk. Many risk owners can be present in one company
• SoD mitigation control owner and tester, they’re responsible for the design of the mitigation control. The control tester is the one who will physically conduct the controls.

How can the owners be of help?

When talking about authorization management, supposing that a model of roles based on professional figures exists, the identification of a role owner (in the two possible types) can facilitate:

• Role change. The business knows how the roles are constructed and what they should contain. All requests towards the IT department are then very precise.
• User attribution. The business is aware of what users should or shouldn’t be assigned to the various organizational roles. Also in this case, support requests are much more precise and require no further iterations to be fulfilled.
  
  

The described scenario can be realized through iterations via mail, or even better, through the use of approval workflows.

The tool that SAP puts at disposal to manage the users and roles lifecycle is called SAP Governance Risk and Compliance Access Control. In particular, the Access Request Management (ARQ) and Business Role Management (BRM) modules.

The ARQ module allows to define approval workflows that govern the users' lifecycle, particularly during hirings, job switching and termination.

The BRM module, instead, allows to define methodologies that must be followed by who constructed the organizational roles during the definition of the authorizations.

These methodologies can contain approval steps that formalize the various steps of the lifecycle of the authorization organizational roles.

For both tools a formalization of the owners is requested, so that it may be possible to configure and utilize the available functions.

It’s not necessary to have the SAP GRC Access Control tool to activate a process of users and roles lifecycle management, even though it is surely useful.

Defining owners inside the organization and utilizing the already existing tools is for sure a good first step, instrumental in facilitating the adoption of tools like GRC Access Control

Still unclear on how to define owners? Tell us your needs, we have faced many such projects.

Blog post originally translated from: https://www.aglea.com/blog/quali-sono-gli-owner-nellarea-governance-e-security