Skip to main content

Security & Compliance FAQ (SOC 2, ISO 27001, Data Handling)

P
Written by Peace Aisosa

Common security and compliance questions from vendor and procurement reviews, answered below.

Do you hold SOC 2 or ISO 27001 certification?

Shotstack does not currently hold ISO 27001 or SOC 2 certification directly. Our infrastructure runs on AWS, and we rely on AWS's own ISO 27001 and SOC 2 Type II certifications for the underlying infrastructure layer (see our Data Processing Addendum, Annex 2).

We already operate to SOC 2-aligned security policies internally, and formal SOC 2 certification is on our near-term roadmap.

Do you use customer-submitted video or content to train AI/ML models?

No. Customer-submitted video and content is never used to train or fine-tune any ML model. Our Terms permit analysing Assets and API call data "for product development purposes" (clause 2.7), but that's limited to things like QA and aggregate usage analytics — in practice, diagnosing problems with the service itself, such as examining a file when a render fails because of its codec. It is not used to build datasets or train models.

How long is my data retained, and can I request deletion?

  • Source media referenced by URL (passed directly in your render request rather than uploaded via the Ingest API) is fetched for the render and not persisted beyond it. By default we cache fetched files for 24 hours to avoid re-downloading them on subsequent renders — add "cache": false to your timeline object if you need us to hold no copy at all beyond the render itself.

  • Source files uploaded through the Ingest API are handled differently: there is no automatic expiry, and they are retained until you explicitly delete them by calling DELETE /sources/{id}. That call removes the original file and any renditions generated from it, and deletion is immediate rather than queued. If your source media is sensitive, delete each source as soon as its render completes to keep the exposure window short. See "Are files I upload via the Ingest API publicly accessible?" below for more on this.

  • Render payload JSON is retained as part of your render history. It can be deleted on request, and is automatically deleted for accounts inactive for 3+ months.

  • Output files are hosted on the Shotstack CDN by default. On completion, you also get a temporary link to the file valid for 24 hours — that expiry applies to the link, not the file itself. The file stays saved in our storage independently of that link, until you delete it (via the dashboard or API) or opt out of hosting entirely by adding "destinations": [{ "provider": "shotstack", "exclude": true }] to your render request, in which case nothing is persisted on our CDN after your own destination picks it up.

Are files I upload via the Ingest API publicly accessible?

Yes. Uploads to the Ingest API are signed with a public-read ACL, so the file is reachable by anyone who has its URL for as long as the source exists — the same is true in both the production (ingest/v1) and staging environments.

The source id that forms part of the URL is cryptographically random and cannot be guessed or enumerated, so the practical exposure is "anyone with the link", not "anyone who can guess an id".

If this level of exposure isn't acceptable for your content, either delete each source as soon as its render completes (see above), or skip the Ingest API and pass source URLs directly in your render request instead, hosted wherever you like with whatever access controls you need.

What application security practices do you follow?

Per our Data Processing Addendum (Annex 2), our practices include multi-factor authentication for production access, role-based access reviewed annually, encrypted credential storage, immediate access revocation on offboarding, TLS in transit and encryption at rest, and monitoring via AWS CloudTrail/Inspector.

We don't currently publish a separate secure-SDLC summary or run a formal vulnerability disclosure program or bug bounty. Security reports can be sent to [email protected] and are triaged directly.

What is your incident response process?

Our DPA commits to notifying customers without undue delay after becoming aware of a Personal Data Breach affecting their data (clause 4.7), backed by a documented internal incident response procedure with defined escalation paths and post-incident review. We don't currently publish a standalone public incident response document.

Who are your sub-processors? Do any AI/ML vendors process customer content?

Our current sub-processor list is public at shotstack.io/sub-processors. For Customer Personal Data, that's Amazon Web Services (compute, storage, CDN) and Sentry (error monitoring) only. No AI/ML vendor is engaged as a sub-processor.

Have a question not covered here, or need documentation for a vendor review? Reach out to our team and we're happy to help.

Did this answer your question?