About this agreement
In short The contract Article 28 GDPR requires between an organisation and the service that processes personal data for it — published in advance, so it can be reviewed before signing up.
Such an agreement is usually drafted by each customer and sent to its provider. We publish ours instead, versioned, so a customer and its Data Protection Officer can check what is actually in place before signing up, and request amendments by writing to simon@bricks-softwares.com. The clauses say what each party undertakes; the annexes describe the processing, the security measures, the sub-processors and the tools the platform gives the controller.
1.Parties and roles
- Processor — RainbowTop Softwares SRL, operator of the Bricks platform (“Bricks”).
- Controller — the customer: the organisation (the “tenant”) that, through its operators, configures the platform to process personal data of its own end users (members, visitors, partners). Operators are the people who act on the platform on the organisation’s behalf. The controller decides which personal data is collected, on what legal basis and for what purpose; Bricks carries out those instructions through the platform.
- Data subjects — the controller’s end users whose personal data is processed by its apps on Bricks.
- Where Bricks is not the processor — Bricks is sole controller of BricksID accounts and of each operator’s own account. For data about the organisation itself — its operators and their roles, and its accounting and billing records — Bricks and the organisation are joint controllers (Article 26 GDPR); the essence of that arrangement is published in the Data Protection Notice. Neither falls under this agreement.
- Limits of the processor role — this agreement covers processing through the platform as officially supported. Where a data protection issue results from the controller configuring an app in a way the platform does not officially support, the controller is sole controller for that processing, and the commitments of this agreement do not extend to it.
2.Scope and precedence
In short This agreement is part of the contract formed when an organisation accepts the Terms of Service, and wins over them on data protection.
- This agreement, with its annexes, forms part of the contract between Bricks and the controller under the Terms of Service, and binds both from the moment the controller accepts them.
- On the protection of personal data, this agreement prevails over the Terms of Service and over any other agreement between the parties. A per-customer addendum (clause 14) prevails over this agreement for what it expressly changes.
- Annex I describes the processing; it lasts as long as the controller’s subscription.
3.Instructions
In short Bricks processes the controller’s personal data only as the controller instructs, and says so when an instruction looks unlawful.
- The controller’s instructions are this agreement, the Terms of Service, and what the controller configures on the platform: its schemas, roles and permissions, workflows, data-flow declarations, integrations, and requests made to the Studio AI. Bricks processes the personal data only on those instructions, including as regards transfers outside the EEA (clause 7).
- Where Union or Member State law requires Bricks to process the data otherwise, Bricks informs the controller before processing, unless that law prohibits it.
- Bricks informs the controller immediately if, in its opinion, an instruction infringes the GDPR or other data protection law.
4.Confidentiality
In short Only people who need access get it, they are bound to confidentiality, and their access is logged.
Bricks grants access to the controller’s personal data only to the members of its staff who need it to provide the service, each bound by a confidentiality obligation. Staff cannot sign in as a controller’s user. Access to a tenant’s infrastructure for support is logged and requires a documented reason.
5.Security
In short The measures in Annex II are in place, each with the way it is checked. They may change, but never to a lower level of protection.
Bricks implements the technical and organisational measures described in Annex II to ensure a level of security appropriate to the risk (Article 32 GDPR). It may update them as the platform evolves, provided the overall level of protection does not decrease.
6.Sub-processors
In short The controller authorises the sub-processors listed in Annex III, gets 30 days’ notice of any change, and can object.
- The controller gives Bricks a general authorisation to engage the sub-processors listed in Annex III.
- Bricks informs the controller’s administrators by email, and updates Annex III, at least 30 days before adding or replacing a sub-processor. Within that period the controller may object on reasonable data protection grounds. If the parties cannot resolve the objection, the controller may terminate the affected service without penalty.
- Bricks imposes on each sub-processor, by contract, data protection obligations equivalent to those of this agreement, and remains fully liable to the controller for their performance (Article 28(4) GDPR).
- An integration the controller activates itself (Annex III, last table) is engaged on the controller’s specific instruction, and is recorded as a data-flow declaration.
7.Transfers outside the EEA
In short Data leaves the EEA or Switzerland only where Annex III says so, and each such transfer rests on a safeguard the GDPR recognises.
Bricks transfers personal data to a third country only on the controller’s instructions and in compliance with Chapter V GDPR — an adequacy decision, or the European Commission’s Standard Contractual Clauses concluded with the sub-processor. Each current transfer and its safeguard is named in Annex III. Switzerland benefits from an adequacy decision.
8.Assistance to the controller
In short Bricks provides the platform tools in Annex IV and answers reasonable questions; the controller remains the one who answers its data subjects.
- Data subject requests. Taking into account the nature of the processing, Bricks assists the controller in answering requests under Articles 12 to 22 through the tools described in Annex IV, and passes on any request it receives directly that concerns the controller’s data.
- Security, impact assessments, prior consultation. Bricks provides the information the controller reasonably needs to meet its obligations under Articles 32 to 36 — including for a data protection impact assessment — starting with this agreement and its annexes.
9.Personal data breaches
In short Bricks tells the controller without undue delay, and within 72 hours where feasible, with what the controller needs to notify in turn.
In the event of a personal data breach affecting the controller’s data, Bricks notifies the controller without undue delay and, where feasible, within 72 hours of becoming aware of it. The notification describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed; information not yet available is provided as soon as it is. Notifications go to the organisation’s administrators on file.
Where a breach results from an act or omission of a member of Bricks’s staff or management under irresistible coercion within the meaning of Belgian criminal law — in particular an imminent and serious physical threat against them or someone close to them, wherever it occurs — Bricks treats it as a personal data breach under Articles 33 and 34 GDPR and notifies it as described above as soon as the threat has ceased. The Terms of Service treat such coercion as force majeure.
10.What the controller answers for
In short The controller decides the purposes and answers its data subjects; a few practices keep its users’ data out of places it does not belong.
- A lawful basis, and any safeguards Article 9 requires if its schema holds special categories of data.
- Its record of processing activities and, where required, its impact assessments — the platform prepares much of both (Annex IV).
- Its own end users: identifying which records belong to whom, deciding whether an exception to erasure applies, contacting them, and building in its app the self-service views they need.
- Not pasting end users’ personal data into the Studio AI, in chat or in image prompts. Refer to a record abstractly (“the member with ID X”); the AI is instructed not to ask for more.
- Image rights. Checking that images it publishes — including AI-generated ones — do not depict a recognisable person without their consent.
- Integrations. Analysing, for its own purpose, each integration it activates; our curation of what we offer is not a substitute for that analysis.
- What it does with data once exported: an export is a transfer to a system it chooses, not a transfer of responsibility.
11.End of processing
In short The controller can export everything at any time; after termination, Bricks deletes the tenant within 30 days.
- At any time, and on termination, the controller can export all its data in portable formats (Annex IV).
- On termination, or earlier on the controller’s request, Bricks deletes the tenant’s database schema, files and published apps within 30 days, unless Union or Member State law requires storage. The record of the deletion itself is kept.
- Backups are not edited selectively; they expire on their own schedule — 7 days for the database. A controller needing a stricter timeline can request an addendum (clause 14).
12.Information and audits
In short Bricks makes available what is needed to demonstrate compliance, and allows audits by the controller or its auditor.
- Bricks makes available to the controller the information necessary to demonstrate compliance with Article 28 GDPR, beyond what this agreement and the Data Protection Notice already publish.
- Bricks allows for and contributes to audits, including inspections, by the controller or an auditor it mandates who is bound by confidentiality — at most once per twelve months unless a breach or a supervisory authority justifies more, with 30 days’ notice, at the controller’s cost. Bricks answers in writing with supporting documentation, or through a remote walkthrough with its technical lead; visits to hosting data centres go through the hosting provider’s own audit process.
- The same applies to a public body that, in its first request, identifies the procurement procedure concerned (reference, procuring entity, deadline).
- Bricks does not undertake to complete any particular industry questionnaire, and may point to existing documentation where it already answers the question. Requests from anyone who is neither a customer nor a public body as above may go unanswered.
- This clause is without prejudice to Bricks’s legal obligations, including towards a supervisory authority or a court.
13.Liability
Liability between the parties is governed by the Terms of Service. This agreement neither extends nor reduces those limits, and does not affect either party’s liability towards data subjects under Article 82 GDPR.
14.Changes, addenda, languages
In short Material changes are versioned and emailed in advance; sector addenda are free; English and French are equally authoritative.
- Material changes are versioned (see version history) and emailed to each tenant’s administrators before they take effect.
- A controller whose sector or framework (healthcare, financial services, public procurement…) needs more can request a per-customer addendum at simon@bricks-softwares.com; we negotiate it at no charge.
- This agreement is published in English and in French, both equally authoritative. No other translation has legal value; translations and adaptations to another jurisdiction’s vocabulary are available as paid addenda.
- It is governed by Belgian law. The courts of French-speaking Belgium have jurisdiction, and the Belgian Data Protection Authority is the lead supervisory authority.
I.Annex I · The processing
In short What Bricks processes on the controller’s behalf.
| Subject matter | Providing a multi-tenant platform on which the controller designs data schemas, access rules and server-side workflows, publishes web apps, and is assisted by an AI in building them. |
|---|---|
| Nature | Storage, hosting, retrieval, structuring, transmission on the controller’s workflows, backup, deletion. |
| Purpose | Running the controller’s apps and workflows as it configures them. |
| Duration and frequency | Continuous, for the duration of the subscription, then clause 11. |
| Data subjects | The controller’s end users (members, visitors, partners); its operators insofar as its apps process data about them; anonymous visitors to its apps. |
| Personal data | Whatever the controller’s schema defines — typically identity and contact details, profile fields, content the end user writes, preferences. For anonymous visitors, HTTP request metadata (IP address, browser identification) in gateway logs. |
| Special categories | None by the platform itself. If the controller’s schema includes them, clause 10 applies. |
II.Annex II · Security measures
In short What protects the controller’s data, and how each measure is checked.
| Measure | What it does | How it is checked |
|---|---|---|
| Isolation between tenants | ||
| Own database schema per tenant | Each tenant’s tables live in its own PostgreSQL schema; a session is restricted to the requesting tenant’s schema, so a cross-tenant query cannot be expressed. | By construction; covered by the API test suite. |
| Row-level security | Inside a tenant, database policies derived from the controller’s roles decide which rows each user reads or writes. The database enforces them, so a faulty application server cannot bypass them. | A platform test iterates over every active tenant and fails the release if any expected policy is missing. |
| Own origin per app | Each published app has its own subdomain (and optional verified custom domains), so browsers keep one app’s cookies and storage from another’s. | Browser same-origin policy. |
| Own storage prefix per tenant | Files are stored under a per-tenant prefix; the platform refuses to construct keys outside it, and signed download links are tenant-scoped. | By construction. |
| Platform tools without a back door | Operational views over the whole platform aggregate metadata and never open a session able to read tenant rows. | Built on the same row-level security. |
| Encryption | ||
| In transit | All traffic over TLS 1.2 or later, with automatically renewed certificates; no public plain-HTTP listener. | Automated certificate management. |
| At rest | Server disks at Infomaniak (Switzerland) are encrypted; the managed database and object storage at Scaleway (France) are encrypted by the provider. | Provider commitments. |
| Identity and access | ||
| BricksID | Built on GoTrue, an open-source, widely deployed identity service: passwords hashed with bcrypt, email verified at signup, self-service password reset by single-use link. | Relies on an audited implementation rather than a home-grown one. |
| Sessions | Access tokens expire after one hour and refresh tokens rotate; the API refuses any token without a valid expiry. | Enforced at the API boundary. |
| Staff access | No impersonation of users; support access to a tenant’s infrastructure logged with a documented reason (clause 4). | Access log. |
| Availability and recovery | ||
| Database backups | Daily snapshots of the managed database, kept 7 days. | Provider backup schedule. |
| Snapshot before destructive changes | Per-tenant snapshots are stored in that tenant’s storage. In the Studio AI’s advanced mode on a tenant with real data, a snapshot is taken automatically before a destructive schema change; in standard mode the AI stops and recommends one. During the change, the app shows a maintenance page. | Enforced by the AI’s schema tools. |
| Restore | Restoring a tenant’s live data from a snapshot is performed by Bricks staff on request, scoped to that tenant, and logged. | Operator procedure. |
| Change management | ||
| Release pipeline | A release runs, as gates: unit tests, browser tests of authenticated pages, integration tests, the row-level-security test over every tenant, and API behaviour tests. Deployment ships the tested version’s files, not a working copy. | Continuous integration. An emergency path that skips the tests exists for urgent fixes and is the exception. |
| Apps and third parties | ||
| Declared data flows | Every external request an app makes a visitor’s browser send must be declared by the controller — vendor, purpose, lawful basis, data categories, retention — and signed by an administrator. The app’s Content-Security-Policy is generated from those declarations. | The browser blocks anything undeclared. |
| No third-party code | Apps cannot load scripts, fonts or stylesheets from third-party origins; fonts are served by the platform. No analytics, tracking, advertising or profiling is added to apps. | Content-Security-Policy; the Studio AI refuses such additions. |
| The Studio AI | ||
| One tenant per conversation | Database handles, file roots and tools are bound to one tenant at the start of a turn and cannot change during it. | By construction. |
| What reaches the language model | The operator’s messages and the results of tools reading the tenant’s structure — schema, code, workflows, roles. It does not read the app’s rows. Two exceptions: reading the last few inputs a workflow received, only after warning the operator and receiving their go-ahead; and, in advanced mode, rendering a published page as an anonymous visitor, which shows only public content. The model is Anthropic’s (US) or, if the controller selects it, Mistral’s at Scaleway (France). | Tool-level restrictions; the warning is required by the tool itself. |
| No training, no identifiers | Anthropic’s commercial terms exclude training on API inputs and outputs by default; Bricks enables no extended retention and attaches no end-user identifier to requests. | Client configuration. |
| Sandbox on synthetic data | When the AI tests a change before applying it, it works in a separate sandbox schema loaded only with synthetic data it generates; its restore tool refuses any snapshot that is not a synthetic fixture. | Enforced in code. |
| Auditable logic | Server-side behaviour — workflows, schema, roles, permissions — is stored as structured configuration read directly by the platform’s engines; no language model runs in an app at runtime. Every AI tool call is logged, and the conversation is visible to the controller, who can delete it. | Structured artefacts; exportable (Annex IV). See also AI transparency. |
III.Annex III · Sub-processors
In short Who processes the controller’s data on Bricks’s behalf, where, and on what safeguard. The list is complete.
| Sub-processor | Service | Data | Location · safeguard |
|---|---|---|---|
| Infomaniak Network SA | Servers hosting the platform; DNS; team mailboxes | Controller data resident on the servers; team email | Switzerland · adequacy decision |
| Scaleway SAS | Managed PostgreSQL and object storage; transactional email for tenants using the platform sender; Mistral inference when the controller selects that preset | The platform database and files at rest; recipients and content of tenant emails sent through it; for Mistral, the same context as the Studio AI row of Annex II | France (fr-par) · EU |
| Anthropic | Language model for the Studio AI | As described in Annex II, “What reaches the language model” | United States · Standard Contractual Clauses in Anthropic’s data processing addendum |
| Brevo | Relay for platform account emails: sign-up confirmation, password reset, email change, invitations, platform notifications. Not tenant app email. | Recipient address and message content | France, sending infrastructure in the United States · Standard Contractual Clauses in Brevo’s data processing agreement. Being replaced by Scaleway; see the known gaps. |
| Grepleaks | Security audit of an app, only when the controller runs one | App source code, workflow and table definitions; no database rows | [location and safeguard to confirm] |
Also used, but not on the controller’s behalf
- Mollie (Netherlands) and Cabai (Belgium) — payments and invoicing for Bricks’s own billing of the organisation; see the Data Protection Notice.
- Black Forest Labs (Germany) — generates images from the text prompts an operator writes; it receives no end users’ personal data (clause 10 on image prompts).
Integrations the controller activates
Connecting an app or workflow to another service — an external SMTP provider, a CRM, a calendar, a meeting-notes service such as Leexi — makes that service a recipient on the controller’s instruction (clause 6.4). We list an integration only once we can answer the questions a data protection review would ask of it: jurisdiction, retention, data processed, security, typical lawful basis. Each activation is recorded as a data-flow declaration and appears in the controller’s register (Annex IV).
IV.Annex IV · Controller tools
In short What the platform gives the controller to meet its own obligations.
| Tool | What it gives | Where |
|---|---|---|
| Record of processing activities (Art. 30) | A register per organisation, composed from what the platform knows: controller and privacy contact, personal-data columns in its schema, recipients and transfers from its data-flow declarations, retention, and the automated processing its workflows perform. Each section is marked as derived, declared, or to be completed — purposes and security, for example, are the controller’s to write. It covers processing on the platform, not what the controller does elsewhere. | Organisation settings → Data protection · PDF, and CSV per section |
| Data subject requests | End users file access and erasure requests from their account; they reach the organisation, which decides. Closing a BricksID files an erasure request with every organisation the person belongs to. | Organisation settings; the end user’s My organisations page |
| Transparency for end users | Each end user sees, per organisation, the workflows that process their data and the organisation’s data protection page. | /account → My organisations |
| Data-flow declarations | The list of third-party recipients per app, with lawful basis; also downloadable as CSV per app. | App settings → Data flows |
| Export | The database schema as a SQL dump, all files, the source of every published app, and the configuration (workflows, roles, permissions, declarations) as JSON — enough to run the processing elsewhere. | Organisation settings → Export |
Other data protection frameworks
The platform is designed around the GDPR. Controllers under the Swiss revFADP, Brazil’s LGPD, South Korea’s PIPA or Japan’s APPI can use the same measures — row-level security, declared data flows, the register, the end-user transparency views — to evidence their own compliance. This is a statement about the architecture, not a certification; the assessment for a given use remains the controller’s.
Version history
- 2.0 · 29 September 2026 — Restructured as clauses and annexes after the Commission’s standard contractual clauses (2021/915). Added: binding effect and precedence, documented instructions, confidentiality, 30-day notice and right to object for sub-processors, transfers, assistance with impact assessments, inspections. Aligned with the v3 Terms: roles (clause 1), breaches under coercion (clause 9). Corrected: what reaches the language model, account closure, the Article 30 register, backup retention, missing sub-processor (Grepleaks). Removed: automatic deletion after inactivity and a dedicated security-contact setting, neither of which exists.
- 1.0 — First published version.
Not yet cryptographically signed. Our Terms of Service are; this agreement will follow.