A small property management firm in the East Midlands found out their cloud storage was misconfigured when a prospective client Googled their company name and found a publicly accessible folder containing tenancy agreements, passport copies, and bank statements for hundreds of tenants. Nobody had intentionally made it public. A developer had set up an S3 bucket during a software evaluation, left the “public access” setting on, and the business had forgotten it existed.
That’s cloud misconfiguration. It’s not a sophisticated attack. It’s not malware or a phishing campaign. It’s a setting that shouldn’t be on, sitting quietly in an account nobody’s reviewing, waiting for someone — a curious person, an automated scanner, an organised threat actor — to find it.
What Cloud Misconfiguration Actually Means
Cloud services — Amazon Web Services, Microsoft Azure, Google Cloud — are genuinely powerful, but they come with an enormous array of settings, many of which have permissive defaults designed for ease of development rather than production security. The problem is that most small businesses set these services up once, by someone who knows enough to get things working, and then never review them again.
The most common issues:
Public cloud storage. AWS S3 buckets, Azure Blob containers, and Google Cloud Storage buckets can be configured to allow public read access. When they are, anyone with the URL — or anyone running an automated scanner looking for open buckets — can download everything in them. This is the classic misconfiguration, and it still accounts for a huge number of data breaches. AWS added account-level “block public access” settings a few years back; they’re on by default for new accounts, but older accounts or specific bucket configurations can override them.
Overpermissioned accounts. Cloud IAM (Identity and Access Management) works on the principle of least privilege — give each user and service only the permissions they need. In practice, small businesses often create single admin accounts that get used for everything, or attach policies like AdministratorAccess because it’s quick and “it’ll do for now.” An overpermissioned account that gets compromised (through a phishing email, a leaked API key, a reused password) gives an attacker full control of your cloud environment.
Exposed databases. MongoDB, Redis, Elasticsearch, and other databases are frequently spun up in cloud environments with no authentication enabled and network access wide open to the internet. Automated scanners find these within hours. The breach risk is obvious; what’s less obvious is that attackers often don’t just steal the data — they delete it and demand a ransom for the backup.
Forgotten test environments. Development and staging environments get created, used briefly, and then left running — with real or realistic data copied in for testing purposes. These tend to have weaker security configurations than production, and nobody’s paying attention to them.
Misconfigured cloud functions and APIs. Serverless functions (AWS Lambda, Azure Functions) and API Gateways can be deployed without authentication requirements, exposing business logic and any data they can access to unauthenticated requests.
Why This Is a GDPR Problem
Under UK GDPR, you’re responsible for the security of personal data you hold, regardless of whether the breach was technically your fault or “just a misconfiguration.” The ICO has been clear about this. If personal data is exposed because of a misconfigured cloud service, that’s a data breach — and if you hold personal data about more than a handful of people (which essentially every business does), you may need to report it to the ICO within 72 hours of becoming aware of it.
The ICO has issued reprimands and fines specifically for misconfigured cloud storage. You don’t need to be a large organisation to attract attention; the ICO investigates small businesses when complaints are made or when breaches are self-reported.
Beyond the regulatory angle, there’s the business impact. Clients whose data was exposed through a misconfiguration don’t much care about the technical explanation. A property firm that exposes tenant passports, a dental practice that leaves patient records publicly accessible, an accountancy firm with client bank statements in a public bucket — these aren’t abstract risks. They’re business-ending incidents for small firms.
How to Find Out If You Have a Problem
You probably don’t have dedicated security staff, so the approach needs to be practical.
Start with your cloud provider’s built-in tools. AWS Trusted Advisor and AWS Security Hub flag misconfigured resources. Azure Security Center and Azure Advisor do the same. These tools are available within your existing account and require no specialist knowledge to run. Log in to your cloud console and look for the security section — it will tell you whether any S3 buckets are public, whether MFA is enabled on accounts, whether there are overpermissioned roles.
Review public access settings on storage. In AWS, go to S3 → Block Public Access settings for this account. Make sure all four settings are on. Then review each bucket individually to confirm there are no bucket-level policies overriding the account setting. In Azure, go to each Storage Account and check the “Allow Blob public access” setting under Configuration — it should be disabled for production accounts holding real data.
Audit your accounts and access keys. Review which accounts exist in your cloud environment, what permissions they have, and whether any access keys are long-lived and unused. IAM access keys that were created years ago and never rotated are a significant risk — if they’ve leaked anywhere (a public GitHub repository, an old development machine), they’re exploitable. AWS IAM Access Analyzer can identify overly permissive policies.
Check what’s internet-facing. If you’re running any databases, look at whether they’re in a public subnet with security groups that allow inbound connections from 0.0.0.0/0 (anywhere on the internet). They shouldn’t be.
Cloudflare Zero Trust has a free tier that can add an authentication layer in front of applications that should only be accessed internally. This doesn’t replace fixing the underlying misconfiguration, but it reduces exposure while you’re getting things sorted.
The NCSC’s Practical Guidance
NCSC’s Cloud Security guidance for small organisations is worth reading — it’s not technical to the point of being inaccessible, and it covers the main points clearly. The Cyber Essentials scheme, which covers basic security controls including access control and patch management, doesn’t specifically address cloud misconfiguration in its current version, but getting Cyber Essentials certification generally forces a review of access controls that helps.
The most useful thing most small businesses can do right now is spend two hours going through the security recommendations in their cloud provider’s console. You don’t need to understand everything; you need to know which resources are public that shouldn’t be, and which accounts have more access than they need.
Cloud providers want you to use their services securely — they’ve invested heavily in making the tooling accessible. The gap is usually awareness: businesses that don’t know to look for the problem don’t find it until something goes wrong.