Security and data handling
Where your evidence lives, and who can reach it.
You are evaluating a platform that will hold the most sensitive material your organisation produces — misconduct allegations, privileged communications, interview recordings. This page is written for the person who has to sign off on that. We are an early-stage company, so it says what we hold and what we do not, rather than leaving you to find the gap in a questionnaire.
Your data stays in the place you chose.
There are three delivery models, and they differ in who holds the infrastructure. In all three, the AI processing happens in the same place as the data.
- SaaS on Microsoft Azure
- Your organisation is provisioned into one region and its data stays there. The AI runs in that same region, so evidence is not sent to another geography to be processed. Regions in service today: European Union, United States, and Israel.
- Managed service
- The platform runs inside your own environment and our forensic engineering team operates it end to end. The data never enters infrastructure we own.
- Air-gapped on-premises
- The complete platform, including the AI models, runs on your hardware with no outbound connection. Models and patches are delivered offline. Licensing is key-based, with no telemetry callback.
Your directory stays the source of truth.
Access is federated to your identity provider, and authorisation is decided on the server for every request.
- SAML single sign-on
- Per-provider SAML with a published metadata endpoint for each configured identity provider, so you federate against your own directory rather than managing a second set of credentials.
- OAuth sign-in
- Microsoft, Microsoft Entra ID, Google and GitHub are supported as sign-in providers.
- Role-based access on one shared record
- The point of a single case record is that several departments work it at once, which only holds if each of them sees the part they are entitled to. Access is granted by role, and permissions are enforced server-side on every request rather than by hiding controls in the interface.
Encryption, hashing, and a log that is part of the record.
Forensic work has a stricter requirement than confidentiality: you have to be able to show that an item is the same item you collected.
- In transit
- TLS for every connection, with HTTP Strict Transport Security enforced at the edge.
- At rest
- AES-256. Third-party credentials and OAuth refresh tokens are held in AES-256-GCM encrypted fields rather than in plain configuration.
- Evidence integrity
- A SHA-256 hash is computed when an item is acquired and re-verified at each processing step, so a change between collection and production is detectable rather than a matter of trust.
- Audit trail
- Every action against a case is timestamped and attributed to a user. The log is available in the product and is part of the record, not a separate system you have to reconcile against it.
The evidence does not leave to be processed.
In 2026 several US courts began writing the distinction between open, self-training AI tools and closed, contractually-bound ones directly into protective orders. This is how OrcheSight sits on the closed side of that line.
- No evidence is sent to an external model API
- Every shipped environment is configured against an in-cluster model backend, not a third-party provider. The machine-learning stages — transcription, translation, optical character recognition, named-entity recognition, classification — run on models hosted inside the deployment.
- The language model runs inside the perimeter
- Investigation chat, early case assessment, coding suggestions and PII detection call a model served in the same cluster as the data. What it reads does not cross the boundary, because there is no boundary crossing in the path.
- The interaction log is yours
- Prompts and responses are recorded in your own deployment’s database, keyed to your organisation, with a retention period you set. Nothing about an AI interaction is sent to OrcheSight.
- Credentials and policy stay server-side
- Model credentials are read from the server environment at call time and are never exposed to a browser. A misconfigured credential fails at start-up rather than falling back to an unintended provider.
The assurances we cannot claim.
A vendor-security page that lists only strengths tells you nothing, because every vendor has one. These are the gaps, stated plainly so you can judge whether they are disqualifying for you.
- We do not hold SOC 2
- No SOC 2 report, Type I or Type II, and no audit currently under way. If a SOC 2 report is a procurement requirement for you, we would rather you learn that here than four weeks into an evaluation. Worth knowing: the air-gapped and managed models move most of this question from our controls to yours.
- We do not hold FedRAMP, StateRAMP or an ISO certificate
- We are an early-stage company and we have not been through those programmes. We are also not going to describe our environment as "classified ready" or imply an accreditation we do not hold. If a certification is a gate for you, it is a real gate and we would rather say so now.
- We do not publish a penetration-test cadence
- We will tell you what testing has been done, by whom and when, under NDA in an evaluation, rather than printing a reassuring interval here.
Questions this page did not answer
Data processing terms, sub-processors, retention and destruction policy, incident notification, and business continuity are all handled in writing during an evaluation, against your requirements rather than a generic template. Ask us and we will answer specifically, including where the answer is no.