Security questionnaires and compliance posture for an AI service desk

If you run an internal service desk with an AI layer, you are on both sides of this. Your own customers or auditors will send you questionnaires about the system, and you will send questionnaires to the vendor whose model is reading your tickets. The useful thing is that one lens serves both directions: know what each artefact actually proves, and ask the specific question rather than the ceremonial one.

Most security reviews fail on ceremony. A buyer asks whether you are SOC 2 compliant, receives a yes, ticks the box, and learns nothing about whether the thing they are worried about is covered. Below is what the common frameworks attest to, what they do not, and the questions that carry real information for an AI service desk in particular.

SOC 2 is an attestation report produced by an independent auditor against the Trust Services Criteria — security, and optionally availability, processing integrity, confidentiality, and privacy. Crucially, the controls being tested are ones the organisation defined for itself. The auditor tests whether those controls are described fairly and, in a Type II report, whether they operated effectively over a period of time. A Type I report only covers design at a point in time, which is a much weaker statement.

What it does not tell you: that the product is secure, that your specific data flow is covered, or that no exceptions were found. Scope is chosen, and it can exclude the system you care about. So ask for the report itself under NDA rather than the badge, then read three things — the scope section, which criteria were included, and the exceptions or deviations the auditor noted along with management responses. A vendor with a couple of noted exceptions and a clear remediation is often in better shape than one whose report you were never allowed to read.

ISO 27001 certifies an information security management system — that the organisation has a governed process for identifying risk and applying controls, audited by an accredited body. The document that carries the actual content is the Statement of Applicability, which lists which controls were deemed applicable and which were excluded, with justification. Certificate without Statement of Applicability is a logo. Ask for the scope statement too, because certification can cover one business unit and not the one selling to you.

HIPAA is a law, not a certification, and no authority issues a HIPAA certificate. What can genuinely exist is a signed Business Associate Agreement, documented administrative, physical, and technical safeguards, and a third-party assessment against the Security Rule. If a vendor claims to be HIPAA certified, that is a vocabulary error at best. The question that carries information is whether they will sign a BAA, for which product tiers, and which sub-processors are covered by it.

The same discipline applies to GDPR: there is no GDPR certificate. What exists is a Data Processing Agreement, a lawful basis, a documented transfer mechanism, and a sub-processor list. Ask for those documents.

Data residency questions usually conflate storage and processing. Ask separately: where is data at rest, where is it processed, where do backups live, and where does support staff access it from. A vendor can store data in the EU while a model provider processes prompts in another region, and that distinction is exactly what a data protection review is trying to surface.

Sub-processors are where AI vendors carry more risk than traditional software, because a model provider is a sub-processor with unusually broad exposure to content. Ask for the current list, the notice period before a new one is added, and whether you can object. Then retention: how long tickets, attachments, logs, and derived artefacts are kept, and — the question most often missed — what happens to derived data such as embeddings, vector indexes, and cached model outputs when you delete a ticket or terminate. Deletion that leaves an embedding of the deleted content behind is not deletion, and a vendor who has thought about this will answer immediately.

Do you train on our data is the standard question and it is too blunt to be useful, because a vendor can honestly answer no while your content still passes to a third-party model, is retained for abuse monitoring, and is reviewable by humans. Ask the components instead. Is customer content used to train or fine-tune any model, including internal ones? Which model providers receive prompts and completions, under what contractual terms, and is there a zero-retention or no-training arrangement in place? How long does the provider retain prompts, and can content be reviewed by a human during that window? Is content used for evaluation or quality review internally, and by whom?

Then the agent behaviour questions, which are the ones an internal service desk should care about most. What sources is the agent grounded in, and does it inherit the requester permissions or the permissions of a service account with broader access? That single question catches the most serious failure mode in this category — an agent that will happily summarise a document the asker was never allowed to read. What actions can the agent take autonomously, at what granularity is that configured, what is written to the audit trail, and can autonomous action be disabled per category without disabling the product?

On the answering side, the discipline is simple and often ignored. Keep one source of truth for security answers, owned by whoever actually operates the system, and answer from it rather than from memory. Where the answer is not yet, say not yet and give the status — reviewers who deal with dozens of vendors respect a plain no far more than a hedged yes, and a hedged yes discovered later ends the relationship.

Do not let a sales conversation answer engineering questions, because a well-meaning approximation becomes a contractual representation. Publish a trust or security page with your current posture, sub-processor list, and the documents you can share under NDA — it removes most of the repetitive questionnaire load and signals that the answers are maintained rather than assembled per deal. And keep your own vendor questionnaires proportionate to blast radius: a tool that reads your production incidents and can act on systems deserves a real review, and a read-only reporting widget does not deserve the same 300 rows.

Since we build an AI service desk, the relevant disclosures: intake spans Slack, Teams, email, and WhatsApp; triage is grounded in the linked codebase and resolved history; autonomous resolution is allow-listed per category with a full audit trail, and suggest and approve modes exist precisely so autonomy is something you grant deliberately rather than inherit; data residency is selectable across EU, US, and India.

On certifications and current compliance posture specifically, we would rather point you at the maintained source than assert anything in a blog post that may age badly — the security page carries the current position, the documents available under NDA, and the sub-processor detail. That is also the standard we would suggest holding every vendor on your shortlist to: a maintained page, not a claim in a sales deck.

A workable process for an AI service desk review: establish what data the system will actually see, including the systems it is grounded in; request the attestation reports and read the scope and exceptions rather than the cover page; get the sub-processor list and the model provider terms; confirm residency separately for storage, processing, and support access; confirm retention and what happens to derived artefacts on deletion; and confirm the permission model for autonomous actions along with what the audit trail records.

Six questions, answered specifically, tell you more than a 300-row spreadsheet answered ceremonially. And if a vendor cannot answer the derived-data deletion question or the permission-inheritance question crisply, that is information about their engineering, not just their paperwork.