Preventing Cloud Misconfiguration: A Healthcare Checklist
Cloud breaches in healthcare are almost never a provider failure. They are a storage bucket, an over-permissive role or a database exposed by someone who meant well.
GuardsArm Team
Security Experts
Cloud providers rarely fail. What fails is configuration — a storage container made public to fix an access problem at 6pm, a role granted broad permissions because scoping it was slow, a database spun up for a project and forgotten with real data in it. In healthcare the consequence is PHI exposed to the internet with no exploit required.
The five that cause most incidents
1. Public storage. Containers holding imaging, exports or backups made readable without authentication. Usually done to solve an access problem quickly. Enable account-level public access blocking so it cannot be done at all.
2. Over-permissive identity. Roles with wildcard permissions because scoping took too long. The blast radius of any compromised credential becomes the whole account.
3. Unencrypted or publicly reachable databases. A managed database with a public endpoint and weak authentication, holding a copy of clinical data for analytics.
4. Missing logging. Control plane audit logging disabled or not retained, so after an incident there is no record of who did what.
5. Forgotten resources. A proof of concept from two years ago, still running, still holding data, no longer patched, owned by someone who left.
Guardrails beat detection
Finding misconfiguration after the fact is useful. Preventing it at source is better, and cloud platforms support this directly.
The top row is the highest-value and most neglected. Service control policies that make public storage impossible across the whole organisation remove the category rather than monitoring for it.
A healthcare-specific checklist
| Check | Why it matters here |
|---|---|
| Public access blocked at account level | PHI exposure requires no attacker skill |
| Encryption at rest enabled by default | Supports the breach-notification safe harbour |
| Customer-managed keys for PHI workloads | Separates key custody from data custody |
| Control plane logging on, retained 90+ days | The only record of configuration change |
| No long-lived access keys | Use short-lived role assumption instead |
| MFA on all human console access | Especially root and break-glass accounts |
| BAA in place with the provider | Required before PHI enters the environment |
| Data residency confirmed | Where jurisdiction requires it |
| Non-production holds no real PHI | Or is protected to production standard |
| Tagging enforced for data classification | You cannot protect what you cannot identify |
Shadow cloud in research and departments
Healthcare has an unusual amount of cloud use outside IT — research groups with grant-funded accounts, departments with a SaaS subscription, a clinician trialling an analytics tool. These hold real data and appear in no inventory.
Rather than prohibition, which drives it further out of sight:
- Provide a sanctioned path that is faster than going around it
- Offer pre-approved landing zones with guardrails already applied
- Run periodic discovery through expense data and DNS logs
- Make onboarding an existing account possible without blame
Where to start
Check one setting: is public access blocked at the organisation level across every cloud account you know about? It is a single control, it removes the most damaging category outright, and in most healthcare organisations it is not enabled everywhere.
GuardsArm assesses cloud posture for healthcare including guardrail design and shadow account discovery. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “Preventing Cloud Misconfiguration: A Healthcare Checklist”
Talk to the GuardsArm team about how these services apply to your environment.
