
Which Sentry plan do I need for US/Germany data residency + PII scrubbing, and how do I configure it before rollout?
If you need Sentry to keep your data in either the US or Germany and want tight control over PII before you roll out to production, you’re mostly deciding how to configure Sentry, not whether a specific “compliance tier” unlocks these controls. Data residency and PII scrubbing are part of Sentry’s core platform, available across plans, then layered with higher-governance options on Business and Enterprise.
Quick Answer: Choose your data residency (US or Germany) at the organization level when you set up Sentry, then use Sentry’s built‑in Data Scrubber, project-level filters, and SDK configuration to avoid sending PII and to scrub anything that slips through. If you also need SAML/SCIM, audit logs, and formal compliance artifacts, you’ll likely want Business or Enterprise.
Quick Answer: Sentry is a developer-first monitoring and debugging platform for errors, performance, replays, logs, and profiling, with built-in data residency and PII controls you configure before rollout so production telemetry stays both useful and compliant.
The Quick Overview
- What It Is: A code-level application monitoring platform that lets you choose where your data is stored (US or Germany) and gives you granular tools to avoid and scrub personally identifiable information (PII).
- Who It Is For: Engineering, security, and compliance teams that need production debugging data with strong guardrails around where it lives and what personal data (if any) is collected.
- Core Problem Solved: Connecting errors, performance issues, and user impact to code changes—without losing sleep over where data is stored or accidentally leaking PII into your monitoring system.
How It Works
Sentry uses language- and framework-specific SDKs to send events (errors, transactions, spans, logs, replays) from your applications to a Sentry organization hosted in either the United States or Germany, depending on what you select. On ingestion, Sentry applies server-side Data Scrubbing controls that automatically detect and remove values that look like sensitive information. You can extend this with stricter scrubbing rules and project-level filters so that the events developers see in Sentry are already cleaned of PII.
At the same time, you configure quotas, alerts, and workflow rules (Ownership Rules, Suspect Commits, integrations like Linear) so that once data is in Sentry, it flows to the right teams with enough context to debug quickly.
-
Choose your data region and plan:
When you create or migrate your Sentry organization, you pick US or Germany as your hosting region. Then you select a pricing plan (Developer, Team, Business, or Enterprise) based on feature and governance needs. The region selection controls where your service data is stored. -
Set global and project-level PII controls:
Use Sentry’s Data Scrubber and other privacy settings at the organization and project level to automatically remove sensitive values (like passwords, auth tokens, credit card-like patterns). You can add custom rules, disable IP storage, and configure SDKs to avoid sending PII altogether. -
Roll out via staged environments:
Instrument dev and staging with the Sentry SDKs first, verify that events contain no disallowed PII, then promote configuration to production. Use environment tags to keep dev/test data separate from production in Sentry and lock down access with the appropriate plan-level governance controls.
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| Data Residency (US/Germany) | Stores your service data in the region you select (US or Germany) on Google Cloud Platform. | Aligns monitoring data with regulatory or contractual data-location requirements. |
| Data Scrubber & PII Scrubbing | Automatically removes values that look like sensitive information and lets you define extra fields/tags to scrub. | Reduces risk of collecting or exposing PII in monitoring data, even if SDKs are misconfigured. |
| SDK & Project-Level Privacy Controls | Lets you disable IP storage, filter events server-side, and control what SDKs send. | Keeps telemetry focused on debugging context instead of user-identifiable data. |
| Security & Compliance Posture | Uses TLS, AES-256 encryption at rest and in transit, annual third-party penetration testing, SOC 2 Type II, ISO 27001, HIPAA attestation (with BAA on eligible plans). | Gives security and compliance teams the due diligence they expect for production data. |
| Governance (SAML/SCIM, audit logs) | Provides SAML SSO, SCIM provisioning, and audit logs on Business+ for stronger access control and change tracking. | Ensures only the right people access your telemetry and changes to org settings are traceable. |
Which Sentry Plan Do You Actually Need?
The short version:
- US/Germany data residency: Available at the organization level, not gated to a single plan.
- PII scrubbing and data controls: Available broadly via Data Scrubber, project settings, and SDK configuration.
- Governance & compliance needs: Drive whether you choose Developer, Team, Business, or Enterprise.
Here’s how I’d think about it by requirement:
1. “We must keep data in the US or Germany.”
- Sentry is hosted on Google Cloud Platform with multi-tenant architecture.
- You can choose your hosting region: United States or Germany — “choose whichever makes sense for you” (and yes, if you’re unsure, talk to your legal team).
- Sentry will store service data in the region selected via your organization configuration.
Plan impact:
This regional choice is an org-level configuration, not a premium add-on. You don’t need Enterprise just to pick US vs. Germany.
2. “We need strong PII scrubbing and privacy controls.”
Sentry’s official stance: you should not send PII at all. To back that up:
- Data Scrubber (server-side filtering):
- Enabled by default to remove values that appear to be sensitive information before they’re stored.
- You can configure additional keys or patterns to scrub in Project Settings.
- IP Address controls:
- IP storage can be disabled, which is especially important with browser SDKs where an IP could be connected to a person.
- Bulk deletion capabilities:
- You can remove events in bulk for an issue and purge data associated with specific tags if something slips through.
- Privacy posture & DPA:
- Sentry offers a Data Processing Addendum (DPA) that meets GDPR and CCPA requirements.
- AI features follow published AI Privacy Principles.
- For PHI, a Business Associate Agreement (BAA) is available on eligible plans; you shouldn’t send PHI unless you’re on an eligible plan and have signed a BAA.
Plan impact:
- The Data Scrubber and PII scrubbing controls are part of the core product, not locked behind a specific tier.
- If you need a DPA, BAA, or formal security/compliance review, you’ll usually land on Business or Enterprise.
3. “Security, access control, and auditability are non-negotiable.”
If your security team is involved (they probably are), they’ll care about:
- Transport & storage security:
- TLS for data in transit.
- AES‑256 encryption at rest and in transit.
- Annual third-party penetration testing.
- Compliance posture:
- SOC 2 Type II and ISO 27001 certified.
- HIPAA attestation and BAA for eligible plans.
- Org-level governance (Business+):
- SAML-based SSO and SCIM for automated provisioning/deprovisioning.
- Organization audit logs to track changes.
Plan impact (practical guidance):
- Developer / Team:
- Good if you primarily need debugging capabilities and basic privacy controls, and your SSO/governance story lives elsewhere.
- Business:
- Best fit when you also need SAML + SCIM, audit logs, more dashboards, and the governance your security/compliance team will expect.
- Enterprise:
- For large orgs that want technical account managers, dedicated support, custom terms, and more advanced governance.
If your question is “Which plan do I need to pass a security review?”, the answer is usually Business or Enterprise, depending on size and support expectations.
How to Configure US/Germany Data Residency Before Rollout
This is the sequence I recommend when I work with teams rolling Sentry out across multiple services.
Step 1: Decide the data region with your legal/security team
- Confirm whether you need US, Germany, or potentially multiple orgs (for example, EU users vs. global).
- Create or migrate your Sentry organization to the chosen region:
- Region is selected during org setup.
- Sentry stores service data in that region.
If you’re already running Sentry and considering a migration, talk to Sentry support or sales to discuss options like creating a new org in the required region and migrating projects.
Step 2: Select the plan based on governance, not just features
When you sign up or change plans:
- If you’re an early-stage or small team:
- Start with Team if you want a balance of features and cost.
- If you’re in a regulated or larger org:
- Choose Business to get:
- SAML SSO + SCIM
- Audit logs
- More dashboards and quotas flexibility
- Consider Enterprise if you need complex rollouts, a technical account manager, or bespoke terms.
- Choose Business to get:
Tip: Have your security team review Sentry’s Trust Center, where you’ll find details on hosting (GCP), encryption, penetration testing, SOC 2, ISO 27001, and HIPAA attestation.
How to Configure PII Scrubbing Before Rollout
The goal is simple: don’t send PII, and if something sneaks in, scrub it or delete it.
Step 1: Configure SDKs to avoid PII
In each service:
- Avoid sending:
- Full names, emails, phone numbers.
- Addresses.
- Government IDs.
- Payment card data.
- Anything your internal policies classify as personal or sensitive.
- Use user identifiers that are:
- Opaque (e.g., internal user ID or hash), not directly identifying.
- Configurable to be turned off by environment if needed.
In code, this means:
- In your Sentry SDK setup, only set
usercontext fields you actually need. - Avoid dumping full request bodies or headers unless they’re scrubbed.
Step 2: Turn on and tune the Data Scrubber
In Organization → Settings → Security & Privacy (navigation may vary slightly by UI), and then at Project Settings, configure:
-
Data Scrubber (PII scrubbing):
- Ensure the default scrubbing is enabled. Sentry’s scrubbing automatically removes values that appear to be sensitive (e.g., passwords, auth tokens) so they’re never stored.
- Add custom keys to scrub for:
authorization,auth,token,session_id, etc.- Any app-specific fields that might hold PII.
-
IP Address storage:
- Consider disabling IP storage, especially:
- For browser-based SDKs.
- For GDPR-heavy contexts where IP may be considered personal data.
- When disabled, Sentry won’t store IP addresses for events from that project.
- Consider disabling IP storage, especially:
Step 3: Configure project-level filters and event scrubbing
Within each Sentry project:
-
Use Inbound Filters to:
- Drop noisy or non-actionable events before storage (bot traffic, known spammy paths).
- Optionally, filter out events from specific IP ranges or user agents, if that aligns with your policies.
-
Use project-level Data Scrubbing to:
- Override organization defaults when a specific project has stricter or looser needs (for example, production vs. staging).
- Define regex patterns if you’ve got very domain-specific PII.
Step 4: Verify on non-production environments
Before you go live in production:
-
Instrument development and staging with Sentry.
-
Generate a range of test errors and slow transactions.
-
Inspect sampled events in Sentry:
- Confirm that:
- No PII is present in message, tags, or contexts.
- IP is absent if you disabled storage.
- If you spot any sensitive data:
- Add the relevant field names to the Data Scrubber.
- Adjust SDK code to stop sending them.
- Confirm that:
-
Repeat until your test events meet internal policy.
This is the point where I tell teams: “Break it on purpose now, so you don’t have to apologize for it later.”
Step 5: Document and lock down settings
- Document Sentry’s:
- Region choice (US or Germany).
- PII policy and scrubbing configuration.
- Which fields are allowed vs. banned.
- For Business/Enterprise:
- Use SAML + SCIM to ensure only the right users can log into Sentry.
- Use audit logs to monitor changes to org and project settings over time.
Ideal Use Cases
-
Best for teams with EU or US data residency requirements:
Because Sentry lets you store your data in either the United States or Germany and keeps it there, backed by encryption and independent penetration testing. -
Best for orgs with strict PII and privacy policies:
Because you can combine “don’t send PII” SDK practices with Sentry’s Data Scrubber, IP disabling, inbound filters, and bulk deletion to keep telemetry safe and aligned with GDPR/CCPA and internal policies.
Limitations & Considerations
-
Sentry isn’t a data-loss prevention (DLP) system:
If your SDK code intentionally sends sensitive PII or PHI without an appropriate DPA/BAA and plan, Sentry can’t magically make that okay. You must design your instrumentation to avoid sending what you’re not allowed to store. -
PHI requires an eligible plan + BAA:
If you’re in healthcare or similar fields:- You must not send PHI to Sentry unless:
- You’re on an eligible subscription plan, and
- You’ve executed a Business Associate Agreement (BAA) with Sentry.
- Without this, sending PHI would violate Sentry’s terms and your own compliance stance.
- You must not send PHI to Sentry unless:
Pricing & Plans
Sentry offers several plans, each with different feature sets, quotas, and governance options. While plan names and limits can evolve, here’s how to reason about them for data residency and PII scrubbing:
-
Data Residency (US/Germany):
- Configured at the organization level regardless of plan.
- Applies to your service data for that organization.
-
Data Scrubbing & Privacy Controls:
- Data Scrubber, inbound filters, IP disabling, and event deletion are available broadly, so you can enforce PII policies on all paid plans.
-
Governance & Compliance (Business / Enterprise):
- Business: Adds SAML SSO, SCIM, audit logs, and higher usage caps — ideal when security or compliance teams are involved.
- Enterprise: Adds higher-touch support like a technical account manager, custom SLAs, and more flexible contract terms.
In practice:
-
Developer / Team:
Best if your primary goal is debugging and you can live with lighter governance and access controls. -
Business:
Best if you:- Need SAML/SCIM for identity.
- Need audit logs for configuration changes.
- Have formal security reviews that expect SOC 2, ISO 27001, and detailed posture.
-
Enterprise:
Best if you:- Need large-scale rollout coordination.
- Want dedicated support and a partner for ongoing governance.
For up-to-date pricing and plan comparison, check:
Get Started
Frequently Asked Questions
Do I need a specific Sentry plan to get US or Germany data residency?
Short Answer: No. Data residency is an organization-level configuration, not a premium-only feature.
Details:
Sentry is hosted on Google Cloud Platform using multi-tenant architecture and offers hosting in the United States and Germany. When you configure your organization, you choose the region where your service data will be stored. That choice is independent of the plan tier—Developer, Team, Business, and Enterprise all sit on top of the same regional hosting model. Your choice of plan should be driven by feature needs and governance (SSO, SCIM, audit logs), not data residency alone.
How do I make sure Sentry doesn’t store PII from my app?
Short Answer: Don’t send PII from your SDKs, enable and tune the Data Scrubber, disable IP storage if needed, and validate in non-production before rollout.
Details:
Sentry’s official recommendation is to avoid sending PII. To enforce that:
-
SDK level:
- Only send non-identifying or pseudonymous user IDs.
- Avoid including names, emails, phone numbers, and addresses in events, tags, breadcrumbs, or logs.
-
Data Scrubber + project settings:
- Ensure the default Data Scrubber is enabled; it automatically removes values that appear sensitive (like passwords).
- Add custom keys and regexes for fields that might carry PII in your app.
- Disable IP storage, especially for browser SDKs, if IP is considered personal data under your policy.
-
Validation and cleanup:
- Test on dev/staging, inspect events, and update scrubbing rules until they meet your privacy bar.
- If PII accidentally slips through, use bulk event deletion and tag-based deletion to clean it up.
Together, these controls let you keep Sentry events focused on stack traces, spans, and performance context instead of personal data.
Summary
If you’re asking “Which Sentry plan do I need for US/Germany data residency + PII scrubbing, and how do I configure it before rollout?”, the answer looks like this:
- Data residency (US or Germany) is an organization setting available across plans.
- PII scrubbing is driven by:
- How you configure your SDKs (don’t send PII).
- Sentry’s built-in Data Scrubber, inbound filters, and IP controls.
- The ability to delete events and tag data if something slips through.
- Plan choice (Developer, Team, Business, Enterprise) should be based on:
- Governance needs (SAML/SCIM, audit logs).
- Compliance expectations (SOC 2, ISO 27001, HIPAA, BAA).
- Scale and support requirements.
Set the org region, lock down your scrubbing config, validate on staging, and then roll Sentry into production with your security and legal teams already on board.