HCM/HR: Infotype 2 - too broad for all types of users vs. technical limitations of SAP

[Former Member]

Dear colleagues,

have you encountered the following business problem (see below)? I understood it is quite common in some companies (it is also well-known in mine). What do you think could be a possible solution to that today (i.e. with the tools and solutions available today)? What do you think SAP could do (i.e. how could they change their product) to help resolving this problem in the future? I appreciate your input and your views.

Problem:

Infotype 2  is too broad for all types of users, who require access to a single piece of information stored in it.

Detailed problem description:

Infotype 2 in SAP HCM (HR) is a data container which stores Data Privacy sensitive personal information in number of data fields. Whenever there is a new business requirement (coming from a given business user group) to access given piece of information stored in the specific data field within infotype 2, we encounter a problem. Due to technical limitations of SAP HCM:

-          no ability to restrict access to specific field within Infotype 2;

-          no ability to restrict access on the subtype level (infotype 2 does not have subtypes)

we are “forced” to consider assignment of access to Infotype 2 for that particular user group. Now, this is giving headaches to our Data Privacy Officer, who dislikes very much when we (IT for HR) propose to assign full access to this data container (Infotype 2) in order to meet the requirement of providing access to the single piece of information stored within that big container.

Available solutions at the moment:    

1. Creating custom transaction codes which display the required single pieces of information from Infotype 2. Then, including these custom transaction codes in the roles of specific business user groups. At the same time - making sure the user group does not have access to PA20/PA30/PRMS transactions.

Very often, it is difficult / impossible to apply this solution because:

a)        a) given role of the user group requires access to PA20/PA30/PRMS in order to be able to view/maintain another infotype

           b) infotype 2 is widely used in standard authorization checks (not really willing to override standard authorization checks)

2. Push back on the requirement and refuse to provide access to the required piece of information. That is normally not preferable as, apart from creating a lot of noise in the organization, it undermines the reputation/image of Central (Head Office) HR, IT Security, Data Privacy Officer... etc for being too “rigid” and not responsive to the real needs of the business user groups.

Ideally:

It would be great to have some methodical solution to this problem at its core i.e. embedded in the SAP HCM (HR) design so that a standard solution could be applied in such cases. Slicing Infotype 2 into smaller pieces? Making field masking available perhaps?

What do you think?

[Former Member]

Hi Pawel,

I think there is a fair case for encryption/masking of certain elements of personal data in a similar same way to how payment card data has been restricted.  That would deal with multiple entry points (transaction, FM/BAPI, table etc).  Just extending 0002 to include subtypes would give more control though there is still the constraint on getting to the data via alternative routes.

I know that you don't want to override standard checks but it is worth considering using the enhancement framework to put in additional checks and logic when data from IT2 is selected. I've not had a look in any great detail but an example could be to use something like enhancement PBAS0001 to provide an additional check (e.g. against auth object zprivacy) and hide or mask sensitive fields for users who do not have sufficient information.  Integrating this into reporting capabilities (at least on the ECC side) could be problematic but possibly worth a look with a developer who knows HR.

Cheers

Alex

[Former Member]

Creating custome report to display infotype data  is a solution if only display access is needed.

You can use the object P_ABAP to just provide access to the required abap program so the report is displayed without any infotype authorization checks

This way you wouldnt need alter their access levels to PA20 and other transactions.