When asking vendors about GDPR compliance, expect more: how can they help you maintain compliance?

Note: The author of this article is not a lawyer and this article should not be considered legal advice. Please consult a privacy specialist.

GDPR brings major improvements in consumer data protection at the cost of major new privacy requirements for all companies conducting business in Europe or with European citizens. That is, these requirements are not limited to EU-based companies. It’s no surprise then that our customers and partners from all around the world are asking “Are you compliant?” or "Are your products compliant?” Recently we’ve published a GDPR FAQ page that you may want to consult for these kinds of general questions and answers. Earlier, my colleague Thomas Hüttner explained in some detail how Dynatrace is addressing GDPR compliance requirements. These techniques generally apply to both Dynatrace and DC RUM; for DC RUM, we also provide additional product-specific details in our documentation. 

In this article, I want to take one step further and look at the question not only from the perspective of assuring your performance management solutions are compliant, but also to ask how those solutions can help your organization maintain compliance. For sure a Digital Performance Management (DPM) solution can’t replace the GDPR-compliance initiative, but it can be a catalyst for compliance – if the DPM solution is architected properly from the ground-up. Or it can be an inhibitor, if it’s rooted in the past era.  

Let’s take the Dynatrace DC RUM example to illustrate how a sensibly architected performance management solution can become your ally in GDPR compliance efforts.

How to maintain actionable performance troubleshooting capabilities while remaining GDPR-compliant

Many wire data analysis tools rely on upfront network packet collection and additional post-capture performance analysis of stored data. This inherently creates GDPR risks since the stored data will generally exceed the scope of potential analysis needs. Not only is the value of this stored data questionable, it results in costly compliance management. 

Wire data carries a wealth of consumer information, sometimes in obscure places; in the data packets we may track client’s sex, nationality, marital status… If an Application Performance Management (APM) solution relies on traffic recording to measure application performance, this information will get recorded, creating an uncontrolled GDPR subject. But do you need to store it all in the performance management system if it has no relation to application performance?  

DC RUM is different: it analyzes transaction performance in depth in real time, as the transaction occurs, storing only critical performance metadata; it discards information beyond what the solution administrator deems necessary for performance management purposes. Typically, personal data is not essential to identify performance fault domains. By default, DC RUM does not record user names; even unique client IP addresses are aggregated to client locations. 

DC RUM always measures all transaction executions, and for each transaction individually analyzes the cause of degraded performance. Aggregate analysis result reveals how investments – e.g., in server performance – would change the real user perception of the app performance. Individual user and transaction names don’t have to be stored to perform such powerful analysis in real time.

If user name and/or IP address collection is essential for the troubleshooting process, the DC RUM system administrator must explicitly enable such a collection. Although some personal data dimensions may be processed this way and DC RUM owners should be conscious of this fact, there are safeguards applied to limit troubleshooter user access to such personal data or to disassociate users from the data.

Some rather crude approaches rely on pattern-matching to detect user and transaction identifiers from traffic payloads, ignoring important and valuable application-specific intricacies associated with specific application and network protocols. These approaches miss the rich value derived from application-specific measurement analytics, catering primarily to traffic accounting. 

An example of a multiple-step transaction seen on the wire. Without knowledge of the whole transaction flow, one may think that the time spent between hits shall be attributed to the client processing the data. In fact, it is all taken by the server, while client is constantly pinging the server for result of a process initiated by the first request. (From this Dynatrace Community forum.)

More importantly, these approaches represent significant risk of capturing personal data that is unnecessary for the stated purpose and that may be inadvertently exposed to unauthorized users. DC RUM is different here as well, analyzing and interpreting application protocols in depth to measure user and transaction performance characteristics – without capturing and storing unnecessary personal data from the wire.

Use DC RUM to foster your GDPR compliance

Discover all applications and clients on your network

One of the first important steps towards GDPR compliance is to understand the scope of application usage. DC RUM automatically and continuously discovers and identifies all applications and users on the network, especially important at the data center edge where consumers, partners and third-party services connect with your applications. Continuous discovery means that any new services and applications that are added to your network will be immediately visible to you. Similarly, DC RUM discovers new client activity, informing you when Internet-connected consumers access newly deployed services, alerting you to the need for GDPR compliance monitoring.

DC RUM discovers applications served from the data center and then runs a continuous service activity survey to highlight new services that should be taken under performance management control.

Identify TLS ciphers used effectively by the clients  

Contemporary applications are delivered to clients over TLS-encrypted channels, and strong encryption algorithms are required to remain compliant with industry regulations such as PCI DSS. However, encryption levels are negotiable between clients and servers, and real-time encryption levels may differ from the desired algorithm strength. With DC RUM, you can monitor TLS ciphers as they are negotiated between client and server, getting alerted when encryption levels on the wire fall below your intended strengths, allowing immediate remediation.

