Which personal data is in an error report?
An error report is a snapshot of your app at the moment things went wrong. Something personal easily ends up in it:
- the visitor's IP address and browser;
- a user id, e-mail address or username your SDK sends along;
- the URL, sometimes with a search term, order number or token in the query string;
- headers and cookies, including session ids;
- the content of forms or variables in the stack trace, such as an address or IBAN.
All of this falls under the GDPR as soon as it says something about an identifiable person. An IP address, too, generally counts as personal data.
Your error monitoring service is a processor
If you send errors to an external service, that service processes personal data on your behalf. You are the controller, the service is the processor. Under Article 28 of the GDPR you then need a data processing agreement. It states, among other things, where the data is stored, how it is secured, how long it is kept and which sub-processors are involved.
Mind where your data is
If the data is stored outside the European Economic Area, extra rules apply to the transfer. For the United States that has been the EU-US Data Privacy Framework since 2023, for companies that have joined it. But even with EU storage, an American parent company can fall under American law such as the CLOUD Act. For many governments, healthcare and educational institutions that is a reason to choose a European provider. In any case, record which trade-off you make.
Collecting less is the best protection
The GDPR asks for data minimization: don't collect more than you need. For error monitoring that means:
- Don't send user data you don't need. In the Sentry SDKs
send_default_piiis off by default; leave it that way unless you have a good reason. - Filter sensitive fields such as passwords, tokens, cookies, e-mail addresses and account numbers, preferably before they leave your servers, or at least before they are stored.
- Truncate IP addresses if you only use them to see which country or network errors come from.
- Don't keep data longer than needed. An error from a year ago rarely helps. A retention period of 30 to 90 days is enough for most teams.
Checklist
- You have a data processing agreement with your error monitoring service.
- You know in which country the data is stored and who can access it.
- Sensitive fields are filtered and IP addresses truncated.
- There is a fixed retention period, and old errors are really deleted.
- Only colleagues who need it have access, with appropriate permissions.
- Error monitoring is in your record of processing activities and, where needed, in your privacy statement.
How errors.nl handles this
errors.nl is a Dutch company. Everything runs and is stored in a data center in the Netherlands. Personal data is removed from every error by default before we store it, IP addresses are truncated and errors are deleted after 90 days. The data processing agreement is part of our terms.
This article is not legal advice. If you are unsure about your situation, ask your privacy officer or lawyer.