Security

ClientFlow OS is a multi-tenant web application. Every agency’s data is tagged with its own account and every query is scoped to it. Traffic is encrypted in transit, passwords are hashed, backups are encrypted before they leave the server, and every change that affects another person is written to an audit log the agency’s admins can read. We do not hold certifications yet; this page says what we do instead.

• Hosting — a dedicated server managed by Trickle Up, running the application and its MySQL database. Server access is limited to the Trickle Up staff who run it.
• Region — United Kingdom. Sub-processors below may process data elsewhere under UK adequacy regulations or the International Data Transfer Agreement.
• Tenant isolation — clients, projects, tasks, messages, files and settings carry an account id; the data layer filters on it. There is no query path that returns another agency’s rows.

• In transit — HTTPS only, with plain HTTP redirected. Certificates are renewed before they expire.
• Passwords — hashed with bcrypt. Client portal passwords are hashed the same way. Nobody at Trickle Up can see a password.
• Backups — encrypted with AES-256-GCM using a passphrase that is not stored with the backup, before any copy leaves the server.
• API keys — only a SHA-256 fingerprint is stored; the key is shown once at creation.

• Sessions — signed tokens that last a fortnight and refresh with use. “Sign out of every device” invalidates every token an account has issued.
• Email verification — a new address is confirmed before password resets and invitations rely on it.
• Rate limiting — sign-in, sign-up, password reset, contact and the API are limited per address, per account or per key, so a guessing script gets nowhere.
• Roles and permissions — each agency sets which departments can see which modules. Pod managers see their own pod’s clients and projects, not the agency’s.
• Audit log — invitations, role changes, pod moves, permission changes, exports, erasures and key changes are recorded with who, what and when, and kept for 365 days.

• A full database backup is taken daily and kept for 14 days. The backup job checks the dump completed rather than trusting its size.
• A full restore has been tested end to end, not assumed. The recovery target is the previous night’s backup, restored within four working hours of a decision to restore.
• Application errors are captured with the stack and the page, without the request body, and kept for 30 days.

• Anyone can download everything the workspace holds about them, or erase their personal details, from Settings → Your data. Erasure anonymises rather than deletes shared records, and says so.
• Agency admins can export clients, projects and tasks through the read-only data API at any time — there is no lock-in by omission.
• Deleting a workspace removes its data. Backups age out within 14 days.

Suppliers that handle data on our behalf, and only for the purpose given:

Data sent to AI suppliers is used only to generate the response; under their API terms it is not used to train models. AI output is shown to a person at the agency for review before it reaches a client.

Being straight about this saves everyone a questionnaire round-trip:

• No SOC 2 or ISO 27001 — we will pursue certification when a customer’s contract requires it. Until then this page, our privacy policy and a call with the person who built it are what we can offer.
• No independent penetration test yet — dependencies are scanned automatically and patched; a third-party test is planned before the first Enterprise contract.
• No SSO / SAML — sign-in is email and password, or Google. Available when a customer needs it.
• One server, one region — see the service levels page for what that means in practice.

If you find a security problem, email security@trickleup.co.uk with what you found and how to reproduce it. We will acknowledge within two working days, keep you informed, and credit you here if you would like — we do not pay bounties yet, and we will not take action against anyone who reports in good faith, tests only against their own account, and gives us reasonable time to fix it before publishing. This is also published at /.well-known/security.txt.