What are the most important AI employee security questions to ask before buying?

The most important questions cluster into a handful of areas, and asking across all of them gives you a complete picture rather than a false sense of safety from one good answer. First, data handling: is our data used to train shared or third-party models, is it ever exposed to other customers, where is it stored, and how are prompts and outputs logged? For business use you generally want your data used only to do your work. Second, access: can the AI's access be scoped to least-privilege — only the data and actions it needs — controlled granularly, and revoked instantly, and who at the vendor can access our data? Third, retention and deletion: how long is data kept, how do we delete or export it, and how is deletion verified. Fourth, encryption and sub-processors: is data encrypted in transit and at rest, and which third parties touch it? Fifth, oversight and audit: which actions stay human-approved, and do we get a complete log of what the AI did? Sixth, compliance and incidents: what can they evidence rather than merely claim, and how do they detect and disclose breaches? Ask for specifics and evidence, not reassurance, and get the answers that matter in writing and into the contract or data-processing agreement, because a posture that isn't committed can change.

How can I tell if a vendor's security answers are actually good?

A good answer is specific, evidenced, and verifiable; a weak answer is confident but vague. The tell is whether you can do something with the answer. 'We take security seriously' or 'your data is safe with us' are non-answers — they contain no commitment you could check or hold them to. By contrast, 'your data is encrypted in transit and at rest, is never used to train models beyond your account, is retained for the period you configure and deleted within a defined window of your request, and here is our data-processing agreement and sub-processor list' is a set of specific claims you can verify, compare across vendors, and write into a contract. So when you get a reassuring-but-vague reply, treat it as a prompt for a sharper follow-up rather than an answer: ask 'specifically, is our data used to train shared models?', 'can you show me that in your terms?', 'will you commit to that in the contract?'. Willingness to be specific, to provide documentation, and to commit in writing is itself a strong signal of a mature, trustworthy vendor; evasiveness, hand-waving, or reluctance to put basic protections in the contract is equally informative in the other direction. You are evaluating not just the answers but the vendor's confidence in standing behind them.

Why does 'is my data used to train your models' matter so much?

It matters because it goes to the heart of whether your confidential business information stays confidential, and it is the question vendors' answers vary on most. If a platform uses your data — your documents, customer information, internal communications, the content of your prompts — to train models that are shared beyond your account, then in effect your proprietary information could influence outputs seen by others, or simply be retained and processed in ways you did not intend. For most business use, you want a clear, documented commitment that your data is used only to perform your work, not to train shared or third-party models, and is not exposed to other customers. The nuances to probe include: whether any model customisation for you is isolated to your account; whether prompts and outputs are logged, for how long, and who can read them; and whether any data is shared with the underlying model providers and under what terms. This is not about assuming bad intent — many reputable vendors handle this well — but about confirming the specifics, because the defaults differ and the consequences of getting it wrong are significant. Get the answer in writing, ideally in the data-processing agreement, so a good practice today cannot quietly become a different practice tomorrow.

What should I ask about access control and permissions?

Access questions determine how far the AI employee's reach extends and how contained the risk is, so they deserve careful attention. The guiding principle to ask about is least privilege: the AI should have access only to the specific data and actions it genuinely needs for its role, not broad, standing access to everything. Concretely, ask whether you can scope its access narrowly, whether permissions are granular (so you can allow some data or actions and not others), and whether you can revoke access instantly if needed. Ask how its permissions relate to your existing access-control and authentication policies — can it operate within them rather than around them? Ask who at the vendor's side can access your data, under what controls, and whether that internal access is itself logged and limited. Ask what happens to access when a role changes or the engagement ends. And connect access to oversight: for consequential or irreversible actions, can access be paired with a human-approval requirement so the AI can prepare but not unilaterally execute? Strong answers describe granular, least-privilege, revocable access with limited and logged vendor-side access; weak answers are vague about scope or imply broad, hard-to-constrain access. Because an AI worker that can reach more than it should is a larger attack surface and a bigger blast radius if something goes wrong, this is one of the highest-value areas to probe.

