Cloud security baseline: the controls that actually matter

The cloud security configuration question for most mid-market organisations is genuinely difficult. AWS publishes about 100 services with security implications. Azure is similar. GCP not far behind. Each service has its own security knobs. The CIS Benchmarks for AWS run to several hundred pages. The vendor security posture management (CSPM) tools surface thousands of “findings” which are mostly noise.

The realistic answer for a mid-market organisation isn’t configure everything — it’s configure the things that actually matter, given the realistic threat model and the operational tolerance. That list is closer to 30 controls than 300, and it’s achievable in days, not months.

This post is the baseline we configure when an organisation asks what should we have done by now?

The threat model assumption

These controls assume the threat model that actually applies to most mid-market organisations:

• Credential compromise — phished or leaked credentials reach an attacker.
• Misconfiguration exposure — public storage, exposed services, over-permissive policies.
• Compromised CI/CD or developer environment — malicious code reaches production via the deployment pipeline.
• Insider mistake — well-intentioned actions that produce exposure.

These are the patterns where controls produce direct risk reduction. The baseline below addresses them.

What this baseline does not address: nation-state actors, novel zero-day exploitation, supply-chain compromise of cloud providers themselves. Those require additional work and significantly more cost; for most mid-market organisations, they’re outside the practical scope.

The controls that matter (AWS / Azure / GCP)

Identity (8 controls)

1. MFA on every human account. No exceptions except the break-glass account.
2. Phishing-resistant MFA on privileged roles. FIDO2 / WebAuthn keys.
3. No long-lived access keys for human users. Federate identities; use short-lived credentials.
4. No root account use. Root account locked with hardware MFA, used only for the few unavoidable operations.
5. Just-in-time elevation for administrative roles (covered separately).
6. No service accounts with passwords. Use workload identity / managed identity / IAM roles.
7. Cross-account access uses role assumption with explicit trust policies, not access keys.
8. Identity logging to a central SIEM, retained at least 90 days hot, 12 months cold.

Network (4 controls)

9. Default-deny ingress on the VPC level. Outbound is permissive; inbound requires explicit security group rules.
10. No public databases or storage. Database services are private subnet only. Storage services are private by default.
11. Edge service exposure through a managed service (CloudFront / Front Door / Cloud Load Balancing) with WAF, not directly from the application.
12. Private connectivity to PaaS where supported (PrivateLink, Private Endpoints, VPC Service Controls). The default of “internet-routable PaaS” is not the right default.

Data (5 controls)

13. Encryption at rest on all data services. The default is on; verify.
14. Encryption in transit enforced at the load balancer / API gateway. TLS 1.2 minimum, 1.3 preferred.
15. Customer-managed keys (CMK) for sensitive data. The cloud provider’s default keys are convenient but lower-control; CMK gives you key rotation control and key revocation as an operational lever.
16. Storage public access blocked at the account level. This single control prevents the most common cloud exposure pattern.
17. Sensitive data classification and DLP on the data sources where it’s tractable. M365 + Purview, AWS Macie, Azure Purview, GCP DLP — each has gaps but each adds value.

Logging and audit (4 controls)

18. Account-level audit log enabled (CloudTrail / Activity Log / Cloud Audit Logs). Retained at least 90 days hot, 12 months cold.
19. Log integrity (CloudTrail log file validation, Log Analytics workspace immutability). Logs are append-only and verifiable.
20. Logs forwarded to SIEM for analysis and alerting.
21. No production logging blackout. Some services have logging optional or off-by-default; verify the critical ones (Lambda, Functions, S3 access logs).

Configuration management (5 controls)

22. Infrastructure-as-code for all production resources. Click-ops in production is forbidden; every resource is created via Terraform / CloudFormation / Bicep / Pulumi with audit trail.
23. CSPM tool with continuous configuration scanning. AWS Config, Azure Policy, GCP Security Health Analytics natively; Wiz / Lacework / Prisma Cloud as third-party. The baseline is enabled, the high-severity findings are reviewed.
24. Drift detection between intended state (IaC) and actual state. Drift triggers review.
25. Change management for production infrastructure changes. PR-based, peer-reviewed, change ticket.
26. Backup and immutability for critical data. Backups exist, are tested, and are isolated from the production credential boundary.

Workload-level (4 controls)

27. Container image scanning in the registry. Vulnerabilities above defined severity block deployment.
28. Runtime workload protection for production compute. Defender for Cloud, GuardDuty + relevant rules, Falco for k8s.
29. Secrets in a vault, not in environment variables. AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Application reads at runtime; secrets do not appear in deployment configuration.
30. Network egress filtering for production workloads where the threat model warrants it. Production compute does not have unrestricted internet access.

That’s 30 controls. Each is configurable. Each addresses a specific threat pattern. The set is sufficient for a mid-market organisation’s practical security posture.

What’s not in the baseline (and why)

The baseline excludes some controls that appear in vendor benchmarks and CSPM dashboards. The omissions are deliberate:

• Continuous threat hunting in cloud logs. Useful but resource-intensive. For most mid-market environments, the SIEM-based detection content is sufficient until the program matures.
• Custom IDS / IPS in cloud. Limited additional value over native services for most environments. Reserve for specific threat models.
• Advanced data tokenization. For organisations with specific regulatory data (PCI, HIPAA, similar), tokenization is required. For general-purpose mid-market, the encryption + access control baseline is usually adequate.
• Honey tokens / canary credentials. High-leverage but requires operational discipline. Add when the program is mature.
• Hundreds of CSPM-flagged misconfigurations. Most CSPM findings are noise. Filter to high-severity, exploitable-from-internet, cross-account-impact, data-exposure-pattern findings. The filtered list is manageable.

The baseline is not minimum-viable; it’s reasonable for the threat model. Organisations with higher threat exposure (national security, critical infrastructure) need more. Organisations with less exposure can scale down on specific items.

Implementation order

For an organisation starting from a partial baseline, the implementation order:

1. Identity — items 1, 2, 3, 4 first. These prevent the majority of credential-driven incidents.
2. Network and data — 9, 10, 14, 16. Block the misconfiguration patterns that account for most public exposure.
3. Logging — 18, 19, 20. Establish the audit trail that supports detection and incident response.
4. Configuration management — 22, 23, 25. Stop new misconfigurations from being introduced.
5. The remaining items — calibrated to risk.

Each item is small. The first 12 should be in place within 4–6 weeks of focused work. The full 30 within 3–4 months.

Mapping to frameworks

The baseline maps cleanly to:

• ISO/IEC 27001:2022 Annex A controls (A.5, A.8 most directly).
• NIST CSF 2.0 functions (Protect, Detect primarily).
• ASD Essential Eight maturity levels (E8 ML2 covers most of items 1–4, 16, 18; ML3 covers most of the rest).
• APRA CPS 234 paragraphs 23–28.
• CIS AWS / Azure / GCP Foundation Benchmarks (the controls map to specific recommendations in each benchmark).

The cross-mapping is useful for compliance reporting. Each control can be cited against the relevant framework requirement.

A practical first move

This week: confirm controls 1, 2, 4, 16, and 18 in your primary cloud account. MFA universal, phishing-resistant MFA on admins, root account secure, public storage blocked at account level, audit logging enabled. These five are the highest-leverage controls in the baseline. If any is missing, fix it before reading any further.

For organisations doing this as part of broader security work, the Security Posture Assessment covers the cloud configuration baseline as part of the standard scope, mapped to the framework alignment relevant to the organisation’s regulatory context.