The Cloud Security Checklist Every SMB Needs Before the Auditors Arrive

Most cloud security failures are not the result of sophisticated zero-day exploits. They are the result of misconfigurations that have been sitting in production for months - an S3 bucket left public, an IAM role with administrator privileges attached to a development server, a database with no encryption at rest, a VPC with no network segmentation.

The 2024 Verizon Data Breach Investigations Report found that misconfiguration remains one of the top causes of cloud-related breaches. The attacker didn't need a novel technique. They needed a search engine and a target with an exposed AWS key in a public GitHub repository.

The good news: most of these failures are preventable with a systematic review of your cloud posture. This checklist covers the highest-impact controls across AWS, Azure, and GCP, with specific attention to what Quebec businesses must address under Loi 25 before storing or processing personal information in the cloud.

Why Cloud Security Is a Different Problem

Traditional perimeter security assumes a clear boundary between "inside" and "outside." Cloud environments have no perimeter. Every resource you deploy is, by default, reachable from the internet unless you explicitly configure it otherwise. Every IAM policy you write that's too permissive is an attack path. Every secret you hard-code in your application code is a breach waiting to be discovered by an automated scanner.

The cloud provider's shared responsibility model makes this precise: AWS, Azure, and GCP secure the infrastructure. You are responsible for everything you put on it - access controls, data encryption, network configuration, logging, and incident response.

DevOps teams under delivery pressure tend to prioritize speed over security controls. Security teams often lack the cloud-specific expertise to review infrastructure code effectively. The result is an accumulation of misconfigurations that don't trigger alerts, don't show up in uptime monitoring, and only become visible when someone with malicious intent finds them first.

The Seven Control Domains You Must Address

Structure your cloud security review around seven domains. Within each, prioritize by impact - fix the issues most likely to lead to a breach before addressing compliance documentation.

Domain 1: Pre-Migration and Classification

Before you move workloads to the cloud - or if you've already migrated without a formal classification exercise, before you go any further - answer these questions:

What data are you storing in cloud environments? Personal information (employee records, customer data, health data) must be identified and treated differently from general business data. Under Quebec's Loi 25, personal information stored in cloud environments triggers specific obligations.

