What does a cloud security assessment include?

Identity and privilege, public exposure, storage, network paths into management planes, logging, and the places where a workload and its credentials trust each other more than the design intended. We name the accounts in scope. A subscription you did not include is not reviewed, and we will not quietly widen the list because a role could see it.

Is this allowed by AWS, Azure, or Google Cloud?

Reviewing your own account is your right, and the providers expect customers to test their configuration. Attacking the provider's own infrastructure is not. We stay inside the accounts you authorize. Where a provider has a testing policy that asks for notice, we follow it, and we will tell you if a check you want would cross that line.

Do you need administrator access?

Read-only access is enough for most of the work. Where a check needs a change, or where you want us to attempt a specific path, that attempt is written down first. We do not need, and we should not hold, a permanent administrator role in the production account.

Will you compare us to a CIS benchmark?

We can use a CIS benchmark, or the provider's own foundations guide, as a checklist of coverage. A failed benchmark item is not automatically a finding. We write up the items that change exposure. A missing decorative tag and a public management path are not the same kind of problem, even if both fail a spreadsheet.

Is this a cloud penetration test?

The assessment includes attempted use of a path when you authorize that attempt. It is not an effort to break the hypervisor or the provider. If the question is the application running in the account, you also want a web or API test. If the question is the account itself, this is the engagement.

Cloud Security Assessment & Cloud Pentest

What is a cloud security assessment?

A cloud security assessment is a review of the accounts you run, and of the access paths that configuration creates. It looks at identity, exposure, storage, logging, and the credentials a workload is willing to trust. It is not an attempt to break the cloud provider, and it is not a claim that a shared-responsibility model has been certified. The report is written so a platform team can change the account and so a security lead can see which items actually change who can reach what.

What we test

We work in the provider you use. The same questions show up on AWS, Microsoft Azure, and Google Cloud, with different names. Who can assume a privileged role? Which storage is reachable without authentication? Which management endpoint is exposed beyond the people who administer it? Where do logs stop, and would you notice the path we just walked? A workload that carries a credential broader than its job is a finding when we can show what that credential can do, not when a linter disliked the policy language.

Microsoft 365 and similar identity planes are in scope only when you name them. Mail, files, and the directory that feeds single sign-on are a different surface from a virtual network, and the scope should say which one we are looking at. We do not treat a tenant we were not given as fair game because a user in the cloud account could open it.

You provide read-only access for the accounts, projects, or subscriptions in scope, and a person who can explain a path that looks intentional. We name those accounts. Read access to a payer account does not silently add every linked account underneath it.

Approach and standards

Most of the work is configuration review plus a small number of authorized attempts. Read-only access is enough until a check needs a change or you want a path exercised. That attempt is written into the rules first, the same way every other engagement uses the methodology.

CIS benchmarks and the providers’ foundations guidance are useful as coverage checklists. We do not grade you as “CIS compliant.” A control that failed on paper and does not change exposure is noted differently from a public management path. OWASP guidance matters when the thing in the account is an application. The account and the application are different tests. See web application penetration testing when the requests are the question.

If you want findings beside ISO 27001, SOC 2, or a regulator’s cloud expectations, name the set. We map gaps. We do not issue an opinion a certification body would recognize. Teams in Qatar and in the EU often ask about that mapping. The Doha and Marseille pages describe the local context without pretending we are an accredited auditor.

How long it takes and what affects the price

A single account with one main workload is often four to eight days of review, plus the report. Several accounts, a landing zone, or an identity plane that spans cloud and Microsoft 365 takes longer. An authorized attempt to use a specific path adds time because it has to be careful. The contract names the window.

Price follows the number of accounts and providers, whether identity and endpoint management are included, how much of the environment is production, and whether you want a retest after the changes. A tidy account with infrastructure as code is faster to read than an account that grew by hand. We will say which one we think we are looking at during scoping.

What you receive

You receive the list of accounts in scope, findings tied to the control that failed and the impact of that failure, a short summary, and a retest if you asked for one. Engineers get the change to make. Leaders get the items that change exposure, separated from the items that are hygiene. The document set matches the rest of the practice, described on the methodology page.

When to choose this

Choose this when the worry is the account: identity, exposure, storage, and logging. Choose network penetration testing when you want a packet-level view of ranges and remote access that are not expressed as cloud configuration. Choose an application or API test when the data moves through requests a customer sends. A combined scope is reasonable when the application and the account are one question. Say that on the contact page and we will write it as one engagement rather than two reports that do not refer to each other.