HR GDPR Compliance with SAP-HR: Analysing the logs matters

This post is the 2nd in a series of posts around HR GDPR on SAP that explain the operational aspects of managing (sensitive) HR data on past and current employees. You can find the first post in this series by clicking here.  Subscribe to receive automatically the whole series.

This blog provides an overview of logging in SAP-HR. After reading this article, you will understand:

  • Why analysing logs matters
  • Items to look for in logging analysis
  • Different logs available in SAP and SAP-HR
  • Three logs HR should analyse

Reasons for logging analysis

Within the General Data Protection Regulation (GDPR), guaranteeing confidentiality of personnel data becomes even more important. Confidentiality means: “Information should not be made available or disclosed to unauthorised individuals, entities or processes.” With GDPR, only a contractual or legal ground represents a legitimate interest of the company to lawfully store, access and process personnel data. In other words,  personnel data should only be accessible to individuals fulfilling the contractual and legal obligations of the organisation.

Confidentiality of data can be achieved upfront by authorisations. Before a user ID accesses certain data, transactions, or reports, SAP authorizations check to see if the user is allowed to do so. But what did the user really do in the system? And what if authorisations are too large and give the user too many rights?

What user IDs really did in the system can be reviewed afterwards by analysing the log. The log registers who accessed which data, transaction, or report and when they did so.

The purpose of analysing the log is to:

  • Tune your authorisations to what is minimally needed to perform a task
  • To discover data breaches: the unlawful disclosure of data

To prove GDPR compliance and the absence of data breaches, a regular check of the log is a necessity.

Items to look for in logging analysis

Analysis of logs is considered time-consuming work for auditors and the Basis team. What is left for HR or SAP-HR consultants to analyse? Let’s assume auditors and Basis are doing their work: setting up proper authentication, applying security patches, analysing changes to user IDs and authorizations, digging in the system log, monitoring transports, etc.

To guarantee confidentiality of personnel data and to act lawfully and in accordance with GDPR, HR should be looking for users unlawfully reading, changing, or distributing:

  • Sensitive data. Examples include: Ethnic origin, union membership, religion, biometric and genetic data, sexual orientation
  • Data which can lead to identification. Examples include: User ID, name, address, bank account, social security number, license plate
  • Data with financial impact. Example is remuneration data. Disclosure of this data has an impact both on employee and on employer.

But to do this properly, you have to find out:

  • Which tables / infotypes store sensitive data and identifiers?
  • Which transactions and reports read these tables?
  • Which tables, transactions and reports do users with a certain task / profile normally use?

Your goal is to identify unlawful, unusual behaviour such as uncommon transactions, reports and infotypes, massive downloads or a user changing his/her own data. However, to know what is unusual, you first need to know what is usual. Go to processes and work instructions to see what users are supposed to do. Look at the most common transactions in the system log. And verify, for example, the PA-change log to see who accesses usually which data.

 

After you have specified in detail what users usually do, you can filter out automatically (why not?) the massive amount of usual transactions and data access in order to be left with a much smaller list of unusual actions. These exceptions can be an indication that there is a unlawful behaviour such as a data breach: a data leak to persons who should not see or change this information.

Different logs in SAP (across modules)

The challenge in SAP-HR is not that SAP and SAP-HR do not provide logging. The first challenge is that SAP provides too many logs, each with its own purpose. The second challenge is that every log provides information about both usual and unusual transactions, where the interest is on the unusual actions only.

Common examples of logs in SAP in general (and their transaction codes) are listed below:

Table History (SCU3). When a table has been changed, the table is flagged as “to be logged” (SE13) and if the system parameters enable table logging, the change is recorded in the table history log. In SAP-HR, for example, the customising of the change logs (tables T585*) should be monitored.

Program Changes (SE84). All changed programs between two dates can be listed with SE84. To see the difference between the old and the new versions, you can use “Version Management” in the ABAP editor. Also code changes in generated programs (e.g., SAP Query) are logged with a date.

Transport Import History (via STMS). Among others, this transport log gives an overview of all transports imported in a system.

Workload Monitor (ST03N). The workload monitor gives an overview of all transactions executed and at the detail level also who has executed these transactions. Statistics from the workload monitor are typically kept for three months before they are deleted.

