GDPR for SAP: How to restrict personal data processing?
Welcome to the third article of GDPR series on restricting access to personal data (the previous articles answer the questions What are the Security Requirements? and How to find personal data and assess privacy risks?).
SAP provides a wide spectrum of protection mechanisms to make SAP systems safe. They are described in SAP documentation in detail, but the configuration of all these measures can be a tough job, and it’s not always apparent how they operate as a whole and contribute to the business value. Security is often seen as a necessary evil because of the related spending and slowdown in current operations.
That is why it makes sense to consider GDPR privacy requirements. It is a perfect example of security as an enabler, in this case, of digital economy. People don’t trust organizations processing their personal data and should be given more control over their data as well as assurance that the businesses follow best security practices.
In this series of articles, we observe the measures that a company running SAP systems could implement to give assurance to business owners, clients, and officials that personal data processing is governed by strict privacy rules.
We identifies 3 groups of security requirements in the article “GDPR Explained: What are the Security Requirements?”:
- Assessing existing data processes and systems
- Restricting personal data processing
- Monitoring data breaches
The figure below illustrates the relationship between GDPR Security Tasks and SAP system lifecycle.
Once the SAP system is identified in the scope of GDPR, the data controller (or processor) must assess data processing in the system, that means to find personal data and users having access to it, evaluate security controls and detect risks to data subjects if the data breach occurs. These activities were described in the previous article “GDPR for SAP: How to find personal data and assess privacy risks?”.
This article explores the second step: how to treat the found issues and restrict personal data processing in SAP environment.
According to the regulation, data processors have to restrict access to personal data, implement security controls to ensure that restrictions do contribute to privacy, and maintain personal data security lifecycle. These 3 steps can be viewed as 3 tiers for protection maturity: mechanisms, activities, and lifecycle.
Restrict access to personal data
First, we need building block for security. The following table shows by no means an exhaustive list of security mechanisms to restrict access to personal data used in SAP environment. This table intends to demonstrate that SAP systems are protected on all layers.
|Layer||SAP Components||Security Mechanisms|
|Presentation||Client devices and GUI||Access controls|
|Communications||Data flows|| SAP to SAP: XI/PI, RFC, SAProuter|
SAP to User: SNC, SSL, PKI
Network to Network: VPN, SAProuter
Segregation of Duties
Users, roles, SSO and password auth
UI Masking and Logging
|Platform||SAP platforms, databases, operating systems||Secure configuration of OS, DB and SAP components|
Database and volume encryption
OS Identity Management
These security mechanisms are detailed in security guides, administration guides, and SAP security notes and constitute security model of a reliable SAP system. But these are just building blocks.
Implement and describe security controls
A more mature way to manage security is to implement security activities or processes meeting company’s security objectives. The activities make use of afore-mentioned security mechanisms and produce outcomes meaningful for providing security.
The security activities specific for SAP environments are described in SAP Cybersecurity Framework (will be referenced as SCSF) that is freely available.
Let’s consider controls from the SCSF contributing to data privacy.
Article 32 of GDPR requires that “controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk” and mentions 4 categories for the measures. If we take activities related to these categories from SAP Cybersecurity Framework, we’ll get the following list:
- Pseudonymisation and encryption of personal data:
- SCSF. Data Security
- SCSF. Secure Architecture
- SCSF. Asset Management
- SCSF. Access Control
- SCSF. Business Environment
- SCSF. Incident Response
- SCSF. Vulnerability Management
- SCSF. Threat Detection
Don’t treat this list as a complete one but as an example of leveraging recommendations of SAP Cybersecurity Framework to organize GDPR security processes.
The key idea is that any compliance requirements mandated by GDPR, GLBA or ISO27001 may be addressed by security controls from SAP Cybersecurity Framework. This layered approach (from requirements to controls and further to mechanisms) let us ensure the ongoing compliance to any set of contractual, stature legislation and normative obligations.
Manage data security lifecycle
To ensure the data privacy in a long run, we need to maintain the consistent security model of SAP system or, in other words, manage personal data security lifecycle.
This is achieved in 2 ways:
- Protecting data on various stages:
- processing period – personal data should be accessible for intended purpose, e.g. creation of a contract, delivery and payment;
- blocking period – data is retained for legal reporting obligations and is accessible only for explicitly authorized users;
- end of retention – in case of the ending of purpose and (or) fiscal/legal retention periods, data should be deleted.
Protecting data on various stages is attained in SAP via special authorizations (P_DURATION) and SAP Information Lifecycle Management. Below is a slide of my presentation regarding the implementation of SAP requirements:
The consistency of security model can be achieved by developing system security plans, as it’s advocated by NIST SP800-18 “Guide for Developing Security Plans for Federal Information Systems”.
Although not all SAP systems are federal, all organizations can benefit from the structured approach to description protection of systems and maintaining it up to date.
According to NIST SP800-18 a security plan should contain following information:
- security plan roles and assignment security responsibilities;
- description of system: purpose, environment, and interconnections;
- description of assets: name, purpose, environmental context, severity, and type of information;
- laws, regulations, and policies affecting the system and data;
- security control selection;
- information about approving and completion;
- security plan maintenance considerations.
Good security plans are living documents that are regularly updated and revised. The security plan ensures that security controls address initial privacy requirements, security mechanisms are configured in consideration with interdependencies and links, and finally, the controls and mechanisms are regularly tested and being improved.
GDPR forces us to take a fresh look at security and think of it as an enabler, not a burden. All companies will reach that enlightened point someday, just as we all now recognize IT itself as an enabler. The question is whether you’ll reach that point before, with or behind your competitors.
To understand your security posture and make a business case for GDPR project, we offer the special solution for GDPR compliance. During the provision of the service, you’ll get a clear understanding of what personal data you process, who has access to it, and how effective the security controls are. Finally, you will understand what you should do to protect personal data in terms of implementing security controls and remediating the found weaknesses.
The next article will cover recognizing a SAP data breaches and monitoring the data processing in SAP systems.