In Brief: Cloud provider due diligence means asking who can access your data before you sign, not after a breach. Five direct questions cover staff access, sub-processors, government requests, and your GDPR liability as data controller.
Most SMEs signing up with a cloud provider spend more time comparing storage tiers than asking who, precisely, can open their files. That oversight is worth fixing before you commit, not after a breach makes the question urgent. Cloud provider due diligence is not a bureaucratic checkbox; it is the process of understanding exactly what you are agreeing to before someone else holds your data.
The good news is that you do not need a legal team to ask the right questions. You need five specific ones, asked directly, before you sign anything.
Why Cloud Provider Due Diligence Matters More Than Most SMEs Realise
When a business moves data to the cloud, it does not give up ownership. What it does give up, at least temporarily, is physical control. Your customer records, financial data, and internal communications now sit on infrastructure owned by someone else, maintained by staff you have never met, and governed by contracts that your provider’s legal team wrote.
That is not inherently a problem. Cloud infrastructure is often more secure than an SME’s own server room. The problem is assuming that ‘secure’ means ‘private from everyone, including the provider’. It frequently does not. Provider employees, sub-processors, and in some cases government agencies may all have routes to your data depending on where the provider is headquartered and what their contracts actually say.
The UK’s ICO is clear that under GDPR, you remain the data controller. Your liability does not transfer just because the data moved to AWS, Google Cloud, or a smaller specialist provider. If a subject access request arrives, or a regulator asks questions, the responsibility lands with you.
The Five Data Access Questions Worth Asking
These are not aggressive demands. They are reasonable questions that any reputable provider should answer without hesitation. If the answer is vague, deflected, or buried in a reference to a 40-page terms document, that tells you something useful.
1. Which of your employees can access our data, and under what circumstances?
This is the most basic question and, surprisingly, one of the least often asked. You want to know whether access is role-based, whether it is logged, and whether it requires a reason to be recorded. A good answer will describe a specific access control policy. A poor answer will say ‘only authorised staff’ without explaining what authorisation actually means in practice.
Some providers operate on a zero-knowledge model, where encryption means even their own engineers cannot read your files. Others can access data freely for support or maintenance purposes. These are very different arrangements. Know which one you are in.
2. Where is our data stored, and which legal jurisdictions apply?
A provider based in the United States, even one with servers in the UK or EU, may be subject to US legal frameworks that require cooperation with American government requests. The CLOUD Act, for instance, allows US authorities to compel US-based companies to hand over data regardless of where it is physically stored.
This is not a reason to avoid US-headquartered providers entirely. It is a reason to know the answer before assuming that a UK server address means UK-only legal exposure. Ask specifically: ‘If a government authority requests access to our data, which country’s laws govern that process, and would we be notified?’
3. Who are your sub-processors, and what access do they have?
Almost every cloud provider uses sub-processors, meaning third-party companies that handle parts of the service. This might be a backup provider, a monitoring tool, or a customer support platform. Each of those sub-processors potentially touches your data. Under GDPR, your provider is required to maintain a list of them and to notify you of changes.
Ask for that list. Ask whether sub-processors are contractually bound to the same data protection standards as the provider. If the answer is ‘yes, it is in our DPA’, ask to see the DPA rather than taking that on trust. A data processing agreement that exists on paper but says nothing specific is not protection.
4. What happens to our data if we end the contract?
This question is less about access during the relationship and more about what happens on the way out. Some providers retain data for months after a contract ends. Others delete it within days but charge for the export process. A few make it genuinely difficult to retrieve data in a portable format, which is both an operational risk and a potential GDPR issue given the right to data portability.
Ask: ‘After we terminate, how long do you retain our data, and can we retrieve it in a standard format at no additional cost?’ The answer shapes your exit strategy. You should have one before you sign in.
5. How do you notify us if there has been a breach, or if someone requests access to our data?
Breach notification timelines matter under UK GDPR. You have 72 hours to notify the ICO once you become aware of a breach that poses a risk to individuals. That clock does not start when your provider eventually emails you. It starts when you become aware. If your provider’s notification process is slow or unclear, your 72-hour window shrinks accordingly.
Ask the same question about government or legal access requests. Will they tell you if a third party has asked to see your data? Many providers include gag clauses in government cooperation processes, meaning they legally cannot inform you. That is a fact worth knowing, not a reason to panic, but worth factoring into what data you put where.
Building Your SME Cloud Security Checklist
These five questions are a starting point, not a complete audit. If you are building a broader SME cloud security checklist, you would add questions about encryption standards, penetration testing schedules, incident response procedures, and SLA terms around availability. But data access is the right place to start because it addresses the most fundamental question: do you actually know who can see what you are storing?
A useful habit is to treat the sales call as the worst time to ask these questions, because it is. Ask them during or after the technical review, when you are talking to someone who actually manages the infrastructure rather than someone who manages the relationship. The answers tend to be more honest and more specific.
What to Do With the Answers
If you get clear, documented answers to all five questions, you are in a reasonable position to make an informed decision. If answers are vague, inconsistent between the sales team and the technical team, or require signing an NDA before the provider will share them, those are genuine warning signs. Not dealbreakers automatically, but signals that the provider has not built transparency into how they operate.
Document the answers you receive. If something goes wrong later and you need to demonstrate due diligence to a regulator or insurer, having a written record of what you asked and what you were told is considerably more useful than a signed contract you never read in full.
The Bottom Line
- Ask who at the provider can access your data and under what conditions, not just whether access is restricted.
- Find out which legal jurisdiction applies to your data, particularly if the provider is headquartered outside the UK.
- Request a full list of sub-processors and check whether they are bound by equivalent data protection terms.
- Clarify what happens to your data when the contract ends, including format, timeline, and any associated costs.
- Confirm breach and access-request notification procedures in writing before you go live.
If asking these questions feels uncomfortable, consider that a provider who finds them inconvenient is probably not the right fit for a business that takes data responsibility seriously.
