The Complete Guide to Cloud Security for Mid-Market Companies

A comprehensive cloud security posture assessment evaluates your environment across eight domains. Understanding these domains — and how they interact — is the foundation for building a security program that actually works.

Domain 1: Identity & Access Management. IAM is the most exploited attack surface in cloud environments. This domain covers user authentication (MFA enforcement, conditional access), authorization (role design, least privilege, separation of duties), service identities (machine-to-machine authentication, key management), and privileged access (break-glass procedures, just-in-time access). The most common finding: service accounts with admin-level permissions that were created during initial setup and never scoped down.

Domain 2: Network Architecture. Cloud networking is not just VPCs and security groups — it is the entire data flow model. This domain covers segmentation (account-level, VPC-level, subnet-level), traffic filtering (security groups, NACLs, NSGs), connectivity (VPN, peering, transit gateways, private endpoints), and DNS security. The most common finding: default security group rules that allow all outbound traffic, enabling data exfiltration from any compromised workload.

Domain 3: Data Protection. Encryption at rest and in transit is the baseline, not the finish line. This domain covers encryption key management (provider-managed vs. customer-managed keys, rotation), data classification (what is sensitive and where does it live), access controls on data stores (S3 policies, database authentication), and backup security (immutability, cross-region replication). The most common finding: customer-managed KMS keys with overly broad key policies granting decrypt permissions to entire accounts.

Domain 4: Compute & Workload Security. Whether you run VMs, containers, or serverless functions, the compute layer has its own security surface. This domain covers instance metadata protection (IMDSv2 enforcement), container image scanning, Kubernetes RBAC, serverless IAM permissions, and runtime protection. The most common finding: EC2 instances running IMDSv1, allowing SSRF attacks to steal instance credentials.

Domain 5: Logging & Monitoring. You cannot detect what you do not log, and you cannot respond to what you do not detect. This domain covers audit logging (CloudTrail, Azure Monitor, GCP Audit Logs), security event detection (GuardDuty, Defender for Cloud, Security Command Center), log retention, and SIEM integration. The most common finding: CloudTrail enabled but not monitored — logs exist but nobody is looking at them.

Domain 6: Governance & Guardrails. Preventive controls that stop misconfigurations before they reach production. This domain covers Service Control Policies (AWS), Azure Policy, GCP Organization Policies, tagging enforcement, and account/subscription governance. The most common finding: no preventive controls at all — relying entirely on detective controls to find misconfigurations after deployment.

Domain 7: DevSecOps & Supply Chain. Security integrated into the build and deployment pipeline. This domain covers infrastructure-as-code scanning (Terraform, CloudFormation), secrets detection, container image scanning, dependency analysis, and SBOM generation. The most common finding: long-lived CI/CD credentials with admin permissions stored as pipeline secrets.

Domain 8: Compliance Alignment. Mapping your cloud controls to the compliance frameworks your organization is subject to — SOC 2, ISO 27001, PCI DSS, HIPAA, CMMC. This domain covers control mapping, evidence collection, continuous compliance monitoring, and audit preparation. The most common finding: controls exist in practice but are not documented or mapped to framework requirements, creating audit risk.

After conducting cloud security assessments across dozens of mid-market environments, these five findings appear with near-universal frequency:

1. Over-permissioned service accounts. Service accounts created during initial cloud setup with admin or broad permissions that were never scoped to least privilege. These accounts often have long-lived access keys that have never been rotated. Impact: a compromised workload inherits the full permissions of its service account, which in many cases means full account access.

2. Default-allow outbound network rules. Security groups or NSGs that allow all outbound traffic on all ports. This means any compromised workload can communicate with attacker infrastructure, exfiltrate data, and download additional tools without network-level controls preventing it. Impact: data exfiltration goes undetected and unblocked.

3. Unmonitored API activity. CloudTrail, Azure Monitor, or GCP Audit Logs are enabled (often by default) but nobody reviews them. No detection rules, no alerting, no integration with a SIEM or security platform. Impact: attackers operate undetected for days or weeks because the evidence of their activity exists in logs that nobody reads.

4. Inconsistent encryption key management. A mix of provider-managed keys, customer-managed keys, and sometimes unencrypted resources. No key rotation policy. KMS key policies that grant access to entire accounts rather than specific services. Impact: encryption provides a false sense of security when key management is not controlled.

5. No preventive guardrails. No Service Control Policies, Azure Policies, or Organization Policies preventing the creation of insecure resources. Security relies entirely on finding and fixing misconfigurations after they are deployed. Impact: the same misconfigurations recur because nothing prevents them from being introduced.

Cloud Security Posture Management (CSPM) tools — AWS Security Hub, Microsoft Defender for Cloud, Wiz, Orca, Lacework — provide continuous automated scanning against configuration benchmarks. They are essential for ongoing monitoring. But they do not replace expert assessment, for three reasons:

First, CSPM tools generate findings but do not prioritize by architectural risk. A tool reports 200 findings with severity ratings based on generic benchmarks. An expert assessment identifies the 5 findings that actually create exploitable risk in your specific architecture — and the 15 that are false positives in your context.

Second, CSPM tools cannot assess trust relationships. The most dangerous cloud security issues are not individual misconfigurations — they are combinations of configurations that create attack paths. A service account with moderate permissions + a role assumption trust + a permissive resource policy = a privilege escalation path that no individual finding captures.

Third, CSPM tools produce dashboards, not roadmaps. They tell you what is misconfigured today. They do not tell you what to fix first, how to fix it without breaking production, or how to prevent it from recurring. An assessment produces a sequenced, risk-rated remediation roadmap with effort estimates.

The right approach: use CSPM for continuous monitoring and trend tracking. Use expert assessment for the initial baseline, architectural review, and roadmap development. Then use CSPM to measure progress against the roadmap.