Cloud Security Checklist for SMBs: What to Verify Before an Audit

2026-07-19•24 min read

Introduction

Most cloud security failures don't come from sophisticated zero-day exploits. They often stem from misconfigurations left in production too long: public storage, overly permissive roles, exposed keys, unprotected databases, or insufficient logging.

The Verizon Data Breach Investigations Report 2025 reminds us that human error, misconfigurations, and accidental exposure remain significant factors in security incidents. In the cloud, these errors can be exploited quickly—sometimes by simple automated scans.

The good news: many of these risks are preventable with a systematic review of your cloud posture. This checklist helps SMBs verify essential controls on AWS, Microsoft Azure, and Google Cloud, with special attention to requirements for Canadian organizations.

Short Answer: What to Verify Before a Cloud Security Audit?

Before a cloud security audit, an SMB should prioritize verifying:

  • human and technical access
  • multi-factor authentication
  • excessive permissions
  • long-lived access keys
  • public storage exposure
  • data encryption
  • overly open network rules
  • audit logging
  • threat detection
  • backups and restore testing
  • data residency
  • regulatory and compliance obligations

The goal isn't to fix everything in one day, but to quickly identify the gaps most likely to lead to a breach.

Why Misconfigurations Expose SMBs in the Cloud

In the cloud, exposure depends heavily on configuration. An overly open network rule, misconfigured storage, exposed key, or overly permissive role can make a resource accessible or exploitable much faster than in a traditional environment.

SMBs are particularly exposed for three reasons:

  • technical teams must deliver quickly
  • cloud responsibilities are sometimes unclear or poorly distributed
  • security controls are added after the fact, rather than by design

A cloud environment can be robust, but it requires ongoing discipline: identity, encryption, networking, logging, backup, compliance, and incident response.

Why Cloud Security Is Different

Traditional perimeter security assumes a relatively clear boundary between "inside" and "outside." Cloud environments work differently. Resources are dynamic, identities are numerous, APIs are everywhere, and a single misconfigured permission can create an attack path.

The shared responsibility model is central. AWS, Microsoft Azure, and Google Cloud secure the underlying infrastructure. Your organization remains responsible for what you configure and operate:

  • accounts and identities
  • roles and permissions
  • data encryption
  • network configuration
  • storage
  • logging
  • backups
  • monitoring
  • incident response
  • regulatory compliance

In other words, using a major cloud provider doesn't automatically make your environment secure. Security depends on how services are configured, monitored, and governed.

7 Domains to Verify Before a Cloud Audit

1. Pre-Migration, Data Classification, and Compliance

Before migrating workloads to the cloud, or if you've already migrated without formal classification, start with your data.

Questions to ask:

  • What data is stored in the cloud?
  • Does it include personal information?
  • Is it customer, employee, health, financial, or contract data?
  • Where is this data physically located?
  • Who can access it?
  • Can vendors or support teams outside your country access it?
  • What's the retention period?
  • Are privacy assessments required?

AWS, Azure, and Google Cloud all offer Canadian regions. AWS ca-central-1 is in Montreal, Google Cloud northamerica-northeast1 is in Montreal, Azure Canada Central is in Toronto. Choosing a Canadian region supports data residency, but isn't sufficient by itself to demonstrate compliance.

You must also verify:

  • data replication
  • logs and metadata location
  • support access
  • vendors and subcontractors
  • backups location
  • contractual clauses
  • protective measures applied to sensitive data

2. Identity and Access Management

Identity and access management errors are among the most critical risks in the cloud. An overly permissive account, exposed key, or misattributed role can allow an attacker to move laterally and access sensitive data.

Priority controls:

  • stop using root or owner accounts for daily operations
  • enable multi-factor authentication for all human accounts
  • favor identity federation and temporary access
  • eliminate long-lived keys where possible
  • audit high-privilege roles
  • remove inactive accounts
  • regularly review permissions

AWS root accounts and Azure global administrator accounts should be reserved for exceptional operations. They must be protected by multi-factor authentication, monitored, and used minimally.

