Trust centre
Vaethra's security, availability, privacy and compliance documentation, in one place.
The answers a vendor security review asks for, published in advance
A vendor security review usually means a questionnaire, several weeks of email and a call. The questions are largely the same each time, so they are answered here in the detail a reviewer needs: architecture, access control, availability, recovery, incident handling, vulnerability management, how code reaches production, what happens to data over its whole life, and which frameworks we work to. It is written before the first enterprise agreement on purpose: so that the first enterprise conversation is not stalled for a quarter by a questionnaire, and so that a reviewer can see what is running and what is committed before anyone is asked to trust a summary.
Two points about scope. Where a control is planned rather than running, or committed rather than yet exercised, the relevant page says so on the page itself rather than only in an appendix. And evidence — the risk register, the records of processing, access reviews, vendor assessments, the policy set, and the recovery test report once the first exercise has run — is provided under NDA rather than published, because those documents describe operational detail in a form more useful to an attacker than to a reviewer.
eighteen public pages
Security programme
| Page | Covers |
|---|---|
| Security overview | Approach, infrastructure, encryption, authentication, monitoring, logging, personnel, physical security, governance, contacts |
| Architecture | Components, trust boundaries, environments, data flows, model processing, tenancy, network boundaries |
| Access control | MFA, least privilege, production access, access reviews, joiners and leavers, credential management, service accounts |
| Data protection | Classification, the licence filter, encryption, retention, deletion, residency, ownership and export |
| Privacy | Categories of personal data, lawful bases, retention, individual rights, privacy governance |
| Subprocessors | The four subprocessors, what each holds, where, their attestations, and 30 days' notice of change |
Operations
| Page | Covers |
|---|---|
| Availability | Uptime measurement, availability architecture, monitoring, maintenance, and the enterprise service level |
| Business continuity | Backups, recovery objectives, five disaster scenarios, recovery procedure and testing |
| Incident response | Classification, detection, process, the 72-hour notification, and the post-incident report |
| Vulnerability management | Dependency monitoring, patch windows, security testing, and responsible disclosure |
| Secure development | The path to production, change management, environment separation, secure coding practice |
| System status | What is running now, answered by the running system |
| Support | Channels, hours, response targets, escalation, notice periods |
Compliance and legal
| Page | Covers |
|---|---|
| Compliance | Framework status, and a control-by-control map of SOC 2, ISO 27001 Annex A and the GDPR against where each is implemented |
| Enterprise Service Addendum | The availability commitment, the service-credit schedule, support targets, notice periods, residency and escrow, as an enterprise order form incorporates them |
| Data Processing Agreement | Ready to execute, with the Standard Contractual Clauses and the annex of technical and organisational measures |
| Privacy Policy | The formal notice |
| Terms | Terms of use, and how an enterprise agreement differs |
Our security contact details are also published at /.well-known/security.txt in the format defined by RFC 9116.
Evidence, available within two business days
The pages above state what our controls are. The documents below evidence that they ran, and are provided to customers and to organisations in an active evaluation under a mutual NDA. Each row says whether the document exists today or depends on an exercise that has not yet been run, because a document offered by name and not yet written is exactly the failure this page is written against.
| Document | Contents |
|---|---|
| Security policies | Exists. Access control, change management, incident response, cryptography, acceptable use, vendor management, business continuity. Written 12 September 2026. |
| Risk assessment | Exists. The register: risk, likelihood, impact, owner, treatment. First review 12 September 2026; reviewed quarterly. |
| Records of processing | Exists. The Article 30 record, by category of data and purpose. |
| Access control evidence | Exists. The access review of 12 September 2026 — every platform, every holder, the second-factor state of each — and each quarterly review after it. |
| Vendor assessments | Exists. Our review of each of the five subprocessors, and their attestations. |
| Vulnerability assessment | Exists, live. The dependency audit (zero open findings on 11 October 2026) and the open integrity findings published on /status, with remediation dates. |
| Completed security questionnaire | Committed. Completed in writing within five business days of a request — CAIQ, SIG Lite or your own format. None has been requested yet. |
| Disaster recovery test report | After the first exercise. The written test plan exists; the first restore to a scratch instance runs before the first enterprise agreement, and the report — what was restored, from which backup, how long it took, what failed — joins the pack then. |
| Backup restoration evidence | After the first exercise, as above. Evidence that backups restore, not that they are taken. |
| Penetration test report | After the test. An independent test is to be commissioned before the first enterprise agreement; no firm is engaged yet. |
| Incident response exercise | After the first exercise. No incident has been declared and no tabletop has been run; the first is scheduled with the disaster-recovery exercise. |
| Compliance evidence | Being assembled. The control-by-control map on /compliance, with the artefact behind each row attached as it is produced. |
Request it from security@vaethra.com with the entity name and the NDA you would like signed, or ours.
Three terms, used consistently
| Term | Meaning |
|---|---|
| Live | Running in production. Where you can verify it independently, the page says how. |
| Committed | A contractual undertaking — a response time, a notification deadline, a recovery objective. It binds us under the agreement. |
| Planned | Not yet in place, with the dependency stated. |
Figures carry the date they were measured. Where a page states a number — tables with row-level security, functions executable by the public role, automated tests — it was taken from the running system on that date and can be re-checked on request.
If you find a statement here that does not match what you can observe, please tell us at security@vaethra.com.
The same documents as files, for the people who file things
A vendor record wants one attachment, not eighteen URLs. Counsel wants a contract that can be printed and signed. And a document read by a language model — now a normal step in a procurement review — is easier to supply as one file than as a crawl. All four carry the date they were issued and are rebuilt from the pages above, so a PDF cannot quietly diverge from what the site says.
Security & Compliance PackageEvery page of this trust centre in one file — architecture, access control, availability, recovery, incidents, vulnerabilities, development, data protection, privacy, subprocessors, compliance and support.PDF · 72 sheets · 1230 KBData Processing AgreementReady to execute. Annex I, the 2021 Standard Contractual Clauses Module Two, the UK Addendum, and the Annex II measures.PDF · 12 sheets · 321 KBPrivacy PolicyPDF · 8 sheets · 226 KBTerms of UsePDF · 5 sheets · 150 KBEnterprise Service AddendumThe availability commitment, the service-credit schedule, support targets, notice periods, residency and escrow, as an order form incorporates them.PDF · 5 sheets · 166 KBNothing here is under NDA. The evidence pack in §3 — policies, the risk register, recovery test reports, access-control evidence — is a separate request to security@vaethra.com.
Every address, and what it is for
| Subject | Address |
|---|---|
| Vulnerability reports and security incidents | security@vaethra.com |
| Security questionnaires, evidence requests, DPAs | security@vaethra.com |
| Privacy and data subject requests | privacy@vaethra.com |
| Contracts, terms and licensing | legal@vaethra.com |
| Faults, support and enterprise escalation | support@vaethra.com, and +1 253 402-5005 for an enterprise Sev-1 |
| API access, pricing, general enquiries | contact@vaethra.com |
| Data providers, about our crawling | ops@vaethra.com |
Security contact details are also published at /.well-known/security.txt in the format defined by RFC 9116, so a scanner finds them without reading this page.
Legal entity and notice address
| Registered name | Vaethra Technologies LLC |
| Form and jurisdiction | Limited liability company, State of Wyoming, United States |
| Mailing address | 30 N Gould St Ste N, Sheridan, Wyoming 82801, United States |
| Notices | The address above, or legal@vaethra.com |
This is the entity that contracts, holds the infrastructure accounts and signs the Data Processing Agreement. It is established in the United States, so for a customer in the EEA or the UK it is the data importer under the Standard Contractual Clauses rather than the exporter.