Security at Kindle Holdings

This page describes the controls we actually run today. Where a control is planned rather than in place, it says so — we would rather lose a deal than answer a security questionnaire dishonestly.

01Infrastructure

Kindle Holdings runs on TBC: cloud provider in TBC: primary region, with Business-plan data residency available in the US or the EU. Production is isolated from development and test at the network and account level, and no production customer data is ever copied into a non-production environment.

Infrastructure is defined as code and changes go through review. There is no manual console access to production in normal operation.

02Encryption

• In transit — TLS 1.2 or higher everywhere, HSTS enabled, modern cipher suites only.
• At rest — AES-256 on databases, object storage and backups.
• Secrets — held in a managed secret store, never in source control, rotated on personnel change.
• Passwords — hashed with a memory-hard function; we never store or log them in plaintext.

03Access control

• Least privilege by default. Access to production requires a documented business reason and is time-bound.
• Multi-factor authentication is mandatory for every employee and contractor.
• Access is reviewed quarterly and revoked within 24 hours of a person leaving.
• Administrative actions are logged to an append-only store that operators cannot edit.
• Customers on Business plans get SAML SSO, SCIM provisioning and their own audit log.

04Secure development

Every change is peer reviewed before merge. Dependencies are scanned continuously and patched on a severity-based clock: critical within 7 days, high within 30. Static analysis and secret scanning run on every pull request. Changes that touch authentication, authorisation or data export get an additional security review.

05Monitoring and response

We centralise application, infrastructure and audit logs, and alert on authentication anomalies, privilege changes and unusual export volume. We maintain a written incident response plan with named roles and a severity ladder, and exercise it at least annually. Customers affected by a security incident are notified without undue delay and, for personal data breaches, within 48 hours as our DPA commits.

06Backups and resilience

Databases are backed up continuously with point-in-time recovery, and backups are encrypted and restore-tested. Our current targets are a recovery point objective of 5 minutes and a recovery time objective of 4 hours. Deleted workspaces stay recoverable for 30 days before permanent erasure.

07Testing and certification

Independent penetration test: TBC: most recent test date and vendor, or remove this line.

Certifications: TBC: SOC 2 / ISO 27001 status — do not claim a report that does not exist.

Do not fill this in optimistically. A claimed SOC 2 report is the first thing an enterprise buyer asks to see, and the first thing that kills the deal when it does not exist. Until a report exists, say so plainly — and make sure the pricing FAQ on the home page says the same thing.

08Sub-processors

The vendors that may process customer data on our behalf are listed in the DPA. We give 30 days' notice before adding one, and customers may object.

09Reporting a vulnerability

Send findings to TBC: security@ email, ideally with a proof of concept and your PGP key if you want an encrypted reply. We acknowledge within two business days and aim to give a remediation timeline within ten.

We will not pursue legal action against researchers who act in good faith, stay within their own test workspace, avoid privacy violations and service degradation, and give us reasonable time to fix an issue before publishing. We do not currently run a paid bounty programme.