sota.io
2026-05-01·13 min read·
AWS Pinpoint is Amazon's managed multi-channel marketing engagement platform. It handles email, SMS, push notifications, in-app messaging, and voice campaigns — along with the full analytics pipeline that makes those campaigns addressable: contact attribute storage, behavioural event ingestion, automated segment computation, A/B testing, and journey orchestration. For product teams and marketers, Pinpoint consolidates what previously required multiple third-party services: email delivery, contact segmentation, engagement analytics, and campaign automation in a single AWS-managed system. The GDPR problem is structural. Pinpoint is not a delivery relay — it is the system of record for your marketing database. Every contact, every consent record, every engagement event, every segment assignment sits in a US-controlled service under CLOUD Act jurisdiction. This post analyses what AWS Pinpoint actually holds, why the consent database is the highest-value CLOUD Act target in most SaaS stacks, and what EU-native marketing automation alternatives provide equivalent engagement capabilities without routing your users' marketing profiles through US-controlled infrastructure. --- ## What AWS Pinpoint Actually Processes AWS Pinpoint is commonly described as a messaging service — an abstraction that significantly understates the personal data scope. Pinpoint is more accurately described as a contact intelligence platform. **Endpoint records (the core data store):** Every user, device, or contact address in Pinpoint is represented as an "endpoint" — a record that combines a channel address with a rich attribute set: - Channel address: email address, phone number (SMS), device token (push), advertising ID (in-app) - User ID: the application-level identifier linking the endpoint to a user account - Demographic attributes: country, region, city, language, timezone - Custom user attributes: any application-specific data the developer pushes — plan tier, account age, feature usage flags, referral source, company size - Device attributes: platform (iOS/Android/Web), app version, device model, OS version - Location data: latitude/longitude if the application transmits location events - Channel-specific opt-in/opt-out status: per-channel consent flag with timestamp - Last active date and session count **Engagement event stream:** When Pinpoint SDKs are integrated into mobile apps or web applications, they ingest a continuous stream of user behaviour: - Session events: app open, app close, session duration, session count - Custom events: any application-defined action — button clicks, screen views, feature interactions, purchase completions - Monetization events: in-app purchase amounts, product identifiers, transaction quantities - Authentication events: sign-in, sign-out - Campaign interaction events: email open (with timestamp and IP), email click (with link and timestamp), push notification received, push tap, SMS delivery confirmation All event data is timestamped and linked to the user's endpoint record. The complete event log constitutes a detailed behavioural timeline for each user. **Segment state:** Pinpoint computes and stores segment membership — which users belong to which targeting groups. Segments may be: - Static: a fixed list of endpoint IDs (e.g., a CSV import of newsletter subscribers) - Dynamic: automatically recomputed based on attribute filters (e.g., users in Germany with premium plan and last active within 7 days) - Imported: lists from external CRMs or data warehouses Segment state is stored in Pinpoint. Dynamic segment membership is continuously recomputed as attributes change — meaning Pinpoint tracks not just current segment assignment but the effective history of which users matched which targeting criteria over time. **Campaign and journey execution logs:** Every sent message is logged: recipient endpoint, timestamp, campaign ID, journey state (for multi-step journeys), message variant (for A/B tests), delivery status, bounce category, complaint flag. Journey states record which step of an automated lifecycle workflow each user is currently in. --- ## GDPR Vector 1 — CLOUD Act on the Complete Consent Database The consent database is among the highest-value assets in a GDPR-compliant marketing operation — and for CLOUD Act purposes, among the most revealing targets. **What Pinpoint holds that constitutes the consent record:** AWS Pinpoint stores opt-in status per channel as endpoint attributes. A typical Pinpoint endpoint record contains: - `OptOut: ALL` or `OptOut: NONE` or channel-specific flags indicating marketing consent - The timestamp of the last opt-in or opt-out event (via the UpdateEndpoint API call history) - Application-defined custom attributes that many teams use to store consent metadata: consent version, consent collection method, double opt-in confirmation timestamp, consent source (signup form, checkout checkbox, API grant) This means that for organisations that build their consent management on Pinpoint attributes, the consent database itself — the record of who has given permission to be marketed to, and when, and under what terms — sits in AWS infrastructure and is fully accessible under the CLOUD Act. **The CLOUD Act blast radius on a Pinpoint tenant:** A CLOUD Act order directed at Amazon Web Services for a Pinpoint project can yield: 1. The complete contact list with all channel addresses (email, phone, device tokens) 2. All demographic and custom attributes for every contact 3. Complete per-contact consent history (opt-in/opt-out flags and their effective dates) 4. Full engagement event history (every email open, click, app session, in-app action) 5. Current segment assignments revealing how contacts are categorised and targeted 6. Campaign interaction logs revealing which contacts received which marketing communications and how they responded 7. Journey state revealing where each contact is in active lifecycle marketing workflows This is more than a mailing list — it is a complete marketing intelligence profile for every user your application has ever communicated with, including the behavioural data that informed every targeting decision. --- ## GDPR Vector 2 — Art.22 Automated Profiling through Dynamic Segmentation Article 22 GDPR restricts "solely automated processing" that produces decisions having "significant effects" on data subjects. AWS Pinpoint's dynamic segmentation creates Art.22-relevant automated profiling at scale. **How dynamic segments constitute automated profiling:** A Pinpoint dynamic segment is defined by filter criteria that are continuously evaluated against the endpoint attribute store. Examples of dynamic segments in common use: - "Users who have not logged in for 30 days and have a premium subscription" → receives win-back campaign - "Users in Germany who opened the last three campaigns but did not click" → receives discount offer - "Users with account_type=trial and created_within_last=14_days" → enters conversion journey - "Users with last_purchase_category=enterprise and company_size>500" → receives enterprise upsell journey Each of these segments drives marketing decisions: which message the user receives, whether they get a discount, whether they are targeted for upsell, whether they are deprioritised for future campaigns. The decision is made entirely automatically — no human reviews segment membership before campaign dispatch. **Art.22 documentation obligations:** Controllers processing personal data for automated segment-based marketing must: - Inform data subjects under Art.13(2)(f) that their data is used for automated profiling to make marketing decisions - Provide meaningful information about the logic involved (which attributes determine segment membership) - Guarantee the right to obtain human review, to express a point of view, and to contest the decision - Conduct a DPIA if the automated processing is likely to result in high risk (Art.35(3)(a)) When the profiling engine — Pinpoint's segmentation service — operates on US-controlled infrastructure, the controller cannot guarantee that the profiling logic and data are not accessible to US authorities. An Art.22 DPIA for Pinpoint-based segmentation must document this CLOUD Act risk and assess whether it represents "high risk" under Art.35(3)(a). --- ## GDPR Vector 3 — Art.17 Right to Erasure: The Endpoint and History Gap Article 17 GDPR grants data subjects the right to erasure — the requirement to delete personal data without undue delay when consent is withdrawn or the processing purpose is no longer valid. **The structural erasure problem in Pinpoint:** AWS Pinpoint's primary erasure mechanism is the `DeleteEndpoint` API call, which removes the endpoint record for a specific address. However, Pinpoint's data architecture means endpoint deletion does not constitute complete erasure: **Analytics event data:** Pinpoint ingests session events, custom events, and monetization events into its analytics store (Amazon Kinesis Data Firehose + S3 export or direct event stream). Events are linked to the user identifier at ingestion time. Deleting the endpoint record does not retroactively delete or anonymise event records that have already been written to the analytics store. The user's behavioural history remains in the event log. **Campaign message history:** Sent message records (timestamp, recipient, campaign, delivery status) are stored in Pinpoint's campaign and analytics data. DeleteEndpoint removes the endpoint but does not delete sent message records referencing that endpoint ID. **Export and Kinesis streams:** If the Pinpoint event stream is exported to S3 or consumed by downstream analytics services (QuickSight, Redshift, Athena), the erasure obligation extends to all downstream copies. Pinpoint's DeleteEndpoint does not cascade to S3 exports or downstream analytics databases. **A/B test results and journey analytics:** If a user participated in an A/B test or was part of a journey, their interaction data contributed to aggregate analytics (open rates, click rates, conversion rates by variant). While aggregate data may be outside Art.17 scope if truly anonymised, interaction event records linked to user IDs are not aggregate. **The practical erasure gap:** A GDPR-compliant erasure workflow for Pinpoint requires: 1. `DeleteEndpoint` for each channel address 2. Identification and deletion of all event records in the Pinpoint event stream 3. Deletion of all S3 or data warehouse exports containing the user's event data 4. Verification that journey state and campaign history no longer reference the user Steps 2-4 require custom infrastructure outside Pinpoint — there is no built-in erasure cascade. For most teams, only step 1 is implemented, leaving the historical record intact. --- ## GDPR Vector 4 — Art.7 Consent Integrity Under US Jurisdiction Article 7 GDPR requires that consent be demonstrably given — the controller must be able to demonstrate that the data subject consented. Consent records stored in Pinpoint endpoint attributes are held in US-controlled infrastructure. **The consent record jurisdiction problem:** When a user exercises their Art.7 right to withdraw consent, the controller must update the Pinpoint endpoint opt-out flag and document the withdrawal event. This consent change event is written to AWS's infrastructure. The complete consent audit trail — original opt-in, any subsequent re-consent events, final withdrawal — exists only in Pinpoint's data store. For a GDPR enforcement action requiring demonstration of consent, the controller must produce consent records from Pinpoint. These records are simultaneously accessible to US authorities under the CLOUD Act. A CLOUD Act order during regulatory proceedings (a GDPR complaint investigation, a DPA audit) could result in US access to the same consent records the EU regulator is examining — creating a parallel disclosure pathway not contemplated by the GDPR's Art.46 transfer mechanisms. **Mass opt-out event intelligence:** A CLOUD Act order can reveal not just individual consent status but aggregate consent events — mass opt-out surges that correlate with news events, competitor actions, or regulatory announcements. This provides competitors or US government actors with intelligence about user satisfaction and retention dynamics that constitutes commercially sensitive information beyond mere personal data. --- ## GDPR Vector 5 — Art.25 Data Minimization: Rich Telemetry by Default Article 25 GDPR requires privacy by design and by default — processing should be limited to what is necessary for the specified purpose from the outset, without requiring users to take action to minimise data collection. **Pinpoint SDK default telemetry collection:** The AWS Amplify SDK (which integrates Pinpoint for analytics) collects by default when analytics is enabled: - Session start and stop events with duration - Device metadata: model, manufacturer, OS version, locale, timezone - App version and build number - In-app purchase events with transaction ID and product identifier - Custom user attributes and endpoint attributes populated by the application For a basic email delivery use case — the most common Pinpoint deployment — the session analytics, device metadata, and in-app event collection are not necessary for the processing purpose. Art.25 requires these to be disabled by default; configuring them out requires explicit developer action. **Location data collection:** Pinpoint's `UpdateEndpoint` API accepts latitude and longitude as endpoint attributes. If the application transmits location data, it is stored in the endpoint record and available for geographic segmentation. Location data is among the most sensitive personal data categories under GDPR (and may constitute special category data when revealing home address or religious attendance patterns). The default SDK does not disable location attribute storage if the application transmits it. **Retention policy:** Pinpoint retains event data for 90 days by default in the analytics console. Endpoint records persist indefinitely unless explicitly deleted. The 90-day event retention may exceed the purpose limitation period for many processing activities — but there is no automatic data aging or anonymisation. Compliance with Art.5(1)(e)'s storage limitation principle requires explicit configuration outside Pinpoint's defaults. --- ## GDPR Vector 6 — Art.13/14 Transparency: The Marketing Stack Hidden in Plain Sight Article 13 requires controllers to inform data subjects about the identity of all processors at the point of data collection. Article 14 applies when data is not collected directly from the data subject. Both are systematically unmet in typical Pinpoint deployments. **The push notification transparency gap:** When a user grants push notification permission to a mobile application, they consent to receiving notifications from the app — not to having their device token stored in Amazon's infrastructure, their session behaviour tracked, and their notification engagement profiled. Privacy notices typically state that the company "uses your data to send relevant notifications" — without disclosing Amazon Web Services as the underlying infrastructure processor. **The email engagement transparency gap:** When a user receives a marketing email, they are not informed that clicking a link or opening the message generates an event record in AWS Pinpoint containing their email address, the timestamp of the interaction, and their device's IP address. The visible sender is the company; the invisible processor is Amazon. **Art.13(1)(e) disclosure requirement:** Art.13 requires disclosure of any recipients or categories of recipients of personal data. For Pinpoint deployments, the complete disclosure would name Amazon Web Services as a recipient of engagement event data. Most privacy notices describe marketing analytics in generic terms ("analytics partners") without identifying AWS as the specific infrastructure processor. **Art.35 DPIA trigger:** When Pinpoint is used for large-scale processing of behavioural engagement data (which it typically is — a marketing database is by definition large-scale), the combination of behavioural profiling, automated segmentation, and cross-channel tracking may trigger the Art.35 DPIA requirement under the criteria of "large scale processing of personal data" and "systematic monitoring." The DPIA must assess CLOUD Act risk — a risk that cannot be adequately mitigated while the marketing database remains on US-controlled infrastructure. --- ## EU-Native Alternatives to AWS Pinpoint European product teams need marketing automation that handles segmentation, email, push, SMS, and behavioural analytics — without routing the marketing database and consent records through US infrastructure. ### Brevo — EU-Native Marketing Platform [Brevo](https://www.brevo.com/) (formerly Sendinblue) is a French company headquartered in Paris, with EU-resident data processing as a core offering. It provides: - Email marketing and transactional email with SMTP relay and API - SMS and WhatsApp campaigns - Marketing automation: behavioural triggers, drip sequences, lead scoring - Contact segmentation: attribute-based and behavioural segments - Landing pages, forms, and CRM lite - Dedicated IP options for high-volume senders Brevo's Art.28 DPA guarantees EU data residency with no transfer to non-adequate third countries. As a French company with no US parent, it is not subject to CLOUD Act jurisdiction. The consent database and engagement history remain in EU jurisdiction. **Strengths:** Competitive pricing, complete marketing suite, established EU company with strong DPA documentation, GDPR-native design. High-volume plans include dedicated sending infrastructure. **Considerations:** Less developer-centric than Pinpoint. Event-driven automation is less flexible than Pinpoint's Journey builder for complex multi-channel workflows. **Best for:** B2B and B2C product teams needing full marketing automation with email, SMS, and transactional messaging from a single EU-native provider. ### Mautic — Open Source Marketing Automation [Mautic](https://www.mautic.org/) is an open-source marketing automation platform with full self-hosting capability. Deployed on EU infrastructure, it provides complete control over the marketing database and all engagement data: - Contact management with custom field support - Segment builder: attribute and behavioural filters - Campaign builder: visual multi-step automated workflows - Email and SMS channel support - Form tracking and landing page builder - Lead scoring and contact lifecycle management - REST API for integration with product analytics Self-hosted on EU infrastructure (Hetzner, OVHcloud, Ionos), Mautic eliminates all third-party cloud jurisdiction — the marketing database, consent records, and engagement event log are under the controller's direct control with no sub-processor in the consent chain. **Strengths:** Zero cloud vendor dependency, full data portability, extensive API, active open-source community. No per-contact pricing — cost scales with infrastructure rather than audience size. **Considerations:** Requires infrastructure management: MySQL/PostgreSQL, web server, cron jobs, file storage. Managed Mautic hosting services exist (Acquia Mautic, hosted EU providers) for teams that prefer SaaS deployment. **Best for:** Organisations with DevOps capacity that need full data sovereignty and no per-contact cost ceiling. ### PostHog — Product Analytics and Feature Flags with EU Hosting [PostHog](https://posthog.com/) is an open-source product analytics platform that covers the behavioural analytics function of Pinpoint (session recording, event analytics, funnel analysis, feature flags, A/B testing) without the email delivery component. Available as cloud (EU hosting in Frankfurt) or self-hosted. **GDPR-relevant strengths:** - EU Cloud option with EU data residency and no US data transfer in the standard configuration - Open source: self-hostable on EU infrastructure for full sovereignty - Built-in GDPR controls: person deletion API, property sanitisation, sampling - Feature flags for gradual rollout without US infrastructure dependency **Best for:** Product analytics and experimentation use cases where Pinpoint's behavioural event collection is the primary need. Pair with Brevo or Mautic for email delivery. ### Iterable / Customer.io — US Platforms with EU Region Option [Iterable](https://iterable.com/) and [Customer.io](https://customer.io/) are US-based marketing automation platforms that offer EU data residency options. While EU hosting reduces latency and some compliance burden, both companies are US-headquartered — meaning CLOUD Act jurisdiction applies to the US parent regardless of where data is hosted. These platforms are a meaningful improvement over AWS Pinpoint's unrestricted US-jurisdiction exposure, but they do not provide CLOUD-Act-free sovereignty equivalent to Brevo (EU company) or self-hosted Mautic. For organisations where CLOUD Act risk to the marketing database is a material compliance concern, EU-company or self-hosted options are the appropriate choice. --- ## Migration Strategy: From AWS Pinpoint to EU-Native Marketing **Phase 1 — Audit the Pinpoint data scope.** Export all endpoint records (via `ExportJob` API), event data exports, and segment definitions. Identify which personal data categories are present in custom attributes — this determines the Art.30 entry and Art.35 DPIA scope for the replacement system. **Phase 2 — Map consent records.** Identify where consent metadata is stored: in Pinpoint endpoint attributes, in an application database, or split between both. If consent records exist only in Pinpoint endpoint attributes, the migration must export and re-import them into the replacement platform before deactivating Pinpoint. **Phase 3 — Select replacement stack.** For full marketing automation: Brevo (SaaS, EU company) or Mautic (self-hosted, EU infrastructure). For product analytics only: PostHog (EU cloud or self-hosted). For transactional email: Brevo or Postmark EU routing. **Phase 4 — Migrate contacts with consent metadata.** Export Pinpoint endpoint records. Transform into the replacement platform's contact format. Import with consent status and timestamp preserved. Validate opt-out flags are correctly mapped — incorrect mapping could result in marketing to contacts who have withdrawn consent. **Phase 5 — Migrate segments and campaigns.** Recreate dynamic segment definitions in the replacement platform. Rebuild campaign and journey logic. Test against a subset of contacts before full cutover. **Phase 6 — Erase Pinpoint data and update Art.30 records.** After migration validation, execute `DeleteEndpoint` for all endpoint records and delete Pinpoint projects. Update Art.30 register to remove AWS as a processor for marketing engagement data. Update Art.13/14 privacy notices to reflect the new EU-native processor. Update Art.35 DPIA to document CLOUD Act risk elimination. --- ## The Marketing Database as CLOUD Act Intelligence Asset AWS Pinpoint concentrates a specific category of high-value data: the relationship between a company and its users, expressed as contact attributes, engagement behaviour, and consent state. This data is commercially sensitive not just for the company but for market intelligence purposes. A CLOUD Act order on a company's Pinpoint tenant reveals: - The total size of the addressable user base (all endpoint records) - Geographic distribution of users (demographic attributes, locale settings) - Engagement quality of the user base (open rates, click rates, active vs dormant segments) - Which marketing campaigns are active and how users respond to them - The consent health of the marketing database (percentage of opted-in contacts, recent opt-out trends) - Lifecycle automation state (which users are in what stage of onboarding, conversion, retention journeys) This is competitive intelligence that goes beyond personal data protection — it reveals commercial strategy, customer acquisition performance, and product adoption patterns. For SaaS companies, the Pinpoint database is simultaneously a GDPR compliance obligation and a commercially sensitive asset. Placing it in US-controlled infrastructure means accepting US government access to both dimensions without notice. --- ## Practical Decision Matrix | Requirement | AWS Pinpoint | Brevo | Mautic (self-hosted) | PostHog | |---|---|---|---|---| | Email marketing | ✅ | ✅ | ✅ | ❌ | | SMS/Push | ✅ | ✅ | ✅ Plugin | ❌ | | Behavioural event ingestion | ✅ | ⚠️ Limited | ⚠️ Via forms | ✅ | | Dynamic segmentation | ✅ | ✅ | ✅ | ✅ | | Journey/automation builder | ✅ | ✅ | ✅ | ⚠️ Feature flags | | A/B testing | ✅ | ✅ | ✅ | ✅ | | CLOUD Act exposure | ❌ Yes | ✅ None | ✅ None | ✅ (EU) / ✅ (self) | | EU company/jurisdiction | ❌ | ✅ French | ✅ Self-hosted | ✅ EU cloud | | Per-contact pricing | ✅ | ✅ | ❌ Fixed infra | ✅ Event-based | | Self-hosted option | ❌ | ❌ | ✅ | ✅ | --- ## Why the Marketing Database Is Not a Peripheral GDPR Decision Organisations frequently treat the marketing stack as a lower-priority GDPR concern compared to databases holding health records, payment data, or authentication credentials. This prioritisation underestimates what the marketing database contains. The marketing database combines three categories of high-sensitivity data: identity (contact addresses that identify natural persons), consent (the legal basis for most marketing communication), and behaviour (engagement history that profiles preferences and activity patterns). No other operational system holds this combination simultaneously — and no other system makes the data as readily addressable at scale. AWS Pinpoint is operationally excellent at what it does: it makes large-scale behavioural marketing infrastructure simple to operate. But operational simplicity comes with a structural trade-off — every user's marketing profile, consent record, and engagement history is stored in US-controlled infrastructure accessible under the CLOUD Act. For European organisations committed to GDPR-compliant marketing operations, the consent database and engagement record should be the first systems migrated to EU jurisdiction — not because they contain the most sensitive data, but because they hold the legal basis and the evidence trail that justifies all other data processing. Placing this foundation in US infrastructure undermines the GDPR compliance argument for everything built on top of it. [sota.io](/) provides EU-native platform infrastructure for deploying marketing automation — Brevo, Mautic, PostHog — without routing contact profiles, consent records, or engagement history through US-controlled platform layers. Deployed on sota.io, your marketing database operates in EU jurisdiction with no US parent company in the processor chain.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing