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.

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:

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.