Implementing Data Protection Impact Assessments with SAP GRC Risk Management

[AndersonOliveir]

 

An Overview of the Main Features of SAP GRC Supporting Privacy Impact Assessments

Authors:

Anderson Santana de Oliveira, Senior Researcher, SAP Product Security Research

Pollen Pei, Product Owner, SAP GRC Risk Management

 

1        Introduction

Data Protection Impact Assessment (DPIA) is used to assess potential harm to individuals as well as the risks to carrying out processes. There are strong requirements about the need to measure the impact of business on privacy within the revised European General Data Protection Regulation. Based on this regulation, running a DPIA is going to be mandatory for organizations in certain situations. Organizations will have to carry out a DPIA once the new EU General Data Protection Regulation (EU GDPR) is in effect (early 2018).

 

As a running example, suppose ACME AG wants to revamp its recruitment processes. It will start by integrating with social media – allowing prospect talents to use their profile information from LinkedIn, for instance. It also intends to collaborate with 3^rd party portal to publish statistics about the applications it receives. Moreover they will use some automated processing to match candidate profiles with the necessary skills for posted job offers.

 

By running Data Protection Impact Assessment (DPIA), ACME will be able to identify the main risks of this project with respect to the rights of data subjects. For instance, what is the risk of processing incorrect or inaccurate personal data when running the automated candidate matching task? What is the impact to the applicants if they are unable to modify their personal data from the recruitment system?

 

Using a systematic DPIA approach, ACME will elicit the threats mentioned above, and others affecting the privacy rights of individuals. ACME will also identify the procedures and practices in place to mitigate these threats. For instance, ACME can ask the candidate to verify all imported personal data from the imported external profile. In order to ensure accuracy over time, ACME can regularly remind the candidate to re-launch the importing procedure, or to manually change the personal data in regular intervals.

 

It is also fundamental to document how the risks were addressed in order to minimize harm to data subjects. For instance loss of confidentiality can be disastrous for candidates applying for a job at ACME. In order to participate to statistical data releases, ACME has to make sure proper anonymization of the applicant data has been carried out before transferring information to a 3^rd party portal.

 

A DPIA has multiple steps. The graphic below shows a simplified overview of them:

Figure 1 - Illustrative general steps for performing DPIAs

A DPIA will allow ACME to demonstrate its awareness about the risks concerning privacy and data protection and their commitment in ensuring an effective level of protection of personal data. By implementing the measures identified in it, ACME will safeguard of privacy and data protection rights for the candidates applying to jobs in their company. After the ACME signs off the DPIA, it shall conduct regular reviews of its personal data processing activities. It shall equally determine procedures to monitor compliance of its operation with respect to its own privacy policy, but also to ensure compliance the EU GDPR and other data protection laws.

 

In this document we explain how to take advantage of the SAP GRC suite to conduct DPIAs and to support a continuous improvement program for personal data protection. Figure 2 suggests a path for running DPIAs in using some powerful features in SAP GRC, which we will explain in detail in the remainder of the document.

 



Figure 2- Using SAP GRC suite features towards effective DPIAs

 

The readers of this guide should be aware that it has no intention to be a complete methodology for conducting data protection impact assessments, but to provide an overview of the features in SAP GRC Risk Management solution which support managing such process. The reader should refer to regulatory requirements, such as the EU GDPR[1], guidance published by data protection authorities[2] or yet standards[3]. The next section of the document explains the initial steps to prepare a DPIA using the GRC suite.

 

 

 

2        Regulations

In order to fulfil requirements concerning the EU GDPR or other, you will need to create a new regulation regarding your organizational hierarchy in the Master Data work center → Regulations and Policies. It is possible to enter as many regulation specific requirements as necessary as shown in the Figure below.

 

You can structure regulations in groups, according to your preferences. More importantly, you need to define the regulatory requirements your organization needs to satisfy. The Figure below illustrates one of them. Remark there are many other requirements in the full text of the EU GDPR and other data protection laws that are effective in the countries your company operates.

Figure 3 – Regulation hierarchies

 

3        Central Controls

In order to have meaningful risk assessments, we must allow to associate local controls to risk templates. For that, we must start from central controls, under the Master Data work center, select the target organization in the hierarchy and click open. In the sub processes tab, you can maintain central control definitions relevant to a given regulation. The screenshot in Figure 4 displays some example sub processes that are relevant for the EU GDRP and DPIAs in such context for ACME.



