Cloud security assessment services
A cloud security assessment checks how your AWS, Azure or GCP accounts are set up and how an attacker could move through them: who can do what, which storage is exposed, which network paths are open and whether anyone would notice. BERRY9 reviews the configuration and traces the attack paths that matter, working remotely from Hyderabad for teams across India.
- Providers
- AWS, Microsoft Azure, Google Cloud
- Covers
- Identity, storage, networks, secrets, logging
- Delivery
- Remote, from Hyderabad
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Pathpublic internet → F-01 → storage bucket → F-02 → deploy role → F-03 → customer data
Also mappedaudit log · F-04
- F-01A storage bucket lets anyone on the internet list and download its filesHigh
- F-02A backup file in that bucket holds a long-lived access key for the deployment pipelineHigh
- F-03The deployment role may attach any permission policy to itselfCritical
- F-04Audit logging is off in the region where the key was usedMedium
01 / What it is
What a cloud security assessment is, and when you need one
In the cloud, most of the attack surface is configuration. An assessment reads that configuration the way an attacker would, looking for the settings that open a door and the combinations that turn a small opening into a breach.
A cloud security assessment examines how an organization's cloud accounts are configured and what an attacker could do with that configuration. It looks at the settings you control: who and what may act in the account, what each identity is allowed to do, which storage and services can be reached from the internet, how networks are joined, where keys and secrets live, and whether the account keeps a record that someone would actually read.
Those settings are yours to get right because cloud providers split security with their customers. The provider secures its data centers, its hardware and the software that runs its services. The customer secures what it builds and switches on: identities and permissions, data, network rules and the options of every service it uses. Where the line sits depends on the service, and a customer carries more of the work on a virtual machine than on a fully managed database.
BERRY9 assesses accounts on AWS, Microsoft Azure and Google Cloud (GCP), working remotely from its office in Hyderabad.
- AWS
- Microsoft Azure
- Google Cloud (GCP)
The moments when a cloud review earns its cost:
The account grew faster than its rules
A cloud account that started with three engineers and one application tends to collect roles, keys, buckets and peering links nobody remembers creating. A review takes an inventory of what is there now and of who can reach it, before an outsider does the same.
Before a launch or a migration
Moving workloads from your own servers, opening a new region or going live with a product all change what is exposed. Checking the settings before the switch is cheaper than unpicking them afterwards.
After an incident or a leaked key
When a credential has been exposed, the question is what it could reach. Tracing the permissions behind it shows how far the damage could have gone and which other paths look the same.
When a customer or auditor asks
Enterprise questionnaires, SOC 2 and ISO 27001 work regularly ask how the hosting environment is secured. How a cloud review counts as evidence is covered in the compliance section.
Several accounts, several providers
Groups with one subscription per business unit, or one workload on AWS and another on Azure, end up with different rules in each place. An assessment compares them on the same terms and shows where the weakest account sits.
02 / Review or test
Cloud configuration review or cloud penetration test
Two kinds of work go by the name cloud security assessment. One reads every setting with read-only access; the other starts from a foothold and proves how far an attacker gets. Knowing which you need decides the access, the effort and the price.
| Question | Configuration review | Cloud penetration test |
|---|---|---|
| What it answers | Which settings in the account are weaker than they should be | Whether an attacker starting from a given point can turn those settings into access to something that matters |
| Access it needs | A read-only role in each account, subscription or project in scope | Test identities or a test workload at the agreed starting point, plus read-only visibility to plan the paths |
| How wide it goes | Every service and region in scope, at the same depth | The routes the review and the threat model rank highest, followed end to end |
| What it changes in your account | NothingA read-only role cannot create, edit or delete resources | Only what the written scope allows, such as using a test identity to call a service it should not reach |
| Provider testing rules | Reading your own configuration is ordinary use of the account | The provider's published rules for customer security testing apply and are read before testing starts |
The two fit together. A review finds the misconfigurations quickly and across the whole estate; a test proves which of them chain into real access and which are dead ends. The hero diagram on this page is the kind of chain a test follows: each setting is a review finding on its own, and together they are a breach.
BERRY9 offers both: a read-only configuration review and active testing of cloud attack paths such as metadata exposure and role assumption.
AWS, Microsoft Azure and Google Cloud each publish rules for security testing that customers carry out against their own resources. In broad terms, testing your own resources within those rules does not need the provider's approval in advance, while some activities, denial-of-service testing among them, are prohibited or need separate permission. The rules change from time to time, so the current version should be read against the planned tests before any active work begins.
03 / What we check
What a cloud security assessment covers on AWS, Azure and GCP
Six areas make up the assessment, and identity runs through all of them. The provider names differ, so a table below translates each area into AWS, Azure and Google Cloud terms.
Show details for What a cloud security assessment covers on AWS, Azure and GCP
Identity and access management
Users, groups, roles and service identities; the policies attached to each; who can assume which role, from which account; and the permissions that let an identity raise its own privileges. Identity decides almost everything else in a cloud account, so it deserves the closest look.
Storage and data exposure
Buckets, blob containers, file shares, snapshots and database backups: which of them can be read from the internet or from another account, which links have been shared with anyone, and whether encryption settings match what the data needs.
Network fabric
Virtual networks and the peering between them, security groups and firewall rules, internet gateways, and the links back to offices or data centers. The perimeter and internal hosts are covered in depth by network penetration testing.
Secrets and key management
Long-lived access keys and when they were last rotated, secrets left in environment variables, startup scripts and images, and who may use or administer the encryption keys that protect your data.
Logging and monitoring
Whether audit logging is on in every account and region, where the logs are kept and for how long, whether they are protected from the identities they record, and whether anything alerts when a privileged identity signs in or a policy changes.
Workloads and the metadata service
Virtual machines, serverless functions and the roles attached to them. A server-side request forgery flaw in an application can reach the instance metadata service and borrow the host's role; where the older metadata version is still allowed, that one bug can hand over the host role's credentials.
Containers and Kubernetes add their own layer of identities and network rules on top of the account. Whether they are in scope is settled at scoping.
The ideas are the same on each provider, but the names differ. For reference:
| Area | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Unit of scope | Accounts in an organization | Subscriptions under a tenant | Projects under an organization |
| Identity and permissions | IAM users, roles and policies | Microsoft Entra ID and Azure role-based access control | IAM principals, roles and service accounts |
| Virtual network | VPC and VPC peering | Virtual network and peering | VPC network and peering |
| Traffic rules | Security groups and network ACLs | Network security groups | VPC firewall rules |
| Object storage | S3 buckets | Blob Storage in storage accounts | Cloud Storage buckets |
| Keys and secrets | KMS and Secrets Manager | Key Vault | Cloud KMS and Secret Manager |
| Audit trail | CloudTrail | Activity log and Entra ID sign-in logs | Cloud Audit Logs |
Public baselines, such as the CIS Benchmarks published for each of the three providers, list recommended settings and are a common yardstick for the read-only part of the work.
04 / Method
How a cloud assessment runs
A cloud engagement moves through five steps, starting with written authorization and ending with fixes in priority order. Active testing is a step of its own and runs only where the scope asks for it.
Show details for How a cloud assessment runs
Step 1
Scope, authorization and access
Agree which accounts, subscriptions or projects are in scope, which providers and regions they use, where the sensitive data sits and whether active testing is wanted. Written authorization covers every account touched, and a read-only role is created in each one.
OutputSigned scope and read-only access
Step 2
Configuration review
The settings of identity, storage, networking, keys, logging and workloads are read across every account and region in scope and compared with a baseline. Each weak setting is recorded with the resource it belongs to.
OutputMisconfiguration list
Step 3
Attack-path analysis
Single settings are joined into routes: which identity can reach which data, from where, and through how many steps. The routes that end at production data, payment systems or administrator rights are ranked first.
OutputRanked attack paths
Step 4
Active testing, where agreed
From the starting point the scope allows, such as an internet-facing application, a compromised workload or a low-privilege identity, the highest-ranked routes are tried for real: metadata exposure, role assumption across accounts and privilege escalation among them.
OutputConfirmed paths with proof
Step 5
Reporting and clean-up
Findings are written up for decision makers and for the engineers who change the settings, ordered by what to fix first. Once the work is accepted, the review role and any test identities can be deleted from your accounts.
OutputReports and remediation matrix
Read-only access reveals what is configured; it does not show whether a setting is actually exploited somewhere today. A cloud assessment is a point-in-time examination of the estate, not continuous monitoring and not an incident investigation.
05 / Common findings
Cloud misconfigurations that keep coming up
The same handful of mistakes appear on every provider, because they come from how teams work under deadline rather than from any one platform. Each is simple on its own and dangerous in combination.
Show details for Cloud misconfigurations that keep coming up
| Finding | Why it matters | Severity | The change that closes it |
|---|---|---|---|
| Storage readable from the internet | Buckets and containers opened for a quick share, a static site or a partner, and never closed. Backups, exports and log archives in them are often the most sensitive files in the account. | VariesDepends entirely on what the storage holds. | Block public access at the account level and grant access through identities or expiring signed links instead. |
| Permissions far wider than the job | Wildcard actions, administrator policies attached to build servers and functions, and users who still hold rights for a project that ended. Any one compromised identity then reaches much more than it needs. | VariesA common root cause behind cloud attack paths. | Policies narrowed to the actions each identity actually uses, and unused identities removed. |
| Routes to escalate privilege | An identity that may edit its own policies, pass a powerful role to a new resource, or change code that runs with administrator rights can make itself an administrator without anyone granting it. | VariesRarely visible without tracing permissions end to end. | The specific permission removed, or limited with conditions and permission boundaries. |
| Long-lived keys and misplaced secrets | Access keys that have never been rotated, and passwords or tokens stored in environment variables, startup scripts, container images or code repositories, where far more people and systems can read them. | VariesOne leaked key can undo every other control. | Short-lived credentials issued to roles and workloads, and secrets moved into the provider's secret store. |
| Administration ports open to everyone | Security group and firewall rules that allow remote login or database ports from any address on the internet, often added during a fault and left in place. | VariesEasy to find for anyone scanning the internet. | Rules limited to known address ranges, or administration moved behind a managed access service. |
| Metadata service reachable through SSRF | Hosts that still accept the older, token-less metadata requests, combined with an application that fetches URLs for its users. The application flaw becomes a theft of the host's cloud credentials. | VariesAn application bug with an account-level impact. | Token-based metadata access enforced on every host, outbound requests to the metadata address blocked, and the host's role narrowed. |
| Audit logs off, partial or unread | Logging missing in some accounts or regions, kept for days rather than months, stored where the logged identities can delete them, or never connected to an alert. | VariesDoes not open a door, but hides every other finding. | An organization-wide audit trail written to a separate, locked-down account, with alerts on privileged activity. |
| Privileged sign-in without a second factor | Root or global administrator accounts, and console users with wide rights, protected by a password alone. | VariesTurns a phished password into control of the account. | Multi-factor authentication enforced for every person, and the root account locked away for emergencies only. |
A setting's severity depends on what sits behind it and on whether an attacker can reach it, so the table rates each class as Varies. In the report, every finding is rated for your account.
06 / What you receive
What you receive from a cloud assessment
A cloud report is read by two audiences: the people who decide what gets fixed first, and the engineers who change the settings. Each gets a report written for them, and both see the attack paths, not just a list of settings.
Show details for What you receive from a cloud assessment
- An executive report for the people who set priorities: which accounts were assessed, the routes that matter most to the business, and roughly how much work closing them takes.
- An engineering report that names each weak setting, the account and resource it belongs to, and the change that fixes it, written for the engineers who own the infrastructure.
- Attack paths drawn end to end, so a team can see why three medium findings together count as one serious one.
- A proof of concept for each confirmed finding from active testing, showing what an attacker could actually reach.
- A remediation matrix that orders the fixes, so the change that breaks the most paths comes first.
- Severity scoring: A CVSS 3.1 score goes with every finding, read-only configuration review included.
To see how findings, severity and fixes are laid out across a whole engagement, open the sample VAPT report. The phases behind a cloud review are set out in our VAPT methodology.
Finding F-03 · Cloud assessment
Deployment role can grant itself administrator rights
- Severity
- Critical
- Resource
- Role deploy-pipeline, production account
- Starting point
- The access key from finding F-02
How the path was confirmed
- The key found in the public backup file signs in as the deployment pipeline's identity.
- That identity may assume the deploy-pipeline role, whose policy allows attaching any policy to any role.
- Attaching an administrator policy would give the role full control of the account, including the customer database.
"Effect": "Allow",
"Action": "iam:AttachRolePolicy",
"Resource": "*"
Fix
Remove the policy-attachment permission from the role, limit what it may deploy to named resources, and replace the stored key with short-lived credentials issued to the pipeline.
Example layout, not client dataPrivilege escalation · IAM
07 / Your access
What access you give us
The access you grant shapes the assessment and the risk you take on. A configuration review needs read-only visibility; a cloud penetration test needs test identities placed where an attacker would start.
Show details for What access you give us
What we need from you
- A list of what is in scope: accounts, subscriptions or projects, the regions in use, and which of them are production.
- A read-only role in each one, created by your team, so you decide when it is granted and when it is removed.
- Test identities or a test workload, only if active testing is in scope, set up at the starting point the scope describes.
- An architecture sketch, even a rough one, showing the main workloads, where customer data is stored and how the accounts connect.
- Authorization in writing from someone entitled to give it for every account, including accounts run for you by a partner.
Read-only review. The provider's built-in read-only or security-audit roles let a reviewer see settings without being able to change them. A good review role can read configuration but not the contents of your storage or databases, and it expires or is deleted when the work ends.
Active testing. A test needs identities that start where an attacker would: an ordinary user, an application's role, or no access at all. They are created for the engagement, limited to the scope, and removed afterwards. Root accounts and global administrator passwords should never be shared for either kind of work.
Role names, account identifiers and architecture notes you hand over are covered by the engagement agreement. The privacy notice deals only with messages sent through this website.
Cloud accounts are reached over the internet, so the whole assessment runs remotely from BERRY9's single office in Hyderabad; a meeting at your premises can be arranged if you want one.
08 / Related tests
Cloud assessment alongside network, web, API and DevSecOps work
A cloud account is where your applications run and your networks meet, so attack paths rarely stay inside one kind of test. These are the services a cloud review most often sits next to.
Show details for Cloud assessment alongside network, web, API and DevSecOps work
Network penetration testing
The hosts behind your public addresses and the network inside, tested as an attacker would meet them. Hybrid estates, where cloud networks connect back to offices, often need both pieces of work.
Web application testing
A cloud breach can begin in an application: a URL-fetching feature, an upload or an exposed admin panel. Testing the application finds the first step of the chain the cloud review then follows.
API security testing
APIs running on serverless functions and managed gateways inherit the permissions of the roles behind them. An API test shows what a caller can do; the cloud review shows what the function's role could do if that caller got further.
DevSecOps services
Settings defined in infrastructure-as-code drift back to their old values if the template is not fixed too. Checking templates and pipeline identities before anything deploys belongs to a separate DevSecOps engagement.
For the full list of tests, from wireless to red teaming, see the offensive security services hub.
09 / Price
What a cloud security assessment costs
A cloud security assessment starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. Cloud work is an advanced scope: the size of the estate and the depth you choose vary too much for one figure to fit every account.
Cloud security assessment
Starts fromINR 27,000 + 18% GST
The opening figure for the smallest cloud scope. Accounts, providers and depth move it, and your number appears in the proposal.
Request a scoping call- How many accounts. One production account is a different job from an organization with separate accounts or subscriptions for every team and environment.
- How many providers. Each provider has its own identity model and its own services, so an estate split across two of them is assessed twice over.
- Review only, or review and test. Reading configuration takes less time than confirming attack paths from a starting point, and the scope says which you want.
- How much runs there. The number of services and regions in use, and how much of the estate is managed by hand rather than by templates, change the work.
Turnaround: Timing is agreed in the written proposal once the scope is known.
For a side-by-side look at what web, API, network and cloud tests cost, read our guide to VAPT pricing in India.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
Cloud assessments by city
10 / Compliance evidence
Cloud assessment for ISO 27001, SOC 2, PCI DSS and HIPAA
Frameworks rarely name a cloud review, but most ask how the environment that holds your data is protected. The report is one piece of evidence; how much weight it carries is your auditor's or assessor's call.
Show details for Cloud assessment for ISO 27001, SOC 2, PCI DSS and HIPAA
ISO 27001
Two controls in the 2022 edition of ISO/IEC 27001 touch cloud accounts directly: information security for the use of cloud services (5.23) and management of technical vulnerabilities (8.8). An assessment of the cloud accounts in your ISMS scope is evidence for both. BERRY9 holds ISO/IEC 27001:2022 certificate 26MEQVU27.
SOC 2
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. For a SaaS product, the cloud account the product runs in usually sits inside the system the report describes.
PCI DSS
PCI DSS version 4.x, in requirement 11.4, expects penetration tests from outside and from inside the network. If network controls are relied on to keep systems out of the cardholder data environment, those segmentation controls are tested as well. In a cloud-hosted environment those controls are often security groups, firewall rules and peering.
HIPAA
Under the HIPAA Security Rule, organizations that handle electronic health information analyze the risks to it and evaluate their safeguards periodically. When patient records sit in cloud storage, a review of that account feeds the risk analysis.
BERRY9 assesses and tests cloud accounts; it is not an auditor or a certification body for your organization. The auditor or assessor judges whether a cloud assessment counts toward their framework, which makes their written requirement useful to have before scoping starts.
11 / Inquiry
Tell us about your cloud estate
Tell us which providers you use, roughly how many accounts, subscriptions or projects there are, what runs in them, whether you want a review, a test or both, and your deadline. That is enough to propose whether a review, a test or both fit, and how long the work should run.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
12 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What is a cloud security assessment?
It is an examination of how your cloud accounts are configured and what an attacker could do with that configuration. It covers identities and permissions, storage that can be reached from outside, network rules and peering, keys and secrets, logging, and the roles attached to workloads. The result is a list of weak settings, the attack paths they form, and the changes that close them. See the section on What a cloud security assessment is, and when you need one above.
What is the difference between a cloud configuration review and a cloud penetration test?
A configuration review uses read-only access to read every setting in the accounts in scope and compare it with a baseline; it changes nothing and covers the whole estate quickly. A cloud penetration test starts from an agreed foothold, such as an internet-facing application or a low-privilege identity, and tries to turn misconfigurations into real access. The review shows what is weak; the test shows which weaknesses an attacker can actually chain together. See the section on Cloud configuration review or cloud penetration test above.
Do we need permission from AWS, Azure or Google Cloud before a cloud penetration test?
Generally not in advance, for testing your own resources. Each of the three providers publishes rules for customer security testing: within them, no prior approval is needed for most tests, while some activities, such as denial-of-service testing, are prohibited or need separate permission. The rules change from time to time, so the current version should be checked against the planned tests before work begins. You still need to authorize the test in writing for every account involved. See the section on Cloud configuration review or cloud penetration test above.
What access do you need to our AWS, Azure or GCP account?
For a configuration review, a read-only role in each account, subscription or project in scope, created by your team so you control when it is granted and removed. For active testing, test identities or a test workload at the starting point the scope describes. Root accounts and global administrator passwords should never be shared for either kind of work. See the section on What access you give us above.
How much does a cloud security assessment cost in India?
A cloud security assessment from BERRY9 starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The main factors are how many accounts, subscriptions or projects are in scope, how many providers you use, how many services and regions run there, and whether you want a read-only review or active testing as well. Because the work is done remotely from Hyderabad, the starting price is the same wherever your team is based. See the section on What a cloud security assessment costs above.
Do you assess AWS, Azure and GCP?
Yes. BERRY9 assesses accounts on AWS, Microsoft Azure and Google Cloud, including estates that use more than one of them, and hybrid networks where cloud networks connect back to offices or data centers. The checks are the same on each provider, applied to that provider's own identity model and services. See the section on What a cloud security assessment covers on AWS, Azure and GCP above.
What is the shared responsibility model?
It is how cloud providers divide security with their customers. The provider secures its data centers, hardware and the software that runs its services; the customer secures what it builds and configures, including identities, permissions, data, network rules and service settings. The split shifts with the service: a customer is responsible for more on a virtual machine than on a fully managed database. A cloud security assessment checks the customer's side. See the section on What a cloud security assessment is, and when you need one above.
Will a cloud assessment disrupt our production workloads?
A configuration review works through a read-only role, which cannot create, change or delete resources, so it does not touch running workloads. Active testing does act inside the account, which is why what may be tested, from which starting point, and what is off limits are agreed in writing before it begins. See the section on How a cloud assessment runs above.
How often should a cloud environment be assessed?
There is no single rule. A common pattern is to assess once a year and again after significant changes, such as a migration, a new region, a merger of accounts or a change in who manages the infrastructure. Compliance frameworks and customer contracts may set their own interval, so check what yours ask for.
Which cloud accounts and regions should be in scope?
Start with the accounts that hold production workloads and customer data, together with the identities and roles that can change them. Development and test accounts are worth adding when they share credentials, networks or pipelines with production. List every region actually in use, because resources left running in a forgotten region are still part of the estate. The written scope names each account or subscription, and anything left out is listed as excluded.