SAP HCM: dual control principle

Payroll accounting, time evaluation: the HR department probably places the highest demands on data protection and security in the entire company. The dual control principle for processing and releasing sensitive data is an important security mechanism here. Here we explain how to implement the dual control principle in SAP HCM as an authorizer.

Let’s assume that there are three teams in the HR department: each team includes a few clerks and a team leader. In future, time evaluation and payroll accounting are to be reorganized: In future, clerks who record and process data for time evaluation should approve each other’s data records before they are used for payroll accounting (symmetrical dual control principle). In future, clerks who process payslips will only be able to create data records. However, these must be approved by the team leader (asymmetrical dual control principle).

Let’s assume that there are three teams in the HR department: each team includes a few clerks and a team leader. In future, time evaluation and payroll accounting are to be reorganized: In future, clerks who record and process data for time evaluation should approve each other’s data records before they are used for payroll accounting (symmetrical dual control principle). In future, clerks who process payslips will only be able to create data records. However, these must be approved by the team leader (asymmetrical dual control principle).

Authorize dual control principle via P_ORGIN

This requirement sounds more complicated than it is – at least when it comes to authorizations. You simply make the specification in the P_ORGIN object (or P_ORGXX). The “Authorization level” field is decisive here.

To implement the symmetrical dual control principle, you need the value “S”, for the asymmetrical dual control principle the values “D” and “E”:

  • Users in whose role the field is marked with “S” have write access and can unlock data records – but only those that were last edited by another user.
  • Users with the value “E” are only authorized for locked writing. They can therefore create data records, but these must then be unlocked by another user.
  • Users with the value “D” can change the lock indicator. They can therefore unlock/release locked posts.

Because some programs have problems if read permissions are not explicitly assigned, the value “R” (read) is also relevant.

Important: With the asymmetric dual control principle, you automatically authorize the deletion of data records via the D-/E-Level. If only S authorizations are assigned, none of the users can delete data.

In our example, the time evaluation clerks are assigned roles in which P_ORGIN (or P_ORGXX) is defined as follows:

Authorization level: S, R
Infotypes: 2001 – 2005 and 2011

You define the fields Personnel area, Employee group, Employee subgroup, Subtype and Organization key according to your specifications or with *.


The object can look like this for payroll clerks:

Authorization level: E, R
Infotypes: 0008, 0014, 0015

The team leaders who have to release the salary data records receive the following in return:

Authorization level: D, R
Infotypes: 0008, 0014, 0015

Here you also mark the remaining fields of the object according to your specifications or with full authorization (*).

Important: If you restrict subtypes in addition to infotypes, please remember to also include a space in the subtype field. This allows you to grant authorizations for data that is not defined with subtypes. If you forget the space, users will not be able to access any data records that are only defined using infotypes (and not subtypes).

Leave a Reply

Your email address will not be published. Required fields are marked *