What the conversation should produce.
- A service register listing every in-scope resource, its owner and the region it resides in.
- An identity chain diagram showing trust relationships and role assumption paths across accounts.
- An evidence matrix recording which policy exports, logs and snapshots are available, with source and timestamp.
Define the specific cloud estate and shared responsibilities
A cloud estate is not a single account but a collection of services, regions and accounts that together hold data and run workloads. Before any review begins, list every service in scope, including storage buckets, compute instances, managed databases and identity providers. Note which components are managed by the provider and which the organisation controls. This distinction determines what evidence can be requested and what must be inferred from configuration.
Map responsibilities for each service and deployment model rather than applying one generic cloud checklist. The provider’s managed scope and the customer’s configuration responsibilities can differ substantially between infrastructure, managed platforms and hosted applications. Ask the relevant owners to confirm which settings they control, what evidence is available and which provider guidance applies. Patching, encryption and network controls should not be assigned to one party by assumption. The resulting responsibility map helps keep the review within authority and identifies questions that require a different source of evidence.
Map account boundaries, identity relationships and data flows
Accounts and organisational units create the first layer of isolation, but identity relationships cross those boundaries more often than expected. Policies attached to roles, groups and service accounts can grant access across accounts without obvious visual indication. Map every role that assumes another role, every trust relationship between accounts and every cross-account resource reference. This map becomes the foundation for understanding how a compromise in one area could reach another.
Data flows reveal where isolation matters most. Trace how data moves between services, regions and accounts, noting where it is stored, processed or exported. A storage bucket that appears private may still be reachable through a cross-account role or a public endpoint enabled by a template. Document the flow paths alongside the identity map so that later findings can be traced to their origin rather than treated as isolated observations.
Prepare configuration evidence and narrowly scoped review access
Configuration evidence should be collected before access is granted, where possible. Export current policy documents, resource inventories and audit logs so the review can proceed even if live access is restricted. Version the exports with timestamps and note the source account or region. This practice protects both parties: it reduces the window during which review credentials exist and creates a baseline that can be compared after changes.
When granting review access, use the narrowest scope that still allows meaningful evaluation. Prefer read-only permissions on specific resources rather than broad administrative roles. Time-bound access with automatic revocation limits exposure if credentials are compromised. Document exactly which permissions were granted, for which resources and for how long. This discipline keeps the assessment itself from becoming a new attack surface while still providing enough visibility to assess risk accurately.
Evaluate permissions, exposure and logging as connected questions
Evaluate permissions, exposure and logging as connected questions. A permission may be usable through a path that is not visible from a simple external view, and a private resource may still matter through an identity relationship. Ask which identities can reach the relevant action, under what conditions and what observation would be available if it occurred. An apparently restricted network location is context, not proof that an excessive permission is harmless. Preserve the distinction between a possible path and one actually verified within the review.
Conversely, a finding that appears minor in isolation can be significant when combined with others. A weak password policy may matter little until a misconfigured role allows lateral movement to a logging system that should have recorded the abuse. Structure the evaluation around chains rather than individual items. This approach surfaces the combinations that actually matter and avoids the false confidence that comes from checking boxes without understanding connectivity.
Separate observed misconfiguration from untested consequence
A misconfiguration is an observed fact: a bucket set to public, a role with excessive permissions, a logging rule that is disabled. A consequence is a hypothesis about what that misconfiguration enables. Distinguish the two explicitly in every finding. State what was seen, what was tested and what remains untested. This separation prevents readers from assuming that a visible flaw automatically means a breach or that an untested area is safe.
Untested areas are not failures of the assessment; they are honest boundaries. Access may be restricted, tools may not cover a service or time may be insufficient to probe every path. Record these limits clearly so the organisation knows where confidence is lower. The value of the assessment lies in the quality of the distinction, not in the illusion that everything has been verified. Unverified assumptions should be treated as work for the next review, not as resolved findings.
Plan ownership, change control and verification of improvements
Assign improvements to owners who can coordinate the relevant resource, policy and workflow. In a shared platform, that may require more than one team. Document the proposed change, its dependencies and the decision that has been agreed, including any unresolved constraints. Do not confuse ownership of the report with authority to alter a production environment. Use the organisation’s change process to assess operational effects, then keep the original finding linked to the implementation and the evidence used to check it.
Define verification in terms of the improvement being claimed. A configuration export may show that a setting changed, while an observed test may be needed to examine the resulting behaviour. Record the source and timing of the evidence and choose a review arrangement appropriate to the importance of the change. A future check should be tied to the organisation’s needs and relevant changes, rather than an arbitrary schedule. The goal is a repeatable question with clear limits, not a permanent claim that the environment cannot drift.
A data pipeline that crosses an account boundary
Consider an illustrative organisation with an analytics environment that reads a selected dataset owned by a separate platform environment. The intended relationship is documented, but the review needs to establish which identity performs the read, what permissions are effective and what records of the activity are available. The environments have different owners and deployment processes. Configuration exports describe the declared access, while agreed observations can help determine whether the intended boundary is reflected in actual behaviour. Other datasets and unrelated identities remain outside the review.
- Confirm the complete permission and trust relationship with both owners before treating either a private storage setting or an individual policy statement as the whole answer. Record which conditions were directly verified.
- Determine what activity evidence is available and whether its detail and retention support the investigation question. Missing history limits reconstruction; it does not establish that no activity occurred.
- If access is broader than intended, agree the required business use and a controlled change with the relevant owners. Define how the specific relationship will be checked afterwards without disrupting unrelated work.
The example explains why an account boundary, a permission record and a logging setting need to be considered together. It does not assert that a particular provider policy grants access, that an exposure has been exploited or that changing one statement resolves every related path.
Useful decision table for cloud assessment scoping
| Question | What to establish | Useful output |
|---|---|---|
| Which services hold data we care about | Inventory of storage, compute and database resources with owners | Service register with region and owner columns |
| Who can reach those services across accounts | Trust relationships and role assumption paths between accounts | Identity chain diagram showing each assumed role |
| What evidence exists for each control | Availability of policy exports, logs and configuration snapshots | Evidence matrix listing source, format and timestamp |
Scroll the table horizontally on smaller screens.
Useful questions.
How do we know which findings are urgent versus cosmetic?
Consider the verified consequence, effective access conditions, affected data or workflow and existing controls. A lack of logging may make investigation harder; it does not make an exposure less urgent. Record uncertainty and dependencies alongside the finding so the responsible owners can make a contextual priority decision rather than ranking isolated settings by appearance.
What if the organisation cannot grant read-only access to all resources?
Prioritise the resources that hold data or control identity, and accept that other areas will remain untested. Document the limitation explicitly and treat it as a boundary, not a failure. The assessment can still provide value by verifying the parts that are accessible and flagging the gaps for a future review when access can be broadened.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.