Where the data is
Hosting. The application, its database and the documents uploaded to it are hosted by Clever Cloud SAS in Paris, France. The off-platform backup copy is held at Scaleway SAS, also in Paris. Both are European companies; Boardee transfers no data outside the European Union.
Microsoft 365. The emails Boardee sends leave through Microsoft 365 (Microsoft Graph), from Boardee's own Microsoft tenant. When a client connects its own Microsoft 365 account, Boardee writes the meetings into its Outlook calendar, reads its colleagues' availability and, if the client asks for it, a register kept in SharePoint; these exchanges take place with the client's Microsoft tenant, under the contract the client has with Microsoft. Microsoft is named as a sub-processor in the data processing agreement.
AI drafting, at the client's option. A workspace can switch on a draft of the minutes written by a language model. Boardee holds no key of its own: the client's administrator pastes the key of the provider the client has a contract with — Anthropic, Azure OpenAI or OpenAI — and the text of the meeting (agenda, attendance, the secretary's notes, board papers) is sent to that provider, under that contract, when a user asks for it. Boardee keeps the key encrypted, neither stores nor logs what goes out or comes back (the audit log records that a draft was requested, never its content), marks every proposed line as an AI draft, and sends those minutes for signature only once a reviewer has approved them. Without a key, nothing goes anywhere.
No other sub-processor. No audience analytics, no font or script loaded from a third party, no fallback email transport: a message Microsoft refuses stays in the outbox with its status, visible to the operator, and is never handed to another provider.
Who can reach what
No public sign-up. A client workspace is opened by Boardee once the contract is signed. The administrator the client designates then invites their colleagues; each invitation is a single-use link valid for seven days, at the end of which the person chooses their own password. No password is ever sent by email or known to Boardee.
Isolated workspaces. Each client workspace is a separate compartment, checked on every request at the server: no object identifier can reach another client's data. This isolation was verified by a two-client usage simulation before opening, and every change to the code runs through an automated test suite that replays it.
Roles and permissions. Four roles: administrator, member, deal team, external manager (portal access). The administrator can withdraw five actions from a member — cancelling or moving a meeting, sending invitations and messages, editing companies and people, deleting documents, sharing documents outside — and can restrict a member's reading to the investments assigned to them: that member then sees only the companies of those investments, their meetings and their documents. Every change of role or permission is logged.
External guests. The people convened, the signatories, the contributors and the reviewers who have no account act through a personal link that cannot be guessed (256 bits), limited to their one meeting or their one document, rate-limited, and every action of which is logged. A data room share to the outside carries an expiry date, can require a password (ten wrong attempts block the link for a quarter of an hour) and, unless the person sharing chooses otherwise, stamps the PDFs opened with a watermark naming the recipient.
Sign-in and sessions
Passwords. Hashed with bcrypt (cost 12), never stored or logged in clear; complexity rules; reset by a link valid for one hour.
Two-factor authentication. A TOTP second factor (authenticator app, with printable backup codes) is available to every user. A workspace can require it of its administrators or of its whole team: a person concerned who has none is taken to the setup before any other page, and the server refuses them everything else until it is done. Every workspace Boardee opens requires it of its administrators from day one; the client's administrator can then extend it to everyone or lift it, and each change is logged.
Sign in with Microsoft 365. A user can sign in with their Microsoft work account ("Sign in with Microsoft"). No account is created by this route: only an address already invited opens an account, and only if Microsoft vouches for the domain of that address. A workspace can require this sign-in: passwords are then refused to its members and the second factor is the one the client's Microsoft 365 imposes; administrators keep a fallback entry by password and second factor.
Sessions. Carried by a cookie the page cannot read (httpOnly, SameSite), signed, valid twelve hours at most, closed after thirty minutes of inactivity, revocable at any time by the user or an administrator, and ended at the server on sign-out. Every write requires an application header, which closes the door to requests forged from another site.
Against brute force. Twenty-five attempts per quarter of an hour and per account, one hundred per address; the cost of the check is the same whether or not the account exists, so that nothing is revealed about addresses; guest links are limited to sixty requests a minute; file uploads to two thousand per workspace and per day. Every refusal states the waiting time.
Alerts. Three signals tell somebody without blocking anything: the first sign-in of an account from a browser family and address never seen earns its owner an email, with the link to end their sessions; ten refused passwords on one account in a quarter of an hour tell the workspace's administrators, once a day at most; fifty downloads in ten minutes through one data room link tell the share's author, once an hour at most. Each alert is written to the audit log.
Encryption and browser protections
In transit. TLS 1.2 at least between browsers and the application, and between the application and its storage.
At rest. Database and objects encrypted at rest by the hosting providers. The access tokens to clients' Microsoft calendars, the two-factor secrets and the client's AI provider key are in addition encrypted by the application (AES-256-GCM) with a key that is in no backup. Uploaded documents are not encrypted a second time by the application, and no antivirus scans them on upload: they are served as they are to the people authorised.
Security headers. HSTS, nosniff, a restrictive Content-Security-Policy, frame-ancestors limited to the application itself, a Permissions-Policy closing camera, microphone, geolocation and payment.
Audit log
Every sensitive action is written to an append-only log — successful and failed sign-ins, invitations, permission withdrawals, sends, signatures, shares, external guests' replies, deletions — with the timestamp and the IP address. Nothing in it is changed afterwards. The client's administrators read it from the application (latest entries) and obtain the full export on request. It is kept twelve months.
Backups and recovery
Every night, Boardee produces two copies: an export of every table of the database at the hosting provider (the last fourteen exports are kept) and a copy of the database and of the documents at the second provider, kept thirty days. The database also benefits from its provider's daily backups. A portable export can be produced on request.
Objectives. Maximum data loss (RPO): twenty-four hours. Target time to restore service (RTO): four hours. A tooled restoration procedure exists; it was exercised on 2 September 2026 on a test set and on 13 September 2026 on a real production backup, restored onto a blank instance in a few seconds, then erased. Any backup failure triggers an email to the operator.
Deletion. At the end of the contract or on request, the client's workspace is deleted by Boardee, never by an automatism, and the deletion propagates to the backup copies within thirty days. Past that period, no copy under Boardee's control holds the deleted data any longer. The workspace is closed as the erasure begins — no more sign-in, no link, no write — and every document is deleted, then checked gone. What stays, on purpose: the invoices issued to the client and their PDFs, its billing terms, and the audit log (twelve months). The client is handed a written attestation: provisional while a document still awaits its deletion at the storage provider, final after.
Development and operations
Every change to the code runs through an automated test suite before it is published, and every publication is checked in production by a health page that says which email transport, which storage, which database and which off-site copy are active. Secrets are never in the code: environment variables, a certificate for authentication with Microsoft, storage access keys limited to the strict minimum. Access to the production systems is reserved to the founder, protected by two-factor authentication.
In case of an incident
Any confirmed data breach is notified to the client within forty-eight hours at its administrator's address, with what is known, what is being done and what is being asked. Availability incidents are announced through the same channel. Point of contact: support@boardee.eu, read every business day. A security researcher will find how to report a vulnerability in the site’s security.txt file (RFC 9116).
What Boardee does not have yet
No ISO 27001 certification and no SOC 2 report. A penetration test by a third party is planned; its report will be shared on request. Liability and cyber insurance will be taken out with the operating company. These points are stated here rather than discovered in an audit.
This page is reviewed at every change of the architecture and at least once a year.