Our approach#
Expanding Ranks is a connector to systems you already own: your email, your calendar, your meeting platform, your phone system. We are not trying to become your system of record for those tools. We store what you send us: candidate records, résumés, activity history, and, where you choose to enable it, transcripts of calls and interviews.
We never store the recordings themselves. The audio stays in your own meeting platform or phone system, on whatever schedule your own administrator set there. When you play a recording back inside Expanding Ranks, we check that you are allowed to see that record, log the access, fetch the file from your provider at that moment using your own connection, and stream it to you. The credential doing the fetching never reaches your browser, which is why we built a proxy instead of handing out a direct link. The recording's bytes exist on our side only for the length of that one request, in memory, and are never written to a disk we control.
How your data is protected#
Expanding Ranks is a multi-tenant platform: every customer's data lives in a shared system, kept apart by design rather than by convention.
- Every customer's records are isolated at the database level, not only by application code. Database-enforced access policies restrict every query to the requesting customer's own data, so that a bug in a single line of application code cannot, by itself, expose one customer's records to another.
- Within a customer's account, a second layer of the same kind of database-enforced restriction separates one team or agent's records from another's, matching how your organization actually works.
- Relationships between records are constrained so that one customer's data cannot be linked to another customer's records, even by mistake.
- Files such as résumés and transcripts are stored with a unique, customer-specific path from the moment they are created. There is no recording path, because there is no stored recording.
When you connect your email, calendar, meeting, or phone system to Expanding Ranks, we store the resulting access credentials in a per-customer, isolated credential store, separate from your other data. We use those credentials only to perform the actions you have authorized, such as sending a message from your own mailbox or logging a call from your own phone line. We do not use your connected accounts to read or send anything you have not asked the Service to do.
Candidate data you ask us to delete is removed from active systems, and backup copies age out on a defined schedule. Where a legal retention obligation applies to certain records, we retain what the law requires, and delete the rest. Transcripts are kept for 90 days from the day we receive them, on their own clock.
Because we never hold a recording, there is nothing on our side for a retention rule or a legal hold to reach. A hold placed with us covers our own records, including the transcript, and has no reach into your provider's account or its deletion schedule. If you need recordings to last longer, that is a setting and a plan with the provider that made the recording.
Data is encrypted in transit and at rest using our cloud infrastructure provider's standard encryption capabilities.
Access control#
Sign-in is handled through a managed identity service rather than a homegrown password system. Access within Expanding Ranks is governed by roles and explicit grants: a user sees and acts on only the records their role and grants permit.
Actions that affect access, ownership, or configuration, such as granting someone access to a book of records, changing a role, or a support engineer opening a customer's account to help with an issue, are written to an append-only audit log. That log is built so it cannot be edited or deleted through the application, not even by us, and any privileged access we take (for example, during a support session) is itself recorded and, for actions inside your account, visible to you.
We are direct about the limit of this control: someone holding direct production database credentials sits outside any protection the application itself can enforce. No vendor can honestly promise otherwise. What we can promise, and what we have built, is that ordinary application access cannot bypass these logs, and that privileged access leaves a record.
Reporting a security issue#
If you believe you have found a security vulnerability in Expanding Ranks, we want to hear about it.
Email us: the contact form on our Support page
Please include:
- A description of the vulnerability and its potential impact
- Step-by-step instructions to reproduce it
- Any proof-of-concept code, screenshots, or logs that would help us confirm and fix it
- Your contact information, so we can follow up with questions
What you can expect from us:
- We will acknowledge a good-faith report within [PLACEHOLDER: target acknowledgment time, e.g. 3 business days].
- We will give you an initial assessment of severity and next steps within [PLACEHOLDER: target initial assessment time, e.g. 10 business days].
- We will keep you informed as we investigate and fix confirmed issues, and we will let you know once a fix has shipped.
- We do not currently operate a paid bug bounty program. We are glad to publicly credit researchers who report responsibly, if they would like that.
What we ask of researchers:
- Give us a reasonable opportunity to investigate and fix an issue before disclosing it publicly.
- Test only against your own account. Do not access, modify, or download another customer's data.
- Do not run denial-of-service testing, spam our users, or use social engineering against our staff or customers.
- Do not use a vulnerability beyond what is necessary to demonstrate it. Stop and report as soon as you have confirmed impact.
- If you find candidate or customer data you were not expecting to see, stop immediately, do not copy or retain it, and tell us.
We will not pursue legal action against researchers who make a good-faith effort to follow these guidelines, report through the channel above, and avoid privacy violations, data destruction, or service disruption.
The acknowledgment and initial-assessment timelines above are not yet decided.
Incident response#
Final text drafted separately and not yet placed here. Needs a one page process, dated, naming who is notified, in what order, within what window, and how customers are told. This does not exist yet; see docs/paperwork/BLOCKERS.md item B11.
Infrastructure and sub-processors#
Final text drafted separately and not yet placed here. Must match the privacy policy's sharing and sub-processors section exactly. Amazon Web Services, United States regions, is confirmed. Other vendors are not yet confirmed.
Where we are today#
Expanding Ranks is a pre-launch product, currently in use with a small number of design partners as we prepare for general availability. The practices on this page describe how the platform is architected and how we operate it. We do not hold SOC 2, ISO 27001, or any other third-party security certification, and no independent penetration test of Expanding Ranks has been completed as of the date of this statement. We are not going to claim otherwise to make this page read better. As we move toward general availability, we expect to pursue formal third-party security assessment, and we will update this page when we do.
Contact us#
Security reports: the contact form on our Support page. Everything else: see Support.