Security & Privacy Overview

Draft — not yet approved for external use

This document is drafted from the platform’s actual technical implementation, not from an approved legal/security policy — Yareta has no existing customer-facing security or privacy statement to source this from. Have this reviewed by whoever owns legal, security, and compliance messaging before sharing it with a customer or prospect, and before using any of it in a sales or procurement context (a security questionnaire, a DPA, a trust-center page). It intentionally does not repeat the internal, admin-only gap list in the Admin Guide §9 — that’s operational detail for the team, not customer-facing messaging.

How your data is protected in transit and at rest

Yareta runs on Cloudflare’s infrastructure (Pages, Workers, and D1 for data storage), so all traffic to and from the platform is encrypted in transit. Application data is stored in Cloudflare D1, isolated per environment (development and production are entirely separate databases).

Authentication

Sign-in defaults to a one-time passcode (OTP) sent by email rather than a stored password for most account flows, with a fuller password-based option available for the investor-facing login path. Session tokens carry an expiry and can be forced to invalidate platform-wide for a specific user (for example, after a password change or an admin-initiated security action).

Access control

Access to another organization’s data is scoped by organization membership — you only see submissions, reports, and settings belonging to organizations you’re a member of. Within an organization, two roles are available (Admin and Member); platform-level administrative functions (used by Yareta’s own team, not customers) are further gated by role and are entirely separate from your organization’s own admin/member roles.

API and integration security

• Third-party OAuth clients (apps that integrate with Yareta on a customer’s behalf) are provisioned through a controlled process, not open self-registration — see the Admin Guide §5.
• Outbound webhooks you configure to receive events from Yareta are signed on every delivery using HMAC-SHA256, so your endpoint can verify a payload genuinely came from Yareta before trusting it — see the User Guide.
• API keys and client secrets are shown exactly once, at the moment they’re created, and cannot be retrieved again afterward — only regenerated. Treat any of these as you would a password: store it in a secrets manager, not in a shared document or chat message.

Credit and billing integrity

Billing-affecting actions (credit deductions, plan changes) are built with idempotency protections designed to prevent duplicate charges from retried requests. If you ever see a charge for an action that didn’t visibly complete, that’s worth reporting — see the Support / FAQ.

Data retention and deletion

(Placeholder — this needs input from whoever owns data-retention policy before publishing. The codebase does not currently expose a self-service data-export or account-deletion flow to end users that this document can point to; if one doesn’t exist yet, that’s worth flagging as a gap, not glossing over.)

Questions

For any security or privacy question not covered here, contact your Yareta account representative directly rather than assuming an answer from this document — it’s a starting draft, not a finished policy.

---

Related documents: Admin Guide · User Guide · Support / FAQ