Security

1Encryption

In transit. TLS 1.2 or better on every connection. The iOS application enforces App Transport Security, so it will not fall back to an unencrypted request.

At rest. Customer-managed encryption keys, not Google-managed defaults. A single key ring holds separate keys for the database, object storage, message queues, secrets and cache, each on 90-day automatic rotation.

On your device. The local database is SQLCipher-encrypted with a 256-bit key minted per install and held in the iOS Keychain, so the file is unreadable on a lost device until first unlock. Audio files are protected by iOS Data Protection.

2Access control

Identity is the perimeter. The production database has no public IP address and accepts only encrypted connections. Application services authenticate with dedicated service identities holding no broad project roles.

Every API request resolves the account from the session on the server. A client cannot ask for another account's data by changing an identifier in a request.

Sessions end automatically — after a period of inactivity, and again at an absolute limit regardless of activity.

3Monitoring and logging

Authentication failures, authorisation denials, bulk record reads, bulk deletions, permission changes, decrypt failures and attempts to expose storage publicly each emit a metric that raises an alert. Database connection attempts are logged by the database engine itself, independently of the application.

Audit logs are retained for 400 days in immutable storage.

4Resilience

The production database is backed up daily with 30 backups retained and seven days of transaction logs, allowing recovery to any second within the last week. Recovery is rehearsed rather than assumed: our most recent restore drill recovered the production database to a point 24 hours in the past in 8 minutes 45 seconds, against a four-hour objective. Drills run quarterly.

5Change management

Changes reach production through pull requests on a protected branch. Direct pushes are rejected, force pushes and branch deletion are disabled, and the rules apply to administrators without exception. Every pull request must pass automated checks — application and mobile test suites, a file-hygiene check and a secret scan of the diff — before it can merge.

6Subprocessors

We use a small number of processors to deliver the product. Audio and transcripts are handled by our cloud provider and by speech-recognition and language-model providers. We do not sell data, we do not serve advertising, and we do not permit processors to use your content to train general-purpose models.

Where Scriben is used with protected health information, we enter into Business Associate Agreements with the processors that handle it. A current list of subprocessors is available on request.

7Compliance

Scriben is pursuing SOC 2 (Security) and operates a HIPAA programme as a Business Associate. Our security policies are reviewed and approved at least annually. Reports and questionnaire responses are available to customers and prospects under NDA — write to emma@scriben.ai.

8Reporting a vulnerability

If you believe you have found a security vulnerability, please tell us before disclosing it publicly. Email security@scriben.ai with enough detail to reproduce the issue.

We will acknowledge your report within three business days, keep you updated while we investigate, and credit you when a fix ships if you would like us to. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and data destruction, and give us reasonable time to remediate.

To report a concern anonymously, including one about our own conduct, use our anonymous reporting channel.

9Contact

Security: security@scriben.ai
Everything else: emma@scriben.ai