Getting an HR Answering Agent Through Security Review and Procurement

<p id="tldr"></p>

TL;DR

• HR chatbot procurement almost never fails on price. It stalls on paperwork, and usually on paperwork nobody knew to gather until week five.
• Six artefacts carry most of the weight: a data processing agreement, a sub-processor list, a security overview, data residency and retention terms, a deletion commitment, and a statement about whether your content trains anything.
• The review is harder than for most small software because the system holds what employees say about their own circumstances, not just company documents.
• Involve data protection before the trial, not before the purchase. The trial is when your real policies first leave the building.
• If you have a works council or equivalent, they will ask about monitoring. Have a crisp answer about what is logged and who can read it.
• The single biggest time saver is asking the vendor for their standard review pack on the first call. Most have one and almost nobody asks.

Four Months for a Two Hundred Dollar Subscription

The product was chosen in three weeks and signed in nineteen. Nothing went wrong, exactly. Each step was reasonable and each step happened after the previous one finished.

The security questionnaire came back with eleven follow-ups, which took two weeks because the vendor's technical contact was answering them between calls. Data protection then asked for a sub-processor list, which arrived and contained a model provider nobody had considered, which triggered a separate conversation about where inference happens. That conversation surfaced that conversation logs were retained for a period nobody had asked about, which was fine once established and took ten days to establish. By the time the works council asked what exactly was being recorded about employees, the HR team had stopped giving a date to anybody who asked.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The subscription was under three hundred dollars a month. The review consumed perhaps thirty hours of combined time across five people, most of it waiting. And nothing in it was wasted: every question was a fair question that somebody should have asked. They were just asked in series, discovered one at a time, each one restarting a clock.

HR chatbot procurement fails on sequence rather than on substance. The questions are knowable in advance, and asking them all at once takes a fraction of the time of discovering them one by one.

The Six Artefacts HR Chatbot Procurement Needs First

Ask the vendor for all six on the first call. Most have a prepared pack and will send it immediately, which collapses weeks into an afternoon.

A data processing agreement. The contract governing them handling personal data on your behalf. For an HR deployment this is not optional and it is the document most likely to need legal review.

A sub-processor list. Everybody they use who touches your data, including the model provider and the hosting provider. This is the artefact that most often contains a surprise, and the surprise is usually a model API nobody had thought about.

A security overview. Whatever they have: a certification, a completed standard questionnaire, a security page. For a small vendor this may be a document rather than an audit, and that can be acceptable depending on your bar.

Data residency and retention terms. Where data is stored and processed, and how long conversation history is kept.

A deletion commitment. What happens on termination, within what period, with written confirmation and a statement about backups.

A training statement. Whether anything derived from your documents or conversations is used beyond serving you.

Those six answer the large majority of what any reviewer will ask. Gathering them before the review starts is the difference between one round of questions and four.

Why This Review Is Harder Than It Looks

A reasonable objection is that this is a small subscription and the process is disproportionate. The objection is right about the money and wrong about the data, and it is worth being precise about why.

Most small software holds company information. An HR answering agent holds company documents plus a record of what individual employees asked about their own situations. People use these systems to ask about resignation, grievances, pay, illness and family circumstances, precisely because asking a machine feels lower-stakes than asking a person. That is much of the value and all of the sensitivity.

So the conversation log is personal data about identifiable employees, held by a third party, concerning matters employees would consider private. That is a materially different review from a subscription to a design tool, regardless of the price, and a reviewer who treats it as routine is not doing their job.

The second complication is the model provider. Your content is processed by a system the vendor does not own, which means your sub-processor chain is longer than for ordinary software and the residency question has two layers: where the vendor stores data and where inference happens. Those are frequently different jurisdictions and reviewers increasingly ask about both.

None of that makes the purchase hard. It makes it a review that needs the right documents up front, which is the whole argument of this article.

The Order That Avoids a Rerun

Six steps, and the ordering is the point.

