Pre-Audit Your Cloud Before Your Auditor Does

Direct answer: We published read-only cloud audit scripts for AWS, Google Cloud and Azure as cloud-security-audit-scripts, Apache 2.0 licensed. They check the things an auditor asks about first: multi-factor enforcement, public storage, logging configuration, encryption at rest, key rotation, network exposure, backups and secrets handling. Every API call is read-only, so nothing in your environment changes. Output is markdown or JSON you can file as evidence.

What your auditor asks about your cloud

Cloud questions in a SOC 2 or ISO 27001 fieldwork session are more predictable than people expect. Across engagements the same items come up nearly every time.

Is multi-factor enforced on every account with console access, including the root or global administrator. Are there access keys older than the rotation period in your own policy. Is any storage bucket or blob container publicly readable. Is audit logging enabled in every region you operate in, not just the one you think you use. Is logging delivered somewhere the people being logged cannot delete it. Is data encrypted at rest, and who holds the keys. Are security groups or firewall rules open to the whole internet on administrative ports. Do backups exist, and has anyone restored one.

None of that is exotic. All of it is checkable before anyone asks. The gap is that checking it by hand across three providers is a day of clicking, so it happens once, right before the audit, and then drifts.

What the scripts check

The checks are grouped into the same categories as our free cloud security posture check: identity and access management, logging, encryption, network, backups, secrets management, overall posture and governance.

There is a full audit per provider and, on AWS, narrower scripts when you only want one area. An identity-only run is useful before an access review. A storage-only run is useful after someone has been experimenting with public buckets.

Each run produces a structured report rather than console noise, which matters because the output is meant to become an artifact. A markdown report with a date on it, filed against the control it evidences, is the thing an auditor accepts. A screenshot of a terminal is not.

Read-only, and why that is the point

Every call the scripts make is a read. Nothing is created, modified or deleted. The recommended credentials are the read-only, viewer or security audit roles your provider already ships.

This is deliberate and it is worth being explicit about, because the alternative is what makes security teams refuse to run a tool somebody found on GitHub. A script that offers to remediate findings needs write access to your production cloud, and granting that to unreviewed code is a worse risk than the misconfigurations it would fix.

Read the code before you run it. It is Python and it is short enough to read in a sitting. That is also deliberate.

Turning output into evidence

The mistake we see most often is running a posture tool, fixing the findings, and filing nothing. Six months later the auditor asks how you knew your configuration was sound, and the answer is a memory.

The pattern that works is boring. Run the full audit on a fixed cadence, monthly or quarterly depending on how fast your infrastructure changes. Keep the dated report. Where a finding is real, open a remediation item with an owner and a date, and keep the follow-up report showing it closed. Where a finding is a deliberate exception, write one sentence saying why and who accepted it, and keep that too.

That gives you three things an auditor wants and most companies cannot produce: evidence that the control was monitored, evidence that findings were acted on, and evidence that exceptions were conscious rather than accidental. The reports become the artifact trail for several controls at once, which is the whole argument for collecting evidence in a way that maps to more than one framework.

Our writeups on running cloud security and the cloud security requirements checklist go further into which findings actually matter to an auditor and which are noise.

What these scripts do not do

They are not a cloud security posture management platform. There is no continuous monitoring, no alerting, no historical trend, no ticket integration. They are a snapshot you run deliberately.

They do not test your application. A perfectly configured cloud account can host software with an authorization flaw, and no configuration check will find it. That is what penetration testing is for, and the two are not substitutes.

They do not interpret results for you. A public bucket may be a static marketing site, which is fine, or a data export directory, which is not. The script reports the fact. Deciding which one you are looking at is still a human job.

They do not cover every service. The checks concentrate on the areas that generate audit findings, which means the large surface of managed services each provider offers is only partly represented. If your architecture leans heavily on something unusual, expect to check it yourself.

Run them before you need them

The best time to run these is not the week before fieldwork. It is now, while there is time to fix what turns up, and then on a schedule so that the report you hand over describes a steady state rather than a scramble.

Clone from github.com/TrazTech-Inc/cloud-security-audit-scripts, install the dependencies, authenticate with the CLI you already use, and run the full audit for your provider. If you find something alarming and want a second opinion on whether it is genuinely alarming, send us the report.