I've been working with an organization that apparently won't give its developers reasonable access to dev cloud environments "because of SOC2." At least, that is the excuse they tell me.
Example: "I need access to EC2" isn't enough. I wind up with a role where I can launch instances, but not list them. I have to send several emails, have meetings, follow ups, sending links to AWS docs, etc. to get them to modify a custom IAM role. Then they still can't figure it out, so I am literally telling someone what to copy-and-paste into JSON to fix the issue. I completely understand more control in higher environments, but this crap adds up and costs weeks in lost productivity.
Yep! It took a month of back-and-forth to do what should have taken less than a day in an environment with less friction. I'm totally frustrated by the project at this point.
I think we're in quite a bit of agreement.. sometimes the SOC2 review exposes gaps and you need to find a way to close them -- where do you look for critical path on that?
Also, SOC2 audits are sometimes coupled with more strenuous ones, so in the umbrella of audit season, you may have to demonstrate things, or records of things.
Example: "I need access to EC2" isn't enough. I wind up with a role where I can launch instances, but not list them. I have to send several emails, have meetings, follow ups, sending links to AWS docs, etc. to get them to modify a custom IAM role. Then they still can't figure it out, so I am literally telling someone what to copy-and-paste into JSON to fix the issue. I completely understand more control in higher environments, but this crap adds up and costs weeks in lost productivity.