Sune Engsig
The 2018.1 Release of the Leapwork Automation Platform introduces a new Controller – the software that, among other things, stores all the data used in automation flows. With the new Controller, Leapwork users can ensure that their data storage in relation to test and process automation is GDPR compliant.
Data usage in UI automation
With Leapwork, automation is performed exclusively by utilizing the user interface of the applications being automated, whether they are web- or desktop-based. This has several advantages, for example, it ensures that automation flows are adhering to an organization’s business conduct as enforced by the given application. Any data processed and generated as part of automation flows are safely stored within the application being automated.
This means that the Leapwork Controller stores very little data other than what is provided as inputs to automation flows, for example search terms, user names, etc. From a compliance perspective, you obviously want to be able to manage these data – regardless of the quantity and whether they are used in a test or production context, or both.
In this post, we show you how to manage Controller data to ensure GDPR compliance.
Mapping sensitive data
If you are using Leapwork exclusively for test automation, being GDPR compliant also means having strict control over whether the test data you are using contain potentially sensitive data, or if the data in any way can be used to identify your customers and users. This means data should already be anonymized, obfuscated, or similar. This would resolve the issue of what is stored in Leapwork, as data is already “safe”. However, even if you are not affected by GDPR, naturally, it still makes sense to ensure that your test data cannot in any way, incidentally or intentionally, be used to identify your clients and users.
It’s another matter entirely when Leapwork is used for process automation (RPA) in production. As already established, due to Leapwork’s GUI-based approach to automation, processed data is already safely stored in and guarded by your business applications – and not in the Leapwork Automation Platform.
However, Leapwork will potentially contain sensitive information that you need to address to ensure the privacy of your clients and users, including:
- Log entries from the execution of automation flows. These can contain names, addresses, email addresses, etc. as they are entered by Leapwork into the relevant part of the flow and written into the flow execution log.
- Video recordings from the execution of automation flows. Similar to logs, the video recordings show data entries in the application being automated.
- Data sources used in the Read Excel automation block. When the Read Excel-functionality is used for scheduled runs, the spreadsheet in question is uploaded to the Controller as a resource.
- Data entered directly into individual automation blocks (e.g. Type Web Text, Set Text, etc.) The set values are stored as part of the instantiated automation blocks.
In all these cases, data is stored centrally in Leapwork’s “Assets” folder (located in the installation library), in encrypted and separate SQLite database files. Access to these files are thereby restricted. Only users with access to the decryption key can access the contents of the databases.
Tips for GDPR Compliance with Leapwork
To minimize the risk of violating personal data legislation, we recommend you follow these best practices, each of which are described in detail below: Limiting the use of log entries and video recordings when automation is in standard operations mode; and minimizing the amount of data stored by relying on external data sources.
1. Limiting log entries and disable video recordings when in standard operations mode
Logs contain substantial amounts of information which needs to be retrievable if a customer/user requests access his or her data, a right that is granted by GDPR legislation. As mentioned earlier, Leapwork is not the data processor, your business applications are. Therefore, you could argue that there is no need to keep exhaustive logs of each flow execution once the flows have been verified to work as intended.
While logs are a crucial supporting feature when authoring and maintaining automation flows, once a flow is in standard operations mode with potentially multiple daily runs, their role is less significant.
Leapwork allows you to disable the storing of data entered as part of the automation flows. With this approach, the logs are no longer an issue from a GDPR perspective.
Automated video recordings of executed automation flows are stored in the file system in this location: C:\Program Files\LEAPTEST\Assets\AutomationRunMedia. One file per run is generated. Note, that this only applies if you have enabled video recordings.
Recommendation: For each flow, go to Settings and set Logging level to Limited. This way, only the events Start, Pass, and Fail are logged, allowing you to track if a flow needs attention. Regarding video logs, once automation flows are in standard operations mode, we recommend disabling automated video recordings. Go to Settings of the specific flow and choose No video in Video record. This will also save storage space on the Controller.
2. Minimizing the amount of data stored by relying on external data sources
Leapwork is only storing data values entered into automation blocks, as part of their configuration, by the user designing the automation flow. Data which is driven into the automation blocks from external data sources are not stored by Leapwork, except in the log files.
When you configure the Read Excel automation block to use a Data file as Source, Leapwork will upload the spreadsheet in question to the Controller for it to be able to run the automation flow independently of any instance of Studio being active. Managing the individual Excel file is easily done in Leapwork Studio. You can clear and delete the Excel file in question directly from the Read Excel block itself:
Recommendation: When using Leapwork for process automation, we recommend to not enter any sensitive data (e.g. names, addresses, and other personal information) directly into the individual automation blocks. Instead, use an external data source under your control (Read Excel, Database, or HTTP request) to drive this data into your automation flow. For any existing automaton flows with sensitive data entered directly into automation blocks, we recommend you change these to relying on external data sources instead.
Using external data sources (Excel, Databases, web services, etc.) is a crucial part of Leapwork’s support of your GDPR efforts as this ensures that data entered into automation flows are consolidated in their relevant source applications or files, controlled by you.
Avoiding storage of transactional data in Leapwork
Following the guidelines in this article will help you ensure that you can protect the privacy of your customers and/or users – also when automating processes. Leapwork supports this by:
- Not having to store any data needed for your business processes within Leapwork itself. Rather, you should use external data sources for this purpose.
- Storing of both log entries as well as flow recordings is optional. For process automation (RPA), we recommend not to store either log entries or videos once flows are verified and stable. This guarantees that no data associated with the automated business flows is stored in Leapwork.
- Leapwork is not processing or managing any of your data – this happens in your business applications where it belongs.
We hope that you find these insights into data management with Leapwork helpful. Please contact us if you have any questions or comments. We’d be happy to receive your feedback!
