Data Processing Agreement

About this document

Under the EU General Data Protection Regulation (GDPR) Article 28, when a customer uses a service to process personal data on their behalf, a written agreement must exist between the customer (the data controller) and the service provider (the data processor). Traditionally that agreement is drafted by the controller and sent to the processor, asking for the specific protections the controller's compliance programme requires.

Bricks publishes this Data Processing Agreement in the opposite direction. Rather than waiting for each customer to send us their own version, we make the technical and organisational measures that the platform actually implements public and versioned. Customers can review what is already in place before signing up, point their Data Protection Officer at this single page during due diligence, and request specific amendments by writing to support@bricks-softwares.com.

This document is the standard offer. Where a customer's regulator, framework, or sector imposes additional requirements (e.g. healthcare, financial services, public procurement), we will negotiate a per-customer addendum at no charge.

This page is not the platform's Terms of Service. The Terms govern the commercial relationship — pricing, service levels, intellectual property, liability — and live at /terms. The two documents are complementary and signed independently.

What this document is and is not. It is a description of the technical and organisational measures the platform implements and commits to maintain for as long as the Bricks service operates. It is not a per-customer binding commercial agreement; the binding commercial agreement is the Terms of Service plus whatever per-customer addendum we negotiate when a controller's sector or framework imposes additional requirements (see §17 below). This page changes as the platform changes; material revisions are versioned and notified per §17.

1. Parties & roles

• Processor — RainbowTop Softwares SRL, operator of the Bricks platform and Bricks Softwares ecosystem.
• Controller — the customer (the "tenant") who configures the Bricks platform to process personal data of their own end users (members, visitors, partners). The controller decides which personal data is collected, on what legal basis, and for what purpose; Bricks executes those instructions through the platform.
• Data subjects — the controller's end users whose personal data is processed by the controller's app(s) running on Bricks.

2. Subject matter, nature, purpose, duration

Bricks provides a multi-tenant Software-as-a-Service platform that lets a controller design data schemas, define access control, run server-side workflows, deploy a public or authenticated web app, and use an AI assistant to build that app. The personal data processed is whatever the controller configures their app to collect — typically end-user account information, content the end user authors, and platform usage signals.

Processing lasts for the duration of the controller's subscription. Upon termination, the controller can export their data in a portable format and Bricks deletes the tenant's primary stores within thirty (30) days; cold backups expire on their own rolling schedule (see §11).

3. Multi-tenant infrastructure

Bricks runs as a single multi-tenant platform — one set of physical machines serving every customer. Isolation is enforced at multiple layers so that two customers running on the same hardware cannot read, modify, or even discover each other's data.

3.1 Per-tenant database schemas

Each tenant gets a dedicated PostgreSQL schema (tenant_<slug>). All tenant tables, views, and stored procedures live inside that schema. The PostgreSQL search_path session variable, set per-request from the authenticated user's JWT, restricts SQL execution to the requesting tenant's schema. A cross-tenant query is not "blocked at the API layer" — it is impossible to express, because the relevant tables are not visible to that session.

3.2 Row-level security

Inside each tenant schema, PostgreSQL Row-Level Security (RLS) policies further restrict which rows a given end user can read or modify. Policies derive from the platform's access model: org administrators see everything in their tenant, members see what their role grants, anonymous visitors see only what's explicitly published. RLS runs in the database engine itself, so even a misbehaving application server cannot circumvent it.

RLS materialisation is itself verified on every release. A platform-level test suite (the substrate specs) iterates over every active tenant in continuous integration and confirms that the role-derived select / insert / update / delete policies exist on every table that requires them. A regression that silently drops a policy on a single tenant cannot reach production: the pre-deploy gate refuses to ship if the substrate spec for any tenant fails. This is in addition to, not in place of, the database-engine enforcement described above — the spec verifies that the policies the engine enforces are the policies the access model intends.

3.3 Dedicated subdomains per app

Every published tenant app receives its own dedicated subdomain (<slug>.apps.bricks-softwares.com) and optionally one or more verified custom domains. The browser's Same-Origin Policy isolates each app as its own origin — cookies, session storage, IndexedDB, and service workers from one tenant's app are cryptographically prevented from being read by another tenant's app even when both run in the same browser. This is in addition to, not in place of, the server-side isolation described above.

3.4 Per-tenant object storage

Tenant assets (uploaded files, AI-generated images, app build artefacts) are stored on S3-compatible object storage (Scaleway Object Storage, region fr-par) under a per-tenant key prefix. The platform refuses to construct keys outside the requesting tenant's prefix; signed download URLs are scoped to the calling tenant only.

3.5 Encryption

In transit: all traffic to *.bricks-softwares.com and to *.apps.bricks-softwares.com is served exclusively over TLS 1.2+ with certificates issued by Let's Encrypt and renewed automatically. Custom domains attached by tenants receive their own TLS certificates the first time they're verified, also via Let's Encrypt. HTTP listeners are not exposed publicly.

