This Data Processing Agreement ("DPA") is entered into between flagr.dev ("Processor", "we", "us") and the entity or individual that has accepted the flagr.dev Terms of Service ("Controller", "you").
This DPA forms part of the agreement between flagr.dev and the Controller and applies wherever flagr.dev processes personal data on behalf of the Controller. It is intended to satisfy the requirements of Article 28 of the EU General Data Protection Regulation ("GDPR") and equivalent provisions under UK GDPR and other applicable data protection laws.
flagr.dev provides a hosted feature flag management service. Under this DPA, flagr.dev Processes Personal Data solely to deliver that service to the Controller. Processing continues for as long as the Controller maintains an active flagr.dev account, and ceases upon account deletion or termination of the Terms of Service, subject to Section 9 (Deletion and Return of Data).
flagr.dev Processes the following categories of Personal Data as a Processor on behalf of the Controller:
| Data | Source | Purpose |
|---|---|---|
| Tenant identifiers | Submitted by Controller via API or dashboard | Partial feature flag rollout — determining whether a given end-user should see a flag as enabled |
| Dashboard user identifiers (Clerk user IDs) | Generated by Clerk on authentication | Audit log attribution — recording which team member changed a flag state |
| Organisation member roles | Set by Controller admins | Access control (RBAC) — enforcing which team members can read, edit, or administer flags |
The Controller determines what values are submitted as tenant identifiers. flagr.dev recommends using opaque internal identifiers (e.g. UUIDs) rather than names, email addresses, or other directly identifying information. The Controller is responsible for ensuring that any Personal Data submitted as a tenant identifier is done so lawfully and in compliance with applicable data protection law.
flagr.dev does not access or store the content of the Controller's application, end-user profile data, payment information, or any data beyond what is described in Section 3.1. Feature flag names, project names, and environment names are treated as configuration data, not Personal Data.
flagr.dev shall:
The Controller shall:
The Controller grants general authorisation for flagr.dev to engage the following Sub-processors. flagr.dev will notify the Controller of any intended changes to this list at least 14 days in advance via email or dashboard notice, giving the Controller the opportunity to object.
| Sub-processor | Location | Purpose | Transfer mechanism |
|---|---|---|---|
| Render | United States | PostgreSQL database and Redis hosting — stores all application data including tenant identifiers | EU SCCs |
| Clerk | United States | Authentication and identity management — stores dashboard user identities and organisation membership | EU SCCs |
| Stripe | United States | Payment processing and billing — stores organisation billing details | EU SCCs |
| Cloudflare | United States / Global | CDN, DDoS protection, and WAF — handles all inbound traffic | EU SCCs |
Each Sub-processor is bound by data protection obligations no less protective than those in this DPA.
flagr.dev implements the following measures to protect Personal Data, in accordance with Article 32 GDPR:
Encryption in transit
All data is transmitted over TLS 1.2 or higher. Plain HTTP connections are redirected to HTTPS. Internal service-to-service communication runs over Render's private network.
Encryption at rest
PostgreSQL and Redis data is encrypted at rest using AES-256, provided by Render's managed infrastructure.
Access control
Role-based access control (Admin, Editor, Read Only) limits which dashboard users can read or modify data. API keys carry embedded roles and are stored as SHA-256 hashes — the plaintext key is shown once and never stored.
Authentication
Dashboard access is mediated by Clerk, which provides secure session management, multi-factor authentication support, and JWT-based API authentication.
Organisation isolation
All database queries are scoped by organisation ID, enforced at both the application and database layer. One customer cannot access another's data.
Audit logging
All flag state changes are recorded in an append-only audit log with actor, timestamp, and before/after state. The log is accessible to the Controller via the dashboard.
Least privilege
The application database user has the minimum permissions required. Administrative database access requires Render account credentials and is restricted to authorised personnel.
Vulnerability management
Dependencies are reviewed periodically. Security issues in the open-source SDK codebases are addressed through the public repository issue tracker.
flagr.dev will assist the Controller in fulfilling Data Subject rights requests to the extent reasonably practicable:
Erasure (right to be forgotten)
Tenant identifiers can be deleted individually via the Management API (DELETE /api/v1/projects/{id}/flags/{id}/environments/{id}/tenants/{tenantId}) or in bulk by deleting the flag or project. Audit log entries referencing a Data Subject's actor ID can be deleted on written request to [email protected].
Access
The Controller can retrieve all tenant identifiers stored for a given flag environment via the Management API. Audit log entries are accessible via the dashboard.
Rectification
Tenant identifiers are opaque strings — if a Controller needs to correct a stored identifier, they can delete the old one and add the corrected value.
Portability
All data is accessible via the Management API in JSON format. Full data export on written request to [email protected].
Upon termination of the Controller's account or written request, flagr.dev will delete all Personal Data within 30 days, except where retention is required by applicable law. The Controller may request a full JSON export of their data at any time by contacting [email protected] before account deletion.
Individual tenant identifiers can be deleted at any time through the dashboard or Management API without requiring account termination.
In the event of a Security Incident affecting Personal Data, flagr.dev will notify the Controller at the email address on file without undue delay and, where feasible, within 72 hours of becoming aware of the incident. The notification will include:
Notification does not constitute an admission of fault or liability. The Controller remains responsible for notifying supervisory authorities and Data Subjects as required under applicable law.
flagr.dev and its Sub-processors are based in or transfer data to the United States. For Controllers subject to GDPR or UK GDPR, transfers to the United States rely on the EU Standard Contractual Clauses (SCCs) (Commission Implementing Decision 2021/914) and the UK International Data Transfer Addendum, incorporated by reference into this DPA. Controller acceptance of this DPA constitutes execution of the applicable SCCs as the data exporter.
For each Sub-processor listed in Section 6, flagr.dev relies on the same transfer mechanisms and has confirmed that each Sub-processor is bound by equivalent obligations.
Each party's liability under this DPA is subject to the limitations set out in the flagr.dev Terms of Service. flagr.dev is liable only for damages directly caused by Processing that is not in compliance with this DPA or with applicable data protection law, and only to the extent that flagr.dev cannot demonstrate that it was not at fault.
This DPA is governed by the laws applicable to the flagr.dev Terms of Service. Where EU or UK GDPR applies, the SCCs referenced in Section 11 take precedence over any conflicting provisions of this DPA to the extent required by those instruments.
Questions about this DPA or data protection at flagr.dev: [email protected]