Somewhere between a successful pilot and a signed contract, a UAE buyer’s information security team sends a spreadsheet. It has two hundred questions, or four hundred, and a deadline. For a small supplier it arrives as a surprise, lands on whoever is least busy, and sits half finished for a month while the sale goes cold.
It should not be a surprise. The questions are predictable, most of the answers are facts about how you already work, and a supplier who has them ready looks like the safer choice before anyone reads a word.
Why it arrives now, and why it stalls everything
During a pilot, the product usually runs on test data, in a sandbox, or for a handful of users, and the security team is not involved. The moment the conversation turns to production, with real records and real staff, it becomes their decision, and they will not approve what they have not assessed. That is the step that follows the silence after a successful pilot, and it is usually the longest.
The questionnaire is not a formality to them. It is how they decide which risks they are accepting and document that they asked. An incomplete answer does not get waved through; it gets a follow-up, and each follow-up round costs a week.
What it usually looks like
Most questionnaires are built from a known framework with the buyer’s own questions added. A common base is the Cloud Security Alliance’s Cloud Controls Matrix and its questionnaire, the CAIQ, which turns a long list of security controls into yes-or-no questions with space for explanation. Large buyers also use their own templates, often longer and less tidy.
Regulated sectors add their own layer. In Abu Dhabi healthcare, the Department of Health’s ADHICS standard applies to any entity that stores, processes or deals with health information from the emirate, and runs to 692 controls across 11 domains. A supplier handling that data is inside its scope, whatever the size of the company.
Who in your company answers it
Not sales, and not whoever is free. The answers commit the company: a wrong “yes” becomes a contractual promise, and a careless “no” can end the deal. One technical owner should answer, with the founder reading every line before it goes back.
In a small company that owner is often the person who built the product and has no time. That is a real constraint, and it is a good reason to prepare the answers once, properly, rather than rebuilding them for every buyer. Where nobody on the team can own it, a fractional CTO can, for the weeks it takes.
Keep a record of what was answered to whom. Two buyers in the same group will compare notes, and a supplier whose answers differ between them without a reason loses the trust both reviews were trying to establish. The master answers, a dated copy of each submission, and the questions that came back are the whole file.
Where the data lives: the question that ends conversations
Every questionnaire asks where the data is stored, processed and backed up, and for some buyers the answer decides everything. For health data it is not a preference: the ADHICS guidance states that health information related to services provided in the UAE may not be stored, developed or transferred outside the country, under Federal Law No. 2 of 2019 on the use of ICT in healthcare.
So know your answer precisely: which region your hosting runs in, where backups go, and where every service you depend on processes data. Backups and third-party tools are where “in the UAE” usually stops being true, as the hosting decision in the UAE sets out. If the honest answer is “outside”, say so and say what you would change for this buyer, rather than finding out in the contract review.
Who can reach it
The access section asks who in your company can see production data, how they log in, and what happens when someone leaves. Buyers want to hear: named people only, multi-factor authentication everywhere, access reviewed on a schedule, and removed on the day someone goes.
Small teams often share a single admin login for convenience. That is the answer that fails a review, and it is fixable in an afternoon. Fix it before the questionnaire, not while writing it, so the answer is true when you give it.
Expect questions about logging as well: whether access to production data is recorded, how long the records are kept, and who reviews them. A simple, honest answer is enough at this size, as long as the logs exist and somebody could produce them if the buyer asked about a specific date.
The third parties inside your product
Every service your product relies on is part of the buyer’s risk: the cloud host, the email provider, the error tracker, the analytics, and for any AI product, the model provider that receives the data. The questionnaire will ask for a list of these sub-processors, what each one receives, and where.
For AI products this is the section that surprises founders. If customer text is sent to a model hosted abroad, that is a data transfer the buyer has to approve, and under the UAE’s data protection law it has conditions. Keep a current list, one line per provider: what it does, what data it sees, where it runs. It is also the list your own staff should be working from, which is a policy question inside your own company as much as a buyer’s.
What happens when something goes wrong
Buyers ask how you would detect a breach, who you would tell, and how quickly. They are not expecting a small supplier to run a security operations centre. They are checking that there is a written plan, a named person, and a commitment to notify them within a defined time.
Write the plan on one page: how incidents are noticed, who decides it is an incident, who informs the customer, within how many hours, and what gets written down afterwards. A one-page plan that exists beats a twenty-page policy that does not.
Test it once before a buyer does. Pick a date, pretend a laptop with production access was stolen, and walk through the plan with the team. The gaps show up in the first ten minutes, and fixing them is far cheaper than discovering them in front of a customer.
The answers you do not have
Every small supplier has gaps: no ISO 27001 certificate, no penetration test this year, no formal disaster recovery test. The worst response is to answer “yes” and hope. Security teams check, and a single claim that turns out to be false makes every other answer worthless to them.
Answer “no”, then explain what you do instead and when the gap will close. “No certification; controls aligned to the CAIQ; external penetration test scheduled for the first quarter” is an answer a reviewer can work with. Many buyers accept a remediation plan with dates, especially for a first contract sized within a lower approval limit.
Build the pack once
The practical move is to write your answers to a standard framework once, keep them current, and send them before you are asked. The CAIQ works well as a skeleton because so many buyer templates are built on it, and the Cloud Security Alliance lets companies publish a self-assessment on its STAR registry at its first level, which gives buyers something to read before their own spreadsheet goes out.
Alongside it: an architecture diagram showing where data flows, the sub-processor list, the incident plan, and the access policy. Four documents and a questionnaire, reviewed every six months. It is also exactly what a buyer’s technical due diligence will go looking for. Where the assistant or system itself has to be rebuilt to pass, Tothiq AI Services and Solutions builds custom assistants with UAE hosting and a documented data flow from the start.
Review the pack whenever the product changes what data it touches or where it runs. A new model provider, a new region, a new analytics tool: each changes an answer. The pack that was true in March and is quietly wrong in September is worse than none, because the buyer relied on it.
Frequently asked questions
Do we need ISO 27001 to sell to UAE enterprises?
Not always, though it shortens reviews. Many buyers accept a completed questionnaire, a clear remediation plan and a smaller first contract. Some regulated buyers do require certification or a specific sector standard, so ask early rather than assuming either way.
How long does a security review usually take?
Weeks when the answers are built from scratch, days when a pack is ready. Most of the delay is follow-up rounds on vague answers, so specific, honest answers are the fastest route.
Our AI product uses a model hosted outside the UAE. Is that a deal-breaker?
For health data it usually is, because health information from UAE services may not leave the country. For other data it depends on the buyer and on data protection conditions. Know which model regions are available to you before the question is asked.
Can we reuse the same answers for every buyer?
Mostly, yes. Keep a master set mapped to a standard framework and adapt it per buyer. The core facts about hosting, access, sub-processors and incidents do not change from one questionnaire to the next.
Should the founder answer it personally?
The founder should read and approve every answer, because the answers become commitments. The technical owner should write them. Sales should not answer them at all.