What retention, deletion and exit questions matter?

These lifecycle questions are frequently overlooked during evaluation and frequently regretted later, so it is worth being thorough. On retention, ask how long the vendor keeps your data by default, whether you can configure or shorten that period, and what exactly is retained — the data you connect, the prompts, the outputs, the logs. On deletion, ask how you request deletion, how quickly it happens, how it is verified, and critically whether it extends to backups and any copies held by sub-processors, since data that lingers in backups is a common gap. On exit — for when you eventually leave, which you should plan for from the start — ask how you export your data, in what formats, whether it is complete, and how the vendor ensures your remaining data is destroyed after you go. Also ask whether all of this is covered in a data-processing agreement rather than just described verbally. Good answers here indicate a mature vendor who has thought about your data across its whole lifecycle and respects that it is yours; vague answers, or an inability to guarantee deletion or clean export, are a real concern both for regulatory compliance and for your basic ability to leave on your own terms without being locked in. Treat clean retention, verifiable deletion, and portable export as requirements, not extras.

How important are audit logs, and what should they contain?

Audit logs are what turn oversight from a promise into something you can actually verify, so they are very important and worth insisting on. Without a clear record of what the AI employee did, you are trusting blind; with one, you can confirm it behaved as intended, investigate anything unexpected, demonstrate compliance to auditors or regulators, and build justified confidence over time. Ask specifically what the logs capture: ideally the actions the AI took, the decisions it made, what data it accessed, when, and the outcomes — enough to reconstruct what happened. Ask whether the logs are complete and tamper-evident, so they can be relied upon. Ask whether they are available to you (not just internal to the vendor), for how long they are retained, and whether you can export them for your own records or investigations. Ask how logs tie to the human-approval and escalation events, so you can see where people were in the loop. A platform that provides comprehensive, accessible, exportable audit logs is giving you the transparency that makes an AI worker trustworthy and manageable; one that cannot show you what its AI did, or keeps logs opaque or inaccessible, is asking for a level of blind trust that is hard to justify in a business context. Make auditability a firm requirement rather than a nice-to-have.

What compliance and incident-response questions should I ask?

On compliance, the key discipline is to ask for evidence rather than accept adjectives. Terms like 'enterprise-grade', 'bank-level' or 'fully compliant' are marketing language with no fixed meaning, so ask instead which specific security standards or frameworks the vendor aligns with or formally holds, and ask them to provide documentation, reports, or attestations you can review. Ask whether they offer a data-processing agreement, and whether they can support the particular regulations that apply to your business, industry, or customers — privacy laws, sector rules, or regional requirements. Where vendors hold formal certifications they can show them; where they align with frameworks like the NIST AI Risk Management Framework or established security practices, they can describe concretely how. On incident response, since no platform can promise nothing will ever go wrong, focus on how they respond: how they detect security incidents, whether and how quickly they will notify you of a breach affecting your data, what their documented process is, who your point of contact would be, and whether they test their response. Ideally, breach-notification commitments are reflected in your contract. A vendor who can evidence a real compliance posture and a clear, tested incident-response and notification process is demonstrating operational maturity; one who offers only confident adjectives and no documentation, or is vague about what happens in a breach, has not earned the same trust. Verify specifics directly rather than assuming any particular certification.

Should these security commitments be in the contract?