At rest: the underlying VPS storage at our hosting provider (Infomaniak, Switzerland) is encrypted at the disk layer (AES-256) by the data centre. The managed PostgreSQL database (Scaleway, France) and S3 object storage (Scaleway, France) are encrypted at rest by the provider; the platform's secret store inherits the Infomaniak disk-level encryption.

3.6 Access & permission management

Tenant users authenticate against a per-tenant identity system. The controller (org admin role) assigns roles to their team and to their end users; permission policies on tables and ownership paths translate those roles into row-level access. Platform staff cannot impersonate a tenant user. Access by platform staff to tenant infrastructure for support purposes is logged and limited to operators with a documented business reason.

Platform-level operational tools (such as the cross-tenant storage audit view used by platform administrators to monitor object-storage footprint) are built on top of the same RLS substrate rather than around it: they aggregate metadata that does not require reading tenant rows, and they do not elevate to a session that could read tenant data. The operational need to see the platform as a whole does not give the platform team a path to circumvent the controller's data boundary.

3.7 Backup, restore, and the maintenance flag

Per-tenant database snapshots are taken via pg_dump into the platform's object-storage backbone. The snapshot is bound to the tenant's identifier and stored alongside that tenant's other data, not in a cross-tenant backup pool — the same isolation rules described in §3.1 apply to the snapshot itself.

Snapshot capture before destructive schema operations is mode-conditional. Under the Studio AI's "heavy reasoning" mode against a production tenant (the platform default for real-data tenants), the AI captures a snapshot automatically before any destructive alter_column operation it would perform on the controller's behalf — the snapshot serves as the recovery point. Under the "preprod" mode (which the operator enables when the tenant carries only test data), the auto-capture is skipped to avoid wasted storage. Under the standard mode, the AI surfaces a recommendation and ends the turn awaiting the operator's manual snapshot — the per-turn budget is sized for small fixes, not for an autonomous capture-then-apply cycle. In every mode, the tenant is placed behind a short "maintenance" flag during the mutation itself so visitor traffic is served a status page rather than a half-applied schema. Restore from a snapshot is itself an explicit operation, scoped to the originating tenant, and recorded in the platform's operational log.

The Studio AI's internal verify-before-apply loop, available under heavy reasoning, uses a separate tenant_X_sandbox schema as its test environment. The AI's sandbox inputs are restricted at the tool layer to synthetic data fixtures the AI generates itself — real production data captured in a snapshot is never made available to the AI through this path, even where the operator could load it for forensic investigation. This separation is enforced in code (the AI's sandbox-restore tool refuses any snapshot whose stored purpose isn't on the synthetic-fixture allow-list).

Restore back into the tenant's live schema (rolling a production tenant back to a captured state after an adverse change) is on the formalisation roadmap; until it ships, live recovery against a snapshot identifier is operator-mediated through support. The snapshot lineage itself — the substantive Article 32(1)(c) measure — is in place. This is the platform's answer to the GDPR Article 32(1)(c) obligation — "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident" — applied not only to disaster recovery but also to the smaller-scale incident class that the AI's own destructive operations represent. Recovery is a designed-in primitive, not an after-the-fact runbook.

3.8 Change management — pre-deploy verification

No code change reaches production without passing a four-stage verification chain that runs as a hard gate on the deploy pipeline: API unit tests, end-to-end API behaviour specs (Webspicy), the platform-level substrate specs that verify RLS materialisation described in §3.2, and full-stack browser tests against authenticated routes (Playwright). Each stage refuses to start unless the previous stage passed, and the slowest stage is gated behind the cheapest, so regressions are caught at the cheapest point at which they are visible. A change that would weaken any of these guarantees does not ship.

4. AI orchestrator — data protection by design

The Bricks Studio AI helps the controller design tables, write workflow logic, generate app code, and produce images. The orchestrator is the part of the platform that has the broadest data access during a turn — by design, it can read the tenant's schemas, edit its app source, and write rows to backend stores. The measures below describe how that power is constrained.

4.1 No cross-tenant context

Every AI conversation is scoped to a single tenant. The orchestrator's database handles, file-system roots, and tool surfaces are bound to that tenant's identifiers at the start of the turn and cannot be swapped mid-turn. A request made from tenant A's Studio chat can never inadvertently mutate or read tenant B's data, because tenant B simply isn't reachable from the session.

4.2 Declared third-party data flows

Bricks treats every external network request that a tenant's app would cause a visitor's browser to make as something the controller must explicitly declare. Each declared flow names the vendor, the purpose, the GDPR Article 6 lawful basis, the personal data categories transferred, the retention statement, and is co-signed by a tenant administrator. The platform's Content-Security-Policy for the app is generated from these declarations — a vendor URL not covered by a signed declaration is blocked at the browser level. The Studio AI is configured to refuse to write code that loads an undeclared third-party URL. See the data-flow declarations design for the full policy table and the AI tool surface.

