OTP is pre-SOC 2 and targeting SOC 2 Type II within six months. We document our controls openly here rather than hide behind a badge we have not yet earned. Our infrastructure runs on Railway, which is SOC 2 Type II certified and HIPAA compliant.
Last updated
Private by default. Your operational data is scoped to your organization and is never exposed on any cross-org surface unless you take an explicit action to publish it.
Each of these requires an explicit action by you.
Organizations flagged private are hard-excluded from every cross-org surface — browse, search, the intelligence graph, recommendations, published best-practices listings, and the network API — regardless of any per-item publish setting.
Enforced through a single shared control so the rule cannot drift between surfaces. A boot-time check rebuilds the network data view to include the same exclusion.
Privacy is all-or-nothing at the organization level; there is no per-item private override.
Multi-tenant by design. Every record (priorities, to-dos, KPIs, meetings, org chart, learnings) carries an organization ID, and every request is bound to one organization before any data is read.
Tenant scoping is enforced in the application layer on every route, and every cross-org read additionally passes through one shared visibility control. We disclose plainly that isolation is enforced in the application, not via database row-level security.
We are an early-stage protocol. We tell you exactly where we are.
On confirming a security incident affecting customer data, we contain it and notify affected organizations within 3 hours, followed by a written post-incident summary.
No reportable security incidents to date.
A comprehensive security audit was completed in July 2026, covering authentication, multi-tenant isolation, injection, the dependency supply chain, and file handling. Findings were remediated and verified in production, and the production dependency tree carries no known high or critical vulnerabilities; any remaining advisories are low or moderate and tracked to resolution. This was a code-level internal review, not a third-party penetration test — a formal external assessment is planned as we grow.
See what was hardened & live status →80 controls across 12 categories, each one a statement made in our approved policy set. Where a control is partial or planned we say so and give the target, because a catalog with no gaps in it is a catalog nobody checked.
Access Control Policy
Every person and every AI agent is granted the minimum access their work needs. Access is granted by role and task, not by default, and broad or standing access is avoided.
End-user authentication is handled by Clerk. OTP stores no passwords.
Multi-factor authentication is required on every administrative account that can reach production: the hosting provider, source control, the auth provider, and any provider console that touches customer data.
OTP API keys are hashed with SHA-256 at rest and presented as bearer tokens. Service secrets are stored as platform service variables, never in source code.
Administrative view-as impersonation uses a signed cookie that binds the action to the acting administrator, so it appears in the audit log under that person.
Access is reviewed every quarter and written up, recording what was checked, what changed, and any exception the owner accepted. A system that could not be verified is recorded as not verified rather than assumed clean. First review 2026-08-03; next due 2026-11-03.
When a person leaves or an agent is retired, access is revoked within one business day and the credentials they held are rotated or revoked.
Access Control Policy; Secure Development Policy
Each AI agent operating on production receives its own scoped credential. Agents never share a credential or borrow a human one.
An agent credential is limited to the specific tools and data that agent needs, and is revoked when the agent is retired.
What an agent does on production systems is written to the same logs as human activity.
Every agent has a named human owner who answers for its actions.
OTP is built with substantial help from AI agents. Code an agent writes is never merged unreviewed, and the reviewer applies the same standard as for human-authored code: correctness, authorization, secrets handling, and tenant isolation.
Billing code (subscriptions, the webhook, wallet metering, the reconcile job, and pricing) is edited by one session at a time, human or agent, coordinated through a lock, so concurrent edits cannot collide in the riskiest code.
Data Classification and Retention Policy; Data Privacy Policy
Seven classifications are defined and maintained: customer operational data, personal data, meeting transcripts, published network data, secrets and credentials, audit and system logs, and public content. Each carries its own handling rule.
Every record carries an organization ID, and every request is bound to one organization before any data is read.
An organization flagged private is excluded from every cross-organization surface through a single shared control, regardless of any per-item publish setting, so the rule cannot drift between surfaces.
Each data type has a stated retention period, from the 30-day sync event log to 12-month audit logs, and the schedule is enforced by scheduled sweeps that write their own audit entries.
On a verified deletion or right-to-be-forgotten request, personal data is permanently removed within 7 days. Organization deletion uses a two-phase process with a 7-day restore window.
Meeting transcripts are auto-redacted before storage and before AI processing. Raw transcript text is never persisted.
AI features send only the content a given request needs to the AI subprocessor, never the organization’s full data set.
Customers may request a copy of their data today and exports are handled on request. A self-serve export endpoint is on the roadmap.
Isolation is enforced in the application layer on every route, not through database row-level security. We disclose this plainly rather than imply a database-level guarantee. What covers it: a single shared visibility control on every cross-organization read, plus authorization tests that assert a request bound to one organization cannot read or write another’s data.
Encryption and Key Management Policy
All connections use TLS: end-user traffic, API traffic, and connections to backend services and subprocessors.
All customer data is encrypted at rest at the storage layer by the managed hosting and database provider.
Daily database backups are encrypted at rest, and the independent offsite copy is encrypted with a public key the storage provider does not hold.
Customer bring-your-own-key credentials are encrypted with AES-256-GCM at the application layer.
Application-issued tokens (demo access, email unsubscribe, admin impersonation) are signed with HMAC-SHA256 and verified in constant time.
Every inbound webhook is verified by signature on the raw request body before it is processed.
Secrets are stored as platform service variables and injected at runtime. Production credentials are never used for local development or testing.
gitleaks runs in continuous integration and blocks known credential patterns from being committed.
Secrets are rotated when a person or agent who held them leaves, when exposure is suspected, and as part of incident containment.
A routine recurring rotation schedule is not yet in force. Target Q1 2027. Current state: rotation is event-driven, as described above.
Beyond customer-supplied keys and service secrets, there is no general column-level encryption in the application. Data at rest is encrypted by the storage layer. We disclose this rather than let "encrypted at rest" imply more than it means.
Change Management Policy; Secure Development Policy
Changes are made on a branch and submitted as a pull request. Direct pushes to the production branch are not the normal path.
Type check, lint, automated tests including integration tests against PostgreSQL, and build all run on every pull request and every push to the production branch.
Branch protection on the production branch requires the CI status checks to pass before a change can merge.
The production dependency tree is audited in CI and the build fails on high or critical vulnerabilities.
Because tenant isolation is enforced in the application layer, tests assert that a request bound to one organization cannot read or write another organization’s data. New routes touching organization-scoped data ship with an authorization test.
Inputs are validated and database access uses parameterized queries. The July 2026 internal audit specifically covered injection and file handling.
An emergency fix may be expedited, but if a control is bypassed to stop active harm the Incident Lead approves it and records what was bypassed and why. The change is reviewed after the fact within five business days.
The knip dead-code check runs on every pull request but is currently non-blocking pending a triage pass. Every other CI gate above is enforced.
Vulnerability Management Policy
Dependabot watches the repository and opens pull requests for vulnerable dependencies.
Critical within 7 days and sooner under active exploitation, high within 30 days, medium within 90 days, low tracked in the backlog. A vulnerability under active exploitation is treated as an incident regardless of its base score.
The production dependency tree carries no known high or critical vulnerabilities. Remaining advisories are low or moderate and tracked to resolution.
A finding that does not apply to how OTP uses the affected component is documented and may be deprioritized, with the reason recorded rather than left implicit.
A code-level audit in July 2026 covered authentication, multi-tenant isolation, injection, the dependency supply chain, and file handling. Every finding was remediated and verified in production.
An annual external penetration test of the OTP application is planned alongside the SOC 2 program. Target Q4 2026. The July 2026 audit was internal, not a third-party test, and we do not describe it as one.
Incident Response Policy
Organization registration, publishing, and other key actions are recorded with the actor and the entity acted on.
Audit rows are kept for twelve months and are preserved as evidence during an incident before any change that could overwrite them.
Sentry has been live since 2026-07-18, scrubbing cookies, authorization headers, and credential-bearing URL segments before anything leaves the process. No request bodies are attached.
The health endpoint is monitored externally.
Three severity levels are defined, and the Incident Lead role is never left unassigned. The clock starts at confirmation, not at discovery of convenience.
On confirming an incident affecting customer data, each affected organization’s primary contact is notified within 3 hours. A complete-as-of-now notice inside the window is preferred over a perfect notice sent late.
Every incident gets a written post-incident summary and a review within five business days.
Error capture is fully active. Sentry auto-instrumentation for database query spans and outbound HTTP tracing is not, because the project runs native ESM without the loader flag it needs. Target Q4 2026.
Business Continuity and Disaster Recovery Policy
The database is backed up automatically every day, retained 30 days, stored in the EU West region and encrypted at rest.
A daily copy is taken to separate infrastructure from both the database and the provider snapshots, read through a SELECT-only role and encrypted with a key neither the CI runner nor the storage provider holds. It exists because the database and its provider snapshots otherwise share one provider and one mechanism.
Recovery Point Objective 24 hours, Recovery Time Objective under 1 hour, both bounded by the daily backup cadence rather than aspirational.
The first test on 2026-08-08 measured total recovery at 1 minute 48 seconds and verified restored data against production by structure, row count and content fingerprint. Next test due 2027-08-08.
A named second party can obtain the root-of-trust credentials and MFA recovery codes through time-delayed emergency access, with the owner notified and able to approve or reject. The path is sealed day to day and verified quarterly by a request-and-deny drill.
Break-glass is in force, but it provides continuity, not capacity: the delay means it does not satisfy the 3-hour notification commitment. One person currently holds production access, tracked as R-1 in the risk register. A standing second operator follows as the team grows.
Vendor Management Policy
Every subprocessor is listed with its function, location and risk tier, and receives only the data that function needs. The register is on this page.
Before a subprocessor is added, its security posture, data handling and location, and compliance status are reviewed, and the narrowest data-sharing that works is chosen.
Customers are informed of material subprocessor changes as set out in the Data Privacy Policy and the standard DPA.
Vendors were assessed at selection, but the annual formal re-review is not yet a documented recurring process. Target Q4 2026.
Risk Assessment Policy
A formal assessment runs at least annually and after any major change to the product, infrastructure, team, or threat landscape. First assessment 2026-08-07; next due 2027-08-07, with an interim check paired to the Q4 2026 access review.
Sixteen risks are recorded with likelihood, impact, current controls, treatment decision, owner and target date. Accepted risks carry the reason for acceptance.
The standing risks (single production operator, application-layer isolation, subprocessor dependency, AI processing of customer content) are stated in the policy set and on this page rather than left for a reviewer to discover.
Information Security Policy; Acceptable Use Policy; Human Resources Security Policy
Fifteen policies, version 1.0, approved by the CEO on 2026-07-18 and effective from that date. Each is owned, reviewed at least annually, and maps to SOC 2 criteria. Next review due July 2027.
Where a control does not yet exist, the policy states the requirement and marks the current state honestly so the gap is visible. That convention is why this catalog has four statuses instead of one.
Credential handling, approved tools, prohibited use, and the rule that a control is not disabled without the policy owner’s approval. It covers AI agents as well as people.
This page is the public statement of the controls above, and it is kept in step with the policy set by an automated check that fails if the two drift apart.
Required before the first hire with access to customer data or systems. No such hires yet, so no standing signed process has run.
Required before the first hire into a production-access role, to the extent permitted by law in that person’s jurisdiction. No such hires yet.
A formal onboarding and annual training program covering phishing, credential handling, data classification and incident reporting. Target Q1 2027, or before the first hire with production access, whichever comes first.
Physical Security Policy
OrgTP is remote-first with no physical office and no on-premises production infrastructure. Physical security of the infrastructure is the provider’s responsibility, and the provider is SOC 2 Type II certified.
Every device that reaches OTP systems or customer data runs full-disk encryption.
Devices lock automatically after a short idle period and require a password or biometric to unlock.
A lost or stolen device is reported immediately, every credential and session it could reach is revoked and rotated, and if customer data could have been exposed it is handled as an incident.
Central device management to enforce encryption, screen lock, updates and remote wipe is not yet in place. Target Q1 2027, or when headcount with device access grows. Current state: the requirements above are enforced by policy and manual configuration on a small number of devices.
By default, nothing. Your operating data stays private to your organization. Only items you explicitly publish (learnings, selected best practices, or a profile or KPIs you mark public) appear on the network.
No. Those are private to your organization and never appear on any cross-org surface.
Yes. A private organization is hard-excluded from every cross-org surface through a single enforced control.
Your database records are in the EU, in Railway's Amsterdam region, with daily encrypted backups retained 30 days. Uploaded files and recordings are in Cloudflare R2 in the United States. All of it is encrypted at rest.
No. AI features send only the content needed for that request to Anthropic's Claude API to generate your response, and Anthropic does not train on data submitted through its paid API.
Yes. On a verified deletion request, personal data is permanently removed within 7 days. You can request a copy of your data, and a self-serve export is on the roadmap.
OTP records an aggregate daily count of the changes each member makes, so an organization's leadership can see which days a person was active and roughly how much they did. It does not capture IP addresses, devices, pages viewed, or the content of any action. These numbers are visible only inside your own organization, to leadership roles, and to OTP platform administrators in aggregate.
Yes. Every member has a personal data page (Settings, My data) showing their identity record, what the organization holds that involves them, and who has viewed their meeting transcripts. This is a product surface, not a support request.
Challenge it. Any member can contest an Ollie Insight, or one specific receipt it cites, right where it appears. The challenge stays attached to the insight, anyone can respond, and only the person who raised it can close it. A wrong claim cannot be quietly outranked or regenerated away.
We are pre-SOC 2 and targeting SOC 2 Type II within six months; our infrastructure already runs on SOC 2 Type II, HIPAA-compliant Railway. For GDPR, customer data is hosted in the EU and a DPA is available on request.
We respond to security inquiries within 1 business day. Our Data Processing Agreement is available on request.
security@orgtp.com
OrgTP, LLC · Fairfield, NJ 07004, USA