Statistics Display or Business Transaction Analysis (STAD or ABAP RSSTAT26). STAD gives a very detailed overview of transactions executed (what, when, by whom). It is also accessible via ST03N. Though STAD offers more detail than ST03N, data in STAD is typically only kept for around 2-3 days.

A condensed example of the STAD log is shown above. Because the programs are displayed clearly, it is not difficult to find out who was reading what information.

Application Log (SLG1). Programs can “drop” an event in the Application Log. For example, program RPUDELPN Delete Personnel Numbers drops an event every time a personnel number has been deleted.

Read Access Logging or UI Logging (SRALMONITOR). The read access logging permits you to configure and log read access to any table displayed on nearly any screen in SAP. Who was reading what when? For performance reasons only tables with sensitive data should be monitored.

User Information System (SUIM). The UIS permits to display changes by date in: user IDs, roles, profiles and authorisations. You can also display the change documents for all of these objects.

Download Log. It would be great if SAP also provided a log to monitor who downloaded data to PC (via ALV, copy to clipboard or spool). Unfortunately, I am not aware of this.

Different logs in SAP-HR

Loggings specifically for SAP-HR are:

Change Log for Personnel Administration (report RPUAUD00). This log displays all changes (not read access) to infotypes in Personnel Administration.

Change Log for Organizational Management and Personnel Development (report RHCDOC_DISPLAY). This change log displays changes to all objects used in OM and PD by customising change documents.

Report starts (report RPUPROTD). Via customising you can register all executions of SAP-HR reports. This presents two disadvantages. First, the report should use logical database PNP or PNP-CE. Second, the customising table is inclusive, not exclusive. The report has to be in the customising table, otherwise it is not logged. It is not possible to tell SAP to “log all report starts except start of report xyz”.

SAP-Query logging (via SQ02). For every infoset, you can indicate whether use of the infoset by launching a query has to be logged (table AQPROTCUST). Then you  can use user group /SAPQUERY/SQ and the InfoSet /SAPQUERY_LOGGING (table AQPROT) to read the starts of SAP queries. Of course, this log only works for SAP Queries.

Three logs HR should analyse using log filtering

The goal of log filtering is to give quick, automated and “one button” answers to questions as:

  • Who inside HR is changing their own data?
  • Who outside HR is displaying / changing HR data?
  • Who in or outside HR is displaying / changing sensitive HR data, but usually doesn’t do this?
  • Who outside of HR is executing transactions / programs dealing with HR data?
  • Who in or outside HR is executing transactions / programs dealing with sensitive HR data, but usually does not do this?

To complement the work done by auditors and Basis, HR should minimally use the following logs:

  • Change Log for Personnel Administration (report RPUAUD00)
  • Read Access Logging or UI Logging (SRALMONITOR)
  • Statistics Display or Business Transaction Analysis (STAD or ABAP RSSTAT26)

In the first phase, HR monitors the PA Change Log* and the Read Access Log. With the last log, you can also monitor read access, not just changes. To filter out information, HR focusses on infotypes storing sensitive information, identifiers and remuneration data. And HR focusses on unusual behaviour. Because of previous analysis by HR, every user ID has a profile storing which infotypes the user normally accesses. This profile is used to highlight only the unusual access, especially to sensitive data. All information concerning usual access is automatically filtered out.

* By itself, using the PA Change Log is standard best practice in SAP-HR. However, the key to making this information easily accessible / useful is to automatically highlight in the output only the relevant infotypes and unusual access to infotypes. Most customers are not capable of doing this automatically and therefore spend too much time finding the useful exceptions.

In a second phase, HR also monitors the STAD or system log. HR has a list of HR transactions and reports dealing with sensitive data. Because of previous analysis, every user ID has a profile that  stores which reports the user normally executes. This profile is used to highlight only the unusual executions. All information concerning usual report executions is automatically filtered out.

Sources

 

Related posts

Leave your comment Required fields are marked *
The Adessa Group was founded in 2005 as a specialized, pan-European Human Resources service provider. The company was founded with the vision of supplying sustainable computer solutions through the development of an international network of subsidiaries, close to their customers and with the aim of growing organically. This vision was translated through the values that shaped Adessa’s corporate culture.   You can follow us on LinkedIn by clicking here.