Security

Version 1, 5 November 2026

Datlay is not open yet. This is version 1 of this page, published ahead of the launch in 2027. It describes how the service is built to be protected from the day it opens. The section on reporting a vulnerability applies now, including to this website.

Datlay holds access to the systems that run its customers' companies, and with a person's confirmation it writes to them. That makes it worth attacking. This page says what protects it, and also what it does not have yet. The measures we commit to in the contract are in Annex II of the DPA.

A workspace of your own

• Each customer's workspace has its own database, its own secrets (such as its database password and signing keys) and its own network, with limits on the computing resources it can use. One workspace cannot reach another workspace's database.
• Trials run on servers separate from those of paying customers.
• Workspaces are hosted in the European Union, in Germany, by Hetzner Online GmbH.

The least access to your systems

• For the process X-ray, Datlay reads each system with a technical reader that has the least rights the system allows, read-only where the system offers it: read-only scopes in HubSpot, and a service login with a read-only set of permissions in Business Central.
• In Odoo, the reader is a separate user with the minimum groups. Odoo has no fully read-only user, so we hold the reader to a test: it cannot create or change orders, invoices, payments or stock moves. On Odoo Enterprise this user takes a paid user licence, and we tell you before you connect.
• Each connection reads a defined list of document types and fields. Datlay does not read payroll or HR records, such as payroll journals and the details of employees' expenses.
• Changes are never made with the technical reader. Where your system checks each person's rights, they are made with that person's login. In QuickBooks Online and HubSpot, which give one company-wide access, the system records the change under the Datlay app or the administrator who connected it, and Datlay's log records who confirmed it.

QuickBooks Online has no read-only access

QuickBooks Online does not offer apps an access that is limited to reading. The token that Datlay holds to read your QuickBooks company could therefore also be used to write. We cannot change that, so this is what Datlay does instead:

• it writes to QuickBooks only to make a change that a person in your company has confirmed in Datlay;
• the token is encrypted with your workspace's own key, which is kept outside the database and its backups;
• because QuickBooks gives one company-wide access, your administrators decide in Datlay who may see and who may change what;
• when you disconnect QuickBooks, Datlay deletes the token and revokes it at Intuit.

Every change is confirmed by a person

• Datlay writes to your systems only after a person in your company confirms the change on Datlay's own confirmation page. The connection your AI assistant uses has no tool to confirm a change: confirmation happens only on Datlay's own page.
• Every person who confirms changes must use two-factor sign-in, and confirming a change to a financial document asks for a fresh code.
• At the moment of confirmation, Datlay reads the document again. If it changed after the change was prepared, the change is refused.
• Datlay makes the change shown on the confirmation page and nothing else. If the outcome is unknown, for example because the system did not answer in time, Datlay does not repeat the change: it reads the document again and shows the person the result.
• Writes can be switched off for one workspace or for all workspaces at once. A fuse stops writes when they run far above their normal rate, and alerts us.
• The log records, for every change, which person or tool asked for it, with whose rights, who confirmed it and what the system answered. It exports for your auditor.
• Changes to financial documents (orders, invoices, payments and purchases) stay off at launch until every critical and high finding of the external penetration test described below is fixed.

Each person's rights

Where your system checks each person's rights, Datlay works with that person's own login, so the person can see and change in Datlay only what that system lets them see and change. Where a system gives one company-wide access (for example QuickBooks Online and HubSpot), you decide in Datlay who may see and change what. A document Datlay has read is shown to a person, on a screen, through the API or through an assistant, only after a check of that person's rights: with the person's own login where the system checks it, and against the roles you set in Datlay where it does not.

Connection tokens

• The tokens that let Datlay into your systems are stored encrypted with a key of your workspace, kept outside its database and outside its backups. A copy of the database without that key reveals no token.
• The service that completes each vendor's sign-in runs apart from the workspaces and keeps no customer tokens: it encrypts each new token for your workspace and passes it on, and renews a token only for the workspace it belongs to.
• A connection can only be started from a signed-in session in your workspace. After the vendor's consent, Datlay shows which company was connected before it reads anything, and one company of a vendor can be connected to one workspace only.
• Messages from vendors (webhooks) are accepted only with a valid signature, and only wake Datlay to read again.
• When you disconnect a system, Datlay deletes its tokens and stops reading from it. In Odoo, disconnecting through the connector module also deletes the key it created.

