System Description (SOC 2 Section III)

System Description (SOC 2 Section III)

Field	Value
Document title	System Description (SOC 2 Section III)
Version	1.0
Effective date	29 May 2026
Owner	engineering@theorahq.com
Approved by	Theora Engineering Leadership
Review cadence	Annual, and upon any material change to the system boundary

0. Document control history

Version	Date	Author	Change summary
0.1	13 May 2026	Engineering	Initial drafting alongside merged security workstreams (rate limiting, query log redaction, CMEK, retention).
0.9	22 May 2026	Engineering	Aligned section structure to SOC 2 Section III requirements; incorporated subservice carve-out language.
1.0	29 May 2026	Engineering Leadership	Approved for inclusion in Theora's Trust Center and as Section III of the SOC 2 report.

1. Company overview and product

Theora Health, Inc. ("Theora") operates a hosted application that helps users explore, organize, and act on health-adjacent information. The service is delivered as a multi-tenant web application backed by APIs that orchestrate large language model providers, structured data lookups, and user-specific session state. Customers interact with Theora through authenticated web sessions; programmatic access is limited to first-party clients.

This System Description covers the production environment of the Theora application as operated by Theora's Engineering organization. It is published in steady-state form on Theora's Trust Center and is the System Description referenced in Section III of Theora's SOC 2 report.

2. System boundary

The boundary of this report includes the production application and the supporting infrastructure that processes customer data:

• The betaapp-api Cloud Run service in region us-central1, in Google Cloud project tactile-stack-491017-c0.
• The container image us-central1-docker.pkg.dev/tactile-stack-491017-c0/betaapp/betaapp-api, built and signed by Cloud Build from the LouizaLab/BetaApp source repository on GitHub.
• The Cloud SQL for PostgreSQL instance backing the application, reachable only over private IP via the Serverless VPC Access connector betaapp-connector.
• The Google Cloud Storage bucket tactile-stack-491017-c0-betaapp-assets, encrypted with customer-managed encryption keys (CMEK) backed by a Cloud KMS data key on a 90-day rotation.
• Firebase Identity Platform, which provides primary authentication, multi-factor authentication (TOTP and SMS), and Argon2 password hashing for the application.
• Firebase Hosting, which fronts the Cloud Run service and serves static assets.
• The supporting VPC, including all 42 subnets in scope, with VPC Flow Logs enabled at a 50% sample rate and configured to include all metadata.
• The Cloud Build pipeline defined in cloudbuild.yaml, triggered on push to main, which builds, tests, and deploys the container image to Cloud Run.
• The Django 4.2 application running on Python 3.14, including the core.logging.RedactingFilter that strips user query content from logs prior to delivery to Cloud Logging, and the delete_expired_queries Django management command that runs daily to enforce data retention.

Out of scope: Theora's corporate IT environment (laptops, identity for employees, productivity SaaS) other than where it directly supports administrative access to the production environment described above; marketing properties; and any pre-production or experimental environments that do not process production customer data.

3. Components

3.1 Infrastructure

Production infrastructure runs in Google Cloud project tactile-stack-491017-c0, region us-central1. Compute is provided by Cloud Run (betaapp-api). Persistent storage is provided by Cloud SQL for PostgreSQL on private IP and by Cloud Storage (tactile-stack-491017-c0-betaapp-assets) with CMEK. Egress and east-west traffic between Cloud Run and Cloud SQL traverses the Serverless VPC Access connector betaapp-connector; no public IP is exposed by the database. VPC Flow Logs are enabled on all 42 in-scope subnets.

3.2 Software

The application is a Django 4.2 service on Python 3.14, packaged as a container image and deployed to Cloud Run. Production currently serves 100% of traffic from revision betaapp-api-00070-lnq. The image is built and pushed by Cloud Build from cloudbuild.yaml on each merge to main in LouizaLab/BetaApp. Authentication is provided by Firebase Identity Platform, including MFA enrollment and verification. Application-layer logging is filtered by core.logging.RedactingFilter before records reach Cloud Logging so that the content of user queries is not retained in observability tooling.

3.3 People

Theora's Engineering team is responsible for designing, operating, and securing the system. Roles include engineers with least-privilege production access, an on-call rotation responsible for incident response, and engineering leadership responsible for approving access, change, and security policy. Background checks, confidentiality agreements, and security awareness training are required of all personnel with access to production.

3.4 Procedures

Documented procedures govern change management, access management, vulnerability management, incident response, backup and restoration, vendor review, and data retention. Changes to production require pull-request review and pass through the Cloud Build pipeline; production deploys are sourced exclusively from main. Access to Google Cloud and Firebase production projects is reviewed on a recurring cadence. Daily automated jobs enforce data retention, including the delete_expired_queries Django management command.

3.5 Data

Data in scope includes user account records (managed in Firebase Identity Platform), application data stored in Cloud SQL, and user-uploaded or generated assets stored in Cloud Storage. Data at rest in Cloud Storage is protected with CMEK using a Cloud KMS data key rotated every 90 days. Data in transit is protected with TLS terminated at Firebase Hosting and re-encrypted to Cloud Run. User query content is redacted from log streams by core.logging.RedactingFilter. Retention is enforced by the daily delete_expired_queries job; deletion records are maintained as separate Trust Center evidence.

4. Control objectives by Trust Services Category

4.1 Security (Common Criteria)

