Home/Product/Security and privacy
What we do to protect recordings, in specifics.
A recording is often the most personal data your users hand you. This page lists how the AddPipe Platform protects it at every hop, what an auditor has checked, and the controls you have over what we collect and keep. Send it to your security reviewer as is.
Every hop a recording takes, and how it's protected there.
Follow one file from the user's browser to playback. There is no unencrypted segment.
Client delivery
HTTPSpipe.js reaches the user's browser over HTTPS from CloudFront or our EU servers.
Recording
WSS · HTTPSMedia streams or uploads to the ingestion server over a secure WebSocket or HTTPS.
Processing
LUKS at restIngestion, processing and database servers use LUKS full-disk encryption. Local copies are deleted after the push.
AddPipe storage
SSE-S3 · SSE-ONEAmazon S3 buckets with S3-managed keys; Scaleway buckets with Object Native Encryption.
Push to your storage
HTTPS · SFTP · FTPSTo your S3 or S3-compatible bucket, Dropbox, Box, SFTP or FTPS, encrypted in transit.
Playback and API
HTTPS · signed webhooksPlayback, download, the dashboard and the REST API are HTTPS only. Webhooks are signed so you can verify the sender.
Compliance
What outside parties have checked.
SOC 2 Type I
An independent auditing firm assessed the platform's controls against the SOC 2 framework and issued a Type I report. It's available to customers and prospects for vendor reviews.
GDPR
AddPipe has been through GDPR compliance work both as a processor of the data we handle for you (recordings, metadata, snapshots) and as a controller of the account data we hold. Whether you're in the EU or processing EU subjects' data from elsewhere, the platform's regions, EU silo, PII controls and lifecycle rules are built to support your obligations. Details and answers on the GDPR page; email us with anything specific.
Product security
Protections built into the recording client, the APIs and the storage integrations.
Encryption in transit
TLS 1.3 and TLS 1.2 with strong ciphers on every public-network connection: client delivery, recording (WSS or HTTPS), push to our storage and yours, playback and download, the dashboard and the REST API. The diagram above walks each hop.
Whitelisted hosts
Restrict the recording client to a list of hosts you specify, so your embed code can't be lifted onto someone else's site and record into your account.
Signed webhooks
Every webhook is signed by the platform. Verify the signature on your end and you know the request and its payload came from AddPipe, not a third party.
HTTPS-only API
The REST API refuses plain HTTP. Credentials and recording data never travel in the clear.
Server-side metadata
Timestamps, IP, user agent and device details are recorded by the platform as the media arrives, so they can't be edited client-side.
Your data controls
Minimising what we collect and how long we keep it is your decision, per environment.
Choose what PII is collected
Full transparency into the data we touch, and a switch for each item: IP address, user agent, device names. Collect none of it if your process doesn't need it.
Do not store
After processing and pushing to your storage, all local copies are permanently deleted from our servers, and nothing is written to AddPipe storage. AddPipe becomes a pass-through processor.
Lifecycle rules
Automatically delete recordings after a period you define, so retention policy is enforced by the platform rather than by remembering.
Region and EU silo
Pin an environment to the EU or US. With the EU silo, ingestion, processing, storage and client delivery all stay on EU infrastructure. How regions work.
Deletion on demand
Delete any recording, or everything in an environment, through the dashboard or the REST API, for data-subject requests and the end of legal holds. Recordings pushed to your own storage are under your control from the moment they land.
Infrastructure security
How the servers that ingest, process and store recordings are run.
Encryption at rest
Database, ingestion and processing servers use LUKS. Complimentary storage uses SSE-S3 on Amazon S3 and SSE-ONE (Scaleway Object Native Encryption) on Scaleway.
System hardening
Unnecessary services disabled, security patches applied, and firewalls that restrict each port and protocol to the specific IP addresses of our own infrastructure.
Continuous backups
Daily database backups stored in two separate secure locations, with the recovery procedure tested regularly rather than assumed.
Monitoring and logging
Continuous monitoring for anomalous activity and logging of all access to our systems, so incidents are detected and answered promptly.
Vulnerability scanning
Regular scans of servers and network for known vulnerabilities and misconfigurations. Critical and high findings are tracked to remediation.
Email authentication
DKIM, SPF and DMARC on our sending domains, so mail from AddPipe can't be spoofed to phish your team.
Organisational security
The people side. A small team means each of these applies to everyone.
Access control
Role-based access, multi-factor authentication, and regular access reviews. Only the people who need production data have it.
Background checks
On all employees and contractors with access to sensitive data.
Security awareness training
Regular training for employees and contractors on current threats and practice.
Endpoint security
Managed devices with disk encryption enabled and endpoint security software enforced.
Development practices
Change management for a platform that ships client updates whenever browsers change.
Every change reviewed, staged, then deployed
- Code review by at least one other developer before any merge
- Changes implemented and tested in a development environment, then a staging environment, before production
- Branch protection rules that prevent direct commits to the main branch
- Non-trivial changes published on the changelog with build slugs; incidents on the status page
Reporting a vulnerability
Responsible disclosure, with rewards
We run a vulnerability disclosure program and pay for valid reports, scaled to severity and impact. If you've found something, write to with the details and steps to reproduce, and give us a reasonable window to fix it before publishing.
Bring this page to your security review.
And if the reviewer wants the audit itself, the SOC 2 Type I report is a message away.