What should a modern ATS do in 2026?

These criteria are drawn from public buyer guides and analyses as of July 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
CV parsing into fields	Upload a real CV and look at what lands: structured work history and education as records, or one text blob somebody still has to read
Candidate communication + templates	Email from the system, reusable templates, communication history logged per candidate
Interview scheduling with calendar sync	Sync with Google/Outlook calendars that reads busy time as well as writing invitations, so no double bookings
Collaborative scorecards	Multiple interviewers scoring on the same criteria in a structured way, not scattered in their inboxes
One timeline per candidate	Notes, mail, calls and documents on the record itself, so a handover between recruiters doesn’t need a phone call
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 requirements are deliberately not on that list, and it is worth saying why. Multiposting to job boards and a branded mobile careers site are must-haves the moment you advertise vacancies under your own name at volume: a corporate recruitment team, or an agency that runs its own campaigns. If that’s you, filter on them as hard as on anything above, including on mobile, because more than 70% of job seekers search on their phone. But plenty of agencies buy distribution separately, or work almost entirely on client vacancies published elsewhere, and for them a shortlist scored on advertising reach ends up ranked on the wrong axis entirely. So put these two in must-have or could-have on purpose, rather than inheriting them from somebody else’s checklist.

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 you can add yourself, and the new field turns up in parsing, search, filters and the API without waiting for a release	Everything a free text field, and a new field is a ticket at the vendor
Where the AI runs	The vendor names the model providers, the regions inference runs in, and whether you can bring your own key	“AI-powered”, and no answer to either question
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.

The row about where the AI runs is new to this kind of list, and it’s the one buyers skip most often. Ask it as two separate questions and insist on two separate answers: where is the platform and the candidate data hosted, and where does the model inference happen. A vendor who answers both with one sentence about Europe has compressed two facts into one, and the compression always hides the second. Your DPIA needs both answers on paper anyway, so you may as well get them before the contract rather than after.

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
Sub-processors named, model providers included	A current list of who processes what on the vendor’s behalf, with the AI providers on it. If that takes a follow-up email, it will take one every year

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 was circulating here. The original planning deadline for the full high-risk obligations was 2 August 2026. Since the political agreement of 7 May 2026, the Digital AI Omnibus has been formally adopted — the European Parliament voted in favour on 16 June 2026, and the Council gave final approval on 29 June 2026. The new deadline for high-risk AI under Annex III (which explicitly includes recruitment AI) is now 2 December 2027. That gives more breathing room, but doesn’t mean you can wait: the obligations themselves haven’t been softened, only the enforcement date has shifted. Anyone who starts now has eighteen months to get systems, documentation and processes in order. Anyone who waits until 2027 and then has to rush 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 copilot

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?
A connector list you can count	Ask for the complete list of maintained connectors rather than the logo wall, then check that your two most-used tools are actually on it
Unified-API support	Does the vendor work with providers like Merge, Kombo, Finch or Knit? That cuts integration time considerably
One system of record, or two	If a vendor proposes keeping your current system alive next to theirs with a sync between them, ask who reconciles a conflict, how often, and whose job that is
Interview intelligence / AI copilot	Do recordings, transcripts and summaries land on the candidate record itself, or in a second tool with its own login?
Validation layer at data entry	Is automatically populated candidate data flagged for review before it lands, or written silently?
Runtime-configurable fields/stages	Can you adjust fields and pipeline stages yourself without a developer?
Access from the tools your people already use	A public API with its own keys, signed webhooks, an MCP server. Can a technical colleague query the system from the client they already work in?
Export and exit	Ask for a sample export before you sign: which objects, which format, how long it takes, and what doesn’t come out at full resolution

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 where the assumption behind the previous generation of buyer guides quietly broke. For years the sensible advice was: keep the ATS, put the intelligence beside it. That worked while the intelligence was shallow, a notetaker here, a formatter there. It stops working the moment the intelligence needs the whole file, because then two systems both hold candidate data, both believe they hold the current version, and reconciling them becomes somebody’s standing Friday afternoon.

Simply is built the other way round: it is the ATS, and the intelligence is part of the same records rather than a connection to them. Conversations are captured across channels and become AI summaries on the candidate. A CV is parsed into structured records against a data model you define yourself rather than a fixed template, so a field you add this morning is in the parser and the API this afternoon. Anything the AI wants to write to a candidate arrives as a proposal you approve, with the approval and the name behind it in an append-only audit log. Dashboards return counts, rates and trends over your own objects, and deliberately do not let anyone click a chart through to the records behind the number. There are six connectors, Gmail, Outlook, Google Calendar, Zoom, Slack and HubSpot, and no sync back to another ATS, for exactly the reconciliation reason above. Coming from another system is a one-time migration of about four weeks, and it is one-way. The platform and the candidate data are hosted in the Netherlands on infrastructure Simply runs, with ISO 27001 underneath; and the AI processing runs inside the EU as well, or on your own key with your own provider. The models themselves are bought in, which is a separate question from where they run.

The point isn’t which of those two shapes you buy. Both are defensible, and for a team that only wants conversations captured, the point tool is genuinely cheaper. The point is to make the choice at selection time rather than discovering in month eight that you own two systems of record. Ask every vendor the same plain question: after this is live, where does a candidate live? If two answers come back, ask who reconciles them, and how often.

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. Even with the deferred deadline of December 2027, 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. And ask the hosting question and the inference question separately, in writing: where the platform and the candidate data sit, and where the model calls go. Your DPIA needs both, and a vendor that covers both with one sentence has answered neither.

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. And the quiet shift since the last generation of buyer guides is this: intelligence is no longer something you bolt on afterwards. A system where matching, parsing, conversation capture and reporting all run on the same records is a different product from one where each of those is a connection to somewhere else. The difference doesn’t show up in a demo. It shows up in the reconciliation work eighteen months later.

Plot your requirements onto the four groups, decide consciously what counts as a must-have, and test before the demo. If you want to see what it looks like when that intelligence sits inside the system of record rather than beside it, Simply is that argument in product form, including the parts it deliberately refuses to do. 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.