Developing while maintaining SOX compliance in a Production environment

Help Orchestrator
, ,
1

Our company is new to RPA and have a couple of automations ready to go live to a new Production environment and we must retain SOX compliance in our automations and Change Management Process.

We have 1 Orchestrator licence with licence for 1 Attended Bot, 1 Unattended Bot, 1 Non-Prod Attended Bot, and 1 Concurrent Studio License.

We would like to understand best practices in other companies of continued development once we have automations deployed to production. Here are a couple of our questions specifically:

A. With SOD, we have a different person do migrations from the developer. He would have to be an Administrator on Orchestrator to move but not alter code. Would Administrator rights give him abilities to alter the way a bot performs in production other than starting/stoping?

B. If we have multiple developers but only one concurrent license of Studio and 1 non-prod bot, how can we shift between developers without changing the username associated with the non-prod bot for them to test their automations? The developers would remote control to the Development VM that has the Studio software which asks to acquire the license from Orchestrator upon entry.

C. What best practices are people doing to monitor bot activities? source control? segregation of duties? audit evidence? etc.

2

Hi,
I am a seasoned SOX consultant - and came to the forum because client just installed UIPATH connector to an App. So I am definitely not a UIPATH/Bot expert but I think I understand your questions - except note entirely for B. (And what you laid out helps me help my client so here goes)
A. I do SOD as you describe. And ask - is it very different from having segregation to implement a database or application change and be concerned that the person implementing has Admin rights to Prod. So is regression testing or some sort of validation possible after the change is made in Prod
B I am not familiar with Orchestrator - but if you want to explain this to me I might be able to offer a suggestion
C Access management to start (all new and changed access must be approved) plus Combining SOD with a review of an audit log of changes, will serve you well.
Again thanks - I now have a better idea of the risks and possible options.