The Open Trust Protocol
A public standard for SaaS security and compliance transparency. Published February 28, 2026 by Adaptensor Inc.
1. Purpose
The Open Trust Protocol (OTP) is a public framework for evaluating and disclosing the security posture of software-as-a-service platforms. It is designed as a transparent alternative to closed certification models like SOC 2 Type II.
Any software company can adopt the OTP. Any customer can read the results. There is no certification authority, no audit fee, and no NDA. The protocol provides the standard; the adopting company provides the evidence; the public provides the accountability.
The OTP is designed for SaaS companies that serve small and mid-size businesses — companies whose customers cannot afford to request SOC 2 reports and whose budgets cannot afford to produce them. However, any software company of any size may adopt the OTP, either as a primary disclosure framework or as a supplement to existing certifications.
Adopting the OTP does not require permission from Adaptensor Inc. or any other entity. It requires only a commitment to transparency.
2. Scoring Methodology
2.1 Control Scoring
Every control in the OTP is scored on a 5-point scale. The score reflects the current state of implementation, not intent or roadmap.
Enforced
Control is implemented, automated, and verified in production. Evidence is machine-generated or independently verifiable. No manual intervention required for the control to function.
Implemented
Control is implemented and operational but depends on manual processes, has not been independently verified, or covers the primary use case but not all edge cases.
Partial
Control is partially implemented. Some attack vectors or failure modes are covered; others are not. The gap is documented.
Planned
Control is designed and scheduled for implementation with a specific target date, but is not yet active in production.
Missing
Control does not exist and has no implementation plan. This must be disclosed explicitly. A missing control is not a failure — hiding a missing control is.
2.2 Domain Scoring
Each domain score is the arithmetic mean of its control scores. If a domain has 6 controls scoring 100%, 100%, 100%, 100%, 75%, 75%, the domain score is 91.7%.
2.3 Platform Score & Weighting
The overall platform score is the weighted average of all 8 domain scores. Domains are weighted by their security criticality.
| Domain | Weight | Controls |
|---|---|---|
| 1.Authentication & Identity | 15% | 7 |
| 2.Data Protection & Encryption | 15% | 6 |
| 3.Input Validation & Injection Prevention | 15% | 6 |
| 4.Access Control & Authorization | 15% | 5 |
| 5.Financial Integrity | 15% | 6 |
| 6.Infrastructure & Deployment | 10% | 6 |
| 7.Monitoring & Incident Response | 10% | 5 |
| 8.Availability & Business Continuity | 5% | 5 |
| Total | 100% | 46 |
2.4 Platform Rating
The weighted platform score maps to an overall rating.
All critical controls enforced. Remaining items are non-critical improvements.
Core controls in place. Some controls are implemented but not fully enforced or automated.
Significant controls exist but material gaps remain. Active remediation required.
Foundational security in place but many controls missing or incomplete.
Critical security gaps. Platform should not process sensitive data until remediated.
3. The Delegation Principle
Modern SaaS platforms are not monolithic. They are composed of specialized services. Under SOC 2, delegated functions create a “subservice organization” carve-out, penalizing platforms for making architecturally sound decisions.
The Open Trust Protocol takes the opposite position. Delegating security-critical functions to certified, specialized providers is the strongest possible control — provided the delegation meets three criteria:
The provider is certified. The delegated provider must hold its own security certification (SOC 2, ISO 27001, PCI DSS, or equivalent) relevant to the function it performs.
The attack surface is eliminated. The delegating platform must not store, process, or cache the sensitive data that the provider handles. Delegation means the data never enters your system.
The integration is secured. The connection between the platform and the provider must use secure authentication (API keys, JWT tokens, mTLS) with minimal permissions (principle of least privilege).
| Function | Example Providers | What Platform Eliminates |
|---|---|---|
| Authentication | Clerk, Auth0, Okta | Password storage, session management, brute force protection, credential stuffing defense, MFA infrastructure |
| Payment Processing | Stripe, Square, Adyen | Card number storage, PCI DSS scope, chargeback handling, fraud detection |
| Database Hosting | Neon, Supabase, PlanetScale | Encryption at rest implementation, backup management, physical security, patching |
| Hosting / CDN | Vercel, Cloudflare, AWS | DDoS mitigation, TLS termination, physical infrastructure security |
| Email / SMS | SendGrid, Twilio | Email deliverability infrastructure, carrier compliance, anti-spam |
4. The Eight Trust Domains
Each domain defines a category of security controls. An adopting company must evaluate every control and publish their score with supporting evidence.
5. Publishing a Compliance Report
Any company adopting the Open Trust Protocol must publish an OTP Compliance Report containing their specific scores, evidence, and gap disclosures.
Required Sections
- 1Company identification. Legal name, product name, report date, OTP version audited against.
- 2Architecture summary. High-level description of the platform's technology stack, including all delegated services and their certifications.
- 3Domain-by-domain scoring. Every control in every domain must be scored with evidence. No controls may be omitted without explanation.
- 4Overall platform score. Calculated using the weighted methodology defined in Section 2.
- 5Gap disclosure. Every control scoring below 100% must include: current score, specific gap description, remediation plan, and target completion date.
- 6Delegation declarations. Every delegated function must list: the provider, the provider's certification, and proof that the platform does not handle the delegated data.
- 7Version history. Date and summary of changes since the previous report.
Publication Requirements
- -Public access: The report must be published on a publicly accessible URL. No NDA. No login required. No paywall.
- -Version control: Each report must be dated and versioned. Previous versions should remain accessible.
- -Update frequency: Reports must be updated at least quarterly, or within 30 days of any material security change.
- -Honesty requirement: Inflating scores, omitting controls, or misrepresenting evidence is a violation of the protocol.
The Honesty Clause
The Open Trust Protocol has no enforcement authority. There is no auditor to certify compliance, no body to revoke certification, and no legal mechanism to punish dishonest reporting.
The enforcement mechanism is transparency itself. Because the report is public, anyone — customers, competitors, security researchers, journalists — can read it and challenge any claim.
“A low score honestly reported builds more trust than a high score dishonestly reported. That is the entire point.”