Your AI assistant

• Your own assistant connects with a sign-in of its own and works as the person who connected it, with that person's rights.
• Text from your systems, such as notes and comments, may contain instructions planted by somebody else. Datlay marks such text as data when it passes it to the assistant, and limits how much the assistant can read at once. This reduces the risk but cannot remove it. The confirmation step is what stops a change.
• At launch, the API accepts only personal tokens, which act with the rights of their person.

Encryption

• Connections to Datlay and to this website are encrypted (TLS).
• Connection tokens and backups are encrypted at rest, as described on this page.

Backups and restore tests

• Changes to each workspace's database are copied off its server continuously. The copies are encrypted with that workspace's own key before they leave the server, and kept in Backblaze's EU region in Amsterdam, the Netherlands, where the production server cannot delete them. A nightly encrypted copy is also kept at Hetzner in Germany.
• Backups are kept for at most 35 days.
• Every week, each workspace's backup is restored automatically into an empty database and checked. A failed test raises an alert.
• When a workspace is deleted, its backup key is destroyed, so its backups can no longer be read from that moment.

Monitoring and incidents

• We monitor every workspace and every connection. An alert reaches us when a workspace stops answering or a connection stops reading.
• If a personal data breach affects your data, we notify your administrators without undue delay, and at the latest within 72 hours of becoming aware of it.

Our people and our code

• Our staff reach the servers of the workspaces only through our private network, and each session on such a server is recorded. When our engineer works for you inside your workspace, it is through a role in Datlay, like any other user, not through direct access to its database.
• Releases of code that runs in your systems, such as the Odoo connector module, are signed. Code changes go through protected branches, and an automatic check refuses secrets in code. The accounts that publish our code use two-factor sign-in.
• We build Datlay with the help of software tools, including AI tools. They work on test systems with test data. No AI provider is given your data: none is on our list of sub-processors.
• Our workstations use full-disk encryption and screen lock, and customer data is never kept on unmanaged devices.

No AI on your data

Datlay sends your data to no AI provider, and we do not use it to train any AI model. The AI assistant your company may connect is your own, under your own terms with its provider.

Testing

• The application, the connection service and the assistant connection are scanned automatically for common weaknesses.
• Before launch, an independent firm runs a penetration test on a staging copy of Datlay that holds demo data only. After launch we repeat external tests, and this page says when the last one took place.

What Datlay does not have yet

• No security certification. Datlay does not hold ISO 27001, SOC 2 or any similar certification. This page will not claim one before we hold it.
• No staffed security operations centre. We run monitoring and alerts, not a team watching around the clock.
• No bug bounty. We thank people who report vulnerabilities, but we do not pay rewards.

Reporting a vulnerability

If you believe you have found a security vulnerability in Datlay or on this website, write to security@datlay.com. The same address is published in /.well-known/security.txt. We read reports in English.

Scope

Until Datlay opens, only this website, datlay.com, is in scope. From the opening, the scope also covers app.datlay.io, your workspace at datlay.io and the Datlay connector module for Odoo.

Out of scope: other websites, including those that share our servers; our sub-processors and the vendors Datlay connects to; and reports without a demonstrated impact, such as missing headers on static pages, email authentication advice, clickjacking on pages without actions, or self-XSS.

What to include

• what you found and where (the address, page or interface);
• the steps to reproduce it, and what an attacker could do with it;
• the date you found it, and how we can reach you.

What we commit to

• We acknowledge your report promptly and keep you informed while we work on it.
• We fix what we confirm, in order of severity, and tell you when it is fixed.
• We do not pay rewards: there is no bug bounty.

Safe harbour

If you research in good faith and follow this section, we consider your research authorised. We will not bring a claim against you or ask the authorities to act against you for it, and if a third party does, we will say that it was authorised. Good faith means that you:

• test only with accounts and workspaces of your own, and access no more data than you need to show the problem;
• do not read, change, keep or share data of other people or companies, and stop and tell us at once if you reach any;
• do not degrade the service: no denial of service, no load or volume testing, no spam;
• do not use social engineering, phishing or physical access;
• do not attack the systems of the vendors Datlay connects to (report a problem in their systems to them);
• do not put other people's personal data in your report;
• give us a reasonable time to fix the problem before you disclose it.

This safe harbour covers only our own systems and our own claims. It cannot bind a vendor or any other third party.