Security controls + posture

Plain-English summary

We are not SOC 2 certified yet. We have documented security controls and can share this overview with your security or procurement team. We're building toward SOC 2 readiness as Yesoma grows.

What we do today: row-level security on every customer-data table, encrypted secrets via Supabase Vault, signed webhooks for billing + booking integrations, audit logs for staff access, self-serve workspace deletion with a 30-day cooling-off window, and inbound webhook rate limiting.

What we do not do today: SOC 2, ISO 27001, or HIPAA certification. We'll be honest with you about what's in place vs what we're working toward — and we'll update this page when something material changes.

What is still being verified: production backup and point-in-time recovery coverage, a measured restore time, production-console access and MFA evidence, and formal recovery targets. We do not claim those controls as complete until the evidence record is closed.

1. Certifications + posture

Yesoma is not currently certified under SOC 2, ISO 27001, or HIPAA. Our public claim is “Trust controls from day one” — meaning the controls listed on this page are implemented and verifiable in our codebase today, but they have not been independently audited.

If you need a formal SOC 2 report for procurement: please reach out to security@getyesoma.com and we'll start the conversation. We can share this controls overview and the sub-processor list directly. A full SOC 2 audit will be initiated as customer demand justifies the cost; we'd rather under-promise and deliver than claim a status we don't have.

2. Access control

Authentication. Customer sign-in uses Supabase Auth (email magic-link or Google OAuth). Sessions are httpOnly + same-site cookies; CSRF mitigated by Next.js same-site default.

Authorization. Every workspace has a role hierarchy: owner > admin > manager > agent > viewer. Permissions are enforced at three layers:

• Database (RLS): Postgres row-level security policies on every customer-data table — see §3.
• Server action layer: every mutation calls a centralised requireUserWithOrg() + role check before issuing any DB write.
• UI layer: buttons / settings are hidden for roles that lack permission. This is advisory only — the database and server layers are authoritative.

3. Row-level security (RLS)

Every customer-data table in Postgres has at least one RLS policy that scopes reads + writes to the authenticated user's organization. Verified tables include: inquiries, customers, messages, follow_ups, ai_outputs, templates, services, policies, faqs, agreement_acceptances, channel_consents, app_events, and the per-channel tables.

The shared policy helper is_org_member(organization_id) matches the currently authenticated auth.uid() against the profiles table. RLS is designed to prevent cross-tenant access at the database layer, even if application code has a scoping bug.

Service-role writes (used by inbound webhooks, billing webhooks, and the staff console) bypass RLS by design. Every such write is paired with an explicit organization_id validation derived from the authenticated session — not from the request body — so service-role usage can't be tricked into writing to a different workspace.

4. Yesoma Support Access + audit log

Yesoma support can reproduce a customer workspace experience only after its Workspace Owner or Admin enables access. Support selects the exact affected teammate for UI context but never inherits that teammate's authority. The system has six layers:

1. Session TTL: default 60 minutes; expires automatically.
2. Limited-change approval: read-only by default. A narrow operational repair requires separate Workspace Owner/Admin approval with its own 30-minute TTL.
3. Permanent restrictions: customer messaging, deletion and merge, consent, quotes and billing, security, credentials, roles, membership, and protected Business Brain changes remain blocked in every support session.
4. Read-only Supabase proxy: during a read-only session, all attempted mutations are intercepted and return a structured "read-only support session" error. Staff cannot accidentally write.
5. Audit log: every staff request that touches a customer workspace writes a row to staff_audit_log with the staff user, the org, the action, and a timestamp. Append-only.
6. Customer visibility: an active support session shows a sticky banner across the entire workspace UI for the duration of the session. Customers see exactly when Yesoma Support is in their workspace.

For procurement and security teams: the support-access system was designed for B2B due-diligence questions of the form "what happens when your support touches our data?" The default is read-only, the customer owns approval, and every action is preserved in an append-only audit log. Staff cannot disable the banner, cannot extend a session past its TTL, and cannot escalate scope without a fresh Workspace Owner/Admin approval. Workspace Owners and Admins can disable access entirely from Settings → Yesoma Support Access, which immediately revokes active sessions and causes new sessions to refuse to start.

5. Webhook verification

All inbound webhooks authenticate the sender before processing:

All inbound webhook routes additionally enforce per-org sliding- window rate limiting (default 1000 requests/hour per channel) to limit abuse and runaway costs.

6. Secrets + encryption

In transit: all customer traffic is HTTPS-only (TLS terminated at Cloudflare). All sub-processor connections use TLS by default.

At rest: Supabase Postgres encrypts the underlying storage. Customer data sits inside this encrypted-at-rest layer.