Get the six artefacts. First call, before any evaluation. This is free and it determines everything downstream.

Run a data protection review before the trial, not before the purchase. The trial is when your real policies first sit with the vendor and when real colleagues ask real questions. Teams routinely treat the trial as pre-procurement and therefore outside the process, which means the data has already left before anybody reviewed the terms. If a full review cannot happen in time, trial on a redacted document set and accept a weaker evaluation.

Scope what the system will hold, in writing. One paragraph: which documents, which audiences, what is logged, how long. Reviewers assess a described system far faster than an open-ended one, and this paragraph is also what the works council will ask for.

Submit the security questionnaire with the vendor's pack attached. Many questions are pre-answered in their standard documentation, and attaching it reduces the follow-up round substantially.

Consult the works council or equivalent with the scoping paragraph. Early, and with a specific description rather than a general intention.

Then negotiate the commercial terms. Last, because the terms you want depend on what the review concluded, and because a signed contract that the review then modifies is worse than a short delay.

Who Needs to Be in the Room, and When

Four functions touch this and the sequencing of people matters as much as the sequencing of documents.

The sponsor, usually in HR or people operations, owns the problem and the outcome. Their job is to hold the thread, which sounds trivial and is the thing that most often fails. A review with no one chasing it stops between steps rather than at them, and nobody notices for a fortnight because every individual party is waiting reasonably on somebody else.

Data protection, whoever that is in your organisation, assesses the processing. Involve them before the trial. If the role does not exist formally, this is a reasonable moment for external advice, and an hour of it costs less than the review time wasted by proceeding on assumption.

Security, who will send a questionnaire. Give them the vendor pack with it, and give them the scoping paragraph, because a reviewer assessing a described system asks far fewer clarifying questions than one assessing an open-ended request.

Procurement or legal, who handle the agreement and the commercial terms. Last, deliberately, because the terms depend on what the review concluded.

The pattern that works is one meeting at the start with all four present, lasting half an hour, where the sponsor describes the scoping paragraph and each function says what they will need. That half hour surfaces most of the requirements that would otherwise be discovered serially, and it is the single highest-return intervention in this whole article.

The pattern that fails is a relay. HR evaluates, then hands to security, who hand to data protection, who hand to legal, each discovering requirements the previous party could not have anticipated. Nothing goes wrong and four months pass.

One practical note on seniority: these reviews move faster when somebody reasonably senior has said out loud that the purchase is wanted. Not to pressure reviewers, which is counterproductive and unfair, but because small purchases with no visible sponsor sit at the bottom of every queue they enter. A one-line statement of support from whoever owns the people function is usually enough.

The Questions Security Will Ask

Predictable, and worth having answers ready for rather than discovering.

Where is data stored and where is it processed? Two answers, not one. The vendor's hosting region and the model provider's inference region may differ.

Who at the vendor can see our content? Support access is the honest answer for most products, and the useful follow-up is whether it is logged and whether it requires customer approval.

How do users authenticate? Your identity provider, ideally, which also answers the access control question. A product with its own separate user list is a harder review.

What is logged and for how long? The conversation history, retention period, and whether you can shorten it.

What happens on a breach? Notification period and process. Standard, and reviewers will want it in the agreement rather than on a web page.

Is any of our content used for training? Covered above and asked by nearly every reviewer now.

What is the deletion process? On termination and on request, with confirmation.

Prepare those seven and the questionnaire round becomes short. The pattern worth avoiding is answering them from your own assumptions, because a confident wrong answer to a security reviewer costs more credibility than saying you will check.

What the Works Council Will Ask

If you have a works council, a staff committee or any equivalent consultation body, their concern is almost never data protection in the abstract. It is monitoring.

The question underneath their questions is whether this system can be used to observe individual employees. Can somebody see that a named person asked about resignation three times last month. Can a manager see their team's questions. Is any of it reportable in a way that would identify somebody.

Answer those directly and in writing, because a vague answer here generates a long consultation and a precise one usually ends it. The three things to state plainly: who can read the conversation log, whether it is identifiable or pseudonymised, and whether managers have any access to their team's questions. For most deployments the honest answers are that a small named group of HR administrators can read it, that it is identifiable because authentication is required for the system to work properly, and that managers have no access.

If any of those answers is uncomfortable, change the configuration rather than the wording. A system where managers can see individual employees' questions is a monitoring system whatever it is called, and consultation bodies are right to treat it as one. The deployments that pass consultation smoothly are the ones where somebody decided in advance that question-level visibility stops at a small administrative group.

It is also worth volunteering what the log is for, which is content improvement. Reading the queue to find out which policies generate confusion is a legitimate and easily explained purpose, and framing the retention around that purpose is far more persuasive than a general appeal to service improvement.

Running the Trial Inside the Process Rather Than Before It

The recommendation to review before the trial raises an obvious practical objection: reviews take weeks and you want to know whether the product is any good before investing in paperwork. That is reasonable, and there is a way to have both.

Split the evaluation in two. First a capability check on content that is not sensitive, which answers whether the product can read a conditional policy, decline cleanly, and be administered by somebody in HR. Public-facing material works well for this: your careers-site FAQ, a published benefits summary, anything already outside the building. That tells you most of what a demo cannot and it carries no data risk, so it needs no review.

Then the real trial on real documents, once the processing review has cleared. This is the one that tells you about your own awkward content and your own employees' phrasing, and it is the one where the data genuinely leaves.

Running it this way means the capability check happens in week one, in parallel with the artefact request, and you usually know whether a product is worth reviewing before any reviewer spends time on it. Teams who do this stop two of three shortlisted products before the paperwork starts, which is the cheapest filtering available.

A redacted document set is the middle option where a review will take longer than you can wait. Take five real policies, remove anything identifying and anything genuinely sensitive, and trial on those. The evaluation is weaker because the structure of a redacted document is not quite the structure of the original, but it is considerably better than public material and it carries much less risk than the full set.

What not to do is the thing that happens by default: upload everything in week one because the trial is free and feels pre-procurement, then start the review in week six having already done the thing the review exists to assess. That sequence is the most common error in this article and it is entirely avoidable by deciding, in advance, what the trial is allowed to hold.

When the Review Should Stop the Purchase

Three situations where the honest outcome is not to proceed, and recognising them early saves everybody time.

Residency cannot be satisfied. If your data genuinely cannot leave a jurisdiction and neither the vendor nor its model provider can commit to that, this is a hard stop rather than a negotiation. It is also the clearest case for building rather than buying.

The vendor will not provide a data processing agreement. For a product holding employee conversations this is disqualifying. A small vendor without a prepared one may still sign yours, which is a different and acceptable answer.

No clear statement on training. Not an unfavourable statement, which can be acceptable, but an absence of one. A vendor who cannot say what happens to your content is telling you something about their data handling generally.

A fourth, softer case: if the review concludes that the only acceptable configuration is one where the system holds so little that it cannot answer usefully, the purchase is not worth making. That happens occasionally in heavily regulated settings and the right response is to stop rather than to deploy something that will be judged a failure.

What Each Option Costs, and What That Means for the Review

Worth noting because the price shapes how much process is proportionate, even though it should not shape the data questions.

Every figure below was read from the vendor's own page on 15 October 2026. Matram is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats. Crisp is $0, $45, $95 and $295 a month per workspace, with additional agents charged on top. SiteGPT takes one yearly payment of $468, $948 or $3,108, equivalent to $39, $79 or $259 a month billed yearly. Chatbot.com starts at $19 per user a month, with Essential at $29.50 and Growth at $79.

Two implications for the review process specifically.

At these levels, a disproportionate process will kill the purchase rather than improve it. A thirty-hour review of a two-hundred-dollar subscription is how teams conclude the category is not worth the trouble. The answer is not to skip the review but to front-load it, which is the argument of this article: the same questions asked at once cost a fraction of the same questions asked in series.

Products with no published price usually mean an enterprise cycle anyway. Leena AI and Moveworks publish nothing, and that generally comes with a longer procurement process, a security pack already prepared, and a sales team accustomed to questionnaires. That is easier in some ways and slower in others.

Six Options Worth Knowing

Matram. Best for teams wanting to start small on a low-commitment basis while the review proceeds. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site. It is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats, and a 30-day trial that takes no card, which is genuinely useful here because it allows evaluation to run alongside a review rather than after it. Where it struggles, stated plainly: there is no free tier, so there is no indefinite zero-cost holding position if the review runs long; it answers questions but does not action tickets; and it is not an HR workflow platform, so it produces no acknowledgement audit trail, which matters if your reviewers are expecting one. Ask it the same six-artefact questions you would ask anybody, because a disclosure is not a substitute for a data processing agreement.

SiteGPT. Best for teams who have already cleared the review and want a lower effective rate. One yearly payment of $468, $948 or $3,108. Where it struggles for procurement: an annual commitment usually attracts more scrutiny than a monthly one, which can lengthen the process.

Crisp. Best where a free tier allows a long evaluation at no cost while paperwork proceeds. Flat per workspace at $0, $45, $95 and $295 a month, with additional agents charged separately. Where it struggles: it is a support product, so expect to explain to reviewers why a customer-facing tool is being pointed inward.

Chatbot.com. Best for website-first deployments where the internal use is secondary. $19 per user a month, $29.50 Essential, $79 Growth. Where it struggles: per-user pricing complicates the scoping paragraph, because the number of users is your whole company.

Leena AI. Best for organisations whose procurement expects an enterprise vendor with a prepared pack. Where it struggles: no published pricing, so there is no way to scope a budget before engaging.

Nothing, for now. Best where the review has surfaced a genuine blocker. Chosen because deploying a system your own reviewers have reservations about is a worse outcome than waiting. Where it struggles: the problem you were solving does not go away, so pair it with the document work, which needs no review at all.

The Decision Table

Building the Scoping Paragraph

This is the single highest-return document in the process and it takes fifteen minutes.

One paragraph covering six things. Which documents the system will hold, named by category rather than individually. Which audiences can ask it, and whether any content is scoped to a subset. What is logged, specifically whether questions are stored with the identity of the asker. How long that log is kept. Who internally can read it. And what the log is used for.

Write it before any review and attach it to everything. Reviewers assess a described system an order of magnitude faster than an open-ended request, because most of their questions are attempts to establish exactly these six facts. Handing them over removes the round trip.

It also forces a decision that teams otherwise defer. The question of whether the log is identifiable, and who can read it, is a real policy choice with consequences for the works council conversation, and deciding it deliberately in week one is better than discovering in week six that nobody had.

Keep it as a living document. When you widen the audience or add a document category, update it. It becomes the record of what the system is, which is the thing nobody can produce two years later when somebody asks.

The Security Questionnaire, Answered Once

Most organisations have a standard questionnaire and most vendors in this category have seen it before. The work is matching one to the other, and doing it once properly saves repeating it per vendor.

Build an internal answer sheet rather than starting fresh each time. For each question your organisation asks, record what the answer needs to establish and which of the six artefacts contains it. Residency questions resolve from the residency terms. Access questions resolve from the security overview plus your own identity provider configuration. Retention questions resolve from the retention terms. Perhaps two thirds of a typical questionnaire resolves from the pack without the vendor doing anything.

Then send the remaining third, and send only that. A questionnaire with forty questions, thirty of which are answered in an attached document, comes back slowly because somebody at the vendor is working through all forty. The same questionnaire with ten flagged as needing an answer comes back in days.

Three questions in a standard set usually need special handling for this category, and it is worth pre-empting them. Anything asking about penetration testing, which small vendors may not have. Anything asking for a specific certification, where the honest answer may be a security document rather than an audit. And anything assuming the vendor processes data entirely on its own infrastructure, which is not true once a model provider is involved.

For each of those, decide your bar in advance. A vendor without a formal certification can be acceptable for a document-answering tool at this price, or can be disqualifying, and either position is defensible. What wastes time is discovering the question, asking the vendor, receiving an unsatisfying answer, and only then deciding what your bar was.

What Changes If You Already Use the Vendor

A meaningful shortcut exists if the product comes from a vendor your organisation already has an agreement with, and it is worth checking before starting anything.

If your HRIS vendor sells an assistant module, the data processing agreement, sub-processor list and security review may already be in place, covering the same vendor and often the same infrastructure. The remaining review is then narrow: what the new module logs, for how long, and whether the model provider is a new sub-processor. That is a conversation rather than a process, and it can take days instead of weeks.

The same applies if your service desk or support vendor offers the capability. Extending an existing agreement is almost always faster than onboarding a new supplier, and procurement teams generally prefer it, which matters when you need them to prioritise something small.

This is a genuine argument in favour of the incumbent that has nothing to do with product quality, and it should be weighed honestly rather than dismissed. A module that is slightly worse and available in two weeks may deliver more value than a better product available in four months, particularly if the gap is in capabilities you were not going to configure anyway.

What it should not do is settle the decision. Check whether the existing agreement genuinely covers the new processing, because an agreement signed for payroll processing does not automatically cover storing employee questions about grievances, and a reviewer will notice even if nobody else does. Ask specifically whether the module introduces a new sub-processor, since that is the most common way an apparently covered extension turns out to need a fresh review.

What Getting HR Chatbot Procurement Wrong Costs

Rarely a bad outcome, usually a dead one. The characteristic failure of HR chatbot procurement is not a rejected purchase but an abandoned one.

A review that runs four months on a subscription worth a few hundred dollars a month exhausts its sponsor. The HR lead who wanted this stops chasing, the evaluation goes stale, the vendor's trial lapses, and the organisation concludes without ever deciding that these tools are more trouble than they are worth. The problem that prompted it, which was employees asking the same questions repeatedly, remains and is now harder to raise because it has a history of failure attached.

The second cost is a review done badly rather than slowly. A purchase waved through on the basis that it is cheap, with employee conversations held by a third party under terms nobody read, is a finding waiting for a governance review. It is also unfair to the people whose questions are being stored, who had no part in the decision and would reasonably expect somebody to have checked.

And the third is the trial that happened outside the process. Real policies uploaded, real colleagues asking real questions, under evaluation terms nobody reviewed, often before anybody considered that the trial was the moment the data left. That one is entirely preventable and it is the most common.

So the question is not whether your HR chatbot procurement will be approved. It is whether you gathered the six artefacts on the first call, and whether the review happened before the trial rather than after it.

When You're Ready to Start

Email the vendor today and ask for all six artefacts in one message. Data processing agreement, sub-processor list, security overview, residency and retention terms, deletion commitment, training statement. Most will send a prepared pack and the request costs you five minutes.

Then write the scoping paragraph while you wait. Six facts, fifteen minutes, and it will be attached to every conversation that follows.

And book the data protection review for before the trial. That is the one piece of sequencing that most reliably prevents a rerun, and it is the one most often got wrong, because a trial feels like something that happens before procurement rather than as the first step of it.

A last word on expectations, because it affects whether you start at all. Done in this order, HR chatbot procurement for a product at these price points is a two-to-four week exercise consuming perhaps six hours of your own time and a couple of hours each from three other functions. That is a proportionate amount of process for a system that will hold what your colleagues ask about their own employment, and it is a fraction of what the same review costs discovered one question at a time. The teams who find HR chatbot procurement unbearable are almost always the teams who ran it as a relay. The teams who find it ordinary front-loaded the artefacts, wrote the scoping paragraph, and got everybody in one room for half an hour at the start. The difference between those two experiences is about ninety minutes of preparation.

Frequently Asked Questions