Your CLOUD Act Exposure Audit: The Step-by-Step Guide for UK Small Businesses
On the podcast this week, Mauven laid out a simple framework for mapping your US vendor dependency. Corrine expanded the legal analysis on Tuesday. Mauven connected it to business risk on Wednesday.
Today, we turn all of that into something you can actually do. This afternoon, if you clear two hours.
I am not going to dress this up. The audit is not complicated. It does not require a consultant. It does not require specialist tools. It requires honesty, a spreadsheet, and a willingness to write down things you have been quietly ignoring.
Let's go.
What You Need Before You Start
People: You and whoever manages your IT. If that is an external MSP, book a call with them. If it is Dave who "does the computers," sit Dave down with a cuppa.
Tools: A spreadsheet. Google Sheets, Excel, LibreOffice, whatever you have. Or a whiteboard and a phone camera if you prefer.
Time: Two hours for the initial audit. Another hour for the crown jewels assessment. Thirty minutes to check encryption key status. This is a half-day exercise.
Documents to hand: Your current vendor list (most businesses do not have one, so part of this exercise is creating it), your latest Data Protection Impact Assessment if you have one, and any client contracts that reference data handling or UK data residency.
Step One: Map Your Vendor Landscape
Create a spreadsheet with these columns:
System/Service | Vendor | Vendor HQ Country | Parent Company HQ | Data Storage Location | US Jurisdiction? | Data Types Held | Sensitivity Level
Now list every system that touches business data. Every single one. Not just the big platforms. The forgotten ones are usually the riskiest.
Start with these categories:
Email and collaboration: Microsoft 365, Google Workspace, Slack, Teams (part of M365), Zoom, etc.
Document storage: SharePoint, OneDrive, Google Drive, Dropbox, Box.
Customer relationship management: Salesforce, HubSpot, Pipedrive, Zoho.
Finance and accounting: Xero (NZ-headquartered but uses AWS), QuickBooks (Intuit, US), Sage (UK-headquartered, worth checking hosting).
HR and payroll: BreatheHR, BambooHR (US), Gusto (US), Moorepay (UK).
Help desk and ticketing: Zendesk (US), Freshdesk (India/US), Jira Service Management (Atlassian, Australia but US-listed).
Marketing and email: Mailchimp (Intuit, US), ActiveCampaign (US), HubSpot (US).
Backup and disaster recovery: Veeam (US), Acronis (Switzerland/Singapore), Backblaze (US), Carbonite (US). Also check: does your M365 backup tool copy data to a US-owned cloud?
Monitoring and endpoint protection: CrowdStrike (US), SentinelOne (US), Sophos (UK, owned by Thoma Bravo, US PE firm), Darktrace (UK).
Website and hosting: AWS, Azure, Google Cloud, Cloudflare (US), Squarespace (US), Wix (Israel).
Communication: Zoom (US), RingCentral (US), 8x8 (US), Vonage (Ericsson, Sweden).
Project management: Monday.com (Israel), Asana (US), Trello/Jira (Atlassian), Basecamp (US).
For each entry, determine the vendor's headquarters country and, critically, the parent company. Ownership matters. Sophos is a UK company, but it is owned by Thoma Bravo, a US private equity firm. That changes the jurisdictional analysis. If the ultimate controlling entity is US-headquartered, mark it as potentially subject to US jurisdiction.
The "Data Storage Location" column matters, but less than people think. As Tuesday's article explained, the CLOUD Act applies based on the company's jurisdiction, not where the servers are. A "UK data residency" option from a US company does not exempt it from US legal process.
When you finish, you will probably have 15 to 25 entries. Most small businesses do. And the majority will be US-flagged. That is fine. This is not about panic. It is about seeing the water you are swimming in.
Step Two: Identify Your Crown Jewels
Not all data deserves the same protection. Your calendar invites and internal banter about Friday's lunch order do not need sovereign-grade encryption. Your client database, financial records, and HR files might.
Go through your vendor list and mark each system's sensitivity level as Low, Medium, or High based on this question: If this data set were exposed, handed to a foreign authority, or published in a news article, what would actually hurt us?
High sensitivity data typically includes:
Client or patient personal data, especially health, financial, or vulnerability information. Legal correspondence and privileged communications. Board minutes and strategic planning documents. HR investigation files, disciplinary records, whistleblower reports. Intellectual property, bid documents, trade secrets. Donor and beneficiary records for charities. Financial projections, merger discussions, investor communications.
Medium sensitivity data typically includes:
General client relationship data (contact details, meeting notes). Internal project documentation. Standard financial records (invoices, purchase orders). Marketing databases and campaign analytics. General internal communications.
Low sensitivity data typically includes:
Published marketing materials. General scheduling and calendar data. Non-confidential internal announcements. Training materials and standard operating procedures.
For each High sensitivity system, note whether it is on a US-owned platform. If it is, that is your priority list.
Step Three: Check Who Controls the Encryption Keys
This is the step most businesses skip. It is also the most important.
For each High sensitivity system on a US-owned platform, determine the answer to this question: Could the vendor, if compelled by a US court, decrypt and produce your data without your involvement?
Here is how to check for the most common platforms:
Microsoft 365: Check your Entra ID (Azure AD) settings. Are BitLocker recovery keys automatically escrowed to Microsoft? (In most M365 tenants, they are, by default.) For M365 data at rest, are you using Microsoft-managed keys (default), Customer Key, or Double Key Encryption? If you do not know the answer, you are using Microsoft-managed keys, which means Microsoft can decrypt your data.
Google Workspace: Google offers Client-side Encryption for Business Plus and Enterprise tiers. If you are not using it (most small businesses are not), Google manages the encryption keys and can decrypt data if compelled.
AWS/Azure hosted applications: Check whether your application encrypts data at the application layer with keys you control, or relies on the cloud provider's default encryption. Default encryption protects against physical theft of drives. It does not protect against a legal demand directed at the provider.
SaaS platforms generally: Most SaaS providers encrypt data at rest using their own keys. Unless you have specifically configured customer-managed encryption (and you would know if you had), the provider can decrypt your data.
The practical test is Noel's principle from the podcast: if the provider can help you recover your data when you have locked yourself out, they can also be compelled to help someone else access it when you would rather they did not.
For each High sensitivity system, record the encryption key status as one of:
Provider-managed keys: The vendor controls decryption. They can be compelled to produce decrypted data. This is the default for nearly all SaaS platforms.
Customer Key with availability key: You hold root keys, but the provider retains a backup key (this is how M365 Customer Key works). Partial protection only.
Customer-managed keys (no provider access): You control all decryption capability. The provider can only produce ciphertext if compelled. This is rare and typically requires enterprise-tier licensing.
Step Four: Fold Into Your DPIAs and Procurement
If you do formal Data Protection Impact Assessments (and under UK GDPR, you probably should for high-risk processing), your CLOUD Act audit findings belong in them.
For each system processing personal data on a US-owned platform, your DPIA should now address:
Transfer risk assessment: The ICO's updated January 2026 guidance requires a three-step test for restricted transfers. Even if data stays in the UK physically, the CLOUD Act creates a potential transfer mechanism that should be assessed.
Legal basis for processing: Your Article 6 basis remains the same, but the jurisdictional risk affects your Article 5(1)(f) obligation (integrity and confidentiality). If you cannot demonstrate you have assessed foreign government access risk, your accountability documentation has a gap.
Vendor contract review: Check whether your Data Processing Agreements with US vendors address the CLOUD Act conflict explicitly. Most do not. Microsoft's standard DPA mentions resisting "overbroad government requests" but does not guarantee immunity from valid US court orders.
For procurement going forward, add these four questions to every new vendor assessment:
Where is the vendor headquartered, and where is its ultimate parent company based?
Is the vendor subject to the US CLOUD Act or equivalent foreign legal process provisions?
Who controls the encryption keys, and can the vendor decrypt customer data independently?
If we needed to extract all our data and leave within 12 months, could we? What format would the export take?
Mauven put this perfectly on the podcast: those are not trick questions. A decent vendor should be able to answer without hand-waving.
Step Five: Build a Realistic Exit Plan
This is not about migrating everything to a European provider next month. It is about knowing you could if you needed to.
For each High sensitivity system on a US-owned platform, document:
Data export capability: Can you extract all your data in a standard, usable format? How? How long would it take? Is there an export fee?
Alternative providers: Identify at least one non-US alternative for each critical system. You do not need to sign a contract. You need to know the option exists.
Migration complexity: Estimate the effort to switch. Some systems (email) are relatively portable. Others (deeply customised CRMs) could take months. Knowing this in advance is the point.
Trigger conditions: Under what circumstances would you actually migrate? An ICO enforcement action in your sector? A client demand? A contract requirement? A geopolitical event? Define the triggers now, when you are thinking clearly, not when you are under pressure.
Here are some non-US alternatives worth knowing about for the most common categories:
Email and collaboration: Proton for Business (Switzerland), Tutanota/Tuta (Germany), Nextcloud (Germany, self-hosted or EU-hosted options).
Cloud storage: Nextcloud, OwnCloud (Germany), Tresorit (Switzerland, owned by Swiss Post), pCloud (Switzerland).
CRM: SuiteCRM (UK, open source), Odoo (Belgium), Twenty (France, open source).
Backup: Hetzner (Germany, object storage), Wasabi (US, but evaluating), OVHcloud (France).
Video conferencing: Jitsi (open source, self-hosted), Element/Matrix (UK-based, used by French government, Bundeswehr, NATO).
Office suite: LibreOffice, ONLYOFFICE (Latvia), Collabora Online (UK).
This list is not exhaustive and not an endorsement. It is a starting point. The NCSC does not maintain a sovereign alternatives list, which is itself a gap worth noting.
Step Six: Document Everything
Your audit is only valuable if it is recorded. Create a summary document that includes:
Date of audit. This is a point-in-time assessment.
Systems assessed. The full vendor landscape map.
Crown jewels identified. Your High sensitivity data sets and where they live.
Encryption key status. Provider-managed vs customer-managed for each critical system.
Risk assessment. A plain English statement of your CLOUD Act exposure.
Mitigation actions taken or planned. What you have done and what you intend to do.
Review schedule. When you will repeat this assessment (annually, minimum).
This document serves three purposes. It demonstrates to the ICO that you have assessed the risk. It provides evidence for client and procurement questionnaires. And it protects your directors by showing the board discussed and addressed the issue.
How to Turn This Into a Competitive Advantage
Include your audit findings in tender responses. "We have conducted a documented CLOUD Act exposure audit, identified our crown jewel data, and implemented proportionate protections" is an answer that wins contracts, particularly in public sector, healthcare supply chain, and legal services.
Use it in client onboarding. Proactively sharing your data sovereignty assessment with new clients builds trust before they ask. It demonstrates a level of governance maturity that competitors cannot match.
Reference it in your annual report or governance statement. For charities, this is particularly powerful. Trustees demonstrating they have assessed jurisdictional risk to beneficiary data show the kind of diligence the Charity Commission expects.
How to Sell This to Your Board
The pitch: "I would like one afternoon with IT to map our cloud vendor dependencies and assess whether any sensitive data sits on platforms subject to foreign legal jurisdiction. The output is a one-page governance document showing we have assessed and documented the risk."
The cost: Approximately four hours of staff time. No external spend required.
The benefit: Regulatory compliance evidence, competitive advantage in procurement, and protection against the question nobody can answer today: "Where does our sensitive data actually live, and who can access it?"
The urgency: European governments are actively restricting US cloud services. UK regulation is heading in the same direction. Clients are starting to ask. Being prepared now costs four hours. Being unprepared when someone asks costs considerably more.
What This Means for Your Business
Block two hours this week to start Step One. Just the vendor mapping. Everything else flows from there.
Ask your MSP or IT lead one question: "Which of our encryption keys are managed by our providers, and which do we control?" Their answer will tell you everything.
Download the ICO's Transfer Risk Assessment template from ico.org.uk and complete it for your primary US cloud provider. This takes 30 minutes and gives you a documented assessment.
Put "Data Sovereignty Risk" on your next board or trustee meeting agenda. One item. Five minutes. The output is a recorded decision that the board has been briefed and approved a response.
Come back tomorrow for Friday's case study comparing how Switzerland and the UK assessed the exact same vendor risk and reached opposite conclusions. It will make the urgency of this audit clearer than anything else this week.
Listen to the Full Discussion
The practical framework in this guide was discussed in detail in Season 2, Episode 7 of The Small Business Cyber Security Guy podcast.
