Data Protection Impact Assessment — mortar

*Generated 2026-05-16. Required by GDPR Article 35.*

This document is generated automatically from the manifests of all installed modules. It cannot drift from what the application actually does — if a module is installed, its processing activities appear here; if it is not installed, they do not.

Note: This document is a template scaffold. Before relying on it as a formal DPIA for notifiable processing under Article 35(3), have it reviewed by a qualified Data Protection Officer.

1. Description of Processing Operations

This Data Protection Impact Assessment covers the processing activities of mortar (org id: mortar-platform) as of 2026-05-16.

The following modules are installed and contribute to personal data processing:

Account & Authentication (platform-account v1.0.0)

Operator and team-member sign-up, sign-in, and session management for the mortar control plane.

Personal data fields:

• email
• name
• authentication_identifiers
• login_ip_address

Subprocessors:

• Clerk (US) — email, name, authentication + session metadata

Product Analytics (platform-analytics v1.0.0)

Pseudonymous product-usage analytics to improve the platform. EU-hosted; no cross-site tracking.

Personal data fields:

• usage_events
• pseudonymous_device_id

Subprocessors:

• PostHog (EU Cloud) (DE) — pseudonymous product-usage events

Subscription Billing (platform-billing v1.0.0)

Plan subscriptions, invoicing, and entitlement state for the mortar platform itself.

Personal data fields:

• billing_email
• subscription_id
• customer_id
• payment_country

Subprocessors:

• Polar (US) — billing email, subscription + payment metadata

Application Database (platform-data v1.0.0)

Primary datastore for control-plane account records, customer-app metadata, and audit logs.

Personal data fields:

• account_records
• app_metadata

Subprocessors:

• Neon (DE) — all stored account + application records (EU region)

Edge Delivery & WAF (platform-edge v1.0.0)

CDN, TLS termination, and web-application-firewall protection for all platform traffic.

Personal data fields:

• request_ip_address

Subprocessors:

• Cloudflare (US) — request IP, edge cache + WAF metadata

Transactional Email (platform-email v1.0.0)

Account, billing, and compliance notification emails (no marketing).

Personal data fields:

• email

Subprocessors:

• Resend (US) — recipient email address, message content

Error & Log Monitoring (platform-observability v1.0.0)

Application error reporting and request-log retention for reliability and security.

Personal data fields:

• error_reports
• request_logs

Subprocessors:

• Sentry (US) — error reports, stack traces
• Better Stack (CZ) — application + request logs

2. Purpose and Lawful Basis

Each processing purpose corresponds to a module and is justified by one or more GDPR lawful bases (Article 6).

Account & Authentication

Purpose: Provide the functionality declared by module platform-account.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Product Analytics

Purpose: Provide the functionality declared by module platform-analytics.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Subscription Billing

Purpose: Provide the functionality declared by module platform-billing.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Application Database

Purpose: Provide the functionality declared by module platform-data.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Edge Delivery & WAF

Purpose: Provide the functionality declared by module platform-edge.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Transactional Email

Purpose: Provide the functionality declared by module platform-email.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

Error & Log Monitoring

Purpose: Provide the functionality declared by module platform-observability.

Lawful basis: Legitimate interests (Article 6(1)(f)) and, where consent is required, explicit consent (Article 6(1)(a)). See the privacy policy for per-field detail.

3. Necessity and Proportionality Assessment

The personal data fields below are collected because they are strictly necessary to deliver the declared functionality. No fields are collected speculatively.

Data minimisation: Each module's manifest declares exactly the fields it writes. The manifest is the source of truth — the application cannot collect data that is not declared here.

Storage limitation: Consent records expire per the expires_at column. DSAR requests are deleted on erasure. Audit log entries are retained for the legally required period only.

All collected fields (deduplicated, lexical order):

• account_records
• app_metadata
• authentication_identifiers
• billing_email
• customer_id
• email
• error_reports
• login_ip_address
• name
• payment_country
• pseudonymous_device_id
• request_ip_address
• request_logs
• subscription_id
• usage_events

4. Risk Identification

Cross-Border Data Transfer Risks

The following subprocessors are based outside the EU/EEA. Transfers are covered by Standard Contractual Clauses (SCCs) or adequacy decisions.

• Clerk (US) — email, name, authentication + session metadata
• PostHog (EU Cloud) (DE) — pseudonymous product-usage events
• Polar (US) — billing email, subscription + payment metadata
• Neon (DE) — all stored account + application records (EU region)
• Cloudflare (US) — request IP, edge cache + WAF metadata
• Resend (US) — recipient email address, message content
• Sentry (US) — error reports, stack traces
• Better Stack (CZ) — application + request logs

General Data Protection Risks

| Risk | Likelihood | Severity | Residual risk after mitigations | |------|-----------|----------|---------------------------------| | Unauthorised access to personal data | Low | High | Low — RLS policies, hashed tokens, DPoP auth | | Data breach / exfiltration | Low | High | Low — encryption in transit (TLS 1.3), secrets via Infisical | | Failure to honour erasure request | Low | Medium | Low — automated erasure orchestrator | | Audit log tampering | Very Low | High | Very Low — hash-chained log + Rekor witness |

5. Mitigations and Safeguards

Technical measures

• Row-Level Security (RLS): every personal-data table has PostgreSQL RLS policies enforced at the database level.
• Hash-chained audit log: every state-changing operation produces a hash-chained entry. Chain heads are committed to the public Sigstore Rekor transparency log.
• IP / User-Agent hashing: no IP addresses or User-Agents are stored in plaintext; only a 16-character SHA-256 prefix.
• Signed privacy receipts: every consent capture produces an Ed25519-signed receipt the data subject can verify offline.
• DPoP-bound agent tokens: agent identities use DPoP-bound access tokens (RFC 9449), preventing token replay.
• Secrets management: all credentials are stored in Infisical; no secrets in source code or environment files in production.

Organisational measures

• Data Subject Request automation: DSAR access, portability, and erasure requests are processed automatically within 30 days (GDPR Article 12).
• Module manifest as source of truth: the privacy policy and this DPIA are generated from module manifests, preventing drift between documentation and implementation.
• Human oversight requirement: AI-impacting MCP tools declare humanApprovalRequired: true — no autonomous AI action affects user data without an explicit human step.

*This DPIA was generated from the `compliance-eu` module. The source of every claim is the manifest of the corresponding installed module — open source and inspectable.*