Cloud security configuration review
Cloud environments are rarely insecure by design. They become insecure by accretion: a role widened for a migration that finished two years ago, a security group opened for a contractor, a logging configuration that was correct when there were four accounts and is now correct for four of forty.
The short version: a configuration review, not a cloud penetration test
No. This is a configuration review, performed from read access you provide or from configuration you export, and nothing is attacked in a running environment. The two answer different questions. A configuration review asks what the environment permits; a test asks what an attacker can actually do with what it permits today.
The distinction matters commercially as well as legally. A configuration review is cheaper, faster, repeatable, and finds a larger share of real exposure per day spent, because most cloud incidents begin with a setting rather than with an exploit. Where you do want an environment attacked, that is scoped separately as penetration testing, under signed authorization and within the provider’s published rules.
How the work is done
A read-only role in the account, subscription or project is the usual arrangement, scoped to configuration and metadata rather than to the data your workloads hold. Where a read-only role is not practical — a regulated environment, a provider-managed tenancy, a client whose change process makes new principals slow — the same review runs from exported configuration: infrastructure-as-code, policy documents, network and identity exports, and the provider’s own posture tooling output.
Findings are produced by reading configuration, not by acting on it. Nothing is created, changed or deleted in your environment during the review.
Identity and access: who can do what, and who could
This is where the largest findings usually sit, because identity in cloud is the perimeter. The review looks at role sprawl — how many roles exist, how many are used, how many were created for a task that is finished; over-broad policies, including the wildcard that was temporary; standing privilege that could be replaced by time-bound elevation; break-glass accounts, whether they are protected differently from ordinary accounts and whether their use raises an alert; and the trust relationships that let one account assume a role in another, including the ones reaching in from a vendor. Where the question is the target design rather than today’s configuration, that work is zero trust architecture.
Workforce identity — the directory your staff sign in to — is a separate and equally productive engagement, covered on identity and workplace security.
Network, logging, encryption
Network exposure and segmentation
What is reachable from the internet and whether it is meant to be; whether a compromise in one workload reaches another; and what egress is permitted, which is the control that decides whether an intruder can get data out and is the one most often left wide open.
Logging and retention
The question is not whether logging is enabled. It is whether, six weeks after something happened, you could reconstruct what happened from what you kept: control-plane logs, data-plane access logs where they matter, retention long enough to cover the gap between compromise and discovery, and storage that the compromised identity could not itself delete.
Data at rest and key management
Encryption at rest is close to universal and close to free, so the finding is almost never that it is absent. It is about who controls the keys, who can use them, whether key use is logged, and whether a single over-privileged principal can decrypt everything.
Which baseline is the review measured against?
The provider’s own. Each major provider publishes a security baseline, and using theirs rather than a private checklist means a finding can be traced to a published position your team can read for itself and argue with:
- Amazon Web Services publishes the AWS Foundational Security Best Practices standard.
- Microsoft publishes the Microsoft cloud security benchmark, organized into control families including network security, identity management, privileged access, data protection, logging and threat detection.
- Google publishes the enterprise foundations blueprint, which doubles as a reference for reviewing an environment that already exists.
These are the provider’s baselines, not ours, and they are named as such in the report. Where this practice disagrees with a baseline item for your context, the report says so and says why, rather than quietly dropping it.
Infrastructure-as-code guardrails, so the fix stays fixed
A finding remediated by hand in a console is a finding that returns. Where your environment is defined in code, the recommendations are written as changes to modules and policy-as-code rules, so the misconfiguration becomes impossible to reintroduce rather than merely absent today. Where it is not defined in code, the report says which findings will recur without that and what the smallest useful first step is.
For environments running models and agents, the equivalent guardrail work is on establishing a secure AI environment.
Provider rules of engagement, and why they matter
Cloud providers set conditions on what customers may do to infrastructure they share with other tenants, and those conditions bind you as well as anyone you hire. A configuration review does not engage them, because it acts on nothing — but the moment a scope extends into testing, they govern it.
Amazon Web Services publishes a customer service policy for penetration testing that names the services customers may test without prior approval and the activities that are prohibited, with simulated denial-of-service handled under a separate policy. Google states in its Cloud security FAQ that customers are not required to notify it before testing their own projects, provided the testing abides by the Acceptable Use Policy and Terms of Service and affects only their own projects. Each provider publishes its own position, and scope is checked against the current text before any testing engagement is agreed.
What you receive
| Deliverable | What it is for |
|---|---|
| Configuration review report | Findings against the provider’s own published baseline, with the baseline item named |
| Prioritized remediation plan | Sequenced by risk and by disruption, so the safe changes go first |
| Guardrail recommendations | Infrastructure-as-code and policy-as-code changes that prevent recurrence |
| Re-review | Confirms what landed, and flags anything the fix moved rather than removed |
Sequencing by disruption as well as risk is deliberate. A remediation plan that opens with the change most likely to break production is a plan that stalls after one attempt, and the second attempt is always harder to fund.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Is this a cloud penetration test?
If what you need is a test, say so at the scoping stage and it is handled as a testing engagement with its own authorization, not folded into a review part-way through.
What access do you need?
Access is time-bounded and removed at the end of the engagement, and the report records what was granted and when it was revoked.
Do you cover more than one provider in one engagement?
Yes, and it is common. Each provider is reviewed against that provider’s own published baseline, and the remediation plans are then merged into one sequence so you are not handed three unrelated backlogs. Multi-cloud estates usually show the same weakness twice in two different dialects, and seeing them side by side is half the value.
Can you fix the findings for us?
We do not operate your cloud environment. The remediation plan is written so your engineers or your managed provider can execute it, and a re-review confirms what actually landed. Keeping the reviewer out of the remediation seat is what keeps the re-review worth reading. The architecture context for those fixes is on security architecture and threat modelling.
Find out what the environment currently permits
Describe the providers, roughly how many accounts or subscriptions are in play, and what the workloads hold. The reply says what a review would cover and what you would receive — see also all security services.