Software development practices have evolved rapidly in recent years, with the rise of agile and continuous delivery methodologies. However, it is generally perceived that many compliance frameworks are still based on outdated methodologies, which can make it challenging for companies to reconcile the two.

As an engineering leader, I have consistently been a strong proponent of agile and continuous delivery practices. When done correctly, they allow for the rapid delivery of value to customers, increase quality and reduce change risk through small iterations and test automation, and increase the visibility and accountability of changes.

As a member of the founding team at TrustCloud, one of my goals was to make compliance approachable and easy for companies practicing agile and continuous delivery to leverage those best practices as part of their compliance program. I was convinced that these practices could form the basis for a robust compliance program that would allow companies to not only achieve compliance certification, but also implement controls that leveraged these practices to improve their security posture, protect customer data and privacy, and provide accountability through the software development lifecycle (SDLC).

We implemented agile workflows and continuous delivery early on at TrustCloud. My assumptions were put to the test when TrustCloud underwent its own SOC 2 audit and achieved SOC 2 Type II compliance. As we developed our compliance program, we attempted to write controls representing our processes that mapped to the SOC 2 standard. What we found was that for SOC 2, there was less of an emphasis on specific practices, and more of an emphasis on ensuring that risks are mitigated by specific controls, that those controls are documented, and that they are traceable and measurable.

When evaluating how to ensure that your development practices can apply to a compliance standard, the first step is to look at the text of the standard, and try to determine its intent.  For example, CC 8.1 of the SOC 2 deals with change management. Hearing about change management often evokes thoughts of a complex change control process with multiple approval steps and possibly a change advisory board. However, the standard says: "The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives." How could this be applied in an agile continuous delivery environment?

Let's break it down:

Authorization: The business authorizes software development to happen. This can be done through an SDLC process document, the creation of tickets, or the assigning of tickets to a sprint or WIP queue.

Design and Development: This refers to the actual development process.

Configuration: This requires some form of configuration management. In an agile continuous delivery environment, configuration as code is a good option. All configuration is tracked in the version control system and goes through the same CI/CD pipeline as a code change.

Documentation: All changes must be documented so that others can be made aware of them. In an agile continuous delivery environment, documentation happens at many stages: the creation of a ticket, the commit and pull request messages, a changelog entry (which can be automatically generated), and automated and manual notifications regarding changes to the software.

Testing: The standard doesn't specify the manner of testing, but a set of automated tests that run on every change prior to deployment is a good option. This is a core principle of continuous delivery, and having the automated testing results attached to each change automatically by the CI system provides auditability and certainty to the process.

Approval: This one always seems to cause some headaches, because in continuous delivery, gates are considered an antipattern. However, the SOC 2 standard does not specify the nature of the approval. In an agile continuous delivery environment, there can be two levels of approval:

• Human approval: A lightweight human approval is an option here. For example, one option would be to require that all changes go through an independent code review and formal approval by another engineer who did not write on the code.  This could take the form of a continuous review that is the result of pair programming, or utilize something like GitHub pull requests that can be used to implement and enforce this workflow in a repeatable and auditable manner.

• Automated approval: Automated PR checks, such as static code analysis, automated tests, and security checks, can function as an approval to the change. If a change does not pass all of these various checks, it cannot be deployed.

Combining the human element (code reviews) with a suite of automated "approvals" both results in lower risk changes and satisfies the compliance requirements.

The next step after analyzing the standard controls and determining how to apply agile and continuous delivery is to develop a set of controls for your company that outline your practices in accordance with the standard.  A control, at its core, is a statement that defines an action that mitigates a risk.  Controls are typically short and concise, specific, and measurable.  You need to be able to provide evidence to support your control, in order to prove that your control is being practiced. 

When defining your controls, it's worth looking at the standard and determining the specific risk that the standard is intended to mitigate against, and then write how your practices mitigate that risk.  As an example, let's take the idea of "approval" discussed above.  The reason that SOC2 requires an approval for changes is to mitigate several risks, such as: 

• The risk of changes from unauthorized individuals that could potentially cause damage or disruption to the production system.

• The risk of accidental changes being released, even by authorized personnel. 

• The risk of improperly tested changes introducing new bugs or vulnerabilities into production systems.
  

In making use of both code reviews and automated tests as a means of gating deployment to production, you could create controls around these practices:

• All application and infrastructure changes require a review and approval by a separate technical resource before being delivered to the production environment.

• The company performs continuous Quality Control as part of the overall development process. The process leverages a variety of automated testing practices and is documented internally.
  

Additionally, since a change to production is deployed by a CI tool, rather than a human, you could write these controls: 

• Deployments to production are carried out by a continuous Integration / continuous deployment tool in order to minimize human error and increase auditability of the changes.

• The ability to initiate a deployment of application changes to production environments is restricted to authorized personnel.
  

With these controls, we mitigate against unauthorized changes by not allowing humans to physically deploy to production and only allowing authorized personnel (in our case, the engineering team) to initiate a deployment.  Accidental changes are mitigated by requiring a second technical resource to conduct a code review and approve the change. Finally, improperly tested changes are prevented by utilizing a robust set of automated tests at various levels (unit/integration/e2e/security), along with the human code review. 

By thinking about practices in terms of the risk mitigation requirements of the compliance standard you are focusing on, you can have a robust set of controls that both mitigate risk while maintaining the velocity and quality benefits of agile and continuous delivery.  Reconciling software development practices with compliance frameworks is no longer a choice, it is a necessity. By thinking about modern software development practices in terms of the risk mitigation that compliance frameworks are designed to promote, companies can protect their customers and their data while maintaining the velocity and quality benefits of agile and continuous delivery. 

##

ABOUT THE AUTHOR

Michael Salinger, a seasoned engineering leader with over 20 years of experience, serves as VP of Engineering at TrustCloud. His passion lies in leveraging technology to solve complex problems and create impactful solutions. At TrustCloud, he leads the development of the company's unique AI-powered Trust Assurance Platform, empowering businesses with programmatic and predictive compliance, streamlining operations, mitigating risk, and unlocking new revenue opportunities.

Prior to joining TrustCloud, Michael's leadership at Kinvey played a key role in building a highly scalable platform powering mobile apps for enterprise companies. His proven track record of delivering customer-centric solutions and fostering diverse, high-performing teams is evident in his work at both Kinvey and TrustCloud. This dedication to excellence translates perfectly to his role at TrustCloud, where he continues to drive success and shape the future of trust assurance.

Beyond his professional pursuits, Michael's deep interest in technology extends to AI/ML, cloud, and mobile, recognizing their immense potential to disrupt and reshape business outcomes. While enthusiastic about the positive impact of these emerging technologies, he is equally concerned about the security implications of an increasingly distributed digital landscape. This concern fuels his interest in Zero Trust architecture, which he believes is an essential part of building a more secure, trustworthy future. His dedication drives his leadership, encouraging innovation and exploration to create impactful and secure solutions. Michael's expertise, strong commitment, and passion make him a valuable asset to TrustCloud and a key player in the future of trust assurance.