4.3 No third-party scripts, fonts, or stylesheets in tenant apps

Tenant apps cannot pull JavaScript, web fonts, or stylesheets from third-party origins. The platform CSP enforces this at runtime; the AI's app-edit tools are prompted to refuse such additions. Web fonts come from a curated, platform-hosted catalogue populated on demand from public-domain font sources; the visitor's browser only talks to the platform.

4.4 No tracking, no advertising, no profiling

The platform does not run analytics, tracking pixels, advertising, or behavioural profiling on tenant apps, and the AI is configured not to add them. Categories like analytics, captchas, payment-processor scripts, social-media embeds, and tenant-chosen third-party CDNs are platform-level "no" and cannot be added by AI through the regular workflow — they're feature requests routed to support@bricks-softwares.com. Vendor-supplied "anonymous" / "no-cookie" URL variants are treated as cosmetic and do not bypass the declaration requirement.

4.5 AI provider — what leaves the platform, what does not

The orchestrator uses Anthropic's Claude API as the underlying language model. The relevant Anthropic terms are publicly available and the controller can verify them directly:

• Training — Anthropic's Commercial Terms of Service commit, by default, to not training Anthropic's generative models on customer API inputs or outputs. This default applies to Bricks's API usage; the platform does not enrol in any programme that would change it.
• Retention — Anthropic retains inputs and outputs for a short window for trust-and-safety / abuse-detection purposes; the current published retention windows live on Anthropic's privacy portal. Bricks does not enable any extended-retention beta feature.
• What Bricks configures in the API call — the platform's SDK construction is a plain commercial API client: API key, optional base URL, request timeout. No metadata.user_id is attached, no end-user identifiers leave the platform with the request, and no opt-in headers for training-related features are set. The platform's interactions with Anthropic are limited to the same surface any commercial API customer uses.

The scope of what Anthropic processes is intentionally narrow. Each turn sends the conversation context (system prompt + the operator's recent messages + tool call results from operations on the tenant's schema, source code, workflows, and roles). That is operator-authored content and software-engineering / business-context information the operator chose to share with the AI to get help building their app.

Anthropic does NOT receive end-user personal data from the controller's deployed apps. The platform is structurally designed so the AI cannot read the deployed app's runtime state, its database rows, or its end users' content — see §4.6 below. As a consequence, the personal data of the data subjects (the controller's app users) never enters the Anthropic processing pipeline through normal platform use.

The controller is responsible for not introducing end-user personal data into the Studio chat manually. Pasting an end user's name, email, address, or other identifying information into a Studio message bypasses the platform's isolation by the controller's own action; that pasted content then becomes part of the conversation context Anthropic processes. Bricks's standing instruction to the controller is: when you need the AI to know about a record, refer to it abstractly ("the member with ID X", "the appointment for the row I'm about to fix") rather than copying the personal data into chat. The Studio AI is itself prompted not to ask for that information.

Anthropic is listed as a sub-processor in §7 below for the operator-scoped data described above.

4.6 No deployed-page scraping

