Field Note: Cloud Security Review Without Slowing Engineering

Engineering teams rarely object to security review as such. They object to review that arrives the week before launch, asks questions the platform could already answer, and ends in a ticket queue with no finish date. A cloud review that works is mostly invisible. Most changes pass through controls that run on their own, and people look only at the few changes that alter the risk.

This note describes how to divide the work so that both things hold: engineering keeps its pace, and security keeps its grip on the changes that matter.

Review the change, not the estate

A review that tries to examine every deployment either stalls delivery or turns into a rubber stamp. A more useful question is whether this change alters who can do what, what is reachable, or where sensitive data lives. If it does not, it should not need a person.

Agree a short list of triggers that send a change to human review. A workable starting set:

• A new account, subscription or project.

• Any new internet-facing entry point.

• A new cross-account, cross-tenant or third-party trust, including federation to an external identity provider.

• Long-lived credentials, or a new non-human identity with broad permissions.

• First use of regulated or sensitive data in the environment.

• A managed service outside the approved catalog.

• Any change to logging, guardrails or the identities that administer them.

Everything outside the list moves on automated checks alone. Revisit the list when an incident or audit finding shows a gap.

Put the repeatable checks in the platform

A question asked the same way on every review should become a control. Four layers cover most of them.

Know what each mechanism does not do. An AWS service control policy sets the maximum permissions available in member accounts. It grants nothing, and it does not apply to the organization’s management account or to service-linked roles, which is one reason workloads do not belong in the management account. Azure Policy behaves as an explicit-deny system: a deny assigned at a management group cannot be loosened by a more permissive assignment lower down, so exclusions have to be made at the higher level. Google Cloud organization policy restricts how resources may be configured regardless of who is acting, which is a different job from IAM. For any new deny control, start in audit mode, measure what it would have blocked, then enforce.

What a human reviewer should look at

For changes that do trigger review, a reviewer with an hour should concentrate on eight areas. They are weighted toward identity and the control plane, because that is where one leaked credential turns into an environment-wide problem.

Handle findings so they stop recurring

A finding fixed in one stack and left in the template returns next sprint. For each finding, ask whether the fix belongs in the module, the policy or the pipeline. Treat every repeat finding as a defect in the platform.

Where a team genuinely needs an exception, record the owner, the compensating control and an expiry date. Report open exceptions to the forum that already sees delivery risk. An exception with no expiry is a permanent decision made by default.

Use recognized baselines rather than inventing your own. CIS Benchmarks give prescriptive configuration recommendations for AWS, Azure and Google Cloud. The Cloud Security Alliance Cloud Controls Matrix indicates which party in the cloud supply chain should implement each control. Responsibility shifts with the service model, so confirm which side owns each control for each service in use.

Measure the review itself

• Share of changes that reached production on automated checks alone.

• Time from review request to decision for triggered changes.

• Repeat findings against the same control.

• Open exceptions past their expiry date.

• Time to detect and correct guardrail drift.

A low first number means the platform is not doing enough. A high second number means the review has become a queue. Both are fixable, and both are visible to engineering leadership, which puts security inside the delivery conversation rather than outside it.

Where this goes wrong

• Reviewing diagrams instead of deployed configuration. The diagram shows intent. The configuration shows what is reachable.

• Treating the ticket queue as the control. Volume rises, quality falls, and teams learn to describe changes in ways that avoid review.

• Enforcing deny guardrails with no route for legitimate exceptions. Teams respond by moving work to accounts security cannot see.

• Scanning without ownership. Findings with no mapped owner age quietly.

• Never testing the guardrails. Attempt the forbidden action in a sandbox account. Confirm it is blocked and that the attempt is seen.

Sources

• AWS Organizations User Guide, Service control policies (SCPs). https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

• Microsoft Learn, Overview of Azure Policy. https://learn.microsoft.com/en-us/azure/governance/policy/overview

• Google Cloud, Organization Policy Service overview. https://docs.cloud.google.com/organization-policy/overview

• Center for Internet Security, CIS Benchmarks. https://www.cisecurity.org/cis-benchmarks

• Cloud Security Alliance, Cloud Controls Matrix. https://cloudsecurityalliance.org/research/cloud-controls-matrix