Trust

Security & engineering practices

How client systems get built, what happens to client data, and what we do not claim. Most of this only matters at the point where something goes wrong, which is exactly why it is worth agreeing before it does.

The short version

Where your data lives

Client data remains within the agreed project infrastructure and the approved third-party services named before the build starts — your cloud accounts and databases, and any hosted service, API or model provider the design genuinely requires. Access is granted on a least-privilege basis, credentials are kept outside source code, and data-handling requirements are agreed in writing before implementation rather than discovered during it.

We used to say “your data stays in your systems”. That is true of most engagements and not true of all of them, because real builds touch third-party APIs, hosted databases and sometimes an AI provider. The sentence above is the accurate version, and it is the one we will hold to.

Practices

How the work is actually done

Standard engineering practice, written down so it can be checked rather than assumed. If your own process is stricter than any of this, we work to yours.

Access & authentication

  • Access to client systems is requested explicitly, granted for the scope of the work, and handed back when the work ends.
  • Applications we build authenticate against a real identity system — your provider where you have one, a managed provider where you do not.
  • No shared logins between people. Where a client offers one, we ask for individual accounts instead.
  • Multi-factor authentication on every account we hold that supports it.

Authorization & data isolation

  • Role-based access in the applications: what a person can open, and which rows they can see inside it.
  • Row-level security in the reporting layer, so a regional manager and a director open the same report and see different data.
  • Multi-tenant systems isolate tenants in the data model, not only in the interface — a query that forgets its tenant should fail, not leak.
  • Least privilege by default. If a job needs read access, it gets read access.

Secrets & configuration

  • Credentials, connection strings and API keys live in environment variables or a managed secret store — never in source code, never in a spreadsheet, never in a chat message.
  • Separate credentials per environment, so a development key cannot reach production data.
  • Secrets are rotatable, and we rotate the ones we held when an engagement ends.
  • Repositories are scanned for committed secrets; anything found is revoked rather than deleted quietly.

Client data

  • We do not retain client data beyond what the project actively needs, and we say what that is before the build starts.
  • Sample and test data is anonymised or synthetic wherever the work allows it. Screenshots on this site are either fictional sample data or real work with names, logos and figures blurred — and each one is labelled as which.
  • Where a build has to move data between systems, the route and the destinations are agreed in writing first.
  • Nothing on this site names a client or shows client figures without that client’s agreement.

Third-party services

  • Every external service a build depends on — hosting, database, email, analytics, an API — is named and agreed before implementation.
  • Accounts are created in your name and on your billing wherever that is possible, so the dependency is yours rather than ours.
  • We do not add a service mid-build because it is convenient. A new dependency is a decision you get to make.

AI and LLM providers

  • Where a system sends data to a model provider, that is stated up front: which provider, which data, and why the feature needs it.
  • We use API tiers whose terms exclude training on submitted data, and we send the minimum the task requires rather than whole records.
  • Anything a model produces that a person will act on is constrained by the data and reviewed — a generated report is written from scored inputs, not improvised.
  • If you would rather no data left your infrastructure at all, say so at scoping and the design accounts for it.

Version control, review & testing

  • Everything is in version control, with readable history. A transformation nobody can review is not finished.
  • Changes go through review before they reach production — ours, and yours where you have a team that wants to see them.
  • Automated checks on the logic that matters, plus real-file testing: the behaviour that decides whether anyone trusts a system is what it does when it meets a bad file.
  • We work inside your conventions where you have them, rather than standing up a parallel stack nobody else can maintain.

Deployment & environments

  • Separate development and production environments, with separate data and separate credentials.
  • Deployments are repeatable and reversible. A release that cannot be rolled back is a release nobody should make on a Friday.
  • Configuration differences between environments are explicit, not accidental.

Logging, monitoring & backups

  • Scheduled jobs report success and failure. If a pipeline fails, you hear about it from the system rather than from the meeting.
  • Logs record what ran and what it did, without recording the contents of the data it moved.
  • Backups on the databases we operate, with the restore path tested rather than assumed.
  • Where you operate the infrastructure, we tell you what needs backing up and how far back.

If something goes wrong

  • You hear about a failed job or a broken pipeline from the system, and from us, before you hear about it in a meeting.
  • Anything affecting your data gets told to you straight and quickly, including when the cause was ours.
  • The fix comes with what actually happened and what stops it happening again — not a reassurance.

Who else touches your systems

  • Datavoris is small, and the person you talk to is the person doing the work.
  • If an engagement ever needs another pair of hands, you are told who, and what they would have access to, before they get any.
  • No offshoring your work to a third party you have not agreed to. Ever.

Ownership & exit

  • You own the code, the data, the data model, the dashboards and the documentation. All of it, from day one.
  • Everything runs in your tenancy and on your subscriptions wherever the architecture allows.
  • Handover includes a walkthrough with whoever will run it, plus written notes they can use afterwards.
  • There is no version of this where leaving us is expensive. If you never speak to us again, what we built keeps running.
Limits

What we do not claim

Datavoris holds no security certifications. We are not SOC 2, ISO 27001 or HIPAA certified, and nobody here will imply otherwise on a call. If your procurement process requires a certified supplier, we are not the right fit, and it is cheaper for both of us to establish that in the first conversation.

What we can do is work inside your controls: your tenancy, your cloud accounts, your identity provider, your repositories, your review process and your change management. For most teams that is the thing that actually matters — not a badge, but whether an external engineer will respect the way you already work.

If you have a security questionnaire, send it. We will answer it straight, including the questions where the answer is no.

On this website: questions typed to Cheenu, the chat guide, are sent to OpenAI to generate a reply. We do not keep the conversation; OpenAI handles it under its own API data terms, which include limited retention for abuse monitoring. If you choose to send Ankush your name and email from the chat, those and your questions are sent to him so he can reply — nothing else, and no mailing list.

AI Workflow X-Ray: your answers are scored on our server, without AI, and stored in our database (Neon) so the result can be reopened. If you ask for the detailed report, we email a verification code through Resend and store your email with your answers; Ankush is notified so he can follow up. The detailed report is written by OpenAI from your answers only, with storage on OpenAI’s side switched off. To keep detailed reports fair to everyone, the page also keeps a random ID in your browser — not a fingerprint, since nothing about your device is read — and we store only a scrambled version of it to limit how many detailed reports one browser can generate in a day. Clearing your browser data resets it. We do not store your IP address, and nothing is added to a mailing list.

Questions before you share anything

Perfectly reasonable. Ask them before the first data extract rather than after — what we need access to, what leaves your infrastructure, and what happens to it when the work is done.

Discuss a project See the work