SCOPE
Document scope
AdaptOrch SaaS, control plane, API gateway, Supabase, Upstash Redis, Railway deployment, and operational workstations.
Status: first operational draft, pending legal review. It must be reviewed by counsel, the privacy owner, and the security owner before it is published as a binding policy or attached to a signed enterprise agreement.
§ 01
Purpose
This policy defines AdaptOrch's baseline security commitments for protecting confidentiality, integrity, and availability across the SaaS control plane.
The policy is designed as a practical pre-ISO operating document: it is not a certification claim, but it establishes the evidence that a customer or auditor expects to see before formal ISO/ISMS work begins.
§ 02
Security principles
Least privilege is the default: production access is granted only when required for a documented role and is reviewed on a recurring basis.
Customer content, prompts, API keys, run metadata, billing metadata, and audit logs are classified and handled according to sensitivity.
Security controls must be observable. Important administrative actions, API key events, authentication changes, and provider-routing changes are logged.
External LLM calls are treated as controlled subprocessors or external processing paths. Only the minimum task data required for inference is sent.
§ 03
Baseline controls
Authentication: user access uses Supabase authentication or equivalent identity controls. Private tenant API endpoints require a valid bearer token in production.
Authorization: tenant-scoped data is filtered by tenant context. Administrative operations require explicit role checks and should not rely on client-side state alone.
Secrets: production secrets are stored in environment-managed secret stores. Secrets must not be committed to source control, logs, screenshots, or support tickets.
Encryption: TLS is required for browser/API traffic. Managed storage providers are expected to provide encryption at rest for production data stores.
Change management: security-sensitive code paths such as auth, API keys, rate limits, billing, and provider routing require code review and test evidence before release.
Monitoring: health endpoints, rate-limit events, lead/API abuse signals, and audit events are monitored for abnormal behavior.
§ 04
Review cadence
This policy is reviewed at least quarterly and after any material incident, provider change, architecture change, or major customer security review.
CONTACT
Questions and updates
For support questions, contact ict03@rfems.com. For security reports, contact ict03@rfems.com. For privacy requests, contact ict03@rfems.com.