cloud-best-practices

Make a cloud workload defensible and provable at once: pick the criteria in scope, map each to a concrete control, implement the control through infrastructure-as-code, and collect the evidence the control produces. A control with no evidence amounts to compliance theater. Click-ops leaves nothing an auditor can verify later. The trail from criterion to control to evidence carries the whole audit.

The controls, the SOC2 Trust Services Criteria mapping, the evidence each control yields, the shared-responsibility split, and the failure modes live in the cloud controls reference.

Steps

1. Scope the criteria. Name the compliance regime in scope (SOC2, ISO 27001, HIPAA) and the exact Trust Services Criteria categories it requires from the cloud controls reference: Security/Common Criteria always, plus the subset of Availability, Confidentiality, Processing Integrity, and Privacy the engagement names. The step is done when every in-scope criterion is listed and every out-of-scope criterion carries a recorded reason.

2. Draw the responsibility line. State, per criterion, which side of the shared-responsibility model owns the control, so the provider's SOC2 report covers the provider's half and the workload covers the rest. The step is done when each in-scope criterion names an owner: the cloud provider, the workload, or both.

3. Map criteria to controls. Translate each in-scope criterion into a concrete control from the cloud controls reference: least-privilege IAM, encryption at-rest and in-transit, centralized audit logging, backups and DR, change management. The step is done when every workload-owned criterion maps to at least one named control and every control names the evidence it produces.

4. Implement controls as code. Express each control in infrastructure-as-code (Terraform, CloudFormation, Bicep) and keep the console out of the change path, so the control is versioned and reviewed, and a rerun reproduces it. A hand-applied click leaves no diff and falls outside the audit trail. The step is done when each mapped control exists as committed IaC and the plan for a destructive or stateful change is read per infra-safety.

5. Gate the controls in CI. Add policy-as-code and IaC scanning to the pipeline through the gates in appsec, so a non-compliant change fails the build before it can reach the account. Configure drift detection to flag any resource changed outside IaC. The step is done when a deliberately non-compliant fixture fails the gate and a drift event raises an alert.

6. Collect the evidence. Capture the artifact each control produces (IAM policy exports, encryption-config snapshots, audit-log retention settings, backup-restore test records, CI policy-scan results) and store each with a timestamp and the control it proves. The step is done when every in-scope criterion has a dated evidence artifact a reader can open.

7. Review against the red flags. Check the assembled mapping against the failure modes in the cloud controls reference: compliance theater, no audit trail, no evidence, secrets in code, over-permissive IAM. The step is done when each red flag is absent or carries a recorded, signed-off exception with a review date.