A service manager, a risk manager and an auditor walk into a bar......Devops and Separation of Duties

Recently colleagues and I were discussing topics such as ITIL Change Management, Continuous Delivery, Devops and Separation of Duties. Stone (2009) stated "the general premise of separation of duties is to prevent one person from having both access to assets and responsibility for maintaining the accountability of those assets." In IT Change Management, the premise is to prevent a developer from deploying untested code into production or modifying it once in production without testing. 

As an ITSM team, we had established clear guidance on separation of duties for production changes with our manual release processes which satisfied all stakeholders including external auditors. The question from development teams then arose of how will we continue to satisfy the needs of separation of duties with Continuous Delivery and/or Devops? 





To establish consistent guidance, my team met with counterparts in Risk Management and Internal Audit (and we didn't really walk into a bar, sadly). From this collaboration, Internal Audit agreed that the question of why we have separation of duties is a matter for the Risk Office and that (IT) Change Management is a mechanism for assisting compliance. The general feeling is that where there is a like-for-like transition of processes from manual to automatic, then there is essentially no change to the separation of duties safeguards.  They still exist, just in a different form.  This may be an over-simplification, as during the transition from manual to automated deployments, there may very well be some process drift, resulting in automation not mirroring like-for-like against the original manual process.  In these cases, there is still a comfort level as long as the following conditions are met:

1. Developers do not have access to make unauthorised and unrecorded manual changes directly into production.  Automated deployments that follow a rigid pre-set and agreed upon path that includes testing and logging are suffice.

2. During a release lifecycle, there is a defined point where there is a code commit and authorised sign-off.  Committed code cannot be modified beyond this point.

3. There shall be sufficient record keeping, artefacts, checks and logging to support the auditability of the system. 

If you have comments or experience that would compliment this post, please feel free to add a comment below. 


References:
Stone, N. (2009). Simplifying Separation of Duties. Retrieved 26 April 2014 from                      http://www.theiia.org/intAuditor/itaudit/2009-articles/simplifying-segregation-of-duties/


Popular posts from this blog

Improving your IT service delivery and operations with ChatOps

Delivering Problem Management with Kanban

IT process automation and its impacts on IT service management