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 notdo 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.

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_idvalidation 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. Staff impersonation + audit log

Afia Labs staff can impersonate a customer workspace only after the workspace owner or admin grants access. The impersonation system has five layers:

1. Session TTL: default 60 minutes; expires automatically.
2. Write approval window: read-only by default. Write access requires a separate per-session approval with its own 30-minute TTL.
3. 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.
4. 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.
5. Customer visibility: active impersonation shows a sticky banner across the entire customer UI for the duration of the session. Customers see exactly when Afia Labs is in their workspace.

For procurement and security teams:the impersonation 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 customer approval. Workspace owners can disable staff access entirely from Settings → Staff access, which 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

The Yesoma database uses Supabase-managed backups according to the active project plan.

We do not currently publish formal RTO/RPO targets. Recovery from Supabase backups would be initiated case-by-case in an incident; the customer-controlled workspace export below serves as an immediate alternative.

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 does not yet have a formal incident response plan with documented severity tiers, acknowledgement SLAs, or notification timelines. As Yesoma grows we will document and publish these on this page. In the meantime, our intent is to follow GDPR-style expectations for confirmed incidents affecting customer data: investigate promptly, remediate, and notify affected workspace owners with scope, impact, and status.

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 currently operated by a single founder (Afia Labs). All sub-processor consoles (Supabase, Cloudflare, Stripe, Resend, Postmark, Twilio, Anthropic, Google) are accessed only by the founder, with multi-factor authentication enforced on every account.

When Afia Labs 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.

Yesoma does not yet have a documented formal review cadence (quarterly sub-processor review, post-incident audit, access register review, etc.). These will be established and published on this page as Yesoma grows.

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, a US entity. When we process personal data of individuals in the EU, EEA, or UK on behalf of a customer, we act as a processorunder 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: hello@getyesoma.com