Many companies are moving away from using SSNs for unnecessary reasons because this practice might lead to a breach of employees’ personal security and privacy. Companies still using the SSN for purposes not related to its prescribed use in payroll, tax, and benefits may potentially face costly legal bills and new liabilities.

Despite your best efforts to remove SSNs from view, searches using the personal ID (PERID) as a search help field can lead users to SSNs and other personal identifying information (PII). The search help function (F4) in SAP provides a tool to identify personnel records stored in the SAP HR system. I’ll examine two key search help components and show how to use them to reduce the exposure of PII data in your company.

The first component associated with the search help is the delivered search help PREM. PREM is the delivered collective search help for personnel numbers (PERNR). Your system uses it when you need to determine a personnel number. Table DD30X stores the search helps. This table uses predefined fields that the system identifies as commonly used criteria in personnel data searches.

Search helps also can use an SAP-defined or customer-designed InfoSet as a search tool. R/3 and mySAP ERP Central Component (ECC) 5.0 and 6.0 use InfoSets with the querying tools InfoSet Query (formally Ad Hoc Query), SAP Query, and delivered SAP reports. HR InfoSets usually consist of master data infotypes in Personnel Administration (PA) and organizational infotype data in Organizational Management (OM) or Personnel Development (PD). The delivered tools and queries usually use one of the SAP-defined logical databases. The key HR logical databases are PNP and PCH. The SAP system determines the logical database for any delivered functionality and companies determine the logical databases for their specific needs.

The search help functionality consists of queries of personnel data to determine a list of possible selections. Users see this list and select the record they wish to examine or process. The search help uses key data fields to provide criteria to search for personnel records. Some of these fields may allow access to PII data. My advice about search helps applies to all versions of R/3 and ECC. The InfoSet parts apply to R/3 4.6C and above because InfoSet functionality was not present before then.

Suppress Included Search Helps

SAP provides SSN as a key for searching for HR records. This possibly exposes all of the system’s SSNs to any person running a search for a PERNR. SAP delivers the search helps with the personal ID (PERID) as a search help field. Users still might access otherwise hidden SSNs using a search help. A global personnel ID search returns all SSNs in the system matched to the PERNR (Figure 1). Even with the system set to prevent viewing of the SSN using configuration, the PERNR and SSN may link to other critical PII such as birth date and address.

Figure 1

A sample global personnel ID search returns all SSNs in the system matched to the PERNR

Any user authorized to view infotype 0002, which includes employee names, would be authorized to see the SSN. That is a common problem for SAP HR implementations and the root cause of why you must alter these search helps. All users generally have access to the search helps relative to their roles and these may or may not have HR components as part of the search components.

SAP ECC and R/3 provide the ability to configure the search help functionality. To adjust the search helps to minimize PII exposure, use the IMG. Navigate to the IMG using transaction SPRO. Select the SAP standard IMG view. Within the standard IMG, follow Personnel Management>Personnel Administration>Basic Settings. The system displays a series of configuration choices. Execute the Maintain Search Help option.

You may see two pop-up screens notifying that you are maintaining or making repairs in a foreign namespace and determining whether you are maintaining the data in the original language (German) or in the logon language (English in my example). Acknowledge the warning and select your preferred language. The system displays the collective search help PREM (Figure 2). This figure shows the entire search help PREM and the included search help PREMC. PREM is a superior object to the included search help component PREMC.

Figure 2

The PREM search help shows the attribute, definition, and included search helps

The collective search help (the highest or superior object in the search help function) consists of elementary search helps (subordinate objects in the search family of components) or other collective search helps (search help objects usually set in a superior function, but the system uses them as subordinates in some cases). The system shows these under the Included search helps tab (Figure 3).

Figure 3

Included search helps (subordinate objects) for the collective search help (superior object) PREM

The search help PREMC contains the personnel ID number. Make sure to scroll to the bottom because PREMC sometimes appears on the second page. Double-click on the included search help PREMC to display the underlying parameters. The parameters are the associated objects or fields for any of the included search helps. They provide the specific reference or data field that users see when they invoke the search help. Figure 4 shows the PERID assigned as a parameter to included search help PREMC.

Figure 4

Parameters making up the PREMC included search help

Navigate back to the collective search help using the green circle icon. You can suppress any included search help by selecting the Hidden check box within each collective search help (Figure 5). Selecting the Hidden option for one collective search help does not hide it in other collective search helps. Rather, it suppresses the search help parameters that comprise the subordinate included search help, in my example the PERID element. This technique limits exposing the SSN inadvertently while allowing other methods of searching.

Figure 5

The PREMC included search help has PERID as a component

Alternatively, you can remove the PERID field from the collective search help in lieu of hiding it by selecting the PREMC parameter and deleting it from the collective search help. Both options provide protection of the SSN within the search help function, and no significant functional differences exist.

Limit the Free Search Component

The second area where you can limit PII exposure is the free search component of the search help. The free search help accesses a predetermined InfoSet that allows the user to select search criteria from an InfoSet. This uses the same selection functionality as the InfoSet Query (formerly Ad Hoc Query) reporting tool.

Turning off the free search eliminates the need to alter or create any InfoSets. In an implementation that restricts or prohibits InfoSet queries, this may be the most efficient means of limiting this form of PII exposure. You can turn off the free search using a setting in table T77S0 or by accessing the switch through the IMG. Within the standard IMG, follow menu path Personnel Management>Personnel Administration>Basic Settings>Hide Free Search in Search Help.

