Ask for a responsibility receipt before you ask for a security score. For every cloud service in scope, the receipt names what the provider secures, what your team still owns, where the evidence lives, and who closes a gap. Microsoft says customers retain responsibility for data, identities, configurations, and access management across cloud service models. AWS says its Well-Architected Framework gives teams a consistent way to measure workloads against current best practices and identify areas for improvement. A consulting engagement earns its fee by turning those broad responsibilities into tested, owned work.
Cloud security consulting services should leave you with proof, not a heat map with twelve amber boxes or a list of every setting a scanner dislikes. This guide shows what to demand in discovery, identity review, data-path analysis, incident evidence, and remediation. Use it to write a request for proposal or challenge one already on your desk.
Build the responsibility receipt first
Cloud security work goes wrong early when everyone assumes the provider owns more than it does. The exact boundary changes by service model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Customer data | customer | customer | customer |
| Identities and users | customer | customer | customer |
| Configurations and settings | customer | customer | customer |
| Applications | customer | shared | shared |
| Network controls | customer | shared | provider |
| Operating system | customer | provider | provider |
| Physical infrastructure | provider | provider | provider |
This is a condensed reading of Microsoft’s shared-responsibility matrix. It exposes the first trap. Moving a database from a virtual machine to a managed database transfers operating-system work to the provider. It does not transfer responsibility for the data, user accounts, access rules, or service configuration. Moving email to Microsoft 365 transfers more of the stack, but you still own who has an account, who has administrator rights, how conditional access is configured, and what data your people share.
Ask the consultant to create a responsibility receipt for every in-scope service. One row per control area. One named owner on your side, one provider responsibility where applicable, and an evidence source. “AWS” is not an owner. “Platform team checks Security Hub findings weekly; evidence is retained in the ticketing system” is.
Inventory the estate from live evidence
You cannot review an environment from the diagram used during the migration. The inventory must come from live provider data.
For AWS, that means accounts, organizations, regions, VPCs, public endpoints, identity stores, data services, keys, logging destinations, and backup vaults. Azure adds tenants, subscriptions, management groups, Entra identities, resource groups, private endpoints, policy assignments, and diagnostic settings. Google Cloud has organizations, folders, projects, service accounts, networks, and audit-log sinks. SaaS belongs in the inventory too when it carries company data or can issue tokens into the cloud estate.
A credible discovery pass reconciles at least four views:
- Billing: resources consuming money but missing from the architecture record.
- Identity: human and machine principals that can reach cloud services.
- Network: internet-facing paths, private connectivity, peering, and egress.
- Data: storage, databases, queues, snapshots, exports, and backups.
The gaps between those views matter. A forgotten subscription with no production traffic may still contain a public snapshot. A service account may hold access to a project that the asset spreadsheet says was retired. An old backup can carry the sensitive data that the current database no longer does.
Do not accept “we scanned the production account” as the complete scope. Shadow accounts, acquired tenants, development subscriptions, and the backup plane are common places for old permissions and old data to survive.
Trace privilege as an attack path
Identity is the control plane. A firewall review cannot compensate for an overpowered administrator token.
The review should separate four populations: workforce users, privileged administrators, workload identities, and external identities. Each gets a different test.
Workforce users: stale accounts, missing multifactor authentication, weak conditional-access coverage, risky authentication methods, and group membership inherited long after a project ended.
Privileged administrators: standing privileges, emergency accounts, role activation, separation between daily and admin identities, and whether privileged actions generate alerts someone sees.
Workload identities: long-lived keys, secrets in deployment systems, unused permissions, cross-account trust, token audience, and whether a compromised workload can assume a more powerful role.
External identities: vendors, guests, support accounts, federated partners, and customer-managed connections. The question is not merely whether access was approved once. It is whether the need still exists and who reviews it now.
Microsoft’s baseline stays useful across providers: customers always retain account and access-management responsibility, including RBAC, multifactor authentication, and conditional access. Your consultant should turn that responsibility into an attack-path view. Start with an ordinary user or workload. Show each step by which it could reach sensitive data or administration. Then remove steps that do not serve a current business need.
Follow sensitive records to every exit
“Encrypted at rest” answers a narrow storage question. It says little about who can export the data, where snapshots replicate, which services can send it to the internet, or whether logs capture the transfer.
Trace a small number of important records end to end. Pick one customer record, one employee record, one secret, and one backup. For each, document:
- where it enters;
- where it is stored and copied;
- which identities can read or export it;
- what encryption and key boundary applies;
- which outbound paths exist;
- where deletion and retention rules are enforced;
- what event would prove it moved.
That last line distinguishes a policy from a control. If an administrator exports a database, which log records it? Where does the log go? Can the same administrator alter or delete that evidence? How long is it retained? Who gets alerted?
The Cloud Security Alliance’s Cloud Controls Matrix is useful here because it is cloud-specific: 197 control objectives across 17 domains, including data security and privacy, identity and access management, cryptography and key management, logging and monitoring, incident management, supply-chain management, and vulnerability management. It is a strong coverage reference. It is not a reason to test 197 controls indiscriminately. Select the controls that intersect the data paths and obligations in scope.
Make the incident trail prove itself
Assume an incident responder arrives on Monday and the person who built the environment is unavailable. Can that responder answer what changed, who changed it, which identity was used, what data was touched, and whether recovery works?
The consultant should sample evidence, not ask whether logging is “enabled.” Useful tests include:
- retrieve a real privileged change from the audit trail;
- trace one denied and one successful access event;
- confirm central logs arrive from every in-scope account or subscription;
- test whether a workload administrator can tamper with the log destination;
- restore a representative backup into an isolated environment;
- compare the recovery result with the documented recovery objective;
- prove that security alerts reach an owned queue and receive a disposition.
A green console icon is weak evidence. A restored object, a searchable event, and a closed alert ticket are stronger.
AWS places security beside reliability, operational excellence, performance efficiency, cost optimization, and sustainability in its six-pillar Well-Architected Framework. That matters because cloud security is not separable from operations. A security control nobody can operate during an outage is not finished. A backup nobody restores is an assumption.
Turn findings into three owned queues
The findings report is where many consulting engagements stop being useful. A list of 140 observations, sorted by scanner severity, pushes the hard prioritization back onto the buyer.
Require every finding to carry seven fields:
| Field | What good looks like |
|---|---|
| Affected asset | exact account, subscription, project, service, and resource |
| Evidence | query, screenshot, configuration, or event that proves the condition |
| Attack or failure path | how the condition becomes business impact |
| Priority | based on exposure, privilege, data, and exploit path, not scanner color alone |
| Fix | specific configuration or engineering change |
| Owner | named team or role able to make the change |
| Retest | the evidence that will close the finding |
Now group the work into three queues. Immediate containment closes exposed data, leaked keys, uncontrolled admin paths, and missing evidence on critical systems. Planned remediation handles architectural changes, identity redesign, segmentation, and logging coverage. Accepted decisions record risks the business chooses not to fix, with an owner and review date.
This structure prevents two bad outcomes: engineers spending a month polishing low-impact settings while a broad role stays untouched, and leadership believing the work finished because the assessment meeting happened.
Cloud security assessment vs penetration test
These are complementary purchases, not interchangeable labels.
A cloud security assessment reviews the broad system: accounts, architecture, identities, configurations, data paths, logging, resilience, and operating ownership. A penetration test works inside an approved boundary and tries to prove that selected weaknesses are exploitable. Assessment asks, “Where are our control gaps?” Pentest asks, “Can this path be used?”
Run the broad review first when the environment has never been assessed or changed materially. It is wasteful to pay a penetration tester to rediscover public storage, permanent administrator rights, and missing logs. Run a pentest when the basic control plane is understood and you need adversarial proof around an application, tenant, external boundary, or high-value attack path. Our security audit services guide breaks down the broader audit types, while the penetration testing cost guide covers the offensive side.
How to compare consulting proposals
Put the proposals side by side and ignore the page count. Score these six commitments instead.
| Proposal question | Strong answer | Weak answer |
|---|---|---|
| How is scope discovered? | live inventory across billing, identity, network, and data | workshop plus supplied spreadsheet |
| How are responsibilities mapped? | per service and control, with named owners | generic shared-responsibility slide |
| How is evidence collected? | reproducible queries and sampled tests | scanner screenshots |
| How are findings ranked? | attack path and business impact | tool severity |
| Who fixes findings? | remediation included or explicitly handed to named teams | assessment ends at report delivery |
| How is closure proved? | retest evidence and residual-risk record | final presentation |
Framework logos do not answer these questions. Neither does a promise to “align with best practices.” Ask which controls will be tested, why those controls fit this environment, which services are excluded, and what artifact your engineers receive for each finding.
The NIST Cybersecurity Framework 2.0 is intended to help organizations understand and improve their management of cybersecurity risk. AWS Well-Architected is aimed at workload decisions. CSA CCM is cloud-control specific. A good proposal may use all three at different levels. A bad one turns one framework into a giant checklist and invoices for coverage you did not need.
When a focused peer review is enough
Not every cloud environment needs a consulting engagement. A small team with one account, infrastructure as code, short-lived access, central logs, tested recovery, and an engineer who owns security can often run a focused peer review. Use the provider framework, pull live inventory, inspect the critical data path, and ask someone uninvolved in the build to challenge it.
Hire outside help when one of these is true:
- a regulated workload or sensitive-data product is about to launch;
- a migration, merger, or acquisition changed the account and identity model;
- a customer, insurer, or board wants independent evidence;
- an incident exposed uncertainty about access or logs;
- multiple clouds or SaaS tenants have no single owner;
- the internal team can operate the platform but cannot independently assess its design.
The trigger is uncertainty with consequences. If nobody can explain the privilege path to production, you do not need another dashboard. You need someone to map it and remove what should not exist.
How gmware scopes the work
Our cybersecurity practice and cloud consulting team work from the same queue. We inventory the live estate, map identity and data paths, collect evidence, and rank the fixes. Then engineers close the configuration and infrastructure work instead of leaving your team with a report-shaped backlog. If the review follows a move, our cloud migration services team also checks whether temporary migration access, duplicate stores, and bridge networks were retired.
We will narrow the engagement when the environment is simple. One subscription and one critical workload should not receive an enterprise framework marathon. We will also separate assessment from certification: we can prepare evidence and remediate technical gaps, but an independent accredited auditor must issue a certification when a formal program requires one.
Bring an account count, cloud providers, critical workloads, identity source, and the reason the review is happening. Reach out, and we will return a proposed scope that names the evidence, deliverables, and owners before anyone starts scanning.