AI safety, security and trust at CaptionHub

Yes. For our Enterprise customers, CaptionHub can be deployed in a variety of ways. Please contact us for more details.

For a cloud install, CaptionHub hosts our applications and your data with Amazon Web Services (AWS). Physical and environmental security of the data centres is provided by AWS and covered by their SOC, ISO and PCI attestations.

It depends on your install. For our multi-tenant customers, it does. CaptionHub is extremely well tested to ensure that users don't see each other's data, but if you require absolute separation, then we'd recommend you opt for our Single Tenant or On Premise installation options.

Customer data is hosted in the EU: our primary region is AWS eu-west-1 (Ireland), with a disaster-recovery environment in eu-central-1 (Frankfurt).

CaptionHub is certified to ISO/IEC 27001:2022 and holds a SOC 2 Type II report covering the Security Trust Services Criteria. Our information security management system is reviewed through an internal and external audit programme and a system of continual improvement.

We ensure compliance with GDPR and other cross-border regulations when transferring data via EU Standard Contractual Clauses (SCCs) plus the UK Addendum, and the UK's International Data Transfer Agreement (IDTA) where appropriate.

A Security Working Group oversees information risk and security management, with clearly assigned roles: a Chief Information Security Officer responsible for security operations, a Chief Compliance Officer responsible for certifications and conformity, and board-level accountability for information risk held by our CEO as Senior Information Risk Owner. Our Information Security Policy and supporting policies are reviewed at least annually and on significant change.

Yes. All traffic is encrypted in transit with TLS 1.2 or higher, using forward-secrecy cipher policies at our load balancers and CDN.

Yes. All production data stores are encrypted at rest under AWS KMS. Databases and caches use customer-managed keys that rotate automatically each year. File systems use AWS-managed keys, and object storage uses S3 server-side encryption (AES-256). Key lifecycle management is delegated to AWS KMS, so keys are generated and held in hardware-backed key management and never handled manually.

Application secrets are held in AWS Secrets Manager. Credentials for your third-party integrations are encrypted with AES-256 in the application, in addition to database encryption at rest. User passwords are never stored by CaptionHub; they are held by Auth0 as salted bcrypt hashes.

We use Auth0 to manage authentication, which enables multi-factor authentication, password strength management, and so on. For SSO, we use WorkOS. Custom integration with your own authentication schemes is available for our on-premise customers.

Via Auth0, CaptionHub protects and notifies users if and when their credentials are leaked by a data breach of a third party. CaptionHub prevents access until the user has reset their password.

None. By default, a new user for CaptionHub has no access – permission needs to be explicit, and given for each and every project.

By default a user can't see anything in CaptionHub, they have to be manually given access to a project before they can view it. We track user login times and IP address, and we log various forms of activity: handover, download, assignment, etc.

Access to data is limited to a small set of CaptionHub engineering roles under least privilege, with quarterly access reviews. From time to time CaptionHub engages third-party developers. They are contractually bound by confidentiality, work through the same code-review pipeline and have no access to production.

We operate least privilege: employees receive only the access their role requires. Access to production and customer data is restricted to a small set of engineering roles, and front-line support staff have no customer-data access unless a customer explicitly grants it. Access is reviewed quarterly.

Enterprise customers can use IP allow-listing, enforced multi-factor authentication, SSO or custom authentication, and watermarking of encoded media.

Expiring URLs mean that it's difficult to download linked media, even if access is granted, and the logged in user's email address is superimposed over video, making screen captures traceable.

Detectify scans our systems every week using the latest attack vectors. We carry out penetration testing and code review at least annually, and after any major architectural change. Every container image is scanned before deployment. Our security control framework is reviewed annually through the ISO 27001 audit programme.

All software reaches production through our peer-reviewed CI/CD pipeline. Container images are immutable, scanned with Trivy and AWS Inspector before deployment, and no additional software is installed at runtime. Amazon GuardDuty provides continuous threat detection across our AWS accounts, with CloudTrail and CloudWatch providing the audit and monitoring trail.