To disable the free search functionality, you need to locate the Group SEARK and the Sem. abbr. (semantic abbreviation) NOAHQ. Type X in the Value abbr. field (Figure 6).

Figure 6

In table T77S0, set the Value abbr. to X to suppress the free search functionality

Users can access the free search function using the assigned InfoSet delivered in the standard SAP system. This may allow users to access PII information such as data in the PERID field. Minimize this by changing the assigned InfoSet to a different custom InfoSet. To change the InfoSet, check the following two important items before making any changes.

First, ensure that you’ve assigned a different InfoSet than the standard InfoSet assigned in the standard system and that you do not alter the delivered InfoSet. SAP delivered reports use it, so changing this InfoSet may affect standard reporting functionality. Second, if users have any assigned value in their user parameter AQS (for setting a specific InfoSet for that user), this may cause problems with the free search. It may return a message stating that the system found no values and that no selections are available. If you see this message, check the user’s parameters for an AQS value. Try deleting it and checking for the same error message.

Investigate and resolve these two items, then change the InfoSet to a customer-defined one that does not include any PII data. The steps for creating a custom InfoSet appear in Graham Wong’s June 2005 HR Expert article “Ask the HR Expert: Save Time by Moving Your Existing Queries to a New InfoSet,” so I won’t discuss them here. When creating a custom InfoSet, make sure to create the InfoSet in the global query area. This is necessary to ensure the new InfoSet is available for the free search functionality.

Navigate to table T77OMAHQ_FUNCAR using transaction SM30. SAP standard table T77OMAHQ_FUNCARS assigns the free search functionality to InfoSets. This table includes the SAP defined InfoSet /SAPQUERY/HR/ADM as the delivered free search InfoSet. You can find this InfoSet in the EMPLOYEE scenario related to the object P for person (Figure 7).

Figure 7

Table T77OMAHQ_FUNCARS with the entries relevant to free search highlighted

Create an entry for the object P and optionally for the scenario EMPLOYEE. PERNR searches do not use the employee scenario, although you can assign this scenario to them. Enter the customer-defined InfoSet in the InfoSet field.

SAP provides a customer view of this table, T77OMAHQ_FUNCAR. This allows you to include a customer-specific InfoSet for any of the objects or scenarios that reference a free search functionality. Object P is the relevant object for the free search in the Personnel Administration (PA) area. The EMPLOYEE scenario is the specific scenario for these search helps. The object type associated with a search help is more important than the scenario as it provides the points of entry when the search helps invoke the InfoSet. The system uses object P more frequently and in more places than the direct search assignment to EMPLOYEE. If there is no scenario assigned in the T77OMAHQ_FUNCARS or T77OMAHQ_FUNCAR tables, all free search functionality associated with the object type P use the associated InfoSet (Figure 8).

Figure 8

Customer table T77OMAHQ_FUNCAR with the object P assigned to the customer InfoSet Z_HR_PA

The system response for the PA free search or object manager follows a hierarchy. This hierarchy looks at the customer table T77OMAHQ_FUNCAR and checks for any EMPLOYEE scenarios, and then it checks the same table for any entries without a scenario associated with object P. If there is no customer definition, the system checks the SAP standard table T77OMAHQ_FUNCARS. It uses the same hierarchy as the customer table, checking the scenario and then the object.

When the search help is the source for the free search, then the system checks the same sequence as for the object manager but also checks the standard parameter settings AQB, AQS, and AQM. The values of these three settings represent query assignments for query area, InfoSet, and specific query. These are user-defined parameters and usually each user has the ability to change them. They are not defined by default. Any of these set with a differing value than the desired InfoSet cause the system to display the wrong free search or possibly no free search and a message stating No values found (Figure 9).

Figure 9

System finds no values when the AQS field is populated

The final configuration is the entry in table T77OMAHQ_FUNCAR for object P and optionally the scenario EMPLOYEE. In this example, the customer-defined InfoSet Z_HR_PA is assigned. Click on the save icon to save the entries. This InfoSet limits the exposure of PII because the PERID (SSN) field was removed. In Figure 10, the custom InfoSet shows the inclusion of infotype 0002 (personal data) with minimal data available for searches, allowing effective searches without exposing PII data.

Figure 10

Assign customer-defined InfoSet with restricted selections for infotype 0002. These restrictions provide protection for PII while allowing the free search functionality using common name fields.

Greg Robinette

Greg Robinette is currently a Level 5 Systems Engineer at Huntington Ingalls–Newport News Shipbuilding. His primary focus is on the SAP systems and supporting the delivery of HR, Payroll, and Environmental, Health, and Safety business value. He is an active member of the Newport News Shipbuilding Information Technology Change Agent Network and provides support as needed to the Systems Engineering Community. Previously, Greg was an independent SAP HR/HCM, SAP Security and Privacy Technology consultant with over 15 years’ experience in SAP HCM, SAP security, HRIS, and privacy consulting. He is certified as an information security manager (CISM) by ISACA, as a Project Management Professional (PMP) by the Project Management Institute, as a Scrum Master (CSM) by the SCRUM Alliance, and as an SAP HR/HCM consultant by SAP.

You may contact the author at gregrobinette@cox.net.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.