Cloud Security Checklist for Growing Companies

Most cloud breaches at growing companies are not clever hacks. They are a storage bucket left public, an admin account without MFA, an access key pasted into a code repository, or logs that expired before anyone noticed something was wrong. The cloud providers secure their data centers well. What happens inside your account is up to you.

This checklist is for companies that have moved past “a few apps and a credit card” and now run real workloads in AWS, Microsoft Azure or Google Cloud, alongside Microsoft 365 or Google Workspace. It focuses on the 4 areas that cause the most damage when they are neglected: identity, logging, storage exposure and backups.

Start with the shared responsibility model

Every major provider uses a version of the same idea. AWS describes it as security “of” the cloud versus security “in” the cloud. The provider secures the physical facilities, hardware and core infrastructure. You secure what you put on it: your data, user permissions, configurations and applications. The exact split depends on the service: you manage more with virtual machines than with fully managed software.

If you are still choosing a platform, compare how each provider documents its side of the model before you commit.

Identity checklist

Identity is the new perimeter. If an attacker gets an admin login, firewalls and encryption do little.

• ☐ Require MFA for every human user, with phishing-resistant methods such as security keys or passkeys for administrators. AWS now enforces MFA for root users across account types, completing that rollout in June 2025. See our guide to multi-factor authentication types.
• ☐ Lock away the root or global admin account. Use it only for tasks that require it, protect it with hardware keys and store recovery details securely. Create 2 emergency break-glass admin accounts and monitor any use of them.
• ☐ Use single sign-on so people sign in to cloud consoles through your identity provider instead of separate local accounts. Disabling one identity then removes all access.
• ☐ Apply least privilege. Give people and services only the permissions they need. Replace broad “admin” or “owner” roles with narrower ones, and review them quarterly.
• ☐ Eliminate long-lived access keys where possible. Use short-lived credentials, workload identities or roles for applications and CI/CD pipelines.
• ☐ Scan code repositories for secrets and rotate any key that has ever been committed.
• ☐ Separate environments. Use different accounts, subscriptions or projects for production, staging and development, so a mistake in testing cannot touch customer data.

Logging and monitoring checklist

Logs are how you find out what happened. Defaults are often too short for a real investigation.

• ☐ Turn on audit logging everywhere. AWS CloudTrail event history covers the past 90 days of management events in each region. For a longer record, AWS says to create a trail or a CloudTrail Lake event data store. Azure keeps Activity Log events for 90 days and recommends a diagnostic setting to keep them longer. Google Cloud has Cloud Audit Logs with its own retention defaults.
• ☐ Send logs to a central, separate location, such as a dedicated logging account or storage location that ordinary admins cannot delete from.
• ☐ Keep logs for at least a year, or longer if your contracts, regulators or SOC 2 compliance goals require it.
• ☐ Enable the provider’s threat detection service, such as Amazon GuardDuty, Microsoft Defender for Cloud or Google Security Command Center, and route alerts to someone who will act on them.
• ☐ Alert on high-risk events: root or break-glass logins, new admin role assignments, disabled logging, public access changes and unusual spending spikes.
• ☐ Log SaaS too. Turn on unified audit logs in Microsoft 365 or Google Workspace and review sign-in reports.

Key takeaway: Make sure an attacker who gets admin rights cannot quietly delete the evidence. Central logs in a separate, locked-down account are one of the best investments a growing company can make.

Storage exposure checklist

Accidentally public storage has caused many well-known data leaks. Providers have improved the defaults. Since April 2023, AWS applies S3 Block Public Access and disables access control lists by default on all new buckets, but older buckets and other services may still be exposed.

• ☐ Turn on account-level public access blocks wherever the provider supports them, not just per bucket.
• ☐ Inventory all storage: buckets, blob containers, file shares, database snapshots and disk images. Use the provider’s security posture tools to flag anything public.
• ☐ Review sharing in SaaS. Check Microsoft 365 and Google Workspace for “anyone with the link” sharing on sensitive files, and restrict external sharing by default.
• ☐ Encrypt data at rest and in transit. Most services encrypt at rest by default; confirm it and decide whether you need customer-managed keys.
• ☐ Close exposed services. Databases, remote desktop and SSH should not be open to the whole internet. Use private networking, VPNs or identity-aware access instead.
• ☐ Classify sensitive data so you know where customer, financial and health records live.

Backup and recovery checklist

Cloud storage is durable, but durable is not the same as backed up. If an attacker or a script deletes your data, the provider will faithfully replicate the deletion.

• ☐ Back up critical data and configurations on a schedule matched to how much data you can afford to lose. Our guide to RTO vs RPO explains how to set those targets.
• ☐ Store backups in a separate account or project with different admin credentials, so one compromised login cannot delete both production and backups.
• ☐ Use immutable or locked backups where available, such as object lock or vault lock features, to protect against ransomware.
• ☐ Back up SaaS data, including Microsoft 365 or Google Workspace mail and files, if your retention settings are not enough.
• ☐ Test restores at least twice a year. A backup you have never restored is a hope, not a plan. Our ransomware protection guide covers this in more depth.
• ☐ Keep infrastructure as code so you can rebuild environments quickly and consistently.

Configuration baselines and posture checks

You do not need to invent your own standards.

• CIS Benchmarks publish configuration guidance for AWS, Azure, Google Cloud and many operating systems.
• CISA’s SCuBA project (Secure Cloud Business Applications) offers secure configuration baselines for Microsoft 365 and Google Workspace, plus free assessment tools: ScubaGear for Microsoft 365 and ScubaGoggles for Google Workspace. They were built for federal agencies, but any organization can use them.
• Provider tools such as AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center score your environment against these benchmarks.

Running one of these checks every quarter turns your checklist from a one-time project into a habit.

Where to start: a 30-day plan

1. Week 1: identity. Enforce MFA for every user, secure root and admin accounts, and remove unused users and keys.
2. Week 2: logging. Turn on audit logs in every account and SaaS tenant, centralize them and extend retention.
3. Week 3: exposure. Enable account-level public access blocks, scan for public storage and open ports, and tighten SaaS sharing.
4. Week 4: backups. Confirm backups exist for critical systems, move them to a separate account, and run 1 restore test.
5. Ongoing: run a posture check quarterly, review admin roles and fix the top findings first.

As your team grows, build these checks into your deployment pipeline. That is the core idea of DevSecOps: catching misconfigurations before they reach production.

Conclusion

Cloud security for a growing company comes down to discipline in 4 areas. Control who can sign in and what they can do. Keep logs that an attacker cannot erase. Make sure nothing is public by accident. Keep backups that survive a compromised admin account and prove they restore. Work through the checklist once, then revisit it every quarter as your environment changes.

Sources

• AWS: Shared Responsibility Model — security “of” the cloud versus security “in” the cloud
• AWS CloudTrail: Working with event history — 90 days of management events and trails for longer retention
• Microsoft Learn: Azure Monitor activity log — 90-day retention and diagnostic settings for longer storage
• AWS: Amazon S3 now applies two security best practices to all new buckets by default — Block Public Access and ACLs disabled by default from April 2023
• AWS: IAM now enforces MFA for root users across all account types — root user MFA enforcement
• CISA: Secure Cloud Business Applications (SCuBA) Project — secure configuration baselines for Microsoft 365 and Google Workspace