Is Recruitly secure?
A straight answer to a question that usually gets a brochure, written so you can hand it to a client who is asking about their candidates' data.
Ask AI about this
Security questions used to arrive once a year from one enterprise client. Now they arrive in supplier questionnaires, in procurement portals, and increasingly from candidates themselves. Agencies get asked and have to go and ask their CRM vendor, who sends back a page of reassurance with no facts on it.
So this is our version with facts on it, written to be useful to the person filling in the questionnaire rather than to a marketing team.
Who can see your data inside your own account
Access is controlled by role, and roles are yours to configure rather than ours. What a consultant can see, what a manager can see, what a director can see, and which records are restricted to a team, are all decisions you make in your own settings.
Two things that are worth checking in any CRM and are easy to forget. Whether a consultant who leaves keeps access until someone remembers to remove it, and whether an export can be taken by anybody or only by named people. Both are settings, both default in ways that suit convenience, and both are how most agency data actually walks out of a building. It is very rarely an attacker.
Who can see your data inside our company
Support cannot browse your database at will. Access for support purposes is deliberate rather than ambient, and engineers do not work against live customer data as a matter of routine.
The honest general point, which applies to every vendor you will ever use, is that some people at the company can reach customer data because otherwise nobody could ever fix anything. The questions worth asking are who, under what circumstances, and whether it leaves a record. Any vendor claiming nobody at their company can ever see your data is describing a product where nothing can be supported.
Where the data physically lives
Your records sit in managed databases in a defined region, with backups held separately, and your files and recordings sit in object storage rather than on somebody's server.
If your clients have a requirement about which region their data sits in, ask us before you sign rather than afterwards. Region is one of the few things that is genuinely difficult to change later, and the answer is worth having in writing.
What the AI does with candidate data
This is the part of a security questionnaire that has changed most in the last two years and the part vendors are vaguest about.
Three things you should establish about any recruitment CRM with AI in it. Whether your data is used to train anybody's model. Which providers receive it. And whether the vendor can actually list the places in their product where a model sees it.
Our answers: we do not hand your data over for model training. Every AI call goes through a layer we control rather than out to a provider directly, which is what makes the third answer possible. And we do not keep the list of AI touchpoints by hand, because a hand-kept list is stale the week after it is written. A program reads all of our code and refuses to finish if it finds anything touching AI it cannot account for.
Sign-in and accounts
Sign-in is handled by a dedicated authentication service rather than something improvised inside the application, sessions expire, and access can be revoked centrally when somebody leaves.
The single highest-value thing you can do for your own security has nothing to do with us. Make sure that when someone leaves your agency, their access here is removed the same day, along with their access to email, the phone system and anything holding candidate data. Almost every real incident in recruitment starts with an account nobody closed.
Keeping the software itself safe
Two parts to this. Our own code is reviewed before it goes out, and nothing reaches customers without passing the automated checks we have built to catch the mistakes we have made before.
The other part is keeping up with the platforms underneath us. Browsers, operating systems and application frameworks publish security guidance and change it regularly. We work through those checklists and we have an automatic weekly check that tells us when the versions we build on have fallen behind. That second part matters more than it sounds, because falling behind is not a decision anybody makes. It happens by nobody noticing for a year.
What to ask any recruitment CRM vendor
| Question | What you are listening for |
|---|---|
| Which region does our data sit in? | A named region, not a reassurance |
| Is our data used to train AI models? | A plain no, or a clear description of what is |
| Can you list where AI touches our data? | Whether they can answer at all |
| Who at your company can access our records, and is it logged? | Named circumstances rather than never |
| How do we remove a leaver's access? | One place, same day |
| How quickly do you update the platforms you build on? | Whether anything checks automatically |
Take those six to every vendor you are considering. They are the questions your own clients are going to ask you, and the point of asking them early is that you can answer with something more useful than a brochure.
If you have a client questionnaire in front of you now and something on it is not covered here, send it to us and we will answer it directly rather than sending you a page of reassurance.
Lokesh is Founder and Head of Engineering at Recruitly.
