GDPR at LeanIX
Here we describe how we use a LeanIX workspace for GDPR at LeanIX. Even a small organization like LeanIX has a lot of technical supported processes - we are counting more than 100 Applications which are relevant to our business.
To be GDPR compliant is not an exercise of our legal unit only. We think that everybody should be sensitive if it comes to personal identifiable information (PII), be it our Engineering or our Marketing department. That is why we are using the collaborative features of LeanIX to gather all relevant information and keep this up-to-date at the source of the information.
Overview
This document describes how LeanIX as an organization captures GDPR relevant information in a LeanIX Workspace.
How to model the necessary information in LeanIX
The following paragraph describes how we modeled the information in LeanIX to be able to generate a directory of all procedures.
General Information
Topic | LeanIX |
---|---|
Processing ID | Each application that processes data has a unique ID, in UUID format, and can be retrieved via the LeanIX workspace, e.g. b21d68b9-e404-46c0-88b7-5679c0d921e2 You can copy and paste this into the External ID field to establish direct linkage to external systems. |
Description of the processing | The relation to the Business Capability defines the area of processing. In case of need for more information, this can be captured in the description field of an Application Fact Sheet |
First description of an automated procedure | This information should be reflected in the Lifecycle of an Application Fact Sheet: - Active - Plan - Phase-In, in case of a new release. As an alternative, this can be even reflected in a cloned successor application If this is not sufficient we use a Tag for this kind of information. |
Data Management
In the Application factsheet, we created a section in which the Data Management details can be added, stored, and edited.
We created two subsections Data Objects and GDPR.
The first section captures the Data Objects with which the application deals, using the following scheme.
Topic | LeanIX |
---|---|
Data Object | The affected Data Objects must be linked to the Application Fact Sheet. The CRUD information at this relation shows the type of processing. The associated Data Object must be the lowest available hierarchy. We wanted to avoid a fine granular data model to make the assignment as easy as possible. This is our list of key data objects: - Applicant - Business Sensitive - Customer - Employee - Marketing and Sales Content - Operational Data - Other - Partner - Prospect - Supplier |
Usage | Here the users can specify how the application affects the Data Object. - Create - Read - Update - Delete. |
Description | Space provided to add additional specifications of data usage within the application, including the purpose of the processing and any “other” categories of personal data. |
Categories of Personal Data | This is only relevant if the Data Objects are different per User Group. Otherwise, it is defined in the relations Application / User Group and Application / Data Object. Users can pick from a predefined list of the most common options: - Name - Private address - Date of birth - Place of birth - Email address - Social security number - Tax number - Bank account number - IP address - Sex/gender - Picture - Employee ID - Other |
Special Categories of Personal Data | Users can indicate if there are special personal data involved in the usage of this application. - Racial or ethnic origin - Political opinions - Religious beliefs - Union membership - Genetic/biometrical data - Health/disability data - Sexual orientation |
Time Limit for Erasure of Personal Data | Users can indicate when personal data will be deleted. |
GDPR section
The second section captures the GDPR aspects of the data
This only needs to be completed if personal data is being processed by the application.
Topic | LeanIX |
---|---|
Data Owner | Space where users can indicate which LeanIX entity uses personal data for its own purposes, i.e the data controller. Usually: "All Sales Entities" for customer/prospect/partner data "All LeanIX Entities" for employee data |
Processing Locations | Users can select from a Country list the Location of Servers and any service personnel processing our data. |
Justification for processing/hosting in non-EU countries | Transfer of data to non-EU countries needs to be justified; Here the workspace users can select from a predefined list why the data is being processed or hosted outside the EU. - Art. 45: Adequacy - Art. 46 (2) (a): enforceable Instrument - Art. 46 (2) (b): Binding Corporate Rules - Art. 46 (2) (c): EU SCC (v.1) - Art. 46 (2) (c): EU SCC (v.2) (yet to be released) - Art. 46 (2) (d): other standard clauses - Art. 46 (2) (e): Approved CoC / enforceable commitment - Art. 46 (2) (f): approved certification mechanism - Art. 49 (1) (a): explicit consent - Art. 49 (1) (b): performance of contract - Art. 49 (1) (c): conclusion of contract - Art. 49 (1) (d): public interest - Art. 49 (1) (e): legal claims - Art. 49 (1) (f): vital interests - Art. 49 (1) (g): register |
Recipient | A recipient is anyone that has access to the data. In the Business Support Section, User Groups of the Application can be defined. Usually, we expect “user groups” to be the recipient of personal data; but the recipient field allows to add any further recipients that are not part of a user group. Also, any relevant restrictions can be added (e.g. in general applicant data can be available to members of all departments – but this is limited to those involved in the hiring process) |
Recipient Locations | As long as there are no external recipients, this will be "Data Owner Locations" The users of LeanIX can add any additional external recipient locations from a list of countries. |
Justification for transfer to Recipients in non-EU countries | In the case of the transfer of data to non-EU countries, the users can select a predefined reason for why this is happening. - EU data not available outside EU - Art. 45: Adequacy - Art. 46 (2) (a): enforceable Instrument - Art. 46 (2) (b): Binding Corporate Rules - Art. 46 (2) (c): EU SCC (v.1) - Art. 46 (2) (c): EU SCC (v.2) (yet to be released) - Art. 46 (2) (d): other standard clauses - Art. 46 (2) (e): Approved CoC / enforceable commitment - Art. 46 (2) (f) approved certification mechanism - Art. 49 (1) (a): explicit consent - Art. 49 (1) (b): performance of contract - Art. 49 (1) (c): conclusion of contract - Art. 49 (1) (d): public interest - Art. 49 (1) (e): legal claims - Art. 49 (1) (f): vital interests - Art. 49 (1) (g): register |
Legal Basis | Users of our workspace can select an entry out of a list of predefined options to make it easier for the responsible person to enter the appropriate legal basis (in our case within the LeanIX legal department): 1. Art. 88 GDPR, § 26 BDSG -> All employee and applicant related data 2. Art 6 (1) (b) GDPR -> Existing Customers and Prospects 3. § 7 UWG -> Electronic Direct Marketing with a consent 4. Art 6 (1) (f) GDPR -> Direct Marketing without consent, e.g. targeting (category should be avoided as far as possible) |
Legal Basis Detail Information | Please provide more information about the legal basis of this Application if necessary. |
Technical and Organizational Measures | General description of the technical and organizational security measures |
Data Processing Information confirmed by Legal | If all GDPR-related data is completed, this will be confirmed by legal |
Note: This selection requires that attributes were created on the respective Fact Sheet (Config Basic add on required)
How to standardize objects for GDPR
Business Capability
We are using the Business Capability structure to primarily capture the area of processing. In our case, we have Capabilities like Demand, Marketing, Sales, Engineering, and Operations. A good start is to capture the functional structure of the company, even if this is not reflecting true business capabilities.
User Group
A basic User Group can be a legal entity of the corporation - in our case, we have LeanIX GmbH and LeanIX, Inc., our US-based subsidiary. Other User Groups are Legal Advisor, Tax Consultant, Auditor and Third Party Data Processor in general.
We distinguish between internal and external User Groups which we tag with 'Internal' or 'External'.
Application
Guess what, we have more than 100 Applications. Yes, we are a very small company but have a lot of processes automated to be more efficient. We count every Excel Spreadsheet that is used in a business process a single Application, but this does not lead to the high number because we are very restrictive in using LeanIX for business-critical operations.
With only two Tags we manage the progress of our compliance project - SSO (needed/not needed, urgency) and DPA (in Germany: ADV) to know where we have an actual DPA in place. A nice side-effect is that we can show the progress on our Home Screen Dashboard.
IT Component
This is the tricky part for non-IT experts. An IT Component can be a Hardware, a Software product or a Service. We create first for a Cloud Service an IT Component Type Service with the name SaaS. In the second step, we add the Provider to it. So we can create unique names for every service but comparable names for the SaaS services. The same applies to Hosting Services.
Collaboration Features in LeanIX
LeanIX contains collaboration features that may be useful for the GDPR use case and more information can be found here
Updated over 1 year ago