So, the auditors are saying “for control reasons, a prod admin shouldn’t also be a sb admin, so we can separate writing code from deploying code.” And I’m saying “but, a prod administrator can just write code, no sb access needed. Further, every sb refresh re-grants admin access to sb. Surely there’s a better way to achieve the controls goal here?” And the auditors are saying “do it our way because…reasons.” Has anyone had a positive experience designing a realistic control that ensures that only approved changes are released to prod, and can share any wisdom? From my perspective it seems like you have to put a certain amount of trust in your administrator. Thanks for any ideas! Bonus points if you’re facing down SOx.

In theory this could probably be solved via a CI/CD pipeline where all code changes are approved via merge requests and automatically deployed into production.

not really, his point is that a production admins can do whatever they want, despite whatever arbitrary rules you make up

You can either not give developers admin access to prod, or if the auditors are happy just audit file cabinet changes by hand

The auditors are (appropriately or otherwise) concerned with more than just script changes: workflow, new fields, permission changes on roles etc. I “like” (ie don’t like at all) @battk’s suggestion of removing admin, but at the end of the day you have to have at least one!

emphasis on dont use, not dont have

We used Strongpoint change management - but prior to that we had an excel sheet that we kept of all changes and that document was reviewed/ approved by someone other than the person doing the change. It was a PITA ... but for audit hygiene it worked. Need documentation of sandbox changes (i.e. script files, screen shots etc.)

Thanks @flynn - this may be the first environment I’ve worked in where Strongpoint truly makes sense.

I've faced SOX. I have admin rights in both environments. Who is the audit firm?

Yeah, this sounds like an idiot who's never actually done anything other than audit

Yeah I have seen a lot of customers and this is at the outer edge of caution, from what I’ve seen. It’s a big 4 firm. @KevinJ of Kansas’s analysis smells right (the green part not the idiot part) - but the underlying desire is sound: we want to make sure any changes that could affect the financial statements, or audit controls, etc, are reliably approved. Strongpoint may be a way forward.

Frankly the only way to control it the way they want us to have an outside consultant with admin and no one inside with it. At some level you must have an administrator. I could see wanting to make it so the administrator can't post anything, but good luck preventing it.

This is great. Can’t wait to reference it and say “I don’t know this turtle but this is what people in the community think”

We have 2 big 4 firms in our SOX compliance. One to tell us the controls we need and the other to test them. Neither is concerned about this

StrongPoint’s ITGC will help with documenting and tracking changes in your environment. You can define a default policy for objects to either just log changes only or to require change requests.

Is MOST cases, your SB developers should not have Admin access to Prod. In fact VERY few people should have admin access to prod and they should not be your developers. In a smaller org it may not be possible to separate them I know, the answer I think is SDF, pushing update from SB into Production give you an audit trail of who changed what and when. This approach passed a SOX audit at a bank I used to work for.