Mixing Agile & DevOps Shops and SOC Reports
On the face of it, mixing Agile, Continuous Delivery or DevOps style firms with the process-and-control focus of Service Organization Control reports seems contradictory. No attempt is made to define these terms. We assume readers are familiar with them.
With a bit of innovation in process, flexibility in execution of development methods, and a good relationship with your Service Auditor, it may be possible to produce SOC 2 reports for these types of shops. Getting over the line would require process and technical innovation like:
- automated authorizations before promotion integrated in source management
- recorded team lead review of code
- automated testing, recording and alerting of results
- lock-out from client data
- write-once logs, particularly for superuser activity
- serious logging and real review of logging
- third-party alerts on code, access types and time-specific access and activities.
However, given only few years of SOC implementation (since 2011), and the upcoming change to the SOC Trust Services Principles (2014), ensuring an unqualified SOC 2 opinion is on the cutting edge.
Why Bother with Agile SOC 2?
There are a number of reasons an Agile firm may benefit from SOC reports:
- better management understanding of the organization
- assurance in the marketplace for prospective and current customers
- ability to compete on an even footing with market leaders who display SOC logos- whether large or small
- a basis for building service maturity with a marketing payoff
- preparation for the more demanding requirements of sharemarket listing or access to venture capital
- a headstart and cross-over on risk management issues.
|Issue||Where’s the Conflict?|
|Segregation of Duties||This is a hard line in many IT frameworks – SOC 2, ISO27001, SOX 404 and others. It is a particular issue in DevOps, but also in Agile Development. For IT auditors coming from an accounting framework, this is the hardest hurdle to jump.|
|– Access||Auditors tend to look for least privilege even though in practice this is hard to implement. Access to root or superuser is often more broad in shops looking for rapid fix or deploy. Some shops operate on the opt-out approach, giving broad access unless directed otherwise.|
|– Testing||Developers doing their own manual testing, particularly if undocumented, rubs the average auditor the wrong way. No second pair of eyes on testing results (manual or automated) challenges segregation.|
|– Authorization||Promoting code to production without explicit authorization from a responsible party – not just peer review – also challenges segregation.|
|– Dev & Ops||Developer access to Operations blows segregation away completely.|
|Change Management||SOC 2 has a separate criteria section on change management. It stresses the system development lifecycle, timely updates to all elements of systems, determined change and incident management processes, and testing and authorization.These are assessed against commitments and requirements.This suggests an Agile, lightweight process consistent with system policies may be sufficient.|
|Roles & Responsibilities||SOC 2 Criteria specifically require clear roles and responsibilities to build accountability. Agile/DevOps/Continuous Delivery methods are more flexible on roles and activities and rely more on transparency and team performance for accountability.|
|Risk-Control Management||Agile, DevOps and Continuous Delivery thinkers take different views of risk-control structures. See, for example, the view of Risk Management Theatre at continuousdelivery.com.The SOC building blocks of controls may be out-of-whack with the culture of the organization.|
|Documentation||Agile is by definition light on documentation. SOC 2 requires clear process, procedures and policies, as well as strong communication tools. The auditor evidence for these is usually documentation. The documentation needed may be more than currently produced.|