Security

Kimie handles resumes and other candidate PII on behalf of recruiting teams, so we treat that data as sensitive by default. This page lays out what we actually do today to protect it, and is honest about the parts of our security program that are still in progress rather than complete. See our Privacy Policy for what data we collect and who we share it with.

All traffic to this website and the Kimie product app is encrypted in transit (TLS), served through Vercel. Data persisted in the product app — recruiter accounts, candidate records, and resume files — is stored in Supabase, which encrypts data at rest by default. See Privacy Policy §8 for the full list of providers we use and what each one sees.

Internal access to candidate and recruiter data is restricted by role: only team members whose work requires it can reach production data, on a need-to-know basis, and that access is logged. Most of our team — anyone outside the roles that need it, including sales or marketing — has no route to candidate data at all.

Recruiter accounts don’t use passwords. Kimie uses Supabase’s email-based authentication, and access is invite-only: the only way to get an account is to receive an invitation email, which can only be sent by a system admin or a recruiter who’s been granted administration rights to invite others. There’s no self-serve signup and no password to guess, phish, or reuse.

We haven’t completed an independent penetration test yet. One is planned ahead of general availability, and we’ll update this page with the outcome once it’s done. We don’t want to imply a level of independent assurance we don’t yet have.

The providers we use to run Kimie, and what each one sees, are named in Privacy Policy §8. If we add a new subprocessor that will process your data, we’ll update that table and the “last updated” date on the Privacy Policy, and make a reasonable effort to email the primary contact on your account with advance notice before the change takes effect where the change is material.

Our commitment to assess and notify affected customers and individuals in the event of a data breach — including one originating at a subprocessor — is set out in Privacy Policy §11. Responsibility for running that process sits with us even when an incident originates at a provider we use rather than in our own systems.

If you’re a security researcher and believe you’ve found a vulnerability affecting Kimie, email hello@kimie.com.au with details and steps to reproduce. We don’t have a dedicated security inbox or a paid bug bounty program yet, but we commit to:

• Acknowledging your report within 5 business days.
• Not pursuing legal action against good-faith security research conducted under this policy — testing limited to your own account or data you’re authorised to access, without accessing, modifying, or exfiltrating other customers’ or candidates’ data, and without disrupting the service.
• Working with you on coordinated disclosure — we ask that you not disclose the issue publicly until we’ve had a reasonable opportunity to fix it, typically within 90 days.

We’ll update this page as our security posture changes — in particular once our first penetration test is complete. We’ll update the “last updated” date above whenever we do.

Questions about this page, or anything covered by it, can go to hello@kimie.com.au. See also our Privacy Policy and Terms of Service.