What should a modern ATS do in 2026?
These criteria are drawn from public buyer guides and analyses as of May 2026. It is not a vendor ranking and not a "best ATS" list. Use it as a requirements framework for your own selection.
Almost every employer of any size runs on an Applicant Tracking System. 99% of the Fortune 500 use one. That doesn't mean those systems are all good, or that they all do what a recruitment team needs in 2026. Many of the ATSs running in production today were designed in an era when "automation" meant posting a vacancy to five job boards at once. Since then the work has changed, the law has changed, and candidate expectations have changed.
This article is for anyone choosing an ATS, or wondering whether their current system still fits. No brand names, no ranking. What you do get is a clear distinction between what an ATS must do at minimum, what makes it modern in 2026, what the law requires, and how it works with the rest of your recruitment stack. We build the guide around four groups of requirements, close with the mistakes we see most often, and an evaluation framework that takes you from longlist to go-live.
Why ATS choices go wrong so often
First, the uncomfortable number. Of the organisations that replace their ATS within two years, 42% cite "poor workflow fit" as the reason. Not price, not a missing feature. The way the system forced their process didn't fit how they actually worked.
That's almost always a mistake in the selection phase, not in the product. Teams go into the demo with a vague idea ("we want something modern with AI") and get carried away by the polished features the vendor most wants to show. The questions that really matter, whether the system bends to your pipeline or forces you into its own, only surface once the contract is signed and the first recruiter hits a wall.
The remedy is boring but it works. Before the first demo, define what your must-haves, should-haves and could-haves are. A must-have is a requirement you reject a vendor over, however good the rest is. A should-have weighs in but isn't a deal-breaker. A could-have is a nice bonus. If you don't have those three lists on paper before a vendor starts presenting, you let the vendor define your requirements. And then you buy what demos well, not what works well.
The rest of this article gives you the material for those lists. Four groups, each with a table. Not every requirement is a must-have for every agency; that depends on your type, your volume and your compliance context. But you want to decide consciously which category each requirement falls into.
Group 1: the core layer
This is what an ATS simply has to do to earn the name. If something is missing here, you're not buying a modern system but a gap in your process you'll have to close elsewhere. Nothing in this group is special; it's the floor.
| Requirement | What you actually test |
|---|---|
| Vacancy and requisition management | Can you create a vacancy, approve it through an approval flow, and link it to a hiring manager? |
| Candidate database | Central storage, searchable on fields, dedupe when the same person applies twice |
| Pipeline / kanban | Visual stages, drag candidates between steps, status at a glance |
| Multiposting to job boards | One vacancy, automatically distributed to the boards you use, without retyping five times |
| Candidate communication + templates | Email from the system, reusable templates, communication history logged per candidate |
| Interview scheduling with calendar sync | Two-way sync with Google/Outlook calendars, no double bookings |
| Collaborative scorecards | Multiple interviewers scoring on the same criteria in a structured way, not scattered in their inboxes |
| Branded mobile careers site | Your own branding, and working on mobile, because more than 70% of job seekers use their phone during the search |
| Basic analytics | Time-to-fill, source, funnel conversion. These three at minimum |
| Handoff to HRIS/CRM | A hired candidate should flow into your HR or CRM system without retyping |
Two notes here. The mobile careers site is often underrated: if candidates apply primarily on their phone and your flow is only decent on desktop, you leak applicants at the first step. And the scorecards look like a detail, but they're the difference between a structured, defensible selection and a collection of gut feelings you can't reconstruct later, which becomes a problem legally (see Group 3).
Group 2: what makes an ATS modern in 2026
Here the roads split. A legacy ATS covers Group 1 fine and stops there. A modern system does more, and in 2026 that difference has become measurable. Teams with an AI-augmented ATS report 55% faster time-to-hire, 53% better candidate quality and 49% higher productivity. Those are vendor numbers, so take them with a pinch of salt, but the direction holds: 80% of organisations have now automated at least one step in the hiring process.
| Modern requirement | Modern (2026) | Legacy |
|---|---|---|
| Matching | Semantic: understands that "React developer" and "front-end engineer with JS" are related | Keyword/Boolean: misses the candidate who used slightly different words |
| AI scoring | Explainable and auditable: you see why a candidate got a score | Black box, or no scoring at all |
| Workflow automation | Rules and triggers you set up yourself without a developer | Fixed flows, every change is a ticket |
| Talent-pool rediscovery | Actively surfaces suitable candidates from earlier applications | Old candidates vanish into the archive |
| Data structure | Typed fields (enums, dropdowns), not just free text | Everything a free text field, useless for analysis |
| Predictive analytics | Flags funnel bottlenecks before they escalate | Backward-looking reporting only |
| DEI / bias monitoring | Measures and flags skewed progression per group | No visibility, so no correction |
| Scalability under load | Stays fast at a peak of hundreds of applications a day | Slows down or falls over under volume |
The most important distinction in this group is the explainability of AI scoring. Not because it's a nice feature, but because in 2026 it has become a legal requirement (Group 3 explains why). An ATS that scores candidates but can't tell you why gives you a number you're not allowed to use for decisions that affect candidates. Ask every vendor to break a score down to the source field. If they can't, the AI layer is more of a liability than an advantage.
Semantic matching is the second point where many older systems get stuck. Boolean keyword search structurally misses the candidate who can do the same thing but writes it up differently. In a tight labour market that's expensive, because it's often exactly the less obvious profiles you need.
Group 3: compliance is no longer optional
This is the group that changes fastest and weighs heaviest. Two regimes run in parallel, and your ATS has to satisfy both. Make no mistake here: from 2026 this is not an extra wish, it's the floor.
GDPR. The baseline that has applied for years, but where many older ATSs still fall short:
| Compliance requirement | What it concretely means |
|---|---|
| Consent at application | Explicit opt-in, no pre-ticked box. The latter is invalid under GDPR |
| Automated retention periods | Data is automatically deleted after 6, 12 or 24 months, per your policy, without manual cleanup |
| DSAR workflow | A candidate's access or deletion request can be handled in a few clicks |
| Role-based access + audit log | Who saw what, when, and who changed which data, all traceable |
| ISO 27001 as a baseline | The vendor has a recognised security baseline, not loose promises |
EU AI Act. This is where it gets sharp in 2026. Recruitment AI is high-risk under the Act, named explicitly in Annex III point 4. That means an ATS that screens, scores or ranks candidates is bound by a set of requirements. And note: those obligations apply to you as the deployer, regardless of who built the system. You can't push the responsibility entirely onto the vendor.
| EU AI Act requirement | What your ATS must deliver |
|---|---|
| Human oversight (Art. 14) | No fully automated hiring or rejection decisions. A human reviews, demonstrably |
| Transparency to candidate (Art. 26(7) + 86) | The candidate knows that, and for what, AI is being used |
| Technical docs + bias audit (Art. 10-12) | The vendor can produce documentation and a bias evaluation |
| AI log retention | At least a 6-month activity log of the AI decisions retained |
You have to be precise about the timing, because confusion is circulating here. The original planning deadline for the full high-risk obligations is 2 August 2026. Since a political agreement of 7 May 2026 there is a proposal, the Digital AI Omnibus, to defer that deadline to possibly December 2027. That proposal has not yet been formally adopted. So the sensible plan is: assume August 2026 and set up your selection accordingly. Anyone who bets on deferral now and isn't ready later carries the liability themselves.
For the full breakdown of what the EU AI Act requires, with all the article numbers and an 8-point vendor checklist, see the EU AI Act guide for recruitment. And for the GDPR side around AI tools specifically: GDPR and the AI Act for recruitment tools.
Group 4: integrations and the AI co-pilot layer
No ATS stands alone. More than 60% of recruiting teams run three or more tools alongside the ATS. That makes your ATS's integration quality just as important as its own features, because a system that integrates badly turns your stack into a set of islands where data is retyped three times.
| Integration requirement | What you actually test |
|---|---|
| Open API + webhooks | Can you pull data out of and into the system yourself, and does it trigger events outward? |
| Native marketplace / certified integrations | Is your stack in an official, maintained integration list? |
| Unified-API support | Does the vendor work with providers like Merge, Kombo, Finch or Knit? That cuts integration time considerably |
| Bidirectional sync | Do all key objects flow both ways, not just out? |
| Interview intelligence / AI co-pilot | Do transcripts and summaries flow back into the candidate profile? |
| Validation layer at data entry | Is automatically populated CRM data validated (green/orange) before it lands? |
| Runtime-configurable fields/stages | Can you adjust fields and pipeline stages yourself without a developer? |
The size of the integration ecosystem varies a lot by vendor. Some large players report hundreds of integration partners, Greenhouse 250+, Bullhorn 300+, iCIMS around 800. A big number is no guarantee, because what matters is whether your specific tools are in there and how deep the connection goes. But a vendor with a handful of integrations and no open API gives you a future problem.
And this is exactly where an AI intelligence layer on top of your ATS fits. An ATS is built to manage candidates through a pipeline. It is not built to record conversations, understand them, and turn them into structured data. That's a different discipline. A co-pilot like Simply sits here: it records intakes and interviews omnichannel (meeting bots, desktop, mobile, VOIP), turns them into AI summaries, populates your CRM with data entry you verify through a green/orange validation system, parses and formats CVs to your house style, and delivers deeper candidate and recruiter insights than an ATS produces on its own. Simply is emphatically not an ATS and doesn't want to be one; it's the intelligence layer that runs on top of the ATS you already have, via a bidirectional API and a managed Salesforce app, with enterprise security and ISO 27001 underneath. What that connection between AI tools and your ATS looks like technically depends on which system you run, and there's a separate guide on ATS integration about it.
The point isn't that you have to buy this from Simply. The point is that your ATS has to be able to receive this kind of layer. An ATS without an open API or without bidirectional sync shuts out this entire category of improvement, and in 2026 that's an expensive limitation.
The mistakes we see most often
Ticking off the feature list and forgetting the workflow. An ATS can have every feature on your list and still not fit your process. That's exactly why 42% migrate again within two years. Test on your real flow, not on a demo scenario the vendor has prepared.
Underestimating the total cost. The licence price is not the real price. Count on implementation, integration work, training and migration. In practice the total cost of ownership runs 30 to 50% above the base subscription price. A vendor who's vague about that will surprise you later.
Handling compliance only after purchase. With the EU AI Act planning at August 2026, the era of buying a system and sorting the legal side later is over. Ask for the documentation, the audit logs and the candidate-rights flow before you sign. A vendor not ready by that date hands you the liability.
No exit strategy. Ask at purchase what happens to your candidate and historical data when you cancel. In what format do you get it back, and how long does that take? A vendor who's vague about this builds a lock-in you'll struggle to escape later.
Trying to automate too much, too early. Especially around rejections. An ATS that automatically rejects at scale without demonstrable human review collides head-on with the human oversight requirement. Scalable is not the same as fully automated.
Evaluation framework: from longlist to go-live
A workable sequence, for anyone starting a process now. The core: define your requirements before you look at the market, not the other way round.
Step 1, lock down requirements (week 1). Run through the four groups above and place each requirement in must-have, should-have or could-have. Do this with your recruiters present, not just from procurement. The people who work in it daily see workflow bottlenecks that are invisible on a feature list.
Step 2, longlist (weeks 1-2). Build a longlist of systems that cover your must-haves. Filter hard. A system that misses one must-have drops out, however attractive the rest is.
Step 3, shortlist and targeted demos (weeks 2-4). Bring it back to three to five. Send your requirements, and especially your compliance questions, ahead by email. Have the vendor show your must-haves in the demo, not their favourite features. A vendor that takes a week to answer your compliance questions will take a week during implementation too.
Step 4, compliance check (parallel to step 3). Test each shortlist vendor against the GDPR and EU AI Act requirements from Group 3. Ask for a real audit log, a bias evaluation and the transparency flow to the candidate. Also ask how an AI co-pilot layer connects to it, because that determines your options for the coming years.
Step 5, pilot (weeks 4-8). No annual contract without a pilot. Run three to six weeks on one team, with measurement points agreed up front. Not "does it feel good", but "does it measurably save time on time-to-fill and data entry, measured before and after".
Step 6, migration and go-live. Plan the data migration and the exit conditions of your old system before the switch, not during it. Train your team on the new flow before going live. An ATS that's technically perfect but used well by nobody delivers no more than a bad one.
Conclusion
A modern ATS in 2026 is not the ATS with the longest feature list. It's the system that covers your core layer, offers semantic and explainable AI, complies with GDPR and the EU AI Act, and is open enough that you can connect the rest of your stack to it. That last requirement is the quiet decider: an ATS that integrates well can grow with you and receive an intelligence layer on top. A closed system locks you into what it can do today.
Plot your requirements onto the four groups, decide consciously what counts as a must-have, and test before the demo. And if afterwards you want an AI layer on top of your ATS that turns conversations into structured, validated data, then Simply fits exactly into that open space, alongside the ATS, not instead of it. For specific agency types the emphasis differs: staffing firms lean more heavily on volume and retention periods, search and selection firms on explainability per candidate. And if the choice between tools is still open, choosing recruitment AI per agency type takes you further.