A real-time snapshot of ciphers negotiated by clients accessing a business application. Runtime levels of negotiated TLS versions and cipher strengths differ from the intended encryption levels – because older, weak ciphers haven’t been disabled while new ciphers were added. Now old client versions fall back to these instead of being denied access.

Encryption levels are important not only in direct transactions with your consumers, but also in cases where your employees and contractors work with consumer data in their CRM and ERP systems. Those “apps of record” systems are monitored by DC RUM using dedicated wire data decodes for SAP, Siebel, Oracle, Peoplesoft, Citrix and more.

Monitor Citrix performance

Application and desktop virtualization provided by Citrix are convenient ways to facilitate GDPR compliance when processing consumer data. With these technologies it’s easy to keep all sensitive data stored and processed inside your data center, while employees and contractors interface with the information as needed using thin terminals. However, switching to virtualized apps or desktops also means introducing a strong dependency on network performance to locations where thin terminals are used. This often-neglected aspect calls for thorough end-to-end performance management, and DC RUM offers unique insight into how Citrix influences application delivery to your users. For more information about DC RUM’s Citrix-specific monitoring, you visit https://www.dynatrace.com/technologies/citrix-monitoring/ or browse the Dynatrace blog posts (note: these are going through a refreshment now, so some content may be temporarily unavailable)

Citrix application delivery performance at a glance – a view from the end user perspective and in context of the business application delivered by Citrix.

Minimize the risk: limit what you know to what you needto know

It’s one of the cornerstones of GDPR: store and process only those pieces of personal information that are necessary to achieve specific purpose permitted by law, and only for the time necessary to achieve it[i]. DC RUM has been employing this approach for years - we are the performance management experts, so we know what information is required to manage performance effectively, while getting rid of what only adds overhead and risk. Here are a few examples that provide some insight into how we employ the need-to-know principle in practice:

Client IP

Out-of-the-box, DC RUM doesn’t collect any personal data. DC RUM administrators may choose to enable specific personal data collection through system configuration. For the web decode and for monitoring Internet traffic, default settings are to aggregate users to Internet locations according to the BGP routing topology (not geographic locations). This inherently assures that client IP addresses are not trackable; not even geographic locations are tracked. 

DC RUM aggregates clients to locations, while retaining counters of unique real users within each location and tracking user-experienced performance.

Why do we use BGP routing hierarchy to aggregate client information? Because this lets us provide coherent and actionable network performance measurements even in the absence of location information. Because of the ways that ISPs manage their clients’ links, AS and CIDR blocks represent consistent IP address groups that have similar network performance characteristics. This is not the case for geographic locations, where multiple ISPs may provide different connectivity options. 

As a result, DC RUM can precisely isolate and confirm end user experience issues that root down to the ISP connectivity. This is complementary to Dynatrace RUM, which focuses on user demographics, like geographical location or device type, to segment end users and analyze their digital behaviors.

User names

The ultimate level of real user performance troubleshooting requires identifying the user; DC RUM can extract user names from monitored traffic for virtually all the protocols it monitors. Middleware and back-end protocols monitored by DC RUM typically carry technical user names that app servers use to communicate with each other, so these are not GDPR subjects. Where user names are not essential to troubleshooting, DC RUM provides an option to simply count unique users per location, per application, or per transaction, without recording the user names. This is the typical approach that DC RUM customers take when monitoring consumer-facing systems: data minimization ensures that the monitoring system doesn’t collect what’s not essential for the performance management discipline. However, when corporate users of internal systems are monitored with DC RUM’s web decode, our customers typically choose to recognize individual login names, for the purpose of detailed troubleshooting when necessary. As mentioned before this is not the default setting, but requires an explicit configuration change.

In the upcoming DC RUM 2018 release, we’ve added a new option to pseudonymize user names[ii], allowing individual users and user-specific actions to be tracked; however, the troubleshooting process begins without associating these with real names. Only named individuals (administrators with proper authorization) can reveal the real user login name during the troubleshooting process.

DC RUM pseudonymizes individual user names, while troubleshooting processes can still be conducted by Operations and Application teams.

Transaction names and errors

It’s important to know that regardless of the configured transaction name recognition settings, DC RUM always measures every individual client transaction separately. Transaction name identifiers may or may not be associated with the measurement; if the DC RUM administrator chooses not to associate these, the measurements are aggregated before recording and those aggregations are stored under their specified names. Therefore, it’s possible – and common for our DC RUM customers – to retain individual measurements for detailed performance diagnostics, while keeping the transaction name visibility on a safe, aggregated level. 