Figure 4- Examples of central control and relevant sub-processes for the EU GDPR

 

A central control has many functions. One of them is to allow for a systematic risk mitigation approach.

In order to configure them precisely, open the selected control to display the screen shown in the figure below. Anonymization, shown in Figure 5, is an important safeguard for ACME’s use case. It drastically reduces personal data leakages if properly implemented[4].



Figure 5 - Example of a central control definition

 

Be aware that some important characteristics to set are about central controls are: purpose, control automation, control category, control relevance, among others.

 

 

4        Response Catalog

Following the sequence suggested in Figure 1, in association with central controls, another useful resource for ACME is to set up in SAP Risk Management is the Response Catalog. Items in the catalog can help teams to select appropriate risk responses. For instance, the OWASP top 10 privacy risks project[5] presents some measures to enhance privacy. Some of them are listed in the figure below.



Figure 6- Example of privacy enhancing response catalog in GRC RM

 

5       Risk Templates

You can define risk templates in the Master Data work center→ Risk Catalog. SAP GRC helps you to document the criteria your organization applied in eliciting risks, the probability and impact thresholds used for the risk assessment, including the analysis profile selected for each risk template, as shown in Figure 7, where ACME is setting the analysis profile for this risk category. You can create a hierarchy following your own organization’s preferences.

Figure 7 - Setting Risk Template Analysis profile

 

Figure 8 - Risk hierarchy illustration

Figure 8 shows that ACME is going to assess whether its Digital recruitment project represents risks of processing sensitive data. There are multiple methodologies to elicit privacy risks. Data protection authorities have rolled-out guides for DPIAs, such as ICO (UK) and CNIL in France.

 

It is a worthy exercise to create privacy risk templates, as ACME may have distinct projects to process personal data across its units, they in their turn are subject to a DPIA. Figure 9 shows the general tab for the example risk template, whereas in Figure 10, ACME defines response templates that help to mitigate the risk on handling sensitive personal data. It is also important to associate central controls to each risk template, in order to have uniform risk treatment across organizational units. See Figure 11.



Figure 9 - Example of Risk Template

Figure 10 - Defining Risk Response Templates

Figure 11- Risk Template Associating Central Controls

 

 

6       Risk Surveys

DPIAs have been driven with questionnaires. See for instance the recommendation from the CNIL[6], the ICO[7], or yet from GS1 on the use of RFID tags[8]. These constitute considerable knowledge sources about privacy risks. In the examples in this section, ACME created relevant question libraries for assessing the privacy risks that may affect the data subjects for whom they are amenable to process personal data. SAP GRC offers advanced features for surveys, useful for assessing risks in a collaborative way, consulting all relevant stakeholders for each project or process in an organization.

 

SAP GRC RM allows importing surveys questions from external files (see Figure 12 and Figure 13). To start, ACME enters the question items. Notice this is one of the few entry points where we can introduce content directly in the current GRC implementation. Below we can see two screenshots of the Excel file used to create a data sensitiveness survey.

Figure 12 - Importing survey questions

Figure 13 - Importing question response items or choices

Figure 14 - Resulting Risk Survey

The resulting survey looks appears as shown in Figure 14 in the survey catalog:

 

ACME has the basic elements for performing DPIAs. With the help of risk templates and surveys, ACME will define the business processes, activities or projects for which it will run risk analysis. We present these steps in the following sections.

 

7        Activities

A DPIA contains the assessment of all risks to the rights and freedoms of the individuals from which you process personal data. Usually, your company will have multiple new projects and or processes handling personal data. One of the best manners to keep track of those is to use the concept of Activities in SAP GRC RM component.

 

Activities provide adequate features to assess personal data processing projects because:

 

• It has an approval workflow, that can be tracked, a helpful feature for documenting the DPIA process


• We can associate specific organizational and project risks to them


• It is possible to do recurrent assessments as the scope of the project (in this case a class of activity) changes.


• Activities can be categorized in a hierarchy (e.g. Projects, Products, Processes, etc.)

You can start by creating an activity hierarchy (Figure 15) and next, in the assessments work center, we can create activities (Figure 16).

 

Figure 15 - Defining an Activity Hierarchy

 

Figure 16 - Creating a new activity

 

 

 

 

