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/


Comments

Post a Comment

Popular posts from this blog

Employing value streams in Enterprise Service Management

Image
Introduction Enterprise Service Management (ESM) is the technical extension of pre-existing Information Technology Service Management (ITSM) to other areas of an enterprise (e.g. Corporate or Shared Services). Successful ESM balances efficiencies gained from employing standardised process management, tooling and reporting with the nuances of organisational capabilities such as Finance, HR, Facilities and so forth. ESM leverages the industry proven service management concepts from ITSM that have been available for more than 20 years. Further to this, ESM operations implement similar concepts as ITSM including a service desk for 1st level support, end to end process management, request/issue management software, self-service knowledge bases and more recently chatbots and AI. Value streams are born from Lean manufacturing and comprise of a series of steps an organisation undertakes to create and deliver value to customers, typically in the forms of products and services. In the IT co
Read more

Using the Lean Canvas for an IT solution proof of concept

Image
I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources.  The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP. To start, we confirmed the following principles to guide the PoC: Do not develop
Read more

Improving your IT service delivery and operations with ChatOps

Image
Introduction IT organisations are under pressure to reduce idea-to-product cycle times while improving the service availability of the diverse range of systems and technologies under their charge. In response, IT leaders are seeking to leverage technologies and delivery models such as cloud, infrastructure as code, Continuous Delivery (CD), Big Data and IT Process Automation.  This intersection of contemporary concepts is deriving new IT delivery patterns which are impacting on traditional IT service management (ITSM). From my recent experiences working with Australian enterprise-sized IT organisations, it is my view that ITSM & Operations teams are not keeping pace with their peers in application development to meet current business demands. ITSM and Operations cannot remain effective and efficient if the teams continue to work in disjointed practices that are underpinned by manually executed processes and activities. To remedy this situation, ITSM & Operations teams need
Read more