Multi-factor authentication must be applied to all human users: developers, administrators, analysts, vendors, and service accounts. In 2026, a human account without multi-factor authentication in a cloud environment is a difficult risk to justify.

For access keys, the best approach is to avoid long-lived keys where possible. Favor temporary roles, federated identity, and the provider's native mechanisms. When long-lived keys are necessary, they must be inventoried, monitored, limited, and rotated according to a clear policy. Keys older than 90 or 180 days should be considered high-risk.

3. Data Protection

Cloud data must be protected in transit and at rest. This is fundamental to security, compliance, and customer trust.

For encryption in transit:

  • apply TLS 1.2 or higher
  • block HTTP for sensitive interfaces
  • disable obsolete protocols and cipher suites
  • use certificate pinning only for highly sensitive applications, where operational needs justify it

For encryption at rest:

  • verify databases are encrypted
  • use customer-managed keys when data or compliance requirements require it
  • centralize secrets in a key vault
  • never store secrets in code or configuration files
  • separate access to data from access to keys

On AWS, Amazon S3 automatically encrypts new objects with SSE-S3 since 2023. For sensitive data or contexts requiring finer key control, favor SSE-KMS or customer-managed keys when relevant.

On Azure, use Azure Key Vault for secrets, certificates, and connection strings. Enable appropriate encryption mechanisms for databases and storage services.

On Google Cloud, use Cloud KMS and customer-managed encryption keys for sensitive workloads when key control is required.

For backups:

  • define RPO and RTO
  • test restores regularly
  • maintain at least one copy in a separate region or account where relevant
  • enable immutable backups where available
  • document the restore procedure

A backup never tested is not a guarantee. It's a hypothesis.

4. Network Security

Your cloud network should be designed according to the principle of assumed breach: if a resource is compromised, it shouldn't freely reach all others.

Controls to verify:

  • segment networks
  • isolate databases
  • limit direct internet access
  • restrict inbound rules
  • control outbound traffic
  • use bastions, VPN, or conditional access
  • enable network flow logs

A simple architecture can already significantly reduce risk:

  • public resources: load balancers, API gateways
  • application resources: private subnets
  • databases: separate private subnets
  • administration: access via VPN, bastion, or secure service

RDP port 3389 and SSH port 22 should not be open to the internet. Rules like 0.0.0.0/0 should be limited to justified, documented, and monitored cases.

For network visibility:

  • AWS: enable VPC Flow Logs
  • Azure: prefer Azure Virtual Network Flow Logs for new deployments
  • Google Cloud: enable VPC Flow Logs

Microsoft has announced the gradual retirement of NSG flow logs: for new deployments, Azure Virtual Network Flow Logs is the preferred option.

5. Logging and Monitoring

You can't detect what you don't see. Logging isn't just a compliance requirement: it's the foundation of detection and incident response.

To verify:

  • AWS CloudTrail enabled on all accounts
  • Azure Activity Log and Microsoft Entra ID logs sent to a monitoring platform
  • Google Cloud Audit Logs enabled
  • logs centralized in a secure account or workspace
  • restricted access to logs
  • sufficient retention
  • alerts configured for critical events

Keep logs long enough to be useful. Many incidents are detected days or weeks later. A 90-day retention is a practical minimum for most environments; systems handling sensitive data may require longer retention.

Enable adapted detection services:

  • AWS GuardDuty
  • Microsoft Defender for Cloud
  • Google Cloud Security Command Center

These services don't replace human monitoring, but they offer a first layer of behavioral detection and risk reporting.

6. Cloud Incident Response

Cloud incident response must account for cloud-specific capabilities. When an instance is compromised, you can often isolate it, take a snapshot, preserve logs, then quickly rebuild a clean version.

But this only works if the procedure is known in advance.

Your plan should cover:

  • isolating a compromised resource
  • collecting logs
  • preserving evidence
  • revoking active sessions
  • rotating secrets
  • disabling exposed keys
  • rebuilding clean environments
  • internal escalation
  • regulatory notification if required