Application secrets (Calendly OAuth tokens, per-org webhook signing keys) are stored encrypted in Supabase Vault, not as plaintext columns. Application code retrieves decrypted values only through narrowly-scoped SECURITY DEFINER SQL functions.

Operational secrets (API keys for Anthropic, Stripe, Resend, Postmark, Twilio, etc.) live as encrypted environment variables in the Cloudflare Workers control plane. Never committed to git.

7. Vendor / sub-processor list

Yesoma uses the following sub-processors to deliver the service. The canonical list (with regions + purpose) is also in our Privacy Policy, §5.

• Supabase — Postgres database, authentication, file storage
• Anthropic — Claude AI for reply drafts, analysis, observations
• OpenAI — Whisper for optional voice transcription
• Stripe — subscription billing
• Resend — transactional + digest email delivery
• Postmark — inbound email parsing (when configured)
• Cloudflare — hosting, CDN, DDoS protection, edge runtime
• Google (OAuth) — sign-in (only if the workspace chooses Google)
• Twilio / Meta / WhatsApp Business Platform — optional connected messaging providers, when enabled by the customer
• Slack / Discord / Web Push — notifications you configure

New sub-processors are added only when a new product capability requires them. We update this page (and /privacy) before such a sub-processor starts receiving customer data.

AI training data. Under our agreements with Anthropic (Claude API) and OpenAI (Whisper API), customer content sent to these providers is not used to train their models. This is the default behavior of both providers' commercial API tiers, not a per-customer opt-out we manage. We can share the relevant contract / policy references on request — email privacy@getyesoma.com. We do not train any in-house models on customer content either.

8. Data residency

Primary datastore. All customer data of record — Postgres rows, file uploads (attachments, staff-note images), auth tokens, encrypted Vault secrets — lives in a single Supabase project hosted on AWS West US (Oregon, us-west-2). Yesoma does not replicate this data to other regions.

Edge runtime. The Yesoma application runs on Cloudflare Workers, which terminate at the data center geographically nearest the visitor. Workers handle the request and forward queries to Supabase in us-west-2; no customer data is persisted at the Cloudflare edge. We do not use Cloudflare D1, KV, or R2 for customer data.

Sub-processor processing. Outbound integrations process data in their providers' own regions:

• Anthropic (Claude) — US.
• OpenAI (Whisper transcription, when used) — US.
• Stripe — global with US primary.
• Resend (outbound email) — US / EU edge depending on recipient.
• Postmark (inbound email) — US.
• Twilio (WhatsApp / SMS) — global, US default region.
• Google (Calendly, sign-in) — global, per Google's own region selection.

Workspace owners who require their data of record to be hosted in a specific region (EU, UK, Canada) can contact privacy@getyesoma.com. Regional hosting is not yet generally available; we will evaluate per-customer requests as we grow.

9. Data deletion + retention

Self-serve workspace deletion. Workspace owners can schedule deletion of their entire workspace from Settings → Security. The flow requires typing the workspace name to confirm, then enters a 30-day cooling-off window during which the workspace stays live and deletion can be cancelled with one click.

After the 30-day window, a background job hard-deletes the organization row, which cascades through the schema. All customer-data tables (inquiries, customers, messages, follow_ups, AI outputs, templates, services, policies, FAQs, Business Brain entries, etc.) are removed. Two tables are intentionally preserved with the organization_id nulled out: the agreement_acceptances and channel_consents ledgers, which are legal evidence of customer consent at the moment they accepted our terms. This is disclosed to customers in the deletion confirmation dialog.

Customer-content retention: indefinitely while the subscription is active; deleted within 30 days of account closure unless the customer requests sooner.

Activity log: 180 days default, configurable per workspace.

AI correction signals: 90 days default, configurable per workspace.

Webhook rate-limit log: 24 hours (auto-trimmed by the prune cron).

Application event log (app_events): 30 days.

10. Backups + recovery

Supabase offers plan-dependent managed database backups and optional point-in-time recovery. Yesoma's active retention, point-in-time recovery setting, and restore procedure are undergoing owner verification. We do not currently claim a fixed backup-retention period.

We do not currently publish formal RTO/RPO targets. We will publish only targets supported by a completed isolated restore exercise. Database backups and uploaded-file recovery are tested separately because database restoration does not itself restore stored file objects.

Workspace owners can export their entire workspace at any time as a structured JSON via Settings → Security → Export workspace. This serves as a customer-controlled backup independent of Supabase's.

11. Incident response

Reporting. Suspected security issues should be reported to security@getyesoma.com.

