Effective September 20, 2026
Security
This is the original English text. Where a translation differs from it, the English version prevails.
This page describes how Datwise protects your data. It is deliberately specific, and it says plainly where a control does not exist yet. It is a description, not a certification.
1. Our approach
Datwise holds business data, so the aim is narrow and practical: only the people you invited can reach your workspace, secrets are stored in a form we cannot read back, and anything a customer would want to audit leaves a trail. What follows is what is in place today. Where something is missing, this page says so rather than implying otherwise.
2. Data in transit
All traffic between your browser, the Datwise website and the Datwise API travels over TLS, with certificates renewed automatically. So do the connections from our servers to our storage, payment and AI providers.
3. Passwords and sign-in
Passwords are hashed with argon2id, an algorithm designed to make guessing expensive. We never store the password itself and cannot recover it, which is why a reset replaces it rather than revealing it. A new email address must be verified before the account is fully usable. If you sign in with Google, Datwise stores no password at all. Passwords set on public dashboard links are hashed the same way.
4. Sessions and tokens
Access tokens last fifteen minutes and are held in memory in the page, not in storage that a script or a browser extension can read later. A separate refresh cookie lasts thirty days, cannot be read by scripts, is limited to the sign-in paths, and is replaced every time it is used. Using it does not push the thirty days back, so a session has a hard end. If an old refresh token is ever presented again — the signature of a stolen or copied cookie — the whole family of sessions it belongs to is revoked immediately and the account has to sign in afresh. Refresh tokens are stored on our side only as a hash, so the database never holds a token that could be replayed. You can list your active sessions, with the address and browser each was created from, and end any of them.
5. What we do not have
Datwise does not support two-factor authentication today. This page will say so until it does. Datwise also holds no security certification: there is no SOC 2 report and no ISO 27001 certificate, and we will not imply one through wording. If your organisation needs either, write to info@getdatwise.com and tell us — knowing who needs what is how we decide the order of work.
6. Encryption at rest
Two kinds of secret are encrypted with AES-256-GCM before they are written to the database: the credentials for the databases you connect, and the Google refresh tokens that keep a Sheets connection alive. We do not claim that everything else is encrypted at rest. Your dashboards, datasets and files are protected by access control and by the storage-level protections of our providers, not by a field-level key we hold, and saying otherwise would be untrue.
7. Workspace isolation and roles
Separation between customers is enforced on the server, not in the interface.
- Every request is checked against the workspace it names, and data is scoped to that workspace as it leaves the database.
- A workspace has five levels of access, from full ownership down to view-only, so you can let someone read a dashboard without giving them your data sources or your billing.
- Invitations are tied to an email address and expire; membership can be removed at any time, which ends that person’s access straight away.
- Significant actions are written to an audit log with who acted, what changed and the address they acted from.
8. Connected data sources and uploads
A SQL source runs one statement and only one, and it must be a statement that reads; a second statement, or anything that writes or alters the database, is refused before it is sent, and every query runs under a time limit and a row cap. Datwise also resolves the host you give it and refuses to connect to private or link-local addresses, so a source cannot be pointed at something inside our own infrastructure. Uploaded files are checked against their actual bytes rather than the file name or the type the browser declares: an image is identified from its own signature, and a spreadsheet that is not really a spreadsheet is rejected.
9. Abuse protection and logging
Sign-in, sign-up, password reset, email verification, public links, form submissions and the AI endpoints are all rate limited. Credentials are removed before a request is written to our logs — the authorisation header, cookies, the header carrying a public dashboard password, and any cookie we set — so a log file cannot become a second copy of a secret. Connection details and Google tokens are stripped from API responses as well, so they never leave the server after they are saved.
10. Payments
Card details never reach Datwise: Stripe collects and holds them, and we store only Stripe’s identifiers and the invoice records. Messages coming back from Stripe are checked against Stripe’s signature before we act on them, so a forged message cannot change a subscription or mark an invoice as paid.
11. Hosting, location and backups
The Datwise website runs on Vercel. The API and the database run on our infrastructure provider’s servers in the European Union. Uploaded files, dataset rows, logos, avatars and exports are stored in Amazon S3 in Stockholm, Sweden. The database is backed up and the backups are kept for fourteen days. Those backups cover the database; the files in Amazon S3 are not part of them, so deleting a file is not undone by restoring a backup.
12. If something goes wrong
If a security incident affects your data, we will tell the workspace owners what happened, what was affected and what we did about it, without waiting until every detail is known. Write to info@getdatwise.com to report a suspected incident, and say what you saw and when.
13. Reporting a vulnerability
Send security reports to info@getdatwise.com, with enough detail for us to reproduce the problem. Please test only against your own workspace, do not access anyone else’s data, and give us a reasonable chance to fix the issue before publishing it. We do not run a paid bug bounty, but we will credit you if you would like us to.
14. Your part
Most incidents start with a detail on the customer’s side. A short checklist:
- Use a password you do not use anywhere else, and do not share an account between people — invite them instead.
- Give each member the lowest role that lets them do their job, and remove people as soon as they leave.
- Check your active sessions if you suspect a problem, and end the ones you do not recognise.
- Remember that a public dashboard link is public: anyone with the address can open it unless you set a password on it.
- Do not put the data listed in our acceptable use policy into Datwise at all.
15. Contact
Excellence and Quality Software Solutions, Al Madina St, Amman, Jordan. Security questions: info@getdatwise.com.