• Logical access: All end-user access is authenticated through Firebase Identity Platform with MFA available (TOTP and SMS) and Argon2 password hashing. Administrative access to Google Cloud and Firebase is granted on a least-privilege basis and reviewed periodically.
• Network security: Cloud SQL is reachable only via private IP through the betaapp-connector Serverless VPC Access connector. VPC Flow Logs are enabled across all 42 in-scope subnets at a 50% sample rate with full metadata for forensic support.
• Change management: Production deploys occur only through the Cloud Build pipeline defined in cloudbuild.yaml, triggered on push to main in LouizaLab/BetaApp. Changes require code review prior to merge.
• Vulnerability and threat management: Dependencies and base images are tracked; per-IP rate limiting protects authentication endpoints from credential-stuffing and brute-force attempts.
• Monitoring and logging: Cloud Logging receives application, build, and infrastructure logs. The core.logging.RedactingFilter removes user query content prior to log emission so sensitive content does not enter observability systems.

4.2 Availability

• Cloud Run provides horizontally scaled, regionally redundant compute for betaapp-api.
• Cloud SQL for PostgreSQL is configured for automated backups; restoration procedures are documented and exercised.
• Cloud Build pipelines support reproducible, auditable deploys, with the ability to redeploy a prior known-good revision (for example, betaapp-api-00070-lnq is the current production revision serving 100% of traffic).

4.3 Confidentiality

• Customer-managed encryption keys (CMEK) protect data at rest in tactile-stack-491017-c0-betaapp-assets, with the Cloud KMS data key rotated every 90 days.
• User query content is excluded from Cloud Logging by the Django core.logging.RedactingFilter.
• Retention of user query data is bounded by the daily delete_expired_queries Django management command.

5. Subservice organizations (carve-out method) and complementary user entity controls

Theora uses the following subservice organizations to deliver the system in scope. This System Description is prepared using the carve-out method: the controls operated by these providers are not included within the scope of this report. Theora relies on each provider's own attestations (for example, SOC 2 or ISO/IEC 27001 reports) to evidence the design and operating effectiveness of their controls, and monitors those attestations as part of vendor management.

Subservice organization	Service provided to Theora	Controls carved out
Google Cloud	Compute (Cloud Run), database (Cloud SQL), object storage (GCS), networking (VPC), key management (Cloud KMS), build (Cloud Build), logging (Cloud Logging).	Physical security of data centers, hypervisor and host security, underlying network fabric, KMS cryptographic operations, regional resilience of managed services.
Firebase (Google)	Identity Platform for authentication and MFA; Firebase Hosting fronting Cloud Run.	Identity provider availability, credential storage operations, edge hosting infrastructure.
Anthropic	Large language model inference used by the application.	Model serving infrastructure, request handling, and provider-side data handling per Anthropic's terms.
OpenAI	Large language model inference used by the application.	Model serving infrastructure, request handling, and provider-side data handling per OpenAI's terms.
GitHub	Source code hosting for LouizaLab/BetaApp and pull-request review tooling.	Repository availability, branch protection enforcement, and authentication for code collaborators.
Vanta	Continuous compliance monitoring and evidence collection.	Evidence ingestion pipeline and integration availability.

5.1 Complementary user entity controls (CUECs)

To achieve the control objectives described in this report, customers and authorized users of Theora are expected to:

• Maintain the confidentiality of their account credentials and enroll in MFA where supported.
• Restrict access to Theora to authorized individuals within their organization and revoke access promptly upon role changes or termination.
• Review access and activity within their organization's use of Theora on a periodic basis.
• Notify Theora promptly of suspected unauthorized access or security incidents involving the service.

6. Changes during the review period

The following material changes were implemented during the review period and are reflected in the current control environment. Each is anchored to a merged change in LouizaLab/BetaApp on main:

Change	Commit	Date	Effect on controls
Per-IP rate limiting on authentication endpoints	f9cc2c1	13 May 2026	Strengthens logical access controls against credential stuffing and brute force.
Django log filter strips user query content before Cloud Logging	d1edc6d	13 May 2026	Reduces confidentiality exposure by excluding query content from observability data.
CMEK on GCS bucket via Cloud KMS data key	39a4056	13 May 2026	Adds customer-managed key control over data at rest in tactile-stack-491017-c0-betaapp-assets.
Fresh-signup login flow correctness fix (Firebase fallback path)	a468e3d	13 May 2026	Improves correctness of the authentication path for newly registered users.
Auto-delete of expired user query data	50a8675	13 May 2026	Enforces retention via the daily delete_expired_queries Django management command.

7. Risks and mitigations

Theora maintains a risk register (docs/soc2/risk-register.md) that identifies risks to the system and the controls that mitigate them. Representative risks and their mitigations are summarized below.

Risk	Mitigation
Credential compromise of an end-user account	MFA via Firebase Identity Platform (TOTP/SMS); Argon2 password hashing; per-IP rate limiting on authentication endpoints.
Unauthorized access to data at rest	Cloud SQL on private IP via betaapp-connector; CMEK on GCS bucket with 90-day key rotation.
Leakage of sensitive content into logs	core.logging.RedactingFilter strips user query content prior to Cloud Logging.
Over-retention of user query data	Daily delete_expired_queries management command; deletion records maintained as separate evidence.
Unauthorized or unreviewed changes reaching production	Code review on pull requests; Cloud Build pipeline (cloudbuild.yaml) sourced exclusively from main; deploys recorded as revisions in Cloud Run (current: betaapp-api-00070-lnq).
Subservice provider failure or change	Carve-out reliance on provider attestations; vendor list maintained at docs/soc2/vendor-list.md and reviewed periodically.
Network detection gaps	VPC Flow Logs across all 42 in-scope subnets at 50% sample with full metadata; documented Cloud IDS exception at docs/soc2/cloud-ids-exception.md with compensating controls.

8. Related documentation

• docs/soc2/inventory-of-resources.md — System and asset inventory supporting this boundary.
• docs/soc2/risk-register.md — Full enterprise risk register.
• docs/soc2/vendor-list.md — Vendor and subservice organization list.
• docs/soc2/cloud-ids-exception.md — Documented exception and compensating controls.