Yesoma maintains a written incident-response procedure covering intake, severity classification, incident command, containment, evidence preservation, customer-notification decisions, vendor escalation, recovery, rollback, and post-incident review. A security event affecting customer data is assessed against applicable legal and contractual notification duties, and affected workspace owners are told the known scope, impact, mitigation, and next update when notification is required. The procedure has not been independently audited, and its first recorded tabletop and restore exercise are still pending.

12. Change management

Source control. All production code lives in git. Every change to production passes through a commit + push to the main branch.

Type + lint gates. The build pipeline runs tsc --noEmit and npm run lint on every change. Type errors block deployment.

Database migrations. Schema changes go through versioned SQL migrations under supabase/migrations/, applied via Supabase CLI. Each migration is reviewed before application; the migration log is the source of truth for schema state.

Deployment. Production deploys to Cloudflare Workers via OpenNext bundling. Each deploy creates an immutable worker version with a unique version ID, enabling rapid rollback if needed.

13. Employee / admin access policy

Yesoma is operated by Afia Labs LLC and is currently founder-operated. Production-console access is intended to be founder-only and protected by multi-factor authentication. A dated project-membership, MFA, and last-use evidence register is still being completed, so Yesoma does not currently claim that universal console MFA has been independently verified.

When Afia Labs LLC hires employees or contractors who require access to production systems, we will:

• Issue per-person credentials (no shared logins).
• Require MFA on every production console.
• Grant least-privilege access scoped to the systems actually needed for the role.
• Document the access in a written access register, reviewed quarterly.
• Revoke access immediately on role change or departure.
• Sign confidentiality + acceptable-use policies before access is granted.

Staff impersonation of customer workspaces is additionally governed by §4 above, regardless of internal access level.

14. Security review cadence

Per-release: every production deploy passes type-checking, lint, and a manual smoke test of changed surfaces.

During launch readiness, the production-access register and unresolved security evidence are reviewed monthly. Sub-processors and privileged access are reviewed quarterly after launch. Every confirmed incident receives a post-incident review before the issue is closed. Reviews are considered complete only when their dated evidence is recorded.

See §15 below for the status of independent penetration testing, bug bounty programs, and coordinated vulnerability disclosure.

15. Independent testing + vulnerability disclosure

Penetration testing. Yesoma has not yet commissioned an independent third-party penetration test. We will introduce an annual pen-test cycle when customer demand (enterprise procurement or compliance-driven requirements) justifies the cost. When we do, we will publish the date of the most recent test on this page and make a summary letter available to customers on request.

Bug bounty. Yesoma does not currently operate a formal bug-bounty program with monetary rewards. We do welcome coordinated disclosure (see below) and will publicly credit researchers whose findings lead to a fix, with their permission.

Coordinated vulnerability disclosure. Security researchers can report suspected vulnerabilities to security@getyesoma.com. Please include reproduction steps, affected URLs, and your contact details. We acknowledge legitimate reports within a reasonable period and will keep you updated on remediation status.

Safe harbor. We will not pursue legal action against researchers who act in good faith and follow these guidelines: do not access, modify, or exfiltrate data belonging to anyone other than yourself; do not perform denial-of-service attacks, social engineering of Yesoma staff or customers, or physical attacks on infrastructure; report promptly and keep details private until we have remediated.

Out of scope. Findings on third-party sub-processor surfaces (Supabase, Cloudflare, Stripe, Resend, Postmark, Twilio, Anthropic, Google) should be reported directly to those vendors' security teams.

16. GDPR / UK GDPR and data subject rights

Yesoma is operated by Afia Labs LLC, a United States limited liability company. When we process personal data of individuals in the EU, EEA, or UK on behalf of a customer, we act as a processor under the GDPR / UK GDPR; the customer is the controller. For cross-border transfers we rely on Standard Contractual Clauses and our sub-processors' own GDPR-aligned transfer mechanisms (see Privacy Policy §6).

Data Subject Access Requests (DSAR). Individuals exercising their GDPR rights (access, rectification, erasure, restriction, portability, objection) can email privacy@getyesoma.com. We acknowledge within a reasonable period and respond within 30 days, per GDPR Article 12. If the requester is an end-customer of one of our workspace owners, we will coordinate the request with the controller (the workspace owner) and may route the request to them for fulfilment.

Erasure. Workspace owners can self-serve deletion from Settings → Security (30-day cooling-off, cancellable any time before then; hard-delete after that). Other erasure requests are honored within the same 30-day window. See Privacy Policy §9 for the full list of rights.

Data Processing Agreement. A DPA is available on request to customers who require one for their own compliance program. Email privacy@getyesoma.com with your company name and we will send the current version.

17. Contact

Security or compliance questions: security@getyesoma.com

General privacy questions: privacy@getyesoma.com — see our Privacy Policy.

Customer support: support@getyesoma.com