It is then possible to add risks related to personal data protection in this activity. You can create a new risk from scratch, or you can use risk templates. A risk template catalog is an interest asset for GRC risk management implementations, since you can establish a standard in the way risks are defined and managed within your organization.

 

The risks and opportunities tab contains the information as shown below. Remark that in this activity example, the “Privacy” risk category was set with the quantitative analysis profile. It is perfectly possible to use other profiles; this does not affect the content we intend to provide. However, the current set of reports in the suite has more interesting features for the quantitative profile.

Figure 17 - Adding risks to an activity

This is the general tab for an example activity.

 

Figure 18 - Activity Risks overview

 

We can create a risk related to the activity using the provided templates. Notice the importance to define activity roles and risk roles for each risk.

 

The risks and opportunities tab contains the information as shown below. Remark that in this activity example, the “Privacy” risk category was set with the quantitative analysis profile. It is perfectly possible to use other profiles; this does not affect the content we intend to provide. However, the current set of reports in the suite has more interesting features for the quantitative profile.

 

 

8        Risk Assessment Planning and Risk Assessment

In the assessments work center, one can plan risk surveys and activity approval workflows.

DPIAs need to be reviewed whenever changes are introduced to projects and processes involving personal data. Organizations are also advised to regularly review impact assessments for their processing activities as part of their privacy management program as a routine task.

Figure 19 - Planning a Risk Assessment

 

Once plans are created, the user assigned the risk owner role will receive the risk survey as shown below.

We need to adjust the existing questionnaires.



Figure 20 - Risk Assessment Survey Responses

 

 

 

 

The risk survey result appears in the survey tab for the selected risk in the activity’s risk:

Figure 21 - Processing Risk Assessment Survey Responses

 

 

9        Reports

ACME must maintain documentation as evidence to demonstrate compliance and/or accountability with the EU GDPR. GRC RM reports offer support for explaining how the organization conducted the DPIA: which risks where identified and detail the selected countermeasures. An example of useful report is the Activity Fact Sheet, which we display in the screenshot in Figure 22:

 

Figure 22 - Extract of an Activity Fact Sheet

 

Further reports bring the probability and impact scales used. Moreover, it is easy for ACME to explain how risk assessment overall was driven, given that the full activity lifecycle is registered in RM.

 

 

10     Policies

 

Figure 23 - Defining new policy

Policies are key to ensure seamless knowledge and adherence to the corporate privacy practices throughout the organization. SAP GRC offers powerful features for creating policies, managing their approval workflows, distributing them to employees, and collecting their acknowledgment. The screenshot in Figure 23 illustrates the creation of the company’s privacy policy as the final step of the DPIA process. Often a DPIA will culminate in changes of process and practices towards improved data protection, which should be reflected in the privacy policies. GRC suite facilitates policy distribution via surveys and collect acknowledgement from all members in an organization.

 

11     Summary and Conclusions

In this document, we suggested how to use some of the main features of SAP GRC suite towards a privacy improvement program, starting with a Data Protection Impact Assessment. The scheme below recaps the different phases of a DPIA and the features from SAP GRC we presented along the document that are useful at each of the steps.

 

 



 

 

 

There are many more features in the SAP GRC suite that can meaningfully support your organization’s privacy management journey. Multiple analysis and reporting functionalities can provide insights in improvement areas, action execution, and incident handling as well. For more information on SAP GRC, contact our sales channels[9]. We recall that the present guide does not constitute legal advice in any way and that organizations implementing EU GDPR privacy program must verify all legal requirements are adequately addressed.

 

 

 

 

[1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ENG&toc=OJ:L:20...

[2] For instance the guidance by the UK’s Information Commissioner’s Office https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf

[3] As an example, consider the upcoming ISO standard “ISO/IEC FDIS 29134 - Information technology -- Security techniques -- Privacy impact assessment -- Guidelines” http://www.iso.org/iso/catalogue_detail.htm?csnumber=62289

[4] See the Working Party 29’s opinion about anonymization to know more http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/20...

[5] https://www.owasp.org/index.php/OWASP_Top_10_Privacy_Risks_Project

[6] Commission Nationale de L'informatique et des Libertés (CNIL): Methodology for Privacy Risk Management (2015).

[7] Information Commissioner’s Office: Privacy Impact Assessment Code of Practice,  (2014).

[8] GS1: Privacy Impact Assessment Tool. (Visited on 12/12/2016)

[9] http://www.sap.com/solution/platform-technology/analytics/grc.html