Scenario
After a cloud migration or lift-and-shift
We moved to the cloud on a deadline — a lift-and-shift to hit a data-center exit or a board timeline. It works, it is live, and now leadership wants to know what changed about our risk when we changed where everything runs. The team that ran the cutover was optimizing for uptime and a clean switchover, not for what is exposed on day one, and no one has looked at the new estate the way an attacker would.
What usually goes wrong
Lift-and-shift carries over on-prem assumptions that no longer hold once workloads sit on the public cloud. Firewall rules written for a hardened perimeter become internet-facing, storage that was private inside a data center is now one policy away from public, and service accounts arrive with broad standing access. Provider defaults get accepted, security groups get opened wide to unblock the cutover and never narrowed, and logging in the new accounts is thin or never enabled. Because the goal was "make it run," nobody measured the estate against a cloud baseline — so the exposure is real but invisible.
How the health check fits
The health check measures the migrated estate against the CIS Benchmark for each provider and provider best practice, then ranks what the cutover left exposed: the security groups and firewall rules opened during migration, the storage that is now publicly reachable, the IAM carried over wider than it needs to be, and the accounts where audit logging was never turned on. On AWS that means EC2 security groups, S3 bucket and block-public-access settings, and CloudTrail coverage; on Azure, network security groups, storage account public access, and Activity/Diagnostic logs; on GCP, VPC firewall rules, Cloud Storage IAM and public access prevention, and Cloud Audit Logs. It is read-only — nothing is written to the environment you just stabilized. You leave with findings in real risk order and a plan you can run while the migration is still fresh.
Domains that matter most
Frameworks in play
Questions
How soon after migrating should we run this?
As soon as workloads are live and stable. Early findings are the cheapest to fix — an open security group or a public bucket is a quick change now, but a harder retrofit once dependencies build up around it.
We used the provider's migration tooling — isn't the result secure by default?
Migration tooling optimizes for a faithful copy and a working cutover, not a hardened baseline. It replicates what you had, defaults included, and will not tell you that an inherited firewall rule is now internet-facing or that logging is off in the new accounts. Measuring the estate against a cloud baseline is exactly the gap the check closes.
Get ahead of it
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
How it works
From request to a plan you can run
However you got here, the health check runs the same way — request, scope, read-only assessment, ranked report, and remediation.
