Sentry publishes a versioned data processing addendum you accept electronically, self-certifies to the EU-US Data Privacy Framework along with the UK Extension and Swiss-US Framework, incorporates the Standard Contractual Clauses, offers an EU region for data residency, and ships PII scrubbing in three different places. The contractual position is in good order.
The problem an error tracker creates is different from the others in this cluster. An error report is a snapshot of your program at the moment it broke, and the moment it broke is exactly when it was holding a real person's real data.
This article covers how the addendum attaches, what actually arrives in an error report, the three places you can scrub it and why only one of them keeps data off Sentry's infrastructure, and the subprocessor mechanics.
The DPA Is Opt-In, And Versioned
Sentry's addendum works differently from most in this cluster, and the difference matters.
It is entered into between Functional Software, Inc., doing business as Sentry, and the party that electronically accepts, agrees or opts in to it — effective as of the date you electronically agree. That is not automatic incorporation into the terms. If nobody at your company has accepted it, you may not have an Article 28 contract in place, and "we pay for the product" does not establish one. Check.
Sentry also publishes its addendum with a version number and date, keeps every earlier version online at its own URL, and links published instructions for entering into it. The version live when we checked, on 7 August 2026, was 5.1.0 dated 29 May 2024, with five earlier versions listed. Record which one you accepted, because the document you agreed to is the one that governs and Sentry has made it possible to prove exactly which that was.
On roles, the addendum applies only where Sentry processes personal data as a processor, with the customer as controller or as a processor acting for a third-party controller. Under US state law Sentry acts solely as a service provider and undertakes not to retain, use or disclose personal data other than as described in the addendum, and not to sell or share it.
One more clause belongs here rather than buried in a schedule. The addendum expressly prohibits you from submitting sensitive personal information or special categories of data, states that Sentry does not request, require or wish to receive it, and provides that Sentry's obligations under the addendum will not apply with respect to such data. Hold that thought for the next section, because it is the reason scrubbing is not optional.
What Actually Arrives In An Error Report
Nobody decides to send personal data to an error tracker. It arrives attached to the exception.
A stack trace can carry local variable values, which on a failed checkout means the address and the order. A captured request can carry the body, which on a failed signup means the form the user just filled in. Headers carry cookies and authorisation tokens. Breadcrumbs carry the sequence of actions the user took to get there. User context carries whatever identifier your SDK was configured to attach, which is frequently an email address because that made triage easier.
The failure mode is specific to this category. Analytics tools capture what you told them to. An error tracker captures the state of the program at the point of failure, and failures happen in the code paths handling the most sensitive input, because that is where validation is hardest and edge cases live. Your error volume is not a random sample of your traffic. It is biased toward exactly the requests you would least like to store.
That is a processing activity, it is yours, and it belongs in your record of processing activities with a retention period beside it.
Now combine that with the prohibition above. A health application's exception can carry a diagnosis in a local variable. A recruitment tool's failed request can carry a declared disability. Nobody chose to send either, but the addendum prohibits submitting that data and disclaims Sentry's obligations over it if you do. So the exposure is not merely that special category data reached a processor — it is that it reached one whose contract expressly does not cover it.
Three Places To Scrub, And Only One Keeps Data Out
Sentry's documentation is unusually clear about this, and the distinction is the most useful thing in this article.
Sentry describes scrubbing PII in two places by default: in the SDK before the event is sent, and on arrival at Sentry's infrastructure. Relay, its optional service, adds a third — scrubbing centrally within your own infrastructure before anything is forwarded to Sentry.
Those three are not interchangeable, and the difference is where the data has been by the time it is removed.
Server-side scrubbing is configured centrally in Sentry and applied when an event arrives. It is the easiest to manage and the easiest to keep consistent. It also means the unscrubbed event crossed the network and reached Sentry before being cleaned.
Relay sits in your infrastructure, uses the privacy settings configured in Sentry, and scrubs before forwarding. Sentry's documentation frames this as the option for teams that cannot send PII outside their own infrastructure but still want central configuration.
SDK-level scrubbing, using the beforeSend and beforeSendTransaction hooks, prevents the data being collected on the device at all. Sentry notes the trade-off plainly: you may have to replicate the same logic across your applications, and it may affect performance.
If you have told a customer that personal data never leaves your infrastructure, only the second and third options support that claim. Central convenience and strict minimisation pull in opposite directions here, and choosing between them is a decision to make deliberately rather than by accepting a default.
The EU Region And The Transfer Position
Sentry states that with EU region availability you can choose to have your Sentry data hosted in the EU rather than the US, to meet data residency requirements. Treat the region as a setup-time decision and confirm the mechanics for your organisation before you create it, rather than after you have a year of events in the wrong place.
On transfers, Sentry self-certifies to the EU-US Data Privacy Framework along with the UK Extension and the Swiss-US Framework, and points customers to the public Data Privacy Framework participant list to confirm it — advice worth taking, since certification is a status that can lapse. Its addendum also incorporates the Standard Contractual Clauses for transfers of personal data out of Europe, with the UK Addendum amending them where the UK GDPR applies, so there is a mechanism underneath the Framework rather than only alongside it.
Subprocessor Notice, And The Address It Goes To
Sentry maintains its subprocessor list at sentry.io/legal/subprocessors/ and commits to imposing equivalent data protection terms on each subprocessor while remaining responsible for their acts and omissions.
The notice mechanism is better than most in this cluster and does not depend on you opting in. The current addendum commits Sentry to thirty days' prior written notice of subprocessor changes, by email or another means specified on the subprocessor page, with an objection window during that period. What it does depend on is your Notification Email Address — the address you designated at signup — and the addendum states you are solely responsible for ensuring it is current and valid at all times. A notice sent to a departed employee's mailbox has been validly given.
The objection right is real but the remedy is blunt: if Sentry does not remedy your objection or offer a reasonable workaround within a reasonable time, your sole remedy is to terminate the Agreement for convenience. Our guide to subprocessor management covers running that review.
Common Mistakes With Sentry And GDPR
Assuming the DPA is automatic. Sentry's addendum takes effect when someone electronically accepts it. Paying for the product does not accept it on your behalf.
Relying on server-side scrubbing while claiming data never leaves. Server-side scrubbing happens on arrival at Sentry. If the claim is that PII stays inside your infrastructure, you need Relay or SDK-level hooks.
Attaching an email address as the user identifier. It makes triage easier and turns every event into a record about a named person. A hashed or internal ID usually does the same job.
Never setting a retention period. Error events accumulate, and the ones with the richest context are the ones with the most personal data in them. Retention is your decision, not a default to inherit.
Leaving a stale Notification Email Address. Sentry gives thirty days' notice of subprocessor changes to the address you designated, and the addendum makes keeping it current and valid solely your responsibility.
FAQ
Do I need to accept a DPA with Sentry?
Yes, and that is the point to check. Sentry's addendum is entered into by the party that electronically accepts or opts in to it, effective from the date of acceptance, rather than being incorporated automatically. Confirm someone has done so, and record which numbered version they accepted.
Does Sentry offer EU data residency?
Sentry states that with EU region availability you can choose to have your data hosted in the EU instead of the US to meet residency requirements. Confirm the setup mechanics for your organisation before creating it, since region decisions of this kind are typically made at organisation creation.
How do I stop personal data reaching Sentry?
Sentry scrubs in the SDK before sending and on arrival at its infrastructure, and its Relay service adds central scrubbing inside your own infrastructure before forwarding. Only the SDK hooks and Relay prevent unscrubbed data leaving your environment; server-side scrubbing applies after the event has arrived.
Is Sentry a controller or a processor?
A processor. Its addendum applies where Sentry processes personal data as a processor, with the customer acting as controller or as a processor for a third-party controller, and under US state privacy law Sentry acts solely as a service provider and undertakes not to sell or share personal data.
Closing Thought
Error monitoring is the one category where the tool works better the more of your users it captures, and where nobody involved thinks of themselves as collecting anything. An engineer adding richer context to an event is trying to fix a bug faster. They are also expanding the categories of personal data your company holds, in a system that was probably never mentioned in a privacy notice.
The fix is unglamorous and it is a decision rather than a setting: agree what an error report is allowed to contain, implement it where it belongs given what you have promised, and put a retention period on the result. ComplyDog gives you a compliance portal on your own domain covering your DPA, your subprocessor list, your data subject request intake and your security page. It will not write your scrubbing rules. It will mean that when a customer asks what your engineers can see about their users, somebody has already answered the question in writing.
