AppSignal is GDPR compliant, and below is an overview of what we changed, and how using AppSignal as your Data Processor enables you to be compliant too.
Our biggest changes were caused by the fact that we collect personal data about our customers' customers (or visitors). The kind and volume of that data, such as IP addresses and parameters, had to determine whether we would be a Data Controller or a Data Processor. Because it's best for all parties involved if we're the Processor, we had to instate some policies and make some technical changes that enabled us to be just that.
Before we get into that, first a note on what lots of people have been waiting for:
Our Data Processing Agreement
We've created a Data Processing Agreement that explains eg. how we are a Data Processor, how we limit processing to the level needed to be able to provide the AppSignal service, that we will ensure that our vendors are compliant too, etc (this is an incomplete list for illustrative purposes only; please see the full Data Processing Agreement for all the details).
The Data Processing Agreement is accessible to all owners for an organization on AppSignal. You can find it by going to your "Profile & Settings" and look for the agreement in the left navigation (there is one for each organization). You can digitally sign the Data Processing Agreement, and once signed we will display who signed it and when.
For you to be GDPR compliant as a Data Controller, you'll likely need to sign it (and as your Data Processor, we'd like you to do that, too).
Changes to how we (and you) collect data
We've always been mindful about the amount and nature of the personal data we collect, process and store. Our data collection agent has always automatically filtered out the sensitive information we could identify. Despite that, some personal data could end up in AppSignal anyway, mostly through request headers, parameters and session data.
Even though we're your Processor, we'd prefer not to process any personal data. Because of that, we'll provide the tools that enable you to strip personal data information before sending it to AppSignal. We've also made changes to our documentation to better help you understand how to use certain features to minimize sending personal data our way.
Whitelisted request headers only
We've always made sure to strip any personal data from incoming events such as database queries, but we did store request headers such as
REMOTE_ADDR. Depending on architecture, this can expose useful information about load balancers or internal IP addresses. In most cases though, this sent visitor IP addresses to AppSignal. Since IP addresses are personal data, we've created a whitelist of headers that we believe won't contain personal data. Customers can add additional headers to the whitelist as needed, as long a they don't identify an individual (eg. if
REMOTE_ADDR contains the IP address of a load balancer, that's fine).
Filtering options for parameters and session data
The latest Ruby gem and Elixir package releases expand this filtering feature to session data too. It allows customers to send parameters to AppSignal without exposing personal data, by replacing that data with
[FILTERED]. Alternatively, a customer can choose to not send any parameters or session data at all.
Requirements for Tagging
We've changed the documentation for our Tagging feature (Ruby / Elixir) to strongly state that no personal data should be sent to AppSignal in tags, and that user IDs, hashes or pseudonymized identifiers should be used instead.