Skip to main content

Security overview

Version 0.6, updated on 30 October 2026 for what has been delivered since 16 October.

Who it is for: the security officer or buyer at a customer who wants to know how their data is protected.

1 · In brief​

BTWB is a working environment for consultants in which a workspace (canvas) is built up per customer, with a dossier of supplied documents and AI support. All data is stored in the European Union (Frankfurt). Access is by invitation only. A user is a member of one or more organisations and sees only the data of those organisations, and of the workspaces in which that user takes part; this separation is enforced not in the screens but in the database, so that an error in a screen cannot break it. Belita, as administrator of the platform, has no access to the content of a customer's workspaces, unless the customer itself grants temporary access.

This overview follows from Belita's information security policy and is updated with every delivery.

2 · Access and identity​

  • By invitation only. An account only comes into being from an invitation that was recorded beforehand: for which email address, in which organisation, with which role and by whom. The database rejects every sign-up without such an invitation; no account is created then, not even an account without rights. Self-registration does not exist, neither in the application nor at the authentication provider, and a nightly check guards the latter. The administrator of the organisation invites, for their own organisation; Belita only invites the first administrator of a new organisation, and after that only if an organisation no longer has an active administrator. Belita can set per organisation within which email domains and up to how many members invitations may be sent; an administrator of the organisation cannot widen those limits themselves.
  • One account, several organisations. Someone who already has an account can work in several organisations. After logging in the invitation is waiting, and the membership only comes into being once the user accepts it; anyone with more than one organisation chooses in the header which organisation to work in.
  • Logging in is done with email address and password. A password has at least ten characters and is checked when it is chosen against lists of leaked passwords; a known leaked password is rejected. Length and a leak check protect better than mandatory punctuation.
  • Second factor. Administrators can log in with a second factor through an authenticator app (time code), with a second device as a reserve. The second factor is switched on per organisation; after that every administrator of that organisation must set it up, and the administration function rejects every administrative action without the second step. The platform administrator can also require, per organisation, that all members and participants use a second factor; that switch is off by default. While it is off, ordinary users notice nothing. When it is on, anyone who has only a password no longer sees the workspaces of that organisation. If a device is lost, the administrator of the organisation, or Belita, resets the factor.
  • Sessions. A session is refreshed in the background and closes after thirty days at the latest, and after seven days without use. More than one active session per user is allowed, so that a consultant can work on laptop and tablet.
  • Roles on three levels. Belita manages the platform as platform administrator. Within an organisation someone is administrator or member, and anyone working in several organisations has a separate role in each. On a workspace someone is owner, editor or reader: the owner manages who takes part, the editor changes the content, the reader looks along and may download reports. An administrator of an organisation invites, ends memberships and changes roles, only within their own organisation, and sees and edits every workspace of that organisation. A reader cannot start an AI function, not even from outside the screen: the server refuses it and the organisation pays nothing for it. An administrator can never make themselves or anyone else a platform administrator. That is enforced in the database, not only in the screen.
  • What Belita can and cannot do. The platform administrator can temporarily work in the environment of an organisation to manage settings, users and budgets; for as long as that lasts, a banner that cannot be dismissed is shown. That switch gives no access to the content of that organisation's workspaces: no access rule on workspace data knows the platform administrator. If a customer wants Belita to look along in a workspace, for instance with a question about the content, the customer grants that access itself: the owner of the workspace or an administrator of the organisation chooses «Access for support» in the participants screen, with the role (reader or editor) and the duration (24 hours, 3 days or 7 days). The access expires on its own, can be withdrawn earlier, and appears in the participants list as «Belita», without personal addresses.

3 · Separation between organisations​

  • In the database, not in the screen. Every table with customer data carries access rules (row level security): a row is only visible and changeable to those who take part in the workspace it belongs to, according to role, and to the administrator of the organisation that workspace belongs to. Who you are and what you have access to is determined by the server; the request from the browser has no influence on that.
  • Separate access per workspace. On every workspace it is recorded who is owner, editor or reader. A participant who is not a member of the organisation, for instance a consultant from an agency, sees only that one workspace and does not read the organisation's settings (such as limits and security settings); only name and branding are visible.
  • A visitor who is not logged in can read exactly one thing: the texts and settings the login screen needs. Everything beyond that is closed, and a check that runs after every database change and every night reports it as soon as that changes.
  • Tested, not promised. A dedicated test series runs with every change that touches the database and every night against a real database: a user of organisation A tries to read and write data of organisation B, and the test is only green when that fails. One hundred and thirty-four series guard the separation and the access rules, and the automated tests run only in an organisation of their own, Platform, where their test canvases are read-only for people.
  • New tables get the rules automatically. A check requires that every table has at least one rule that names an organisation or workspace boundary, or is on a short list of reasoned exceptions (platform administration, general reference data, tables only the server can reach). That list can only get shorter, and a gate rejects every new rule in a loose form.
  • The workspace belongs to the same organisation as the row. On all tables with workspace data, the rule checks not only that the row belongs to the writer's organisation, but also that the workspace of that row belongs to it. An administrator of an organisation can therefore not attach a row of their own to a workspace of another organisation. A gate rejects every new rule that does not check this, and guards that there are no exceptions.

