Data Security

1. How we handle personal data safely

Security starts with not holding data we do not need. Before we collect anything, we ask whether the feature truly requires it, how long we need to keep it, and who needs to reach it. The rules we follow every time we collect data are set out in section 7 of our Privacy Policy.

2. Encryption

• In transit. The website, the apps and our APIs only communicate over HTTPS using TLS 1.2 or later.
• At rest. Databases, uploaded files and backups are encrypted at rest (AES-256) by our infrastructure providers.
• On your device. The app keeps your sign-in session in the iOS Keychain or Android Keystore, not in plain storage.

3. Access control

• Least privilege. People and systems get only the access their job requires, and it is removed when no longer needed.
• Multi-factor authentication is required on every administrative account that can reach member data or infrastructure.
• Logged and reviewed. Administrative access to personal data is logged, and access is reviewed regularly.
• Database rules. Row-level security means members can only reach their own private data. The public website can add a waitlist sign-up through a single database function, but cannot read the list.
• Secrets stay out of code. Keys and credentials are held in our hosting providers' encrypted environment settings, never in the source code.

4. Account protection

• Passwords are stored only as salted hashes using a strong, deliberately slow algorithm. Nobody at CueBridge can see your password.
• You can sign in with Apple or Google instead of a password.
• Sign-in attempts are rate-limited to slow down password-guessing attacks, and we alert you to important account changes.

5. Building securely

• Everything that comes in from a form or the app is validated on the server, not just in the browser.
• Database access goes through parameterised queries and database functions, which protects against injection attacks.
• Changes are reviewed before release, and dependencies are kept up to date and monitored for known vulnerabilities.
• Development and testing use separate environments and never real member data.

6. Infrastructure and providers

We build on established providers — including Supabase for database, storage and authentication, and Netlify for hosting and waitlist form storage — that maintain independent security certifications such as SOC 2. We review a provider's security before using it and sign a data processing agreement that limits how it can use member data. Payments in the apps are processed by Apple and Google, so card details never reach our systems.

7. Keeping data only as long as needed

We keep personal data only for the periods set out in our Privacy Policy, then delete it or make it anonymous. Deleted data leaves our rolling backups within 35 days.

8. If something goes wrong

We have a plan for security incidents: contain the problem, investigate, fix the cause and learn from it. If a breach affects your personal data:

• we notify the relevant data protection authority within 72 hours of becoming aware of it, where the law requires;
• we tell affected members without undue delay — what happened, what data was involved, what we are doing about it, and what you can do to protect yourself; and
• we record every incident, even those that do not need to be reported.

9. What you can do

• Use a strong password you do not use anywhere else, or sign in with Apple or Google.
• Keep your phone, apps and browser up to date.
• Be suspicious of messages asking for your password, codes or payment outside CueBridge. We will never ask for your password.
• Tell us at support@cuebridge.io straight away if you think someone else has access to your account.

10. Reporting a vulnerability

If you believe you have found a security vulnerability in CueBridge, please email security@cuebridge.io with a description, the steps to reproduce it and its likely impact. We acknowledge reports within 3 business days and keep you updated as we fix them.

We will not take legal action against research done in good faith that stays within these rules:

• only test against your own accounts, and never access, change or delete other members' data;
• do not run denial-of-service, spam or social engineering attacks, or test physical security;
• give us reasonable time to fix the problem before disclosing it publicly.

No system is completely secure, and we cannot guarantee that unauthorised access will never happen. What we can promise is that we take protecting your data seriously and will keep improving how we do it.