Auditor wants the SecurityAudit policy for our AWS environment—how safe is this access?

The SecurityAudit policy does not include permissions to download storage objects, so they can't pull customer data. But API calls that read function configs or server user-data are allowed. If you left plaintext credentials in your code or VM startup scripts, the auditor can see them. Clean those up first.

Definitely require an External ID condition when setting up the role. Also, add a source IP restriction to the trust policy so the audit firm can only assume the role from their office or VPN IPs. After two weeks, you can just delete the role with one click.

Is the auditing firm running an automated scanning tool or having engineers dig around via the console? If they're plugging in automated cloud tools, did you get the third-party AWS account number and external ID policy in writing beforehand?

We set up a similar role for a compliance audit. The audit took 12 days. As soon as it was over, we deleted the IAM role and queried the auditor's session through the audit logs; they had made around 14,200 read-only API calls in total. There wasn't a single attempt to download data.

whatever you do don't create an iam user and hand out access keys... those keys end up forgotten somewhere... tbh just create a role set an external id, and delete the role once they're done.

Auditing firms want everything handed to them on a silver platter, but you don't have to grant a role directly on the production account. Most companies pull configuration reports and security outputs themselves using CLI tools and hand them over as files. Why open up your entire live account for inspection?

The NDA signed prior to the audit must explicitly commit to how configuration data will be handled, how many days before logs cached in auditing tools are destroyed, and that no data will be shared with third parties.

To sum up: SecurityAudit accesses configuration, not your data, so it's a standard request. Even so, grant access via a role with an External ID, IP restrictions, and a time limit; delete the role the day the audit ends and check the system logs.

You're right. When you try to change everything at once nothing settles.

Hope this helps.

Exactly, and not many people know this. Most incidents start with a leaked password not a vulnerability.

Same here.

There's a part I don't understand. The harder it is to reverse a decision, the slower you should make it.

Just leaving this note, it might be useful.

we need to take it step by step... tbh when making decisions write down the worst-case scenario too, not just the best.

of course it varies if your situation is different.

I agree with this. Processes without records never improve, because you don't know what to fix.

That's all, sorry if I went on too long.

My questions are cleared up, thanks. Don't hesitate to ask; those who don't ask always pay more.

correct. if you scold false alarms nobody will report again.

if I were you I'd go this route.

I've been down this road, let me tell you. People defend habits, not processes. Resistance comes from there.

im writing this so you dont make the same mistake. anyway your time to detect an issue directly determines its cost.

if I were you, I'd go this route.