Trust Center
Intrusion Detection System installation
Cloud IDS does not meaningfully apply to Theora's serverless Cloud Run architecture; compensating controls (VPC Flow Logs, Cloud Logging, Cloud Monitoring, MFA, rate limiting) provide intrusion detection at fitting layers.
Canonical source: docs/soc2/cloud-ids-exception.md. The content below is reproduced verbatim from that file and governs Vanta tests gcp-cloud-ids-enabled and gcp-cloud-ids-notifications-enabled, including the present test (ids-ips-enabled-in-cde).
SOC 2 — Cloud IDS Control Exception (Documented Risk Acceptance)
Covers Vanta tests: gcp-cloud-ids-enabled, gcp-cloud-ids-notifications-enabled
Decision date: 2026-05-28
Decision owner: Engineering Lead
Review cadence: annually, or when architecture changes to include VM/GKE workloads
Decision
Theora will not deploy Google Cloud IDS at this time. The two Vanta tests above are marked as a documented exception with compensating controls, rather than remediated by enabling the product.
Why Cloud IDS is not applicable to our architecture
Cloud IDS detects threats by packet-mirroring VPC network traffic and inspecting it with a managed Palo Alto threat engine. This design targets workloads that run inside the VPC on mirrorable network interfaces — Compute Engine VMs and GKE nodes.
Theora's production application runs entirely on Cloud Run (serverless):
- Cloud Run instances do not expose mirrorable NICs in the VPC the way VMs/GKE nodes do.
- Inbound HTTPS terminates at Google's managed front end, not at a VPC interface we can mirror.
- The only VPC path is egress via the
betaapp-connectorServerless VPC Access connector (egress set to private-ranges-only).
A Cloud IDS endpoint attached to our default VPC would therefore inspect almost no production traffic while incurring its full cost.
Cost that would be incurred for negligible coverage
- Cloud IDS endpoint: ~$580/month per endpoint (~$7,000/year)
- Plus per-GB traffic-inspection charges
Compensating controls
| Layer | Control | Status |
|---|---|---|
| Network metadata | VPC Flow Logs on all 42 subnets (50% sampling, include-all metadata) | Enabled 2026-05-13 |
| Application logs | Cloud Logging captures every request + structured app logs; query content redacted by core.logging.RedactingFilter | Live |
| Database telemetry | Cloud Monitoring alert policies on Cloud SQL (CPU, memory, disk I/O, storage) routed to email notification channel | Created 2026-05-13 |
| Auth abuse | Per-IP rate limiting on auth endpoints + Firebase Identity Platform abuse detection + enforced MFA | Live |
| Edge | Google-managed front end terminates and filters inbound HTTPS; Cloud Run ingress restricted | Live |
| Access control | GCP IAM least-privilege; Cloud Run invoker restricted to specific principals | Live |
Conditions that would reverse this decision
- We introduce Compute Engine VMs or a GKE cluster carrying production or customer-data traffic inside the VPC (mirrorable surface appears).
- A specific customer contract or auditor explicitly requires network-level IDS regardless of architecture.
- We migrate off Cloud Run to a VPC-resident compute model.
How this is recorded in Vanta
- Open the test in Vanta.
- Choose Deactivate test (or mark as risk-accepted, depending on Vanta workspace configuration).
- Paste the short-form justification referencing this document and its compensating controls.
- Set a review reminder for one year.
Cross-references
Related SOC 2 artifacts in this repository: docs/soc2/cloud-ids-exception.md (canonical), docs/soc2/inventory-of-resources.md (Cloud Run, Cloud SQL, VPC, connector inventory), docs/soc2/risk-register.md (network-level threat detection risk entry), and docs/soc2/vendor-list.md (Google Cloud, Firebase Identity Platform).