The Studio AI is structurally prevented from reading the rendered HTML of a deployed tenant app or its end-user-visible state. This was a deliberate design choice during the AI tool surface review: tools that "screenshot the app" or "fetch deployed HTML" would expose end-user data (data subjects' content) to the AI processing pipeline without the controller's specific instruction. The AI works from the source files it edits and from what the controller tells it.

4.7 Auditability — determinism over generation

Bricks's bias as a platform is to make as much of a tenant's app as possible deterministically derived from structured artefacts, rather than generated turn-by-turn by an LLM. Workflows, database schemas, roles, permissions, and ownership paths — the artefacts that determine what the app actually does at runtime — are configured by the tenant operator (often with the AI's help), stored as structured data in the platform's own engines, and read directly by those engines at execution time. They are not regenerated each turn by the AI, they do not drift, and they cannot misrepresent the system to anyone inspecting them: the structure is the system.

As a consequence, the server-side logic of every Bricks app is fully determined by these constraints. The Studio AI configures business flows by editing these structured artefacts; the orchestrator validates each edit for cybersecurity properties (RLS coverage, lawful access paths, declared data flows for any external request — see §4.2), for quality (workflow consistency, role completeness, schema validity), and for content safety (refusing artefacts that would carry harmful instructions or output that an LLM might otherwise produce). Whatever a tenant's app does on the server side is auditable by inspecting these artefacts directly — no LLM is in the runtime loop.

The frontend of a tenant's app is AI-generated code, and a different set of guarantees applies. The platform's frontend boilerplate imposes the substantive security and predictability primitives (CSP per app, authentication via BricksID, RLS-aware data calls via the Bricks SDK, locked layout and routing files); the AI is instructed to keep its generated code mapped through the platform's semantic layer (concepts, capability index, file-tree shape) so what it writes remains readable as a coherent app rather than as opaque assembly. The full generated source of every published app is exportable and auditable as-is — the controller can read every byte the visitor's browser will receive.

In addition to these architectural guarantees, every AI tool call during a tenant turn is logged with its name, timestamp, and success/failure outcome; the conversation history (user messages, AI messages, attachments) is stored in the tenant's schema and visible to the controller in the Studio interface; the controller can delete a conversation at any time.

Deterministic loop detection — the AI's reasoning is itself an inspectable artefact. When the Studio AI engages with the same problem across multiple turns, the platform records what it has been trying to resolve as a per-tenant intent-tag knowledge graph: structured bindings (which tags fire, against which concept, how many times) in the database, and a short prose record per app at docs/intents/<slug>.md. When the same intent fires three times against the same unresolved binding, the loop is detected deterministically — not as a probabilistic judgement of "did the model figure it out", but as a structural signal that escalation or branching is required. The controller can read both the structured bindings and the prose; the platform's automated decisions about when to escalate are themselves auditable. This addresses the human-oversight requirement of EU AI Act Article 14 at the substrate level: oversight is exercised over an inspectable artefact, not over a probabilistic black box.

4.8 Generative imagery and right to image

The Studio AI can produce images on the controller's explicit request through the generate-image tool. The underlying image-generation service is Black Forest Labs (BFL, Germany). The text prompt the controller types is sent to BFL; BFL returns a generated image which the platform stores in the tenant's asset prefix.

Personal-data scope of this flow: BFL receives only the text prompt and returns an image. Prompts are about visual concepts — they do not, in normal use, contain end-user personal data from the controller's app. BFL is therefore not listed as a sub-processor in §7: it does not process personal data of data subjects (and the controller is asked not to put end-user personal data in image prompts, for the same reason described in §4.5 about the Studio chat in general).

Right-to-image scope of this flow: generative imagery raises a distinct legal concern from data protection. Generated images may depict people, groups, or scenarios that resemble identifiable real-world individuals or communities, even when the prompt did not name anyone. In several jurisdictions Bricks operates in (notably France and Belgium) "droit à l'image" / personality rights protect individuals against the unauthorised publication of their likeness; in cases where a generated image clearly identifies a real person, GDPR may also apply to that image as personal data of the identified individual.

Controller responsibility: the controller is responsible for ensuring that any image they publish through their Bricks-hosted app respects applicable image rights and personality rights of the people who might be depicted, intentionally or incidentally. Practical guidance: do not prompt the AI to generate images "in the style of [named real person]" or depicting recognisable individuals without their consent; review generated images for unintended resemblance to staff, members, or public figures before publishing.

Platform measures: the platform refuses to call BFL when the generate-image tool is not active; generated images are stored only in the requesting tenant's prefix; the controller can delete any generated asset at any time through the Studio chat history or the file management interface.

5. BricksID — end-user identity and data transparency

BricksID is the platform's identity layer for the data subjects: the end users of the controller's deployed apps. A BricksID is a single account belonging to a person — not to a tenant — that they can use to authenticate to any Bricks-hosted app whose controller has invited them or whose surface is public. Authentication, profile, notifications, and data-transparency views all live under /account/* for the end user.

5.1 Why this exists

Most multi-tenant platforms either (a) silo identity per tenant, so the end user has to create one account per app they visit, or (b) federate to a single corporate identity provider, which gives that provider a complete map of which apps the user touches. Neither suits the position Bricks takes: end users should own their identity, see what happens to their data, and exercise their rights without going through the tenant's support desk first.

5.2 GoTrue — why we lean on an existing auth layer rather than rolling our own

BricksID is built on GoTrue, the open-source identity service developed alongside Supabase Auth. Bricks did not roll its own auth stack: choosing GoTrue means the platform inherits well-audited, widely-deployed implementations of the parts of identity that are easy to get dangerously wrong if written from scratch. Concretely:

• Passwords are stored hashed using bcrypt with a per-password salt. The plain-text password is never stored, never logged, and never accessible to platform staff after the moment of submission.
• Email verification on signup is enforced by default — a Bricks-app account cannot operate against the controller's data until the user has proven they control the email address they signed up with.
• Self-service password reset via single-use, time-bounded email links. The user is in control of their credential lifecycle without having to ask the controller's admin to reset anything for them.
• Magic-link login (passwordless email sign-in) is supported, letting users avoid password reuse entirely if they prefer.
• JWT-based sessions with refresh-token rotation: access tokens are short-lived (1 hour), refresh tokens are rotated on every use, so a leaked access token has a small blast radius and a leaked refresh token becomes detectable. The platform's API rejects any token that does not carry a valid exp (expiry) claim — tokens forged or replayed without an expiry are refused at the API boundary itself, not after they have already been used. Authentication errors are surfaced as a structured, typed error layer (a stable error code plus a descriptive message), so a misconfigured client cannot drift into silently accepting an expired or malformed session.
• Self-service account deletion: the user can erase their BricksID from the account interface without going through any tenant. The erasure cascades according to the GDPR-erasure procedure described in §10 below.
• OAuth provider integration for third-party sign-in, together with support for federated identity servers — letting an end user authenticate against Bricks via their own identity provider — are on the roadmap; until then, BricksID authenticates with email + password or magic links.

5.3 Cross-tenant identity, controller-scoped data

One BricksID per person, many apps. The identity itself (email, hashed password, account metadata) belongs to Bricks platform infrastructure; the data the user creates or has created on their behalf inside a particular tenant's app belongs to that tenant's schema. A user revoking their BricksID does not delete the tenant's records about them — that is a separate erasure flow per app, scoped to the controller who holds that data (§10).

Longer-term direction — access-mandate protocol. RainbowTop Softwares is exploring the development of an access-mandate protocol that would let the end user fully hold and manage their own data, and grant applications access to it only by explicit and revocable mandate. This project is not yet built; it remains open to any research partnership, to any public or private funding, or to any investment vehicle wishing to accelerate its concretisation, and aligns with the data-sovereignty trajectory Bricks claims for itself.

5.4 End-user transparency at /account — who processes my data

End users have direct platform-level visibility into how their personal data is processed, without having to file a Subject Access Request. The /account/* interface exposes:

• My data — a structured view of every field stored on the user's account at the platform level (profile, sign-in history, active sessions).
• My apps — every Bricks-hosted app the user has authenticated to, with the tenant (controller) name and contact email for each. Each app row is the entry point to the per-app data + per-app processing views below.
• My data processing (per app) — the list of workflows configured by the controller on that app, with a plain-language description of what each does. This is the practical surface of §5.5 below: the workflow list IS the user's view of the controller's processing activities, structured and queryable rather than buried in a PDF.
• Export and delete: a per-app data export and a per-app erasure request, both routed to the controller's instance directly.

5.5 Workflows as an effective Article 30 register at app level

Under GDPR Article 30, controllers must keep a Record of Processing Activities — a structured list of what personal data they process, why, on what legal basis, and who receives it. For most controllers this is a separate document maintained by a DPO and rarely visible to the data subjects whose data is being processed.

On Bricks, the controller's workflows in their tenant constitute a structured map of in-app processing activities and so provide a substantive starting point for keeping the register required by Article 30 of the GDPR. Each workflow carries explicit metadata: name, description, trigger condition (manual, webhook, schedule, table change), tables it reads, tables it writes, and the external systems it calls (when covered by a signed data-flow declaration — see §4.2). The controller cannot configure a workflow that processes personal data without that processing showing up in this metadata. This in-app audit substantially reduces the controller's Article 30 compliance burden: most of the processing activities the application actually performs are documented by the simple act of building it. For end users, the same metadata drives the transparency view at /account (§5.4).

The in-app audit is not, on its own, a Records of Processing register in the sense of Article 30. It documents only the automated processing executed by the platform; it does not cover manual or off-platform processing the controller may carry out separately (office-tool follow-up, email exchanges, in-practice processing, etc.), nor non-routine processing the controller may organise outside their Bricks application. The controller remains sole judge of the completeness of their register and must, where applicable, complement the Bricks-derived map with the processing they operate outside the platform. Where the controller is required to keep or publish a register under Article 30(1) or 30(2), the Bricks map already covers the bulk of their effective in-app processing and so provides a concrete basis to which they add what happens outside the platform.

Combined with the data-flow declarations of §4.2 (which document third-party data recipients per app), this in-app substrate gives end users a unified answer to "who processes my data, and how" for the application layer: the controller's workflow list for what happens server-side, the data-flow declarations for what crosses to third parties, both queryable through the user's own account view without anyone's permission and without delay.

6. Categories of data subjects & personal data

The controller decides exactly what personal data their app processes. Typical categories observed across the platform:

• Tenant operators (the controller's staff): name, email, role, authentication credentials (hashed), platform usage logs.
• End users (the controller's app users): authentication credentials (hashed), profile fields the controller's schema defines, content the user authors, preferences.
• Anonymous visitors: HTTP request metadata (IP, User-Agent) at the edge proxy, retained in access logs for a rolling 30-day window for security and abuse-investigation purposes; never associated with an authenticated identity unless the visitor signs in.

Sensitive or special-category data (health, religion, political opinion, etc.) is not processed by Bricks itself; if the controller's app schema includes such data, the controller is responsible for the additional safeguards Article 9 requires.

7. Sub-processors

Bricks uses the following sub-processors for the processing of personal data on the controller's behalf. Customers are notified of changes to this list by email and on this page (version bump). The list is intentionally short and disclosed in full.

Black Forest Labs (Germany), the image-generation provider invoked by the Studio AI's generate-image tool, is intentionally not listed here. The platform does not send personal data of data subjects to BFL — only the text prompts the controller authored and the resulting image bytes. The right-to-image considerations relevant to that flow are documented in §4.8 above.

Sub-processors located outside the EU/EEA process data under EU Standard Contractual Clauses where applicable, plus additional safeguards we've documented in the corresponding vendor contract.

8. Cryptographic integrity of platform documents

The Terms of Service published by the platform are cryptographically signed using Ed25519 inside the platform. The signing key, the signed payload format (commit id, content SHA-256, issuer, key id, kind, published timestamp, version tag), and the database columns that record each commit's signature are described in the platform's operations documentation. Verification is available directly through the platform's terms-verify endpoint at /terms/verify.

This Data Processing Agreement is not yet integrated into that signing infrastructure. Extending it to this document — and to the Data Protection Declaration and any other RainbowTop Softwares document carrying legal or compliance weight — is planned, and is part of the same independent-verifiability trajectory. Until then, the content of this Agreement is versioned by manual increment (version tag in the header) and notified per §17; it is not cryptographically signed.

Independent verification — publication in progress. The platform's roadmap includes publishing the public verification keys, a reference offline verifier, and the signed-commit history in a separate open-source repository (OpenBricks) under a permissive licence. Once that publication is in place, any third party — a customer, an auditor, or a court — will be able to verify a downloaded copy of the Terms of Service against the platform's published key history without relying on bricks-softwares.com being online; extending that verifiability to the present Agreement will happen as part of the wider document-signing rollout described above.

9. Data breach notification

In the event of a personal data breach affecting a controller's data, Bricks will notify the controller without undue delay and, where feasible, within seventy-two (72) hours of becoming aware of the breach. The notification will describe the nature of the breach, the categories and approximate number of data subjects concerned, the likely consequences, and the measures taken or proposed to address it. The notification email address per tenant is the org admin email on file; controllers can configure a dedicated security contact via the platform settings.

10. Data subject rights — what we provide, what the controller builds

The controller is responsible under GDPR Articles 12–22 for responding to data subject access, rectification, erasure, restriction, portability, and objection requests. Bricks supports that responsibility with a deliberately narrow set of platform-level capabilities and is explicit about what the controller must build themselves.

10.1 What the platform provides directly

• End-user self-service erasure of their BricksID account — at /account/* as described in §5. Cascades into a per-app erasure that removes the data subject's rows from each tenant schema, while preserving the auditable transaction log of the erasure itself.
• Per-tenant data export — the controller can export everything in their schema, their object-storage prefix, and the source of their published apps from the Studio at any time, in standard portable formats. See §12.
• Article 30 Records of Processing register per app — generated from the data-flow declarations of §4.2 and downloadable as CSV by the controller.
• End-user transparency view — the user-facing /account/* interface lets data subjects see which workflows process their data per the §5.5 transparency surface.
• Reasonable assistance via support@bricks-softwares.com on platform-level questions about the above.

10.2 What the controller must build or operate themselves

Several Article 12–22 obligations require knowledge of the controller's specific processing context that the platform cannot have. Bricks is explicit about not fulfilling these on the controller's behalf:

• Data subject identification. The platform does not maintain mapping logic that determines which rows in a tenant schema belong to which data subject beyond what the controller's schema itself encodes. The controller designs the relationship between their authentication identity and their domain-specific data. If an erasure or access request requires looking up records across several tables that don't share an obvious identifier, the controller builds that lookup in Studio (a workflow, a database view, an app screen) — not Bricks.
• Purpose discrimination. The platform does not track which piece of personal data was collected for which purpose; that is part of the controller's processing-record obligation and is encoded in the controller's own schema design, workflows, and data-flow declarations. Bricks does not determine on the controller's behalf whether a given request can be denied under Article 17(3)(b) (legal obligation), 17(3)(c) (public interest), 17(3)(d) (archival), or another Article 17 exception.
• Proactive contact with data subjects. Bricks does not contact the controller's end users on their behalf — not to notify them of a deletion, not to advise them of a rights change, not to confirm an erasure. The controller owns the end-user relationship and operates that channel themselves.
• Building the access / rectification / portability mechanisms in the app itself. Where an end user expects a self-service view of "my data in this app" or "download my data from this app", the controller builds that surface in Studio — typically a workflow + a page in the app. The Studio AI can help design these but does not know the specific personal-data needs of each end-user population; the design call is the controller's.

This boundary is the GDPR controller / processor allocation applied strictly: the controller decides who the data subjects are, what they need, and how to serve them; the processor provides the platform mechanisms (storage, schema, workflow engine, Studio editing surface) and the few cross-cutting end-user features that genuinely belong at platform level (BricksID account, raw export, Article 30 register).

11. Retention and deletion

Bricks does not run automated retention enforcement today. The platform's retention model has two states: explicit termination by the controller, and the platform's reserved right to delete after prolonged inactivity. Automated retention policies (time-bounded retention per data category, per-tenant schedules, etc.) are a roadmap item; until they ship, the rules below are what the platform actually operates.

11.1 Termination by the controller (explicit request)

• The controller can export all data from their tenant schema, all files from their object-storage prefix, and the full source of their published apps, in standard portable formats (SQL dump, files in their original storage paths, app source as a tar archive). See §12.
• The controller can request deletion. Bricks deletes the tenant's primary stores within thirty (30) days of the request. Cold backups expire on their own rolling schedule (currently ninety days) and are not selectively pruned; controllers needing a stricter timeline should request the per-customer addendum described in §17.

11.2 Inactivity-based retention (platform-initiated)

Bricks reserves the right to delete tenant data after a prolonged period of inactivity to limit the platform's exposure to data it no longer has a documented purpose to hold. Today this works as follows:

• 3 months of inactivity — defined as no login, no app build, no workflow execution, no Studio chat activity from any user of the tenant — triggers a notification to all tenant administrators on file. The notification offers an export option and asks the controller to either log in (which resets the inactivity clock) or explicitly request retention beyond the standard window.
• No response after the notification proceeds to full deletion of the tenant's primary stores on the schedule documented in §11.1. The audit trail of the deletion itself is retained.

Controller's duty during inactivity-based deletion. The controller is the data controller for their end users' data. It is the controller's responsibility to ensure their data subjects have had the opportunity to obtain any personal data they hold rights to (Articles 15, 20) before the deletion is executed. Bricks does not contact the controller's end users on their behalf, does not identify which end-user belongs to which records (see §10.2), and does not delay deletion to give end users individual notice. The controller decides whether to communicate the impending deletion to their end users, and if so, how.

12. Data exports and portability

A tenant data export is available from the Studio at any time and contains:

• the controller's PostgreSQL schema as a portable SQL dump;
• the controller's S3-prefix file storage (uploaded assets, AI-generated images, app build artefacts) as a directory tree;
• the source of every published app as a tar archive of files;
• the configuration metadata that drives the platform's view of the tenant (workflows, roles, permissions, data-flow declarations) as structured JSON.

Together these allow the controller to take their data and re-instantiate the processing operation elsewhere — the GDPR Article 20 (portability) right at the controller level. The structured workflow metadata is the same metadata that drives §5.5; an exported tenant remains queryable for "which workflows processed which data" without depending on Bricks's continued operation.

Once data leaves the platform via export, anything done with that data is the controller's sole responsibility. Bricks has no visibility into and no control over how exported data is stored, who can access it, what additional processing is applied, or where it is forwarded. The controller's obligations as data controller under GDPR continue to apply to the exported copy in exactly the same way as to the in-platform original; the export is a data transfer to a system the controller chooses, not a transfer of responsibility.

13. Interoperability and opt-in sub-processors via integrations

Beyond the named sub-processors of §7, the platform offers an integration surface that lets a controller connect their app or workflows to additional third-party services. Examples include sending email via an external SMTP provider, calling a CRM API from a workflow, pulling data from a calendar service, or activating a specific Studio AI capability that uses a vendor we have separately vetted.

Each integration the controller enables typically introduces a new sub-processor for the data flowing through it. Activating an integration is therefore a controller decision with data-protection consequences:

• Bricks curates what we propose. We do not list an integration until we have a defensible answer to the questions a data-protection review would ask of us — vendor jurisdiction, retention behaviour, data categories processed, security posture, lawful-basis fit for the typical use case. The curated list reflects our judgement of what is reasonable to make available; it is not a substitute for the controller's own analysis.
• The controller's responsibility under GDPR is to conduct that analysis for the specific purpose they intend the integration to serve. A DPIA may be required under Article 35 depending on the use case and the categories of data subjects affected. This is the controller's obligation, not Bricks's. Choosing an integration without the analysis is operating without an Article 6 lawful basis assessment — the same kind of compliance gap the data-flow declarations of §4.2 are designed to surface.
• The Studio AI can advise on good practices — propose a less invasive vendor, point out where a declaration is required, suggest a self-hosted alternative when one exists — but the AI does not know the specific data-protection needs of the controller's end users, the controller's regulatory context, or the controller's risk appetite. AI advice is informative; the controller's analysis is determinative.
• When the controller activates an integration that introduces a new sub-processor, that sub-processor is recorded as a data-flow declaration (§4.2). The full list of declared flows per app is queryable by the controller and exported in the Article 30 register described in §10.1.

14. Compatibility with other data-protection frameworks

The platform is designed around the GDPR's controller / processor model and the Belgian Data Protection Authority's interpretation of it. Several other data-protection frameworks share enough structure with the GDPR that the technical and organisational measures described in this document provide a credible compliance starting point for them as well — though final assessment is always the controller's job for their specific use case.

The frameworks we currently know enough about to credibly claim baseline compatibility with:

• Swiss revFADP / nFADP (Federal Act on Data Protection, revised 1 September 2023). The platform's hosting at Infomaniak in Switzerland makes Swiss law applicable to the at-rest layer regardless; the controller / processor allocation, lawful-basis taxonomy, breach-notification timeline, and data subject rights surface in §10 map closely to FADP requirements.
• Brazilian LGPD (Lei Geral de Proteção de Dados, Law 13.709/2018). The "agente de tratamento" allocation, the rights of the "titular dos dados", and the ANPD's expectations on records of processing and DPIA-equivalents are addressable with the same platform mechanisms — workflows as register of processing (§5.5), data-flow declarations (§4.2), Article 30-equivalent export (§10.1).
• South Korean PIPA (Personal Information Protection Act, last major revision 2023). PIPA's notification, consent-by-purpose, and cross-border-transfer requirements align with the consent and lawful-basis granularity we surface in the data-flow declarations.
• Japanese APPI (Act on the Protection of Personal Information, last major revision 2022). APPI's "personal information handling business operator" obligations and the cross-border-transfer disclosure rules can be served with the same per-app declarations and Article 30-equivalent register.

Baseline compatibility is not certification. None of the above are certifications, audits, or formal recognitions. They are honest statements that the platform's architecture is GDPR-shaped enough that a controller subject to one of these frameworks is unlikely to face platform-level obstacles to compliance, and can use the same technical measures (RLS, per-app data-flow declarations, workflows-as-register, /account transparency) to evidence their own posture under their own framework. Sector-specific adaptations (healthcare records, financial services, public-procurement requirements) and jurisdictions outside this list are handled as paid per-customer addenda — see §17 for the addendum mechanism and §13 for the integration-by-integration responsibility model.

15. Right to audit and security enquiries

RainbowTop Softwares answers reasonable enquiries on the security, compliance, and data-protection posture of the Bricks platform, in addition to the information already published in the present Agreement, in the Data Protection Declaration, and in the technical and organisational measures referenced above.

We undertake to respond, within a reasonable timeframe and to a reasonable level of detail, to enquiries falling into one of the following categories:

• Existing customers — an operator under an active subscription or consulting engagement, with an enquiry proportionate to the scope of their use of the platform, routed through the customer's designated commercial contact at RainbowTop Softwares. The controller may exercise this right at most once per twelve-month period.
• Public bodies in the context of a procurement procedure — a public authority, contracting body, or institutional buyer who, in their initial enquiry, identifies the public tender, framework agreement, or procurement procedure for which the audit information is requested, together with the reference number, the procuring entity, and the deadline of the procedure.

Outside these two cases, RainbowTop Softwares reserves the right not to respond, in particular when the requester is not a customer of the platform and has not declared a public-procurement context as described above, when there is reasonable doubt as to whether the enquiry originates from, or is mandated by, an actual operating customer of the platform, or when the scope or volume of the enquiry is manifestly disproportionate to the requester's actual footprint on the platform and has not been escalated through a commercial contact at RainbowTop Softwares.

RainbowTop Softwares does not commit, by the present clause, to completing any specific industry questionnaire, framework, or template. Where a customer or qualifying public body submits such a template, RainbowTop Softwares assesses in good faith whether it can be answered in a proportionate manner from existing platform documentation, and reserves the right to redirect the requester to that documentation where it already addresses the substance of the enquiry.

For qualifying requests, RainbowTop Softwares responds either in writing with supporting documentation, or by scheduling a remote video walkthrough with the platform's technical lead. Physical visits to the hosting provider's data centres are coordinated through that provider's standard customer-audit process.

The present clause is without prejudice to mandatory information obligations imposed on RainbowTop Softwares by applicable law, in particular under the GDPR, the Belgian Code de droit économique, or any binding decision of a competent supervisory authority or court.

16. Liability and limits

Liability between the parties is governed by the commercial Terms of Service. This Data Processing Agreement does not extend or reduce those limits.

17. Amendments & per-customer addenda

Customers whose framework or sector requires modifications to the above can write to support@bricks-softwares.com with the specific requirements they need addressed. We negotiate addenda at no charge.

Material changes to this document are versioned (version tag in the header) and notified by email to the org admin of each active tenant.

18. Contact

RainbowTop Softwares SRL — operator of the Bricks platform.
Privacy and data protection enquiries: support@bricks-softwares.com.

This document is published in English and French, both equally authoritative. Bricks operates in Belgium under the supervision of the Belgian Data Protection Authority (Autorité de protection des données — Gegevensbeschermingsautoriteit), and Bricks's court of jurisdiction is in French-speaking Belgium; the two language versions are committed to be kept in sync as material changes ship. No other translation has legal value. Translations into other languages, and adaptations of this document to the vocabulary or sector-specific requirements of other jurisdictions, are available as paid per-customer addenda — see §17.