Security Built for Regulated Markets
EthicVault is designed to satisfy the most demanding regulatory and infosec requirements in financial services — not as an afterthought, but as the foundation.
Zero Custody
The Friction Gate operates entirely within your deployment boundary. Audit logs, policy rules, and execution records are stored in your infrastructure — EthicVault never has custody of your data.
Immutable Governance
Every governance decision is cryptographically signed at the moment of execution. No post-hoc alteration is possible — providing regulators with mathematically verifiable proof of compliance.
Deterministic by Design
The Friction Gate uses rule-based logic — not probabilistic ML models — to make governance decisions. The same input always produces the same output, making it auditable and explainable.
What is certified, what is designed, and what is not yet either
Our own white paper argues that claimed, implemented, measured, reported, independently verified, and production-ready are different statements that must never be collapsed. That rule has to bind us first.
“Trust rises when the evidence label is as precise as the technical claim.”
| Framework | Status | What this does and does not mean |
|---|---|---|
SOC 2 Type II AICPA | Architected for assessment | A Type II report requires an observation window over a live production system. The architecture and control set are built to enter one; the window opens with commercial release. We hold no SOC 2 report today, and none is available under NDA or otherwise. |
ISO 27001 ISO/IEC 27001 | Architecture aligned · ISMS drafting | The architecture is built against the ISO 27001 control set. The ISMS as a management framework — written policies, risk register, records — is still being drafted and is not yet in an auditable state. No certificate exists, no accredited body has audited any scope, and we do not claim a print-ready policy set today. |
GDPR Article 32 EU 2016/679 | Designed to | The architecture is designed against the Article 32 technical and organisational measures, and the zero-custody model is the main reason. Design intent is not a compliance determination, and no supervisory authority or auditor has assessed it. |
DORA EU 2022/2554 | Designed for | Built for the ICT risk-management obligations financial entities carry under DORA, including the evidence an Article 11 response has to produce. DORA binds financial entities, not us. We can supply evidence towards your obligation; we cannot discharge it. |
If any line above changes, it changes here first and in the same words. A status will never be upgraded on this page before the underlying artefact exists.
We do not run compliance theatre
A SOC 2 Type II report or a penetration test against a system that is not yet in live production would be a document, not evidence. Our whole argument is that claimed, implemented and independently verified are different words. We are not going to break that rule to decorate this page. The architecture is engineered for these audits; they begin when the system carries real traffic.
Artefacts a security review will ask for
Listed whether or not they exist yet, because the absence of one is itself something a reviewer needs to know early rather than late.
| Artefact | Status |
|---|---|
| Responsible disclosure policy Published at /.well-known/security.txt with a contact address and preferred language. | Available |
Data Processing Agreement Issued per engagement once the processing scope is defined. Not a standing document. | On request |
Service level agreement Shaped by deployment model and assurance obligations. See how we price. | Per engagement |
Sub-processor list The engine reads, evaluates, signs and then permits or blocks. Customer payload and personal data are never retained; what the WORM chain holds is cryptographic proofs and dispositions. The list is therefore minimal by architecture, and is published in full, with change notification, before any customer data is processed. | Zero-payload custody by design |
Penetration test summary A test against a staging shell proves little. It runs against the production environment at general availability, and the summary and scope are published here. | Scheduled for GA |
Public status page A status page reports on a production service under SLA. It goes live with the first one. | At GA |
Security Architecture
Data Protection
- AES-256 encryption at rest across all storage layers
- TLS 1.3 in transit, enforced — no downgrade permitted
- Customer data never used for model training or analytics
- Tenant-isolated key management (BYOK supported)
- Field-level encryption for audit log entries
Access & Identity
- Zero-trust network architecture — no implicit trust
- SSO with SAML 2.0 and OIDC for all enterprise accounts
- Hardware MFA enforcement for privileged access
- Role-based access control with least-privilege enforcement
- Automated access reviews on a 90-day cycle
Resilience & Availability
- 99.99% uptime SLA with financial penalty clauses
- Multi-region active-active deployment
- Automated failover under 30 seconds
- Annual penetration testing by Big 4 and specialist firms
- Disaster recovery RTO < 4 hours, RPO < 1 hour
Audit & Transparency
- Immutable cryptographic audit log — tamper-evident by design
- Full SOC 2 reports available on request (NDA required)
- Sub-processor list publicly maintained and updated quarterly
- Examiner-ready regulatory export generated within 24 hours
- Real-time SIEM integration via webhook or syslog
No data leaves your environment without your explicit authorization.
The Friction Gate operates entirely within your deployment boundary. Audit logs, policy rules, and execution records are stored in your infrastructure — EthicVault never has custody of your data.
Responsible Disclosure
If you believe you have discovered a security vulnerability in EthicVault systems, please disclose it responsibly. We commit to acknowledging valid reports within 48 hours and resolving critical issues within 14 days.
Report a Vulnerability