For an SMB, a simple manual is better than a theoretical 80-page plan. Your team must know what to do, who to call, and how to avoid destroying critical evidence.

7. Compliance Mapping

For organizations handling personal data or subject to Canadian regulations, cloud compliance should be built in from the start.

Key points to verify:

  • personal data being processed
  • collection purpose
  • retention period
  • data location
  • communications outside your country
  • vendors and subcontractors
  • contractual measures
  • access controls
  • logging
  • encryption
  • notification procedures

A Canadian cloud region isn't sufficient by itself for compliance. It can support data residency, but you must also evaluate access, replication, logs, subcontractors, and contractual guarantees.

10 Fixes to Make This Week

You don't need to fix everything at once. Start with the highest-impact controls.

  • [ ] Enable multi-factor authentication on all human accounts
  • [ ] Remove or replace long-lived access keys where possible
  • [ ] Audit overly broad permissions and administrative roles
  • [ ] Verify public storage is blocked or justified
  • [ ] Enable CloudTrail, Azure Activity Logs, or Google Cloud Audit Logs
  • [ ] Enable AWS GuardDuty, Microsoft Defender for Cloud, or Google Cloud Security Command Center where available and suitable
  • [ ] Remove SSH/RDP access exposed to the internet
  • [ ] Confirm encryption of sensitive databases and storage
  • [ ] Test a backup restore
  • [ ] If processing personal data, confirm region, vendor access, and compliance requirements

Quick Prioritization Table

| Priority | Control | Why It Matters | | -------- | -------------------------- | ------------------------------------------------------ | | Critical | Multi-factor authentication| Greatly reduces risk from stolen credentials | | Critical | Minimal permissions | Limits impact of a compromised account | | Critical | Non-public storage | Prevents direct data exposure | | High | Audit logs | Enables investigation and action accountability | | High | Encryption | Protects sensitive data and supports compliance | | High | Tested backups | Reduces incident and ransomware impact | | Medium | Threat detection | Accelerates identification of suspicious behavior | | Medium | Compliance assessments | Frames risks related to personal data and regulations |

Download the Complete Checklist

Download the Cloud Security Checklist

Get the complete 50-point checklist with scoring matrix for AWS, Azure, and Google Cloud, including controls for compliance and data residency requirements.

No spam. Unsubscribe anytime.

Need Expert Guidance?

Planning a cloud audit, migration, or AWS, Azure, or Google Cloud security review? Cybernow can help you assess your posture, prioritize fixes, document controls, and structure your security governance.

Our fractional vCISO service provides security leadership tailored to SMBs, without requiring a full-time security leader.

Learn About Our vCISO Service

FAQ

What is a cloud security checklist?

A cloud security checklist is a list of controls to verify access, network configuration, encryption, backups, logs, alerts, and compliance obligations before an audit, cloud migration, or production deployment.

Do Canadian SMBs need privacy assessments before using the cloud?

Privacy assessments may be required depending on whether you're processing personal data, acquiring or developing new systems, or transferring data outside Canada. The requirement should be evaluated based on your specific context.

Is a Canadian cloud region enough for compliance?

No. A Canadian region supports data residency, but you must also verify vendor access, subcontractors, logs, replication, contractual measures, and protective measures applied to sensitive data.

Which cloud controls should we fix first?

Priorities are multi-factor authentication, excessive permissions, long-lived keys, public storage, encryption, open SSH/RDP ports, audit logging, and tested backups.

What's the difference between cloud security and cloud infrastructure security?

Both terms generally refer to the same domain. They both cover securing cloud resources, configurations, data, and compliance.

Who is responsible for security in the cloud?

The provider secures the underlying infrastructure. Your organization remains responsible for configuration, access, data, applications, logs, backups, and compliance of your own environments.

Key Sources

Need Expert Guidance?

Our fractional vCISO service provides security leadership and strategic guidance tailored to your organization.