Security
Sherpa OS handles deal documents, financials, employee data, and integration plans. That material is the most sensitive a company produces. Here is how we protect it.
Shared responsibility
Sherpa OS runs on Microsoft Azure. Azure maintains SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, and FedRAMP authorizations covering physical security, environmental controls, hypervisor isolation, and network fabric. Those attestations cover Azure infrastructure, not our application.
Everything above the platform is ours. This page describes those controls.
Documents
Every uploaded file is scanned for malware before it becomes available. A document defaults to an unscanned state and is denied on both view and download until a scan returns clean. The gate is an allowlist, so an unknown scan state denies rather than permits. Denials are recorded before the request fails.
Documents are never destroyed. Deleting a document archives it. The record, its folder placement, and every reference to it from risk registers, agent citations, and diligence requests stay intact and keep resolving.
Every action on a document is written to a hash-chained audit ledger: upload, view, download, print, move, archive, restore, access grant, access revocation, restriction, and room policy change. Each entry carries its own hash, the prior entry's hash, and a position in the chain. View events additionally record IP address, user agent, and the specific access grant used.
Access control
Identity and single sign-on are managed through Keycloak using OIDC, with SAML federation supported.
Multi-factor authentication is required across all accounts. Brute force protection locks an account after repeated failed attempts, with an escalating wait. Passwords require a minimum of twelve characters and cannot match the username. Email verification is required. Self-registration is disabled. There is no default administrator account.
Role-based access operates at four scopes: firm, fund, portfolio company, and deal. External parties, advisors, bankers, and counterparties are a tenancy boundary rather than a permission level. A guest sees only their assigned queue.
Tenant isolation
Customer data is isolated at the database engine using PostgreSQL row-level security, enforced across 98 tables. The application connects as a role that neither owns the tables it reads nor holds the privilege to bypass row-level security, so isolation does not depend on application code being correct.
Background processing (document ingestion, financial synchronization, monitoring) runs under a system role with scoping enforced in application code rather than by row-level security. Extending database-level enforcement to those workloads is on our roadmap.
Encryption
In transit: TLS 1.2 or higher on all public endpoints. Database connections use TLS 1.3 with AES-256-GCM.
At rest: AES-256 across all Azure managed storage, databases, and backups. Documents are held in dedicated storage with Microsoft Defender for Storage enabled. Neither storage account permits anonymous access.
Secrets are held in Azure Key Vault with managed identity access. No credentials in source code or environment files.
Business continuity
Automated backups with point-in-time restore across a 35-day window on every production database.
Restore is tested, not assumed. Our most recent restore test was executed on 11 August 2026 against a prior-day restore point, with row counts verified against the source across document, transaction, and audit tables.
Infrastructure is defined as code and reproducible.
Production databases currently use locally redundant storage. Geographic redundancy is on our roadmap.
AI and your data
Sherpa OS uses large language models to power its agents. You should know exactly what that means for your data.
We do not train models on customer data.
Our model provider operates under a Zero Data Retention arrangement. Inputs and outputs from our production path are not retained.
Text embeddings are generated inside our own Azure tenancy and do not leave it.
Agent context is scoped to the deal and to the requesting user's permissions.
Subprocessors
| Subprocessor | Purpose | Location | Attestations |
|---|---|---|---|
| Microsoft Azure | Compute, database, storage, identity, embeddings | US East | SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, FedRAMP |
| Anthropic | Large language model inference | US | SOC 2 Type I and Type II, ISO 27001:2022, ISO/IEC 42001:2023 |
| Cloudflare | CDN, WAF, DNS, static hosting | Global | SOC 2 Type II, ISO 27001 |
We notify customers before adding a subprocessor that processes customer data.
Compliance
Evident Systems does not yet hold its own SOC 2 attestation, and we will not imply otherwise. Certification cannot be inherited from a platform provider.
Our controls are built to the SOC 2 Trust Services Criteria for Security, Availability, and Confidentiality. Type II observation begins once our certification program is underway. We will publish the status here when it changes.
For security review in the interim we provide a completed SIG Lite or CAIQ questionnaire, architecture and data flow documentation, and our subprocessor list on request.
Reporting a vulnerability
Send findings to security@evidentcorp.com. We acknowledge within one business day and provide a remediation timeline within five. We do not pursue legal action against researchers acting in good faith.