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, and so you know what to ask every other vendor on your list.
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, in PSL renewals, and increasingly from candidates themselves. The agency gets asked, has to go and ask its CRM vendor, and gets back a page of reassurance with no facts on it, which is useless because the client wanted facts.
So this is our version with facts on it, written for the person filling in the questionnaire rather than for a marketing team. Where something is a general truth about all software rather than a claim about us, I have said so, because a vendor who pretends otherwise is the one you should worry about.
Who can see your data inside your own account
Access is controlled by role, and the roles are yours to configure rather than ours. What a consultant sees, what a manager sees, what a director sees, and which records are restricted to a team are all decisions you make in your own settings.
Two things worth checking in any CRM, ours included, because both default in the direction of convenience and both are how agency data actually leaves a building.
Whether a leaver keeps access until somebody remembers to remove it. This is the single highest-value thing you can fix, and it has nothing to do with which vendor you chose. Almost every real incident in recruitment starts with an account nobody closed, not with an attacker. The person who left on Friday still has a session on Monday, still has the mobile app, and still has every candidate they ever worked with.
Whether anybody can take an export, or only named people. A full candidate export is your entire asset in one file. Decide deliberately who can produce one, then check the setting rather than assuming.
Neither of those is a product feature we are selling you. They are the two settings I would check on any system on the day you go live.
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 including us: some people at the company can reach customer data, because otherwise nobody could ever fix anything. A vendor claiming that literally nobody at their company can ever see your records is describing either a product where nothing can be supported, or a marketing sentence.
So the questions worth asking are narrower and more answerable. Who can. Under what circumstances. Whether it leaves a record. And whether the people who can are a small named group or everybody with a login. Ask those four of us and of everyone else, and compare the confidence of the answers.
Where the data physically lives
Your records sit in managed databases in a defined region, backups are held separately from the live system, 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, and increasingly public sector and financial services clients do, 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 at the point where you still have a choice.
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 most 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. Ours is not.
Which providers receive it. Every AI call in our product goes through a layer we control rather than straight out to a provider, and the providers are named rather than described as leading AI technology.
Whether the vendor can actually list the places a model sees your data. This is the one that separates real answers from confident ones. We do not keep that list by hand, because a hand-kept list goes stale the week after it is written and a stale list is worse than none: people believe it. A program reads every line of code we have, across this product and the other systems we run, and refuses to finish if it finds anything touching AI that it cannot account for. When we first pointed it at our own code it found more than forty places the hand-written list had missed.
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 practical advice here is the same as above and worth repeating because it is the thing that actually goes wrong. When somebody leaves your agency, their access should be removed the same day, here and in email, the phone system, and anything else holding candidate data. Put it in the leaver checklist next to collecting the laptop. It is more important than the laptop.
Keeping the software itself safe
Two parts, and the second is the one people underestimate.
Our own code is reviewed before it goes out, and nothing reaches customers without passing the automated checks we have built to catch the specific mistakes we have made before. Those checks live in the build rather than in a document, because a rule that must never break belongs somewhere that can actually stop a release.
The second part is keeping up with the platforms underneath us. Browsers, operating systems and application frameworks publish security guidance and change it regularly, and the danger is not that a team decides to ignore it. The danger is that nobody notices for a year. So we work through those checklists deliberately, and we have an automatic weekly check that tells us when the versions we build on have fallen behind. Falling behind is not a decision anybody makes; it is what happens by default, which is why it needs a machine watching rather than a good intention.
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, and how it is kept current |
| Who at your company can access our records, and is it logged? | Named circumstances rather than "nobody" |
| How do we remove a leaver's access? | One place, same day |
| Who can take a full export? | A setting you control, not everyone by default |
| How quickly do you update the platforms you build on? | Whether anything checks automatically |
Take those seven to every vendor you are considering, including us. They are the questions your own clients will eventually 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 over and we will answer it directly rather than sending you a page of reassurance. That is a lower bar than it should be, and it is where most of this industry currently sits.
Lokesh is Founder and Head of Engineering at Recruitly.
