GDPR and Data Privacy
EU data residency
All data is processed exclusively in the EU.
- Application servers: netcup GmbH, Nuremberg, Germany
- File storage: Cloudflare R2 with EU jurisdiction policy — files are stored only in EU-region buckets
- No data leaves the EU under any circumstances related to storage or primary processing
What we store
| Category | Contents |
|---|---|
| Intake metadata | Project name, client email, item definitions, timestamps |
| Submitted values | Text, structured data, color lists, booleans, URLs |
| File references | R2 object keys, filenames, MIME types, file sizes |
| Secrets ciphertext | Encrypted blobs only — plaintext is never stored |
| Audit log | Actor, IP address, action, timestamp |
| Chase history | Sent reminders, delivery status, bounce records |
Client IP addresses collected during portal access are stored alongside the session and audit records they belong to (portal_sessions, sessions, audit_log) and are used only for deduplication, rate limiting and fraud signals. They are never included in webhook payloads.
Data retention
- Default: 150 days after
intake.completed, then automatic purge of all files and submitted values - Configurable per account:
PATCH /v1/account {"retention_days": N}— valid range is 1 to 3650 days - Configurable per intake: the
retentionobject ondefine_intake(below) - Immediate deletion:
DELETE /v1/intakes/:id— removes the intake, all submitted values, all R2 files, and chase history immediately and irreversibly - Account deletion: removes all intakes, files, and personal data within 30 days of the request
Delete as soon as the agent has the files
Ninety days is a long time to keep a client's photos and admin password after
your agent already downloaded them. If an intake holds anything sensitive, set
retention to on_delivery:
{
"project_name": "Website for John Finance",
"client": { "email": "john@example.com" },
"retention": { "mode": "on_delivery" }, // + optional "anonymize": false
"items": [ /* … */ ]
}The contents are then removed roughly 24 hours after get_intake_results
returns a completed intake — the point at which you have the files and a second
copy on our server is liability rather than service.
| Field | Default | Meaning |
|---|---|---|
mode |
"days" |
"days": purge N days after the client finishes. "on_delivery": purge shortly after you collect the results. |
days |
account setting (90) | Days to keep after completion. Only valid with mode: "days". |
anonymize |
true |
Keep the project record and delete everything belonging to the client. false deletes the whole intake. |
Two guarantees worth knowing:
- An intake you never collect still expires.
purge_atis set the moment the client completes, from the day count. Delivery only ever brings that date forward, soon_deliverycan never turn into "kept forever" on a project you abandoned. - There is a grace window of 24 hours. If your agent crashed between reading the response and writing the files to disk, you can ask again. Without it, one crash would mean asking the client to do the work twice.
What anonymize: true actually removes
| Deleted | Kept |
|---|---|
| Files (from R2), secrets, submitted values | Project name, creation and completion dates |
| Client email, name, phone | Item keys, labels, types, statuses |
| Magic token — the portal link stops working | Chase history (counts and timestamps) |
| Live portal sessions | Audit log entries |
What remains is the record you need — "I asked for 7 things on 15 July, all
delivered by the 20th" — holding nothing of your client's. Set
anonymize: false if you want even that gone.
Subject rights
Under GDPR, your clients (as data subjects) have rights over their personal data. As the data controller, it is your responsibility to honor these requests. BriefGate provides the following API support:
Right to access: GET /v1/audit?client_email=owner@bellacucina.cz returns all interaction records tied to that email address across your account.
Right to erasure: DELETE /v1/intakes/:id removes all data for a specific intake. For complete erasure of a client across all intakes, filter by client_email and delete each intake. Contact support for bulk erasure.
Right to portability: Submitted data is available via GET /v1/intakes/:id/results as structured JSON and signed file URLs. Export as needed before the retention period expires.
BriefGate does not provide a separate "export my data" endpoint for end clients (your clients). Providing data subject access is your responsibility as data controller.
Data controller and processor relationship
| Role | Party | Obligations |
|---|---|---|
| Data controller | You (the developer / agency) | Decide what data to collect, from whom, and for what purpose |
| Data processor | BriefGate | Process data on your instructions, implement technical safeguards |
A Data Processing Agreement (DPA) is in force from the moment you create an account — Article 28(9) GDPR allows it to be concluded electronically, so no signature is needed. It adopts the European Commission's standard contractual clauses for controllers and processors (Decision (EU) 2021/915) unmodified. It documents:
- Categories of data processed
- Processing purposes
- Security measures
- Sub-processor list
- Data subject rights procedures
Subprocessors
| Subprocessor | Role | Location | Legal basis |
|---|---|---|---|
| netcup GmbH | Application hosting | Germany (EU) | No transfer |
| Cloudflare, Inc. | File storage (R2 EU jurisdiction) | US company, EU data | Data Privacy Framework + SCCs |
| Plus Five Five, Inc. (Resend) | Transactional email delivery | US | Data Privacy Framework + SCCs |
| Twilio Inc. | SMS delivery (optional add-on) | US | Data Privacy Framework + SCCs |
| Stripe, LLC | Payment processing | US | Data Privacy Framework + SCCs |
| Functional Software, Inc. (Sentry) | Error monitoring — never client-submitted content | US company, EU data residency (Germany) | Data Privacy Framework + SCCs |
Each US subprocessor is an active participant in the EU-U.S. Data Privacy Framework and incorporates the standard contractual clauses of Decision (EU) 2021/914 — both bases are kept so that a change to the adequacy decision does not interrupt the transfer. See the DPA for the detail; that page is the authoritative list.
Security measures
| Measure | Implementation |
|---|---|
| Secret values | libsodium sealed box encryption before storage |
| File access | Signed R2 URLs with 24-hour validity — URLs are not guessable |
| Passwords | argon2id hash |
| API keys | argon2id hash — plaintext never stored after creation |
| Transport | TLS 1.2+ for all connections |
| Audit log | Immutable append-only log for sensitive operations |
| Key isolation | Secrets private key never stored in the database |