Cloud security assessment: agree access before anyone logs in

Scope follows the data

Many cloud assessments go wrong at the access request. Give the assessor a role that can’t see organisation-level settings and the report comes back with blind spots that look like clean results. We’d settle access on the call, so the gap doesn’t turn up halfway through the work.

Scope by where your data and the admin rights live. A forgotten sandbox account holding a copy of production data can matter more than the main account everyone has worked on. Ask about old test and staging accounts by name.

Read-only access that sees enough

Read-only is the right default, but read-only roles vary a lot. Some can see your workloads but not your organisation policies or who holds admin rights. That leaves the most important questions unanswered. When that happens, the report should say so as a limit on scope. A view the assessor never had should not appear as a low-risk result.

Take a company that gives view access to its production account and leaves out the central log archive. The assessment can describe the workloads in that account. It can’t tell you whether a former admin still has a way in.

We’d ask for a separate identity for the assessor. It should have MFA and an end date, and it shouldn’t be able to change anything or read your data. Lending a personal admin account is the shortcut to avoid. If console access isn’t possible, configuration exports work, as long as both sides agree in writing what was left out.

These are the questions we’d settle before any work starts.

• Which accounts, subscriptions or projects are in scope, and who owns each?
• Can the assessor’s role see organisation settings and the audit log archive?
• When does the access expire, and who removes it?
• Will the report list what the assessor could not see?

How deep each area goes

A first assessment usually samples a few workloads and checks the guardrails that apply across the organisation. A deeper one follows a single regulated data flow from end to end. Ask which you are buying. A checklist will confirm that encryption is switched on and miss who is allowed to decrypt.

Logging needs the same care. Switching on a logging service takes minutes. What matters is whether it records admin actions, and whether the people who can delete those records are the same people the logs are meant to watch.

What the report should leave you with

Each finding should name the account it applies to and say how you will know the fix worked. Priority should follow what’s actually exposed. An unused experiment account with owner-level keys can need attention before a page of tagging warnings.