Where will that data physically reside? This matters because Loi 25 requires a Privacy Impact Assessment (EIPD - évaluation d'impact sur la protection des données) before transferring personal information outside of Quebec. All three major cloud providers offer Canadian regions (AWS ca-central-1, Azure Canada Central, GCP northamerica-northeast1 in Montreal). Using a Canadian region is not automatic compliance - you still need to understand what data replication, logging, and support access patterns mean for data residency - but it's a necessary starting point.

What are your compliance obligations? Map your data types to the frameworks that govern them: Loi 25 for Quebec personal information, GDPR for EU data subjects, HIPAA for health data, PCI-DSS for cardholder data. Each has specific technical requirements for encryption, access control, and audit logging.

Domain 2: Identity and Access Management

IAM misconfiguration is the single highest-impact risk category in cloud environments. The attack pattern is consistent: find an over-privileged account, steal the credentials, use the access to move laterally and exfiltrate data.

Immediate fixes with the highest impact:

Stop using root or owner-level accounts for daily operations. AWS root accounts and Azure Global Administrator accounts should be used only for emergency recovery operations, with MFA enabled and credentials stored securely offline.

Enforce MFA everywhere. Every human identity accessing your cloud environment - developers, administrators, analysts - must use multi-factor authentication. This single control stops the majority of credential-based attacks. There is no valid operational reason to have a human user without MFA in 2026.

Apply the principle of least privilege. Every IAM role, service principal, or service account should have exactly the permissions it needs to perform its function - nothing more. Audit wildcard permissions ("*") in AWS IAM policies. Audit Owner and Contributor roles in Azure. Each one is a potential privilege escalation path.

Rotate access keys. Developer access keys that are 180 days old are not keys - they're compromised keys you haven't discovered yet. Set a 90-day rotation policy and enforce it.

Remove unused credentials. Run an audit of IAM users and service accounts that haven't been active in 90 or more days. Inactive accounts are targets. Disable or delete them.

Domain 3: Data Protection

Your cloud data must be encrypted in transit and at rest. This is not optional - it's a baseline expectation in every compliance framework and a minimum requirement under Loi 25 for personal information.

Encryption in transit: Enforce TLS 1.2 or higher on all API endpoints. Block HTTP. Use certificate pinning for sensitive applications. Avoid deprecated cipher suites (RC4, MD5, SHA1).

Encryption at rest:

• AWS: Enable SSE-KMS on S3 buckets (not just SSE-S3). Ensure RDS encryption is enabled at creation - it cannot be added retroactively. Use customer-managed KMS keys for data that requires your control over key rotation.
• Azure: Enable Transparent Data Encryption on SQL databases. Use Azure Key Vault for all secrets, certificates, and connection strings. Never store secrets in application configuration files.
• GCP: Use Customer-Managed Encryption Keys (CMEK) for Cloud Storage buckets containing sensitive data. Enable encryption at rest on Cloud SQL.

Backup and recovery: Define your RPO and RTO before you need them. Test your backup restoration process at least monthly - backup systems that have never been tested are not backups, they're hopes. Keep at least one backup copy in a different region. Enable immutable backups where available; they are your primary defense against ransomware targeting your backup infrastructure.

Domain 4: Network Security

Your cloud network should operate on the assumption of breach: design it so that a compromised resource in one tier cannot freely reach resources in another tier.

Segment your network. Public-facing resources (load balancers, API gateways) belong in a public subnet. Application servers belong in a private subnet with no direct internet access. Databases belong in a separate private subnet accessible only from the application tier. This layered architecture means an attacker who compromises your web tier still faces a network boundary before reaching your data.

Tighten security group and firewall rules. The default security group configuration in most cloud environments allows all outbound traffic. Restrict egress to specific destinations and ports. Remove any ingress rules that allow access from 0.0.0.0/0 (the entire internet) on ports other than 80 and 443. RDP (port 3389) and SSH (port 22) should never be open to the internet - use a VPN or bastion host.

Enable flow logging. VPC Flow Logs (AWS), Network Watcher NSG flow logs (Azure), and VPC Flow Logs (GCP) give you the network visibility you need to detect lateral movement, data exfiltration, and anomalous traffic patterns. Without flow logging, you're investigating a breach with no network evidence.

Domain 5: Logging and Monitoring

You cannot detect what you cannot see. Logging and monitoring are not a compliance checkbox - they are the foundation of your detection capability.

Enable audit logging on every account. AWS CloudTrail should be active on every AWS account, with logs delivered to a centralized, secured S3 bucket. Azure Activity Logs and Azure AD audit logs should feed into Log Analytics. GCP Cloud Audit Logs should capture Admin Activity at minimum, and Data Access logs for sensitive services.

Retain logs long enough to be useful. The average time between compromise and detection is measured in weeks, not hours. If you're retaining logs for only 30 days, you may not have the evidence you need when you discover an incident. Retain logs for 90 days at minimum; one year for services handling personal or sensitive data.

Set up threat detection. AWS GuardDuty, Azure Defender, and GCP Security Command Center provide automated threat detection using behavioral analysis and threat intelligence. These are not expensive services - enable them. Review findings at least monthly.

Domain 6: Incident Response Readiness

Your cloud incident response plan must account for the specific capabilities and constraints of cloud environments.

When a cloud instance is compromised, your response options are different from on-premise: you can snapshot the instance for forensic analysis, terminate it immediately, and spin up a clean replacement in minutes. That capability is valuable - but only if you have a runbook that tells your team to use it.

Define your isolation procedures for each cloud provider. Know how to detach an instance from a VPC without destroying it. Know how to export CloudTrail logs before an account is compromised further. Know how to revoke active IAM sessions immediately.

Connect your cloud incident response plan to your broader incident response process. The detection triggers, severity classifications, and escalation paths should be consistent.

Domain 7: Compliance Mapping

For Quebec businesses, the compliance conversation starts with Loi 25. Here are the technical controls it requires for cloud environments:

Privacy Impact Assessment (EIPD): Required before any transfer of personal information outside Quebec. If you're using a US-region cloud service or a SaaS product with US-based data storage, you need an EIPD on file. The assessment must evaluate whether the receiving jurisdiction provides an adequate level of protection.

Data minimization: Collect and retain only the personal information you need. Cloud storage is cheap, which creates a tendency to retain everything indefinitely. Loi 25 requires you to justify retention and delete data when the purpose is fulfilled.

Access logging: You must be able to demonstrate who accessed personal information, when, and for what purpose. This means enabling Data Access audit logs on cloud services that store personal information - and retaining those logs appropriately.

Breach notification: As discussed in our Incident Response article, Loi 25 requires prompt notification to the CAI if a privacy incident creates a risk of serious injury.

The 10 Fixes You Can Make This Week

You don't need to address everything at once. Start with the controls that stop the most common attack patterns:

1. Enable MFA on all human accounts - no exceptions
2. Rotate or delete any IAM access keys older than 90 days
3. Remove wildcard (*) permissions from IAM policies
4. Verify all S3 buckets are not publicly accessible (use AWS Trusted Advisor or S3 Block Public Access)
5. Enable CloudTrail / Activity Logs / Cloud Audit Logs if not already active
6. Enable GuardDuty / Azure Defender / GCP SCC on all accounts
7. Audit security groups and NSGs for open RDP/SSH from 0.0.0.0/0
8. Confirm database encryption at rest is enabled
9. Test one backup restoration - confirm your RTO is achievable
10. If you're storing personal information: confirm the region and initiate your EIPD if data is outside Quebec

Download the full Cloud Security Checklist with scoring matrix