4 · Where the data is and how it is protected​

  • Location. Database, files and authentication at Supabase in Frankfurt; the application and the server functions at Vercel in Frankfurt. Both are fixed in our configuration.
  • In transit. All traffic runs over HTTPS. We set two security headers ourselves: «HTTPS only» (HSTS) and «cannot be embedded in another site».
  • At rest. The storage is encrypted with the provider's standard facility. The separation between organisations in the database is the first layer.
  • AI processing. Dossier content that is presented to an AI model goes directly to the model provider. The provider does not use it for training and keeps it for thirty days for abuse and safety review; after that it is deleted. Content that the provider flags as abuse may be kept longer. In the standard setting this processing can take place outside the EU. At a customer's request, Belita sets the entire platform to EU processing of text generation: the same models, through providers that process in the EU, without retention of the content; if a call cannot meet that requirement, the platform rejects the call instead of falling back. Making documents searchable also then goes directly to OpenAI, outside the EU. What exactly goes there, what comes back and what is not kept is described in the AI statement (B7). The consultant approves every AI proposal before it lands in the workspace.
  • Secrets. Provider keys are stored only in the shielded environment of the hosting partner and of the build pipeline, never in the code.

5 · Backup and recovery​

  • Weekly copy of the production database, kept for eight weeks, with at least one copy outside the provider and outside the code storage. Before every intervention that can touch data, an extra copy is made first. The provider also keeps its own recovery points.
  • Recovery is tested. A production copy is restored on a separate environment and compared on structure and counts; the last successful recovery test was in July 2026.
  • Age is monitored. Every night a script checks that the latest copy is not older than ten days; if it is, it appears on the internal status board the next morning.

6 · Logging and audit​

  • AI usage is counted per call: model, number of tokens, cost, duration. The content of the question and the answer is not stored.
  • Error messages from the server go in synthetic form to an error monitor: code and kind, never the text of the error and never customer content.
  • Touches of production by Belita (database commands, deliveries) are recorded in an append-only log: kind of command, tables touched and a fingerprint, never the values. That log cannot be changed unnoticed.
  • Access to the platform is recorded by the authentication provider in an audit log in the database: every login, logout, session refresh, password change and second-factor event, with time, user and IP address. That log is not visible in the application; Belita can supply it per organisation on request, for instance in the event of an incident.
  • Administrative actions on access (switching on the second factor, resetting a factor) are recorded without content in the server log. Every change in membership and in participation in a workspace, including giving and withdrawing support access, is recorded in a separate event table: what changed, for whom, by whom and when.
  • Origin of AI proposals. AI proposals carry their origin: the source document, the worksheet or the mark general knowledge.

7 · Change management​

  • Every change goes through a pull request; writing directly to production or to the test environment is technically blocked, as is deleting or overwriting those branches. A change first lands on the test environment; production only changes through a delivery, and only Belita's owner performs that.
  • Four mandatory checks before merging: the full test series of the application, including the guards that record that agreed rules do not silently revert; the separation test between organisations (§3); a proof that those guards can themselves turn red; and a check for build-breaking errors. A change must also be on the latest state of the target branch.
  • Two independent pairs of eyes. Every substantive change is assessed before merging by an independent reviewer and an independent tester; the pull request can only be merged after those two have reported.
  • Database changes go to the test environment first, are proven there, and only then go to production; a check after every step proves that every change has actually arrived.
  • After every rollout a smoke test runs, and on the test environment a deep smoke test: logging in, opening each of the eight worksheets, one generation with the real model, creating and downloading one report. Every night a full journey through the application against the test environment is run as well.

8 · Vulnerabilities and risks​

  • Nightly scan for vulnerable dependencies. Every night a scan checks the packages the application runs on for known vulnerabilities. A vulnerability of high or critical severity in a package that runs turns the check red and leads to a notification to Belita; in build tooling it gives a warning. A scan that could read nothing does not count as green. In addition, an automated package manager proposes bundled updates every week.
  • We carry out an independent penetration test at a customer's request.
  • We keep track of risks in an internal risk log, each with an owner and a condition for follow-up.

9 · Faults and incidents​

  • On an unexpected error the user sees a general message with a reload button; no technical information leaks to the screen.