LeanIX - Product Documentation

Welcome to the LeanIX Product Documentation. Here you will find all the basic information you need to start working with LeanIX. We provide you with well-structured information on how to get more out of LeanIX, best-practices and use-case specific guidelines. Feel free to spread this product documentation in your company and use it as a common information source to answer your colleagues’ most urgent questions.

Get Started

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.
Please note that for some of the described functionality the "Basic Configuration" add on is required.

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.

Type of processing

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.

Available Data Objects in our case are:

  • Applicant
  • Customer
  • Employee / Contact & Login
  • Employee / Full data
  • Partner
  • Prospect
  • Supplier

Responsible Business Area

We store the Domain at a Fact Sheet.

Purpose of data processing

Topic

LeanIX

Purpose

Users of our workspace can select one or many of the purposes of data processing below:

  1. Fulfilment of contractual obligations towards customers
  2. Marketing
  3. Usage of application by employees in order to fulfill their tasks
  4. Recruiting
  5. HR Administration
  6. Financial

Lawfulness of processing

Topic

LeanIX

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)

Note: This selection requires that attributes were created on the respective Fact Sheet (Config Basic add on required)

Affected person and data category

Topic

LeanIX

Categories of affected persons and data categories

This is only relevant if the Data Objects are different per User Groups. Otherwise it is defined in the relations Application / User Group and Application / Data Object.

Origin of data

At the relation between Application and Data ObjectIn the user can describe how and from whom we get the data.
We inserted a new field where the user can select one of the two options:

  1. Data provided by data subject itself
  2. Data provided by LeanIX

Note: This selection requires that attributes were created on the respective Fact Sheet (Config Basic add on required)

Recipients

A recipient is an organization that has access to the data because they need the data to fulfill their services. Due to the size of our company we don't split User Groups in Departments, but distinguish between LeanIX GmbH and LeanIX, Inc. All other parties are named with their service e.g. Accounting, Legal Services or Third-party data processing.

Internal Recipient

Users can mark the User Group with a Tag "Internal"

External Recipient

Ufsers can mark the User Group with a Tag "External"

Data transmission to third countries

Data transmission

Topic

LeanIX

Third countries / international organizations

To identify the transmission to a third party the party must be defined as an IT Component with a defined location where they provide the service (in terms of data processing).

Name and Address of Recipient

The name and full address of the Provider of the service (legal entity) is entered in the location field of the Provider Fact Sheet.

Documentation of reasonable warranties

This service gets Tags like "ADV", "EU Model clauses", "ISO 27001", ...

Deadlines for deletion

Topic

LeanIX

Planned deadlines

This information will be kept in the Deadlines field at the relation Application / Data Object (will be completed by LeanIX legal department)

Technical and organizational measures

TOMs

Reference either to LeanIX own TOMs or link to supplier TOMs in data processing agreements (will be completed by LeanIX legal department)

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'.

Data Object

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:

Data Object

Description

Customer

Customers after contract signing (incl. churned).

Employee Time

Active and former personnel. Login Data

Employee

Active and former personnel. Complete information such as address (Full PII data)

Partner

Work with LeanIX to consult or sell.

Prospect

Organizations and persons in pre-sales phase.

Supplier

Deliver services for LeanIX processes (both product and internal).

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 4 months ago

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.
Please note that for some of the described functionality the "Basic Configuration" add on is required.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.