A SOC 2 badge on a vendor's website tells you they passed an audit at some point. It does not tell you whether single sign-on is actually enforced on the tenant you are about to buy, whether candidate data is encrypted with keys the vendor can rotate, or how fast anyone would tell you if that data leaked.
Most enterprise ATS security reviews stop at the badge. Procurement confirms the certification exists, the security questionnaire comes back with a column of green checkmarks, and the deal moves on. The real review is what happens when you stop accepting the checkmarks and ask the vendor to prove them live, on your tenant, before go-live.
That gap between an assurance and a demonstration is where most recruitment-software risk hides. An applicant tracking system holds some of the most sensitive data your company touches: names, contact details, salary expectations, background-check results, right-to-work documents, and in many cases protected-category information.
The 7 checks below are the ones worth running while you still have the vendor's full attention and your leverage is highest, and for each one the point is the same: ask for the evidence, not the answer.
The checks below move in a deliberate order, from the identity perimeter inward to the data itself and then out to how the vendor behaves when something breaks. Each one has a version that lives in a questionnaire and a version you can watch happen on a real tenant. The second version is the one worth your time, because it is the only one an attacker or an auditor will ever care about.
Almost every enterprise ATS advertises single sign-on. Far fewer can show you it is enforced rather than merely available. The failure mode is a tenant where SAML is configured but local password logins still work as a fallback, so one leaked credential walks straight past your identity provider. MFA carries the same trap when it is offered as an option and never made mandatory.
Ask the vendor to prove it live. On a real tenant with SSO switched on, have them attempt a non-SSO login for a standard user, an admin, and a service account, and confirm all three are rejected. Then have them walk you through how a departing employee gets de-provisioned through your IdP, and request the SAML configuration guide so your team can verify group-based provisioning before anyone signs.
Every vendor says data is encrypted. That word covers everything from disciplined key management to a checkbox someone ticked, so data encryption in recruitment software only means something once you know the specifics. What you are confirming is TLS in transit, AES-256 or equivalent at rest, and key handling that limits who inside the vendor can ever decrypt a candidate record.
The documents that turn the claim into something verifiable are short and specific:
An ATS is rarely one company. It is that vendor plus every sub-processor they route data through for hosting, email delivery, resume parsing, AI features, and analytics, and each one is a place your candidate data lives. Residency compounds the exposure, because a system processing your EU applicant data in another region can put you offside on commitments you made to your own regulators.
Ask for the current sub-processor list with each party's function and location, the residency options for the regions you hire in, and the terms that govern how you get notified when a new sub-processor is added.
A vendor that treats a routine sub-processor question as sensitive is telling you where the gaps are.
Every ATS has a permissions page describing roles. That page is a description of intent. The control is whether the system actually stops people from seeing what they should not, and whether it records the attempt. Documentation and enforcement are different things, and only one of them holds up in an investigation.
Have the vendor set up roles that mirror your structure, then try to break them in front of you:
The question is not whether the vendor has an incident response plan, because everyone claims one. The question is what they are contractually obligated to do for you when something goes wrong, and how quickly. A plan that lives in their internal wiki is worth nothing to you if the contract does not commit them to a notification window and to supporting your own regulatory obligations.
Read the contract language rather than the sales deck. Look for a notification SLA stated in hours, a named point of contact, an explicit obligation to preserve evidence and support forensics, and clarity on who communicates with affected candidates. Then ask for their most recent tabletop exercise or post-incident review, since that is what shows the plan has been tested instead of merely filed.
A vendor that runs a penetration test once and cites it for three years is not really testing. What you want to establish about their ATS penetration testing is cadence, independence, and access: at least annually and after major releases, run by an outside firm, and documented in a report you can read under NDA rather than a one-line attestation.
Three things separate a real program from a checkbox:
At some point a candidate will ask to be forgotten, or a data protection rule will require it, and the ATS needs to genuinely delete the record instead of hiding it from the interface. Many systems soft-delete, leaving the data intact in the database and in backups, which becomes a compliance gap you inherit.
Test it directly. Request deletion of a seeded test record, then confirm it is gone from live systems and from backups within a stated window, and that the vendor issues an erasure confirmation you could hand to an auditor or regulator.
The pattern across all seven checks is the same. An answer in a questionnaire is a claim. A document, a live demonstration, or a report is evidence. Before go-live, ask the vendor to hand over the following, and treat any reluctance as part of the answer:
If a vendor can produce all eight without friction, you are looking at a security program that expects to be examined. If they can only send you a link to their trust page, you have learned something before signing rather than after an incident.
You have just worked through seven things that separate a vendor who passed an audit from one who can prove their controls hold up on your tenant. The uncomfortable part is that running this review well takes time, and most procurement cycles do not budget for it. The easier path is to start with a vendor that has already assembled the evidence and hands it over without you having to pry.
That is the posture RippleHire is built for. The security documentation package brings the artifacts a CISO review actually needs into one place, so the burden of proof sits with us rather than with your team:
Choose RippleHire if you would rather spend your review confirming evidence than chasing it, and never have to relitigate the same seven questions on the next hire, the next region, or the next audit.Request a demo and run your enterprise ATS security checklist against a set of documents instead of a set of assurances.
A SOC 2 report confirms the vendor was audited against a set of controls during a specific window. It does not prove those controls are switched on in the tenant you are buying, or that they still hold today. Treat it as a starting point, then ask to see the controls working live. A badge on a website tells you even less, since it only signals that an audit happened at some point.
Review it at least once a year, and again whenever something material changes. New sub-processors, a move to a different region, a major product release, or a contract renewal are all good triggers. Security is not a one-time gate at purchase. Ask the vendor to notify you when their sub-processor list or certifications change, so your review keeps pace with how the platform actually evolves over time.
Bring in more than procurement. Your security team owns the technical review, legal or your data protection officer covers contract and privacy terms, IT handles identity and integrations, and talent acquisition confirms the workflows people will use day to day. Giving each group a clear part of the review early prevents a last-minute scramble before go-live and stops any single team from signing off on risks it does not fully understand.
It depends on where your candidates live and where their data is processed. Indian hiring falls under the DPDP Act, European applicants are covered by GDPR, and other regions carry their own rules. Because an ATS often stores and moves data across borders, more than one law can apply at the same time. Map the regions you hire in first, then confirm the vendor can meet each obligation for that data.
Security is about protecting candidate data from unauthorized access, through controls like encryption, access rules, and monitoring. Privacy is about how that data is collected, used, shared, and deleted, and whether you have a lawful basis for each step. A platform can be technically secure and still mishandle privacy. A strong review covers both, since regulators and candidates care about how information is used, not only whether it was breached.