A similar approach is taken when analyzing transaction errors: DC RUM can be configured to detect specific transaction errors by analyzing the response content, counting error occurrences and alerting on user-visible soft or hard errors, but it doesn’t mean that the exact error messages have to be recorded. After detecting a specific error message, DC RUM can increment the error counter only, without recording the message itself; error message recording is optional and depends on the system administrator’s intention (and must be explicitly enabled).

DC RUM analyzes each transaction execution individually, and during the analysis counts executions, performance failures and transaction errors. Aggregate counters are recorded, but individual transactions don’t need to be recorded to deliver real-time application performance analysis and alerting.

In the upcoming DC RUM 2018 release, we’ve changed the way detailed transaction-by-transaction logs of user activity are accessed, making it easier to obtain this level of detail for all users and all transactions. Instead of storing the user session details in the DC RUM database, we provide a flat-file storage option on the probe, with on-demand user session flow reporting. Sign up for DC RUM 2018 beta to test it out today!

Consumers versus corporate users: GDPR applies to both, but there are nuances

Considering such major changes that GDPR brings, it’s easy to over-react: “Let’s disable user tracking in every performance management tool we own.” But while GDPR is strict about consumer online data, it also leaves room for business-specific and member state-specific employer-employee regulations[iii]on how employee personal data is handled. Specifically, with employment contracts and internal business regulations built in a sensible way, tracking IP addresses and login names of the employees should be possible given an appropriate business goal. This makes perfect logical sense, and is also the reason why DC RUM is primarily used by our customers to monitor corporate applications and employee users; ensuring application efficiency and enabling employee productivity are fundamental business objectives. This opens an opportunity to improve your compliance stance by proving how you care about the apps and employees that process the consumer data. When you monitor corporate applications and include user and transaction names, you will be in a better position to prove that you are actively tracking how consumer data is accessed and processed by those applications. DC RUM monitors the applications and users that process your consumer data, not the consumer data itself; in fact, DC RUM has no insight into this consumer data. This “watcher” position is essential to prove that you are taking one of the necessary measures to manage your consumer data-processing applications – which could become an important point should regulators decide to probe your compliance and procedures. 

The right to access and the right to erasure 

A separate note is needed on the right to access personal data and the right to be forgotten. The right to erasure grants every consumer the possibility of requiring the data controller/data processor to erase his/her personal data maintained within the data controller’s/data processors’ system. If DC RUM is configured to store traceable individual user and transaction data, by design it retains the data for a limited and configurable period of time. If a user doesn’t show up on the monitored application after the raw data retention period elapses (10 days is the default), this user’s name and IP address, and all history of the user’s activity, is erased automatically. Please note that GDPR regulations require the right to be forgotten to be exercised in 30 days upon request. Therefore if you want to make absolutely sure you are compliant, don't set data storage period in DC RUM longer than 30 days.

The right to access means that a consumer can ask what personal data about him is stored. Upon an investigation, it becomes critical to quickly, precisely and completely present the stored data and explain the purpose of storing it[iv]

This requirement is conveniently realized in the DC RUM: it’s very easy to examine whether the system knows anything about a specific user name: just submit the user name in Search and the whole DC RUM database is searched for traces of this user’s activity. This is useful for two related purposes; to prove that no specific user data is stored, and to illustrate what data is stored – in case it still exists in the DC RUM database

Individual user activity report reveals what user-specific data is stored and for what purpose: performance management done right means that only those pieces of transaction data are stored that matter to performance troubleshooting – the precise user activity trace, but not the transaction business data.


Consider looking at DC RUM as your ally, a key contributor to your GDPR compliance story; not simply another subject that requires the “compliance” check. Checking tool compliance alone won’t accomplish your compliance goals, but the right monitoring solution used effectively will help you understand your business process compliance. 

[i]GDPR Article 5 - processing and storing of personal data – calls out, among others, principles of data minimization (“adequate, relevant and limited to what is necessary”) and storage limitation (“in a form which permits identification of data subjects for no longer than is necessary”). In the performance measurement world, it simply means that only those pieces of personal data should be stored that are related to the performance measurement.  

[ii]GDPR Articles 25 – data protection by design – and 32 – security of processing – call for using appropriate measures, like pseudonymization, minimization and others, to protect rights of the subjects

[iii]GDPR Legislative section – calls out that “collective agreements, including ‘works agreements’, may provide for specific rules on the processing of employees' personal data in the employment context”, so upon employee consent data that supports e.g. planning and organization of work may be collected

[iv]GDPR Article 15 – right to access – calls for being ready to present, upon request, what personal data a company is using and how it is being used.

  • No labels