Hi Matthias, two answers:

1. Session replay / sensitive field masking. Our PostHog clients in the dashboard, mobile app, and docs site are initialized without session recording enabled in the client configuration, so session replays are not being captured through those code paths. The "may use session replay" language in the privacy policy is permissive, not a description of an active, always-on configuration. If we enable replay in the future for diagnostic purposes, we will configure it to exclude credential fields, API tokens, and environment variable values before doing so.

2. EU residency. The "largely operated in the U.S." language refers to Railway's corporate operations, billing, and platform control plane, not to where your deployed services and their data live. When you select EU West Metal (Amsterdam, europe-west4-drams3a) as the region for a service, your application containers and volumes are deployed in that region. So EU deployment is a real residency choice, not failover or best-effort balancing.

For binding details on processing locations and sub-processors, the DPA and Trust Center are authoritative. If you need anything beyond what is published there (custom SCC modules, written confirmation for an audit), we can route it through our compliance team.

Best,

Sam

Hi Sam,

Thanks for the quick answers, really helpful.

Good to know on session replay. The DPA and the SOC 2 report don't go into this level of detail on internal tooling configuration, so having it spelled out directly is exactly what I needed for our records. Noted that the Privacy Policy language is permissive and that any future activation would mask credentials, API tokens and env vars before going live.

Same on EU residency. The DPA acknowledges that primary processing operations take place in the US, which is accurate for the control plane, but it doesn't distinguish that from where deployed containers and volumes actually live. Good to have the clarification on record. I've updated our transfer impact assessment accordingly.

A quick ask on two open points, and I'd appreciate you routing these to your compliance team as offered:

1. A written confirmation that application containers and data volumes in EU West Metal (Amsterdam, europe-west4-drams3a) are resident in that region and not routinely replicated to or accessible from US infrastructure. A brief statement or a pointer to the relevant DPA / Trust Center section would be fine.
2. A note on breach notification timing. The current DPA commits to notifying us "without undue delay" but doesn't specify a timeframe. As a GDPR controller I'm legally required to notify the supervisory authority within 72 hours of becoming aware of a breach, so in practice I need Railway's processor notification to land early enough that this is feasible. A confirmation of Railway's internal target notification window, or a willingness to add a specific SLA to the DPA, would close this for our audit file.

Neither of these is blocking, but both are needed to satisfy our GDPR Article 28 and Chapter V documentation requirements.

Thanks again,

Matthias

Voice2Evolve

Hi Matthias,

Two answers in order:

1. Region residency. When you deploy a service with a volume to EU West Metal (Amsterdam, europe-west4-drams3a), both the application container and the volume live in that region for the entire lifetime of the service unless you move them yourself. They are not routinely replicated to US infrastructure. The DPA's "primary processing operations in the US" language refers to our control plane (orchestration, billing, dashboard backend), not to where your deployed workloads and volume data sit.

2. Breach notification timing. Our internal target is to notify affected processors within 72 hours of becoming aware of a personal data breach, deliberately aligned with the GDPR Article 33 supervisory authority window so that a controller has runway to meet their own notification obligation. We have always held ourselves to this internally, even though the DPA itself uses "without undue delay" rather than a fixed number.

On amending the DPA itself: custom contractual changes (bespoke SCC modules, a numerical SLA written into the document, etc.) are scoped to our Enterprise tier rather than Hobby. For your audit file, please treat this written reply as the confirmation on both points: EU residency for deployed services and their volumes for the lifetime of the service, and the 72 hour internal notification target.

Best,

Brody

Hi Brody,

thanks for your answers! This should be enough at this point.

Really appreciate it, great Service.

Best,

Matthias