Cloud workload security review

Why run this

What this checklist is for

Cloud workloads holding patient data accumulate configuration drift the way any estate does, and the drift is invisible until somebody audits it or exploits it.

Most of the items below are cheap to fix and expensive to have missed. Run this per workload rather than across the estate, so the findings are actionable.

Run it with

CIO or CISO

And with

Cloud architects and security engineers

And with

Privacy officer

The checklist

20 checks, in the order we would run them

Tick only what you can genuinely evidence today. An item you intend to do is not an item you have done, and scoring yourself generously here only produces a comfortable number and an uncomfortable project.

Section 1

Network exposure

The surface an attacker reaches first.

No platform service in the workload accepts public network trafficStorage accounts, databases and key vaults reachable from the internet are the most common finding and the easiest to fix.
Private endpoints configured with private DNS zones resolving correctlyA private endpoint with broken name resolution silently falls back to public routing.
Network security group rules reviewed and any-any rules eliminatedPermissive rules added during troubleshooting are rarely removed afterwards.
Inbound management access restricted to a bastion or just-in-timeRDP and SSH open to the internet remains a live finding in more estates than it should.
Subnet segmentation separates application tiers from data tiersFlat virtual networks let a compromised web tier reach a database directly.

Section 2

Identity and access

Where most real intrusions progress.

Managed identities used instead of stored credentialsA connection string with an embedded key in application configuration is a credential waiting to leak.
Standing privileged access minimised with just-in-time elevationThis is the control an auditor tests directly, and just-in-time with a recorded justification is a strong answer.
Role assignments reviewed with owner-level access justified individuallyOwner is granted for convenience during a project and never removed.
Break-glass accounts exist, are excluded from policy and are alerted onTwo of them, cloud-only, with credentials split between custodians.
Access reviews run on schedule with recorded outcomes including no-changeA review that changed nothing still needs a record showing it happened.

Section 3

Data protection

What determines the severity if something does go wrong.

Encryption at rest confirmed on every data service in the workloadDefault in most services, and worth verifying rather than assuming, particularly on older deployments.
Key vault has purge protection and soft delete enabledBoth are irreversible once set, which is the point, and both are audit expectations.
Customer-managed key requirement confirmed as genuine rather than assumedThey add real operational burden including a recovery position most teams have not thought through.
Backup and restore tested for the workload's data servicesBackup configured is not backup tested. Restore at least once.
Data classification applied so the sensitivity of what is stored is knownYou cannot apply proportionate controls to data whose sensitivity nobody has established.

Section 4

Evidence and monitoring

Whether you could demonstrate any of the above in six months.

Diagnostic settings enforced by policy, not configured by handPolicy covers resources created after it, including ones nobody told you about.
Log retention matches your regulatory window and has been query-testedQuery at the far edge of the window and confirm results return.
Data-plane logs captured, not only management-planeWho changed the configuration is management plane. Who read the data is data plane, and it is the one auditors ask about.
Alerts route to somebody who acts, at a volume they can workAn alert nobody reads is a log entry with extra steps.
A control-to-configuration mapping document exists and is currentEach regulatory control mapped to the specific setting implementing it, with a link to the evidence.

What your score means

Read this against the number above

These bands are deliberately blunt. The middle band is where most organizations honestly sit, and it is a perfectly reasonable place to proceed from — provided the gaps are written down with owners rather than carried as optimism.

0–59%Significant gaps

Do not proceed yet. More than four in ten items are unaddressed, and the ones that fail here are usually the foundational ones that make everything after them harder.

60–84%Mostly ready, with known gaps

Proceed on a defined scope, with the outstanding items written into the plan as risks with owners and dates. This is the most common honest position.

85–100%Ready

The remaining gaps are small enough to handle during delivery rather than before it. Confirm the unticked items are genuinely minor rather than simply unexamined.

Your score highlights automatically as you tick items above. Nothing is saved, sent or tracked — refreshing the page clears it.

Closing the gaps

If you could not tick these, start here

The four items below are the ones whose absence causes the most trouble downstream. If your unticked items include any of these, they are worth addressing before the rest.

Public network access enabled

Address this first. It is the highest-severity common finding and usually a configuration change rather than a project.

Stored credentials in configuration

Move to managed identities. This removes a whole class of credential leak and is straightforward for most services.

Diagnostic settings configured manually

Convert to policy. Manual configuration covers what existed on the day somebody did it and nothing created since.

No control mapping

Build it. This is the document that turns a two-week audit scramble into an afternoon.

Want a second opinion on your score?

We will run this review against one workload and produce a prioritised remediation plan mapped to your specific regulatory obligations.

Talk through your result Read the related guides We reply to every message within one business day.

Keep going

Related checklists

sharepoint

healthcareReadiness

Copilot readiness checklist

Twenty checks to run before assigning a single Microsoft 365 Copilot licence in a healthcare organization.

July 25, 2026 · 20 checksOpen

defender

healthcareReadiness

Ransomware readiness checklist

Twenty checks framed around the only question that matters in a provider organization: how long can you deliver safe care without systems?

May 23, 2026 · 20 checksOpen

What this checklist is for

Run it with

And with

And with

20 checks, in the order we would run them

Network exposure

Identity and access

Data protection

Evidence and monitoring

Read this against the number above

If you could not tick these, start here

Public network access enabled

Stored credentials in configuration

Diagnostic settings configured manually

No control mapping

Want a second opinion on your score?

Related checklists

Copilot readiness checklist

Ransomware readiness checklist

Tell us what you're trying to fix

Let’s get started on something great

Phone

Email