ADOPTION GUIDE

How to Adopt the OTP

Any SaaS company can adopt the Open Trust Protocol. No permission needed, no audit fee, no certification authority. Six steps from zero to published.

What You Need

Access to your codebase

You need to evaluate 46 controls against your actual production code and infrastructure.

A public URL

Your report must be hosted somewhere publicly accessible. Your website, docs site, or a dedicated trust page.

Honesty

The protocol only works if you report honestly. A low score with a plan is better than an inflated score.

The 6 Steps

Step 1: Read the Specification

30 minutes

Familiarize yourself with the 8 trust domains, 46 controls, scoring methodology, and delegation principle.

  • Read the full specification at /specification
  • Understand the 5 score levels: ENFORCED (100%), IMPLEMENTED (75%), PARTIAL (50%), PLANNED (25%), MISSING (0%)
  • Review the delegation principle — using certified providers is a strength
  • Note the honesty clause: transparency over perfection

Step 2: Audit Your Controls

1-5 days

Evaluate each of the 46 controls against your production codebase and infrastructure. Document evidence for every score.

  • Walk through each domain and each control
  • For each control, determine: What is the current state? What evidence proves it?
  • Score honestly — a PARTIAL or PLANNED score with a remediation plan is better than inflating to ENFORCED
  • Identify delegated functions (auth, payments, hosting) and document provider certifications
  • Use automated tools where possible — Claude Code can audit source code directly

Step 3: Calculate Your Score

15 minutes

Compute domain scores (arithmetic mean of controls) and the weighted platform score.

  • For each domain: sum all control percentages, divide by number of controls
  • For the platform score: multiply each domain score by its weight, sum all 8
  • Weights: Auth 15%, Data 15%, Input 15%, Access 15%, Financial 15%, Infra 10%, Monitoring 10%, Availability 5%
  • Determine your rating: STRONG (95-100), SOLID (85-94), DEVELOPING (70-84), EARLY (50-69), INSUFFICIENT (0-49)

Step 4: Write Your Report

2-4 hours

Compile your scores, evidence, gap disclosures, and delegation declarations into the 7 required sections.

  • 1. Company identification (legal name, product, date, OTP version)
  • 2. Architecture summary (tech stack, delegated services)
  • 3. Domain-by-domain scoring (all 46 controls with evidence)
  • 4. Overall platform score (weighted calculation)
  • 5. Gap disclosure (every control < 100%: gap, plan, target date)
  • 6. Delegation declarations (provider, certification, data isolation proof)
  • 7. Version history

Step 5: Publish Publicly

1 hour

Make your report publicly accessible. No NDA, no login, no paywall. This is the entire point.

  • Host on your website, documentation site, or dedicated trust page
  • Ensure the URL is publicly accessible without authentication
  • Include the OTP version you audited against
  • Date the report and plan for quarterly updates
  • Optional: Submit your report to the OTP directory at opentrust.adaptensor.com/reports

Step 6: Maintain & Update

Quarterly

Keep your report current. Update at least quarterly or within 30 days of any material security change.

  • Re-audit controls that have changed
  • Update gap disclosures: close resolved gaps, add new ones
  • Increment the version number and document changes
  • Keep previous versions accessible
  • A changing score is normal — a stale report erodes trust faster than a low score

Controls Quick Reference

All 8 domains and 46 controls you need to evaluate. Click through to the full specification for required evidence details.

1

Authentication & Identity

7 controls - 15% weight
  • 1.1Password storage security
  • 1.2Multi-factor authentication
  • 1.3Session management
  • 1.4Brute force protection
  • 1.5Role-based access control
  • 1.6Account deprovisioning
  • 1.7OAuth / SSO support
2

Data Protection & Encryption

6 controls - 15% weight
  • 2.1Encryption in transit (TLS)
  • 2.2Encryption at rest
  • 2.3Multi-tenant data isolation
  • 2.4Sensitive data handling
  • 2.5Backup encryption
  • 2.6Security headers
3

Input Validation & Injection Prevention

6 controls - 15% weight
  • 3.1SQL injection prevention
  • 3.2Request body validation
  • 3.3URL parameter validation
  • 3.4File upload sanitization
  • 3.5XSS prevention
  • 3.6CSRF protection
4

Access Control & Authorization

5 controls - 15% weight
  • 4.1Tenant data isolation
  • 4.2Role-based permissions
  • 4.3API authentication enforcement
  • 4.4Sensitive action authorization
  • 4.5Audit trail for access changes
5

Financial Integrity

6 controls - 15% weight
  • 5.1Double-entry enforcement
  • 5.2Immutable transaction log
  • 5.3Void/refund audit trail
  • 5.4Register reconciliation
  • 5.5Tax calculation accuracy
  • 5.6Payment card data isolation
6

Infrastructure & Deployment

6 controls - 10% weight
  • 6.1Hosting provider security
  • 6.2Strict compilation / linting
  • 6.3Dependency management
  • 6.4Secret management
  • 6.5CORS configuration
  • 6.6Deployment pipeline security
7

Monitoring & Incident Response

5 controls - 10% weight
  • 7.1Audit logging
  • 7.2API rate limiting
  • 7.3Error monitoring
  • 7.4Uptime monitoring
  • 7.5Incident response plan
8

Availability & Business Continuity

5 controls - 5% weight
  • 8.1Offline / degraded operation
  • 8.2Database backups
  • 8.3Auto-scaling
  • 8.4Disaster recovery plan
  • 8.5Geographic redundancy

Scoring Reference

Enforced
100%

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
75%

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
50%

Control is partially implemented. Some attack vectors or failure modes are covered; others are not. The gap is documented.

Planned
25%

Control is designed and scheduled for implementation with a specific target date, but is not yet active in production.

Missing
0%

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.

Tips for a Strong Report

Be specific with evidence. Link to code, configurations, or provider documentation. "We use encryption" is not evidence. "AES-256 at rest via Neon PostgreSQL (SOC 2 Type II)" is.
Embrace delegation. Using Clerk for auth, Stripe for payments, and Vercel for hosting is not a weakness. Under OTP, it is the strongest possible control — if the provider is certified and you store zero sensitive data.
Disclose gaps proactively. A PARTIAL score with a clear remediation plan and target date builds more trust than a suspicious ENFORCED score with vague evidence.
Use automation. Claude Code can audit your codebase directly — checking for SQL injection patterns, auth middleware coverage, rate limiting, and more. The AdaptBooks report was generated this way.
Start with what you have. You do not need to be 100% on all controls to publish. An honest DEVELOPING (70-84%) report is more valuable than no report at all.
Plan your quarterly cadence. Set a calendar reminder. Reports must be updated quarterly or within 30 days of a material change. A stale report erodes trust faster than a low score.

See a Live Example

AdaptBooks OTP Compliance Report

The first OTP report ever published. 46 controls scored, 11 gaps disclosed, 6 delegation declarations. Platform score: 87.3% (SOLID).

Start your report today

The OTP requires no permission, no fee, and no auditor. Read the specification, evaluate your controls, and publish. Your customers deserve to see the proof.

Read the SpecificationCompare with SOC 2

“Trust isn't a badge you buy. It's a standard you publish.”