Security and Data Handling
Last updated: August 31, 2026
This page answers the questions a security team asks before sending us footage. It describes what Zonic does today, not what we plan to do. Where a control is not in place it says so, and says whether we can put it in place for you under a written agreement.
Shared responsibility
Zonic runs on Google Cloud for storage and processing and on Vercel for the web application. Compliance of the underlying infrastructure — data centres, virtualisation, physical network — is inherited from those providers and evidenced by their own certifications, which they publish and we do not duplicate.
Everything above that line is ours: separation between customers, access control, logging, and the data lifecycle. That is what this page is about, and it is where most of a security questionnaire actually lands.
Separation between customers
Project media is stored in one Google Cloud Storage bucket, with each project under its own unguessable identifier as a key prefix. Separation is enforced by the application's authorisation checks and by path validation that stops a request escaping its own prefix — not by a separate bucket for each customer, and not by storage-level tenancy. If your policy requires a dedicated bucket or customer-managed encryption keys, that is an arrangement we can make; it is not how the standard service is built.
Semantic search is partitioned per project. Each project's scene and script vectors live in their own namespace, and a query that arrives without one is rejected rather than quietly searching everything. Face and speaker groupings are likewise built inside a single project and are never matched across projects.
Database access is authorised in the application layer against project membership. We do not currently rely on database-level row security as a second line of defence, so this is one control deep rather than two.
Encryption, transport, and uploads
Traffic to zonic.tech negotiates TLS 1.3, with TLS 1.2 as the floor, and HTTP Strict Transport Security is enabled with a two-year max-age. Media at rest is encrypted with AES-256 by Google Cloud Storage.
All upload and download access uses short-lived signed URLs rather than public links: ten minutes for an upload or a file download, up to four hours for a video playback session, and one hour for preview segments. Upload URLs are write-only and download URLs read-only. Buckets use uniform bucket-level access, so no object can be made public by an access-control list.
Upload integrity is currently confirmed by transfer status and retried on failure; we do not yet compare an end-to-end checksum on arrival.
Access control and logging
Sign-in is Google OAuth. Zonic never receives or stores a password, which means whatever multi-factor policy your Google Workspace enforces applies to Zonic automatically. Programmatic access uses per-user API keys that can be revoked. SAML or OIDC single sign-on against your own identity provider is not supported today and is an enterprise arrangement.
We keep application and infrastructure logs for operating and debugging the service. A tamper-evident audit trail that you can query yourself, with a contractually defined retention period, is not a self-service feature today.
Our staff can access customer material where support or debugging requires it. A formal break-glass procedure — approval, full trace, and notification to you afterwards — is not part of the standard service and is something we can commit to contractually.
AI providers and model governance
We do not train on your material, and no fine-tuning capability exists in the product. The Privacy Policy sets out what we do instead and what we look at when we do it.
The default pipeline uses local scene detection, Microsoft Azure AI Speech for transcription, Google Gemini for video understanding, and OpenAI for search embeddings; the editing agent is Anthropic Claude served through Google Vertex AI. A project can be configured to use different providers.
Two points a security questionnaire will ask about, answered honestly. We call these providers under their standard commercial terms and API keys; we have not yet obtained written zero-retention attestations from each of them, so a provider may hold material for a limited period to operate and abuse-monitor its own service. And our Gemini usage goes through the Gemini API rather than Vertex AI, so Vertex's data-governance controls do not apply to that path — if a questionnaire assumes they do, the assumption is wrong for us today.
Provider-level zero retention, a named-provider restriction, or routing a specific workload only through providers you have approved are all things we can arrange for a customer. Ask before you upload.
Where processing happens
Project storage and video processing run in Google Cloud's asia-east1 region, which is Taiwan. Our cache and vector search run in the United States.
No Zonic component runs in mainland China, Hong Kong, or Macau, and we use no vendor headquartered there. The single Hong Kong item anywhere in our stack is a Stripe billing entity, which processes payment data and never touches media.
One limit worth stating precisely: inference for the editing agent is not pinned to a single region, so we cannot promise geographic residency for agent prompts and the frames sent with them. Pinning a workload to named regions end to end is an arrangement to agree in writing before you upload.
Backup and recovery
Zonic does not operate an independent backup of project media beyond the durability Google Cloud Storage provides. Object versioning and soft-delete are not enabled, so a deletion takes effect immediately and cannot be undone. We do not publish a recovery point or recovery time objective for the standard service, and we do not run scheduled restore exercises.
The consequence matters more than the detail: if Zonic is to hold the only searchable copy of your footage, the standard service is not the right basis for that. A defined recovery objective, cross-region backup, object versioning, and an annual restore exercise belong in a written service agreement, and we would rather agree one with you than have you assume protection that is not there.
Retention, deletion, and portability
Material is kept until you delete it; nothing expires on its own. Deletion, and the three limits on what it reaches, are set out in the Privacy Policy.
There is no proprietary lock-in. Your original files remain downloadable, project data and metadata are retrievable through the Platform API, and edit decisions export to standard editing project files you can open in your own tools. A single-archive export of an entire project is not a self-service button today; ask and we will produce one.
A deletion deadline after termination, deletion that is evidenced downstream, and a written deletion certificate are contractual arrangements we can make.
Vulnerability management and incidents
We run static analysis, dependency auditing, and web vulnerability scanning against our own code and dependencies, on demand rather than on every commit.
We do not currently commission an annual third-party penetration test, and we do not publish a formal software bill of materials. Both are available where a contract requires them.
If we become aware of a security incident affecting your material, we will tell you and explain what happened. A contractual notification window — seventy-two hours is the usual requirement — is something we can commit to in writing.
Available under a written agreement
Several controls an enterprise questionnaire asks for are not switched on for the standard service, because most projects do not need them and each carries a cost. None of them is exotic, and each is available as a customised arrangement:
- A dedicated storage bucket, or customer-managed encryption keys
- Provider-level zero retention, and restriction to a named set of AI providers
- Deletion evidenced downstream, a deletion deadline after termination, and a written deletion certificate
- A defined recovery point and recovery time objective, cross-region backup, object versioning, and an annual restore exercise
- An availability commitment above the standard service
- A tamper-evident audit log you can query, with an agreed retention period
- A break-glass procedure with notification for any internal access to your material
- Single sign-on against your own identity provider
- A third-party penetration test report and a formal software bill of materials
- A contractual security-incident notification window
- A signed data processing agreement, with advance notice of any change of subprocessor
- Processing pinned to named regions end to end
Contact
Security questionnaires, data processing agreements, and any of the arrangements above: support@zonic.tech. Please start the conversation before you upload material rather than after.