Our workloads run mostly as unprivileged containers on AWS Fargate, where AWS provisions, hardens, patches and isolates the underlying hosts. The few workloads on EC2 run on hardened images (CIS and DISA STIG) that are replaced rather than patched in place, with no inbound SSH. Detection is cloud-native rather than agent-based, through Amazon GuardDuty. All staff devices are company-managed through MDM, with Bitdefender GravityZone endpoint protection, full-disk encryption and automatic OS updates.

Yes. All requests go through a Web Application Firewall to filter traffic from known malicious IPs or with patterns that look like common attacks.

Rules for software and system development cover system design, development environments, secure testing and development principles. All code is peer-reviewed through pull requests before deployment, with security analysis an explicit part of review. Static analysis tests every change for security vulnerabilities, and we manage dependency updates continuously, prioritising security patches.

Yes. Development, staging and production environments are separated in distinct AWS accounts.

No SSH or password access to running containers is possible. Where a developer needs to connect, this is done through AWS Systems Manager under least-privilege IAM, and is logged. Developers hold no long-lived AWS keys: they sign in through single sign-on with enforced multi-factor authentication and receive temporary credentials.

Yes. Every hire goes through employment-reference checks before joining and identity and right-to-work verification at onboarding. Enhanced checks, such as criminal-record checks, apply to roles with elevated access. All staff complete a 3-month probation period.

All employees complete security-awareness training on joining and on an ongoing basis, including simulated phishing.

Contractors and third parties are bound by contractual confidentiality obligations or an NDA before they are given access. Core security policies must be read and acknowledged before access to any information system is granted.

We operate a zero-trust model rather than a VPN. All staff use company-managed devices enrolled in MDM, and multi-factor authentication is required on every system that supports it, with single sign-on wherever available. We maintain clear desk and clear screen policies with appropriate training.

When someone leaves, access to every system is revoked on or before their last day through a documented checklist, with evidence captured for each system. Personal devices are not used for company work.

Databases have continuous point-in-time recovery over a 35-day window, with daily backup copies replicated to a segregated AWS account with tightly restricted access, so backups survive even the compromise of the production account. Video media is stored on Amazon S3 (99.999999999% durability) and is not separately backed up. Caption and work data is fully restorable from database backups.

No. CaptionHub runs in a high-availability pattern within our primary region: multi-availability-zone databases with automatic failover, and infrastructure-as-code to scale services. For a full regional failure we fail over to our disaster-recovery environment in Frankfurt, with a committed recovery time of 8 hours and a worst-case data loss of 24 hours.

Yes. We maintain a business continuity and disaster recovery policy and plan. We rehearse disaster recovery annually and test the business continuity plan annually, and review the plan after each test.

CaptionHub runs a documented incident-response process on a dedicated incident-management platform, with defined severity levels, an on-call escalation path and a public status page. Automated alerting routes to the team continuously. We have formal breach-notification procedures, including notifying the regulator within 72 hours where required, and every incident concludes with a documented post-incident review.

Every supplier is recorded in our supplier register with a criticality and data-access rating, risk-assessed on onboarding and verified annually. For critical vendors this includes reviewing their SOC 2 and ISO attestations. Contracts include security and data-protection clauses.

Some sub-processors, such as our hosting provider, process data as a core part of delivering the service; they are all listed in our sub-processor register. Optional third-party AI services, such as automatic transcription and machine translation, are used only once you enable them for your team. We hold data-processing agreements with all our processors.

Disposal is formal: managed remote wipe for devices, secure erasure for logical data, and certified destruction for physical media.

Captions are served via a publicly visible URL containing a unique, hard to guess identifier for the stream. This identifier can be rotated on request.

Yes. Timbra projects can be configured to only allow authorised access. In this mode, all public endpoints are disabled, and access to caption output is only possible via the API using valid API credentials.

Yes. Timbra can be evaluated in private mode, where no data is publicly available.

Customers can choose SRT, which has built-in AES encryption, or RTMP, which is unencrypted but secured with an unguessable stream key.

All transcription and caption data is kept within the CaptionHub system. Captions are no longer available for archived and deleted projects. For transcription, customers can opt to use a private install of our transcription engine.