Yes — the commitments that matter should be captured in writing, in the contract or an accompanying data-processing agreement, and this is one of the most protective steps you can take. The reason is simple: a security posture that exists only in a sales conversation or a marketing page can change, quietly and without your knowledge, as the vendor's practices, personnel, or business circumstances evolve. A commitment written into your contract is durable and enforceable; a verbal assurance is neither. So once you have asked the questions and are satisfied with the answers, identify the commitments that are genuinely important to you — typically how your data is used (especially the no-training-on-shared-models point), retention and deletion terms, breach-notification obligations and timelines, sub-processor terms and change notifications, encryption, and the availability of audit logs — and ensure they appear in the contractual documents rather than living only in an email or a call. Requesting a data-processing agreement is a natural vehicle for much of this. Beyond the protection it provides, this step doubles as a final due-diligence signal: a vendor confident in their security posture is generally willing to stand behind it in writing, while reluctance to commit basic, reasonable protections contractually is itself informative and worth weighing in your decision. In short, ask the questions, get specific answers, and then make the important ones real by putting them in the contract.

AI Employee Security Questions to Ask (Vendor Checklist)

Quick Answer

The AI employee security questions to ask a vendor fall into a few clear areas: how your data is handled (is it used to train shared models, who can access it, where is it stored), access control (least-privilege, how the AI's permissions are scoped and revoked), data retention and deletion (how long data is kept and how you get it removed or exported), encryption (in transit and at rest), sub-processors (which third parties touch your data), human oversight (what stays approval-gated and auditable), audit logging (can you see what the AI did), compliance posture (which standards and terms they can actually evidence), and incident response (how breaches are detected, handled and disclosed). Ask for specifics and evidence rather than reassurances, and confirm answers in writing and in the contract. This guide gives you a copy-ready checklist of these questions, explains why each matters, and shows what a solid answer looks like — so you can evaluate any AI employee platform on security with confidence rather than guesswork.

Key Takeaways

Ask about data use (especially whether your data trains shared models), access, retention, encryption and sub-processors.
Ask what stays human-approved and auditable, and whether you get complete audit logs of the AI's actions.
Ask for evidence of compliance posture — not just claims — and confirm what's contractually committed.
Ask about incident response: detection, handling, and breach notification timelines.
Ask about exit: how you export your data and ensure deletion when you leave.
Prefer specifics and written answers over reassurances; put key commitments in the contract.
Use the copy-ready checklist below to evaluate any AI employee platform consistently.

Why a security question list matters when buying

When you bring an AI employee into your business, you are giving software access to your data and, potentially, the ability to act inside your systems, so security due diligence is not optional — it is a core part of choosing well. The trouble is that security is easy to gloss over with reassuring language, and vendors vary widely in what they actually do behind confident marketing. A structured list of AI employee security questions to ask turns a vague sense of 'is this safe?' into concrete, comparable answers you can evaluate and hold a vendor to.

This guide is deliberately about the questions you ask the vendor during evaluation — the procurement-side due diligence — rather than the controls you implement on your own side (for that, see our AI employee data security checklist) or the conceptual question of whether AI employees are secure in general. Here the goal is practical: a copy-ready set of questions, why each matters, and what a solid answer looks like, so you can compare platforms on security with confidence. To ground the wider picture first, see what AI employees are.

Ask for specifics and evidence, not reassurance

The single most useful habit in security due diligence is to treat confident but vague answers as a prompt for a sharper follow-up rather than an answer. 'We take security seriously' or 'your data is safe' tells you nothing; 'your data is encrypted in transit and at rest, is not used to train shared models, and is deleted within X days of request' tells you something you can verify and hold them to. Ask for specifics, ask for evidence (documentation, terms, reports), and get the answers that matter in writing and, ideally, into the contract — because a security posture that is not committed contractually can change without notice.

How this differs from your own security checklist

It is worth separating two related things so you cover both. This guide is about evaluating the vendor: what the platform does, commits to, and can evidence about protecting your data and constraining the AI. Your own data security checklist, by contrast, is about the controls you put in place on your side — scoping what data you connect, who on your team has access, your approval policies, and your monitoring. Good security needs both halves: a trustworthy platform and sound practices around it. Using this question list for the vendor and the separate checklist for yourself keeps the responsibilities clear and nothing overlooked.

AI employee data, access and retention questions to ask

The heart of AI-employee security is what happens to your data — where it goes, who and what can touch it, and how long it lives — so this is where to concentrate your sharpest questions. Getting clear, specific, evidenced answers here matters more than almost anything else, because data exposure is the risk with the widest consequences. The questions below cover the areas that most affect your exposure.

Data use and training

Start with the question that surprises people most: is my data used to train shared or third-party models? For business use you generally want a clear 'no' — your data used only to do your work, not to improve a model others benefit from. Ask specifically: Is our data ever used to train models shared beyond our account? Is it shared with or exposed to other customers? If any model customisation happens, is it isolated to us? Are prompts and outputs logged, and if so for how long and who can read them? Clear, documented answers here tell you whether your confidential information stays confidential, which is foundational to everything else.

Access control and least-privilege

Next, probe how access is scoped and controlled, because an AI employee should operate on the principle of least privilege — only the access it genuinely needs. Ask: How is the AI's access to our systems and data scoped, and can we limit it to specific data and actions? Can we control permissions granularly and revoke them instantly? Who at the vendor can access our data, under what controls, and is that access logged? Do you support our own authentication and access policies? Least-privilege access, granular control and instant revocation are what keep an AI worker's reach appropriate and contained, so vague answers here are a meaningful red flag.

Retention, deletion and data export

Finally, pin down the full lifecycle of your data, including how it ends. Ask: How long is our data retained, and can we configure or shorten that? How do we request deletion, and how is deletion actually verified and completed, including in backups? If we leave, how do we export our data, in what format, and how is remaining data destroyed? Can we get a data-processing agreement covering all of this? Retention, deletion and clean exit are frequently overlooked in evaluation but matter enormously — both for compliance and for your ability to leave on your terms — so treat clear answers here as a sign of a mature vendor.

Oversight, logging and technical safeguards

Beyond data handling, you want to understand how the AI's actions are controlled and recorded and how the platform is technically protected, because these determine whether mistakes are caught and whether you can see what happened. The questions here cover human oversight, auditability and the baseline technical safeguards any serious platform should have in place.

Human oversight and control

Ask how the platform keeps humans in control of consequential actions, because for most business uses you want sensitive or irreversible steps to stay approval-gated rather than fully autonomous. Questions to ask: Which actions can be configured to require human approval before they execute? Can we set guardrails and boundaries on what the AI may and may not do? How does it handle uncertainty — does it escalate to a person rather than guessing? Can we review and correct its work? A platform designed around human-in-the-loop oversight, with configurable approval gates and clear escalation, gives you the control that makes deploying an AI worker safe, which is exactly the model ClawHire is built around.

Audit logs and transparency

Ask whether you can actually see what the AI did, because auditability is what makes oversight real rather than theoretical. Questions: Do you provide a complete, tamper-evident log of the AI's actions and decisions? Can we review what data it accessed and what it did with it? Are logs available to us, and for how long? Can we export them for our own records or investigations? Comprehensive audit logging lets you verify behaviour, investigate anything unexpected, demonstrate compliance, and build trust over time — so the ability to inspect a clear record of actions should be a firm requirement, not a nice-to-have.

Encryption, infrastructure and sub-processors

Cover the technical baseline that any credible platform should meet. Ask: Is our data encrypted in transit and at rest? Where (which regions) is it stored and processed? What sub-processors and third parties touch our data, and can we see a current list? How is the infrastructure secured and access to it controlled? How do you handle vulnerabilities and keep systems patched? These are table-stakes protections, but confirming them — and getting a sub-processor list, since your data is only as protected as the weakest party that touches it — separates vendors with real engineering discipline from those relying on assurances alone.

Compliance, incident response and contracts

Finally, evaluate what the vendor can actually stand behind — the compliance they can evidence, how they handle incidents, and what is committed in writing — because this is where marketing claims meet reality. The questions here help you separate demonstrable posture from aspiration and make sure the protections you were promised are contractually real rather than verbal.

Compliance posture — evidence, not adjectives

Ask what compliance they can demonstrate rather than merely assert, and be precise, because 'enterprise-grade' and 'bank-level' are marketing, not evidence. Questions: Which security standards or frameworks do you align with or hold, and can you provide documentation or reports? Do you offer a data-processing agreement? Can you support the regulations that apply to us (for example privacy laws relevant to our customers or industry)? Where a vendor holds formal certifications they can show them; where they align with frameworks like the NIST AI Risk Management Framework or general security practices such as those in OWASP guidance, they can describe how. Insist on evidence you can verify, and confirm ClawHire's specific posture directly rather than assuming any particular certification.

Incident response and breach notification

Ask how they detect, handle and disclose security incidents, because no platform can promise nothing will ever go wrong — what matters is how they respond when something does. Questions: How do you detect and respond to security incidents? Will you notify us of a breach affecting our data, and within what timeframe? What is your process and who is our point of contact? Do you test your incident response? A vendor with a clear, documented incident-response and breach-notification process — ideally reflected in your contract and aligned with recognised practice such as guidance summarised by CISA — is demonstrating the operational maturity that reassuring words cannot.

Getting it in the contract

Close the loop by making the important answers contractual, because a security posture that lives only in a sales conversation can quietly change. Ask: Which of these commitments — data use, retention, deletion, breach notification, sub-processor terms, data-processing agreement — are in the contract or DPA? Getting the answers that matter committed in writing protects you if practices drift or personnel change, and it signals whether the vendor is confident enough in their posture to stand behind it formally. A vendor willing to commit clearly is usually one worth trusting; hesitation to put basic protections in writing is itself informative.

What to evaluate before choosing an AI employee platform

Pulling the questions together, evaluating a platform on security comes down to whether it can give clear, specific, evidenced, and ideally contractual answers across the areas above, and whether its design keeps you in control of your data and the AI's actions. Rather than being reassured by confident language, look for the substance below — it is the difference between a platform you can trust and one you are simply hoping is safe.

The copy-ready security question checklist

Data use: Is our data used to train shared models or exposed to other customers? (You generally want: no.)
Access: Can we scope least-privilege access and revoke it instantly? Who at the vendor can access our data?
Retention/deletion: How long is data kept, how do we delete/export it, and how is deletion verified?
Encryption: Encrypted in transit and at rest? Where is it stored?
Sub-processors: Which third parties touch our data — can we see a current list?
Oversight: Which actions require human approval, and can we set guardrails and escalation?
Audit logs: Do we get a complete, exportable log of the AI's actions?
Compliance: What can you evidence (not just claim)? Do you offer a DPA?
Incidents: How are breaches detected, handled, and disclosed — and within what timeframe?
Exit: How do we export data and ensure deletion when we leave?

ClawHire is designed around human-in-the-loop oversight, scoped access and auditability; confirm the specifics for your requirements by talking to our team or during a free trial, and verify current compliance posture directly. See also what data an AI employee needs.

Copy-ready AI employee vendor security question checklist across data, access, oversight, compliance and incident response

Frequently Asked Questions

What are the most important AI employee security questions to ask before buying?: The most important questions cluster into a handful of areas, and asking across all of them gives you a complete picture rather than a false sense of safety from one good answer. First, data handling: is our data used to train shared or third-party models, is it ever exposed to other customers, where is it stored, and how are prompts and outputs logged? For business use you generally want your data used only to do your work. Second, access: can the AI's access be scoped to least-privilege — only the data and actions it needs — controlled granularly, and revoked instantly, and who at the vendor can access our data? Third, retention and deletion: how long is data kept, how do we delete or export it, and how is deletion verified. Fourth, encryption and sub-processors: is data encrypted in transit and at rest, and which third parties touch it? Fifth, oversight and audit: which actions stay human-approved, and do we get a complete log of what the AI did? Sixth, compliance and incidents: what can they evidence rather than merely claim, and how do they detect and disclose breaches? Ask for specifics and evidence, not reassurance, and get the answers that matter in writing and into the contract or data-processing agreement, because a posture that isn't committed can change.
How can I tell if a vendor's security answers are actually good?: A good answer is specific, evidenced, and verifiable; a weak answer is confident but vague. The tell is whether you can do something with the answer. 'We take security seriously' or 'your data is safe with us' are non-answers — they contain no commitment you could check or hold them to. By contrast, 'your data is encrypted in transit and at rest, is never used to train models beyond your account, is retained for the period you configure and deleted within a defined window of your request, and here is our data-processing agreement and sub-processor list' is a set of specific claims you can verify, compare across vendors, and write into a contract. So when you get a reassuring-but-vague reply, treat it as a prompt for a sharper follow-up rather than an answer: ask 'specifically, is our data used to train shared models?', 'can you show me that in your terms?', 'will you commit to that in the contract?'. Willingness to be specific, to provide documentation, and to commit in writing is itself a strong signal of a mature, trustworthy vendor; evasiveness, hand-waving, or reluctance to put basic protections in the contract is equally informative in the other direction. You are evaluating not just the answers but the vendor's confidence in standing behind them.
Why does 'is my data used to train your models' matter so much?: It matters because it goes to the heart of whether your confidential business information stays confidential, and it is the question vendors' answers vary on most. If a platform uses your data — your documents, customer information, internal communications, the content of your prompts — to train models that are shared beyond your account, then in effect your proprietary information could influence outputs seen by others, or simply be retained and processed in ways you did not intend. For most business use, you want a clear, documented commitment that your data is used only to perform your work, not to train shared or third-party models, and is not exposed to other customers. The nuances to probe include: whether any model customisation for you is isolated to your account; whether prompts and outputs are logged, for how long, and who can read them; and whether any data is shared with the underlying model providers and under what terms. This is not about assuming bad intent — many reputable vendors handle this well — but about confirming the specifics, because the defaults differ and the consequences of getting it wrong are significant. Get the answer in writing, ideally in the data-processing agreement, so a good practice today cannot quietly become a different practice tomorrow.
What should I ask about access control and permissions?: Access questions determine how far the AI employee's reach extends and how contained the risk is, so they deserve careful attention. The guiding principle to ask about is least privilege: the AI should have access only to the specific data and actions it genuinely needs for its role, not broad, standing access to everything. Concretely, ask whether you can scope its access narrowly, whether permissions are granular (so you can allow some data or actions and not others), and whether you can revoke access instantly if needed. Ask how its permissions relate to your existing access-control and authentication policies — can it operate within them rather than around them? Ask who at the vendor's side can access your data, under what controls, and whether that internal access is itself logged and limited. Ask what happens to access when a role changes or the engagement ends. And connect access to oversight: for consequential or irreversible actions, can access be paired with a human-approval requirement so the AI can prepare but not unilaterally execute? Strong answers describe granular, least-privilege, revocable access with limited and logged vendor-side access; weak answers are vague about scope or imply broad, hard-to-constrain access. Because an AI worker that can reach more than it should is a larger attack surface and a bigger blast radius if something goes wrong, this is one of the highest-value areas to probe.
What retention, deletion and exit questions matter?: These lifecycle questions are frequently overlooked during evaluation and frequently regretted later, so it is worth being thorough. On retention, ask how long the vendor keeps your data by default, whether you can configure or shorten that period, and what exactly is retained — the data you connect, the prompts, the outputs, the logs. On deletion, ask how you request deletion, how quickly it happens, how it is verified, and critically whether it extends to backups and any copies held by sub-processors, since data that lingers in backups is a common gap. On exit — for when you eventually leave, which you should plan for from the start — ask how you export your data, in what formats, whether it is complete, and how the vendor ensures your remaining data is destroyed after you go. Also ask whether all of this is covered in a data-processing agreement rather than just described verbally. Good answers here indicate a mature vendor who has thought about your data across its whole lifecycle and respects that it is yours; vague answers, or an inability to guarantee deletion or clean export, are a real concern both for regulatory compliance and for your basic ability to leave on your own terms without being locked in. Treat clean retention, verifiable deletion, and portable export as requirements, not extras.
How important are audit logs, and what should they contain?: Audit logs are what turn oversight from a promise into something you can actually verify, so they are very important and worth insisting on. Without a clear record of what the AI employee did, you are trusting blind; with one, you can confirm it behaved as intended, investigate anything unexpected, demonstrate compliance to auditors or regulators, and build justified confidence over time. Ask specifically what the logs capture: ideally the actions the AI took, the decisions it made, what data it accessed, when, and the outcomes — enough to reconstruct what happened. Ask whether the logs are complete and tamper-evident, so they can be relied upon. Ask whether they are available to you (not just internal to the vendor), for how long they are retained, and whether you can export them for your own records or investigations. Ask how logs tie to the human-approval and escalation events, so you can see where people were in the loop. A platform that provides comprehensive, accessible, exportable audit logs is giving you the transparency that makes an AI worker trustworthy and manageable; one that cannot show you what its AI did, or keeps logs opaque or inaccessible, is asking for a level of blind trust that is hard to justify in a business context. Make auditability a firm requirement rather than a nice-to-have.
What compliance and incident-response questions should I ask?: On compliance, the key discipline is to ask for evidence rather than accept adjectives. Terms like 'enterprise-grade', 'bank-level' or 'fully compliant' are marketing language with no fixed meaning, so ask instead which specific security standards or frameworks the vendor aligns with or formally holds, and ask them to provide documentation, reports, or attestations you can review. Ask whether they offer a data-processing agreement, and whether they can support the particular regulations that apply to your business, industry, or customers — privacy laws, sector rules, or regional requirements. Where vendors hold formal certifications they can show them; where they align with frameworks like the NIST AI Risk Management Framework or established security practices, they can describe concretely how. On incident response, since no platform can promise nothing will ever go wrong, focus on how they respond: how they detect security incidents, whether and how quickly they will notify you of a breach affecting your data, what their documented process is, who your point of contact would be, and whether they test their response. Ideally, breach-notification commitments are reflected in your contract. A vendor who can evidence a real compliance posture and a clear, tested incident-response and notification process is demonstrating operational maturity; one who offers only confident adjectives and no documentation, or is vague about what happens in a breach, has not earned the same trust. Verify specifics directly rather than assuming any particular certification.
Should these security commitments be in the contract?: Yes — the commitments that matter should be captured in writing, in the contract or an accompanying data-processing agreement, and this is one of the most protective steps you can take. The reason is simple: a security posture that exists only in a sales conversation or a marketing page can change, quietly and without your knowledge, as the vendor's practices, personnel, or business circumstances evolve. A commitment written into your contract is durable and enforceable; a verbal assurance is neither. So once you have asked the questions and are satisfied with the answers, identify the commitments that are genuinely important to you — typically how your data is used (especially the no-training-on-shared-models point), retention and deletion terms, breach-notification obligations and timelines, sub-processor terms and change notifications, encryption, and the availability of audit logs — and ensure they appear in the contractual documents rather than living only in an email or a call. Requesting a data-processing agreement is a natural vehicle for much of this. Beyond the protection it provides, this step doubles as a final due-diligence signal: a vendor confident in their security posture is generally willing to stand behind it in writing, while reluctance to commit basic, reasonable protections contractually is itself informative and worth weighing in your decision. In short, ask the questions, get specific answers, and then make the important ones real by putting them in the contract.