data processing agreement
last updated 2026-08-20 · briven.tech
This Data Processing Agreement (the “DPA”) applies whenever your use of the briven Service involves personal data governed by Regulation (EU) 2016/679 (the “GDPR”). It forms part of the Terms of Service and takes effect automatically — you do not need to sign anything for it to apply.
In plain English. This document is offered as-is, on standard terms, to every customer. It is written to be genuinely usable rather than to look impressive: where briven cannot offer what a larger vendor offers, the clause says so instead of going quiet. If your organisation needs a signed, negotiated DPA on your own paper, or additions such as a specific audit right, write to legal@flndrn.com and we will work through it with you.
1. Parties and roles
You (the “Customer”) are the controller of the personal data contained in your databases and object storage. flndrn Limited (the “Operator”, “we”), registered at Arch. Makariou III 171, Vanezis Business Center 4th floor, 3027 Limassol, Cyprus, with day-to-day operations in Flanders, Belgium, is the processor. Where you are yourself a processor acting for another controller, the Operator is a sub-processor and this DPA is read accordingly.
The Operator is a separate controller for the small amount of personal data it needs in order to run the business rather than to run your database — your account email, sign-in events, billing records and audit entries. That processing is described in the Privacy Policy and is outside the scope of this DPA.
2. Subject matter and duration
The subject matter of the processing is the provision of the hosted briven Service: operating PostgreSQL databases and S3-compatible object storage on the Customer’s behalf, together with the dashboard, the management API and the connection pooler through which the Customer reaches them.
The processing lasts as long as the Customer has an account with the Operator, and ends when the account is closed and the retention windows in §11 have run out. Individual obligations that survive by their nature — confidentiality, and the deletion duty — survive termination.
3. Nature and purpose of the processing
The Operator stores, hosts, transmits, backs up and restores whatever the Customer places in the Service, and performs the operational tasks needed to keep it available: applying security updates, taking the backups described in §7, rotating credentials on request, writing audit records of platform actions, and responding to Customer support requests.
The Operator does not read, mine, profile, sell or train models on Customer data, and does not use it for any purpose other than providing the Service and complying with law. Staff access to a Customer database happens only where the Customer asks for support that requires it, or where the Operator must act on a security incident or a binding legal demand.
4. Types of personal data and categories of data subject
The Operator does not know what you put in your database. A briven database is standard PostgreSQL with a schema you design; the Operator hosts the bytes and does not inspect their meaning. The Customer therefore determines and documents, as controller, which types of personal data and which categories of data subject the Service processes on its behalf.
By way of illustration only, the types typically include identifiers, contact details, account and profile data, usage and transaction records, files uploaded to object storage, and any free-text field the Customer’s application writes. Categories of data subject typically include the Customer’s own end users, employees, contractors and business contacts.
If the Customer intends to process special categories of personal data under Article 9, or criminal-conviction data under Article 10, it must satisfy itself that the measures in §7 are appropriate to that risk before doing so. The Operator holds no health, payment-card or government-issued-identifier certification — see §12.
5. The controller’s instructions
The Operator processes personal data only on the Customer’s documented instructions, including as to international transfers, unless required to do otherwise by EU or Member State law. This DPA, the Terms, and the Customer’s ordinary use of the Service and its documented features together constitute those instructions; the Customer may issue further written instructions to legal@flndrn.com.
Where the Operator is required by law to process beyond the Customer’s instructions, it will inform the Customer of that legal requirement before processing, unless the law prohibits it on important grounds of public interest. The Operator will tell the Customer if, in its opinion, an instruction infringes the GDPR or other data-protection law, and may decline to act on it.
6. Confidentiality of personnel
The Operator ensures that every person authorised to process personal data under this DPA is bound by a duty of confidentiality that survives the end of their engagement. Access is granted on a need-to-know basis and only to those who require it to operate or support the Service; the number of such people is small, and the Operator will state the current number on request.
7. Security measures
Taking account of the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, the Operator implements the technical and organisational measures described on the security page and summarised here. That page is kept current and is the authoritative description; the list below is the Article 32 summary.
- Isolation per database. Each database has its own login role, and connect rights are revoked from everyone else in the cluster, so one tenant cannot reach another tenant’s data.
- Encryption in transit. TLS on every public endpoint, with certificates from Let’s Encrypt and HTTP Strict Transport Security set to one year including subdomains.
- Credential protection. Database passwords are encrypted at rest with AES-256-GCM under a key held outside the database, and every reveal is written to the audit log. API keys are stored only as a SHA-256 hash with the last four characters kept in the clear, so a key cannot be recovered by anyone, including support.
- Rotation that actually revokes. Rotating a credential changes the password, resynchronises the pooler and cuts live sessions, so an exposed credential stops working rather than merely being replaced. Rotation is available through the management API and the CLI.
- Backups and restore. A full backup nightly at 02:00 UTC plus continuous write-ahead-log archiving using pgBackRest, with seven full backups retained. A restore has genuinely been performed on the live server on 19 August 2026. Restores always land in a new database beside the original and never overwrite it. The backup repository is currently held on the same machine as the databases. It protects against a dropped table, a bad migration or a corrupted cluster; it is not protection against the loss of that machine. Off-site copies are being wired now.
- Access control and accountability. Organisations, roles and per-resource permissions govern who can do what, and an append-only audit log records platform actions on the pro plan and above.
- Portability as a safeguard. Data sits in standard PostgreSQL, so a
pg_dumpover the Customer’s own connection produces a complete copy at any time and at the Customer’s own discretion.
Two limits belong in this clause rather than in a footnote. First, TLS is offered but not required on customer database connections: connection strings use sslmode=require, which encrypts the connection but does not verify the certificate, and the pooler will still accept a client that insists on plain TCP. Second, the Operator offers no multi-factor authentication, passkeys or single sign-on for dashboard accounts. Customers whose risk assessment requires either should account for that before placing sensitive data in the Service.
The Operator may update these measures over time provided the overall level of security is not reduced.
8. Sub-processors
The Customer grants the Operator a general written authorisation to engage sub-processors. The current list, with each party’s purpose, location and status, is published at /subprocessors.
The Operator will announce the addition or replacement of a sub-processor on that page, and by email to account owners, at least 30 days before the new party begins processing customer data. The Customer may object on reasonable data-protection grounds within those 30 days by writing to legal@flndrn.com. If the objection cannot be resolved, the Customer may terminate the affected part of the Service without penalty and export its data within that window; export is a standard pg_dump over the Customer’s normal connection.
Every sub-processor is engaged under a written contract imposing data-protection obligations no less protective than those in this DPA, and the Operator remains fully liable to the Customer for a sub-processor’s performance of those obligations.
9. Assistance with data subject rights
The Customer, as controller, is responsible for responding to requests from data subjects. Because the data sits in the Customer’s own database under the Customer’s own schema, the Customer can normally satisfy an access, rectification, erasure, restriction, portability or objection request directly with ordinary SQL, without involving the Operator. That is the fastest route and the Operator recommends it.
Where the Customer nevertheless needs help, the Operator will provide reasonable assistance by appropriate technical and organisational measures, insofar as this is possible, taking into account the nature of the processing. If a data subject contacts the Operator directly about data the Operator holds only as processor, the Operator will not respond to the substance itself; it will forward the request to the Customer without undue delay and tell the data subject it has done so.
The Operator will likewise assist the Customer with data protection impact assessments and prior consultations under Articles 35 and 36, to the extent the information required is within the Operator’s knowledge and not already published on this site.
10. Personal data breach notification
The Operator will notify the Customer without undue delay after becoming aware of a personal data breach affecting personal data processed under this DPA. The Operator does not commit to a fixed number of hours, because it does not yet operate detection tooling precise enough to make that promise meaningful, and a deadline nobody can measure is not a safeguard.
The notification will describe what the Operator knows at the time it writes: the nature of the breach and, where possible, the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point for further information. Where the full picture is not yet available, the Operator will send what it has rather than wait, and follow up as the investigation progresses.
Notifying a supervisory authority or affected data subjects is the Customer’s responsibility as controller; the Operator will provide the information reasonably needed to do so. Report a suspected breach or vulnerability to security@flndrn.com.
11. Deletion and return of data
The Customer can export at any time during the term, without asking the Operator: the data is standard PostgreSQL, so a pg_dump over the Customer’s own connection produces a complete copy, and object storage is reachable with any standard S3 client. The Operator will not hold data in a proprietary format only it can read.
At the Customer’s choice, on termination the Operator will delete or return the personal data it processes under this DPA, and delete existing copies, unless EU or Member State law requires storage. Deletion follows the retention windows in the Privacy Policy. Copies inside backup sets are not deleted individually — that is not technically possible in a write-ahead-log archive — and instead age out as those backups are rotated, within the seven-full-backup retention described in §7. Backups remain protected by the same measures for as long as they exist.
12. Audits and information
The Operator will make available to the Customer the information necessary to demonstrate compliance with Article 28 and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.
What that means in practice, honestly: flndrn Limited is a small, independent company. It holds no SOC 2 report, no ISO 27001 certificate, and no third-party audit report of any kind — no external audit has ever been carried out. There is therefore nothing to send you in place of an audit, and this DPA will not imply that there is.
What the Operator does offer is:
- answering reasonable written questions about its security and processing practices, including a security questionnaire, within a reasonable time;
- the published, maintained descriptions at /security, /trust and /subprocessors, which name mechanisms and gaps rather than certifications;
- reasonable access, on reasonable notice and at most once a year unless a breach or a supervisory authority requires otherwise, arranged so that it does not compromise the security or confidentiality of other customers.
Audits are at the Customer’s expense, and the Customer must keep everything it learns confidential. If and when the Operator obtains an independent audit report, this clause and the security page will be updated in the same change.
13. International transfers
The Service is operated from within the EU/EEA, and Customer databases and object storage stay on the Operator’s own infrastructure — PostgreSQL and the object store are not third parties and appear nowhere on the subprocessor list for that reason.
Where a sub-processor is established outside the EEA, or where personal data would otherwise be transferred outside it, the transfer relies on the European Commission’s Standard Contractual Clauses (Decision 2021/914), Module Three (processor to sub-processor), together with supplementary measures appropriate to the transfer: TLS in transit, AES-256 at rest, and minimisation of what reaches each party. The SCCs are incorporated into this DPA by reference for any such transfer, with the governing law and forum in §15 completing the optional clauses. The current position of every sub-processor is listed at /subprocessors.
If a transfer mechanism is invalidated, the parties will cooperate in good faith to put a lawful alternative in place, and the Customer may suspend the affected transfer meanwhile.
14. Liability
Liability under this DPA is subject to the limitations and exclusions in Section 12 of the Terms of Service, which apply to the DPA and the Terms taken together rather than to each separately. Nothing in this DPA limits a data subject’s rights under Article 82 of the GDPR, or any liability that cannot be excluded under mandatory law.
15. Governing law and order of precedence
This DPA is governed by Belgian law, and disputes are subject to the exclusive jurisdiction of the courts of Antwerp, Belgium, without limiting non-waivable rights elsewhere. Where this DPA conflicts with the Terms of Service, this DPA prevails on matters of personal-data processing; where it conflicts with the Standard Contractual Clauses, the SCCs prevail. The English version controls if translations conflict.
16. Contact
Data protection and DPA questions, including a request for a signed or negotiated version: legal@flndrn.com. Security and breach reports: security@flndrn.com. General support: support@flndrn.com.