Removable media encryption policy

Removable Media Encryption Policy

Field	Value
Document title	Theora Removable Media Encryption Policy
Version	1.0
Effective date	29 May 2026
Owner / Author	security@theorahq.com (Security Lead)
Approved by	Engineering Lead
Review cadence	Annually, or on material change to the endpoint fleet

0. Document control history

Version	Date	Author	Change
1.0	29 May 2026	security@theorahq.com	Initial published version with enforcement-evidence section.

Theora is a fully cloud-native SaaS. Production workloads run on Google Cloud Run (Python 3.14, Django 4.2) in GCP project tactile-stack-491017-c0, region us-central1. Customer data is stored in Cloud SQL Postgres (private IP, reached via Serverless VPC Access connector betaapp-connector) and in Google Cloud Storage buckets. Authentication is handled by Firebase Identity Platform. By design, no portable or removable media is part of the production data path: there are no servers to plug a USB drive into, no backup-to-disk jobs, and no on-prem hardware.

This policy still exists because employee and contractor endpoints (laptops) are the one place where removable media is physically possible. It complements the Acceptable Use, Endpoint Security, and Incident Response policies and the inventory captured in docs/soc2/inventory-of-resources.md.

1. Scope

This policy applies to:

• All Theora employees and contractors (currently a remote team of approximately 5-10 people) with access to Theora production systems, source code, or customer data.
• All company-issued and personally-owned endpoints used to access Theora systems (GCP console, Google Workspace, GitHub, Firebase, Vanta, Cloud SQL via IAP, etc.).
• All removable media types: USB flash drives, external HDD/SSD, SD/microSD, optical media (CD/DVD/Blu-ray), tape, and smartphone mass-storage modes used as transfer devices.

2. Prohibition on Copying Production or Customer Data

Production data and customer data MUST NOT be copied, exported, or written to removable media. This includes, but is not limited to:

• Cloud SQL Postgres dumps, backups, or query result exports containing customer rows.
• GCS object downloads containing customer-uploaded content or generated artifacts.
• Cloud Logging exports or BigQuery extracts derived from production logs (note: production logs are already passed through core.logging.RedactingFilter, but redacted logs are still treated as sensitive).
• Firebase Auth user lists, service-account JSON keys, or any secret material.

Time-bounded exceptions (for example, a forensic export during incident response) require written approval from the security lead, must be encrypted at rest on the receiving media using an approved algorithm (AES-256), and must be recorded in an audit log entry stored under docs/soc2/ alongside the existing cloud-ids-exception.md precedent. The exception entry must record: requester, approver, business justification, data scope, expiration date, and destruction method.

3. Endpoint Full-Disk Encryption

All company laptops are required to have full-disk encryption enabled before being issued and before any access to production systems is granted:

• macOS: FileVault 2 enabled, recovery key escrowed to the issuing admin (or MDM once deployed).
• Windows: BitLocker enabled on the OS volume with TPM-backed key protection; recovery key escrowed.
• Linux (engineering workstations): LUKS on the root volume.

This ensures that if a laptop containing cached source code, IDE workspaces, or browser sessions to GCP/Firebase is lost or stolen, data at rest on that endpoint remains protected. Encryption status is verified at provisioning and re-verified during the quarterly access review process (which already cross-references the personnel list and access systems tracked in Vanta).

4. Enforcement

Current state (HONEST):

• Policy-based: this document plus onboarding attestation.
• Manual verification: screenshot of fdesetup status (macOS) or manage-bde -status (Windows) captured per endpoint at provisioning and at each quarterly access review.
• No automated MDM enforcement is in place today, and no technical control currently blocks USB mass-storage writes on endpoints.

Gap and remediation: Theora plans to deploy an MDM (Kandji for macOS, with Jamf or Intune as alternatives under evaluation) to (a) enforce FileVault/BitLocker as a configuration profile, (b) produce a per-device encryption compliance report that can be uploaded directly as Vanta evidence, and (c) optionally restrict USB mass-storage classes. This gap is tracked in docs/soc2/risk-register.md with a target completion date during the inaugural SOC 2 reporting period.

5. Violation Handling

Suspected or confirmed violations (for example, customer data copied to an unauthorized USB drive, or an unencrypted laptop discovered during access review) are handled as security incidents under Theora's Incident Response Policy. The standard process applies: triage by the security lead, scope assessment, containment (revoke credentials and Firebase sessions, rotate any keys cached on the endpoint), customer notification if required, and a written post-incident review filed under docs/soc2/.

6. Enforcement Evidence Pack (attach to Vanta alongside this policy)

Vanta requires enforcement-based evidence showing encryption is actively in place, not just policy intent. Theora attaches the following artifacts per audit cycle:

#	Artifact	How to capture	Frequency
1	FileVault status screenshot (macOS endpoints)	On each company-issued Mac, run fdesetup status in Terminal and screenshot the output showing FileVault is On. Save as docs/soc2/evidence/filevault-<device-id>-<YYYY-MM-DD>.png.	Quarterly + at provisioning
2	BitLocker status screenshot (Windows endpoints)	On each company-issued Windows laptop, run manage-bde -status in an elevated PowerShell and screenshot the output showing Conversion Status: Fully Encrypted and Protection Status: Protection On.	Quarterly + at provisioning
3	LUKS status (Linux workstations, if any)	Run cryptsetup status <device> on the root volume and capture output.	Quarterly + at provisioning
4	MDM encryption compliance report (once deployed)	Export per-device encryption compliance from Kandji / Jamf / Intune as PDF or CSV. Replaces artifacts #1 and #2 above once available.	Per audit cycle
5	Onboarding attestation log	Export from HR onboarding checklist or signed acknowledgement form showing each employee acknowledged this policy at hire.	Per new hire + per audit cycle
6	Removable-media exception log	Contents of docs/soc2/removable-media-exceptions.md (initially empty, mirrors the cloud-ids-exception.md pattern).	Per audit cycle

The expected evidence bundle attached to the Vanta test therefore consists of: (a) this policy document, (b) one screenshot per device for items 1–3, or (c) the MDM compliance report (item 4) in lieu of per-device screenshots once Theora completes the MDM rollout tracked in docs/soc2/risk-register.md.

7. Not-Applicable Alternative

Because Theora's production environment is entirely cloud-resident and there is no organizational use of removable media in the production data path, this control may alternatively be marked Not Applicable with this policy serving as the justification. The vendor and resource inventories in docs/soc2/vendor-list.md and docs/soc2/inventory-of-resources.md support the NA position by demonstrating that no removable-media-bearing systems are in scope. The Engineering Lead and Vanta auditor should agree which posture (applicable-with-evidence vs. NA-with-justification) to use prior to closing the audit.