Cloud security questions your auditor will ask

Cloud audits go badly for a predictable reason: the controls are usually in place, but the evidence that they were in place throughout the period is not. An auditor is not asking whether your environment is secure today. They are asking whether you can demonstrate it was secure for the whole period, and that you would have noticed if it had not been.

This is the list of questions that comes up most often, and what to have ready for each.

Access

Who has administrative access, and how did they get it?

Have an export of privileged roles and their members, and be able to show the request and approval that put each person there. "They have always had it" is the answer that generates a finding.

How do you remove access when someone leaves?

Show the link between your HR leaver process and cloud access removal. If access is granted through your identity provider and groups are driven by HR data, this is a short conversation. If cloud users are created manually, expect to be asked for evidence of every leaver in the period.

Are there any long-lived credentials?

Access keys and service account passwords that do not expire are a standard finding. Have an inventory, an age for each, a justification for the ones that remain, and evidence of rotation.

How is emergency access controlled?

There should be a break-glass account, it should be documented, its use should generate an alert, and you should be able to show whether it was used during the period.

Configuration

What is your baseline, and how do you know things still match it?

An auditor wants to see a defined standard and a mechanism that checks against it continuously. A configuration compliance service, a policy engine, or benchmark scanning all qualify. A quarterly manual review is weaker but is better than nothing.

How do you prevent public exposure of storage?

Show the preventive control, not just the detective one. Being able to say that public access is blocked at the account level and can only be overridden by an explicit, logged exception is much stronger than showing a report that says nothing is currently public.

Is data encrypted at rest and in transit, and who controls the keys?

Have the answer for each data store, not in general. Be clear about which keys are platform-managed and which are customer-managed, and be able to justify the choice.

Logging and monitoring

What is logged, where does it go, and who can delete it?

The important part is the last one. If the people with production access can also delete the audit trail, the control is weak regardless of what is captured. Show that logs are written to an account or subscription that workload teams cannot write to.

How long is it retained?

Have the number, and check it against what your policy says. A mismatch between stated policy and actual configuration is one of the easiest findings for an auditor to write.

What generates an alert, and what happened when one fired?

Be ready to show a real alert from the period, what was done about it, and how long it took. One well-documented example is worth more than a list of detection rules.

Change

How does a change reach production?

Show the path: where it is proposed, who approves it, how it is deployed, and what record it leaves. If infrastructure is defined as code, the pull request history is usually the strongest evidence available, and it is evidence you already have.

Can anyone change production directly?

If manual changes are possible, expect to be asked how you would know. Detecting drift between the declared configuration and the running one is the control here.

Third parties and shared responsibility

Which parts of this does the cloud provider own, and which do you?

Be able to state the boundary for the specific services you use. It differs between a virtual machine and a managed database, and a generic answer suggests the question has not been thought about.

What assurance do you hold from the provider and from any managed service partner?

Have the current reports on file rather than promising to obtain them. Check the dates; an expired report is a finding.

Recovery

When did you last restore something, and how long did it take?

Backup configuration is easy to show. A tested restore is what is actually being asked for. Have a dated record of a real restore, with the time taken, and compare it to your stated recovery objective.

Preparing without a scramble

Most of the work is gathering evidence continuously rather than producing it in the week before an audit. Three habits make the difference:

• Keep exports on a schedule. Privileged access lists, configuration compliance summaries and alert reports, exported monthly and filed. Point-in-time evidence collected after the fact is weaker and takes longer to assemble.
• Write down the exceptions as you grant them. Every deviation from the baseline, with a reason and a review date. An exception with a rationale is a managed risk. An exception discovered by the auditor is a finding.
• Do one internal pass first. Walk the list above yourself a month ahead. Everything you find is something you fix on your own timetable rather than under a deadline with a report already being drafted.