The software development cycle is all about making sure changes to your system(s) are high quality, appropriate, and protect the system integrity and security.

The development lifecycle covered in this post assumes the priorities in the backlog have already been set. See our post on the Product Backlog. There are other change types beyond software coding changes, like the infrastructure configuration changes for example. The core principles for all changes are the same, although they will take different forms accordingly. This post focusing on software development that tends to have the most comprehensive process steps and requirements.

In the earlier stages of your business, there’s less need for formality in your software development. The team size is smaller, generally more senior and experienced developers, and the use of your system is lesser in terms of the data stored on it and the dependence of others using it. Accordingly the risk; both likelihood and impact of bugs, vulnerabilities, and inappropriate changes, is lower. But as the team size expands, you add more junior developers, and your system is used by more customers and particularly enterprise business users, the likelihood and impact of those risks quickly increases. It becomes expected, important, and perhaps even a necessity to survival, to have a clearly defined software development process.

Let’s look at the core process elements. These are roughly in order of the stage that you would implement them as your business grows.

Segregated change environments

You should always start with at least three environments for your software development processes; development, test and production. They each do what their title suggests. It’s important to ensure the test environment closely reflects production so that testing is close to what you expect when it goes live into production. These environments provide the structure for promoting your code changes into the live environment as they pass the relevant checks along the way.

Version control: source code repository

The source code repository provides the central place for developing software, tracking versions, dev team collaboration and reviews, and being able to roll back to past software versions if unexpected production issues occur. Modern software like Github, Bitbucket and Gitlab provide the code branching functionality and workflows to support some of the following process elements.

Testing of changes

As soon as you have live users of the system, it’s expected you will test changes before they go live. That’s to ensure they function as intended and don’t create unexpected issues with other system functions. This is a broad category that itself should evolve as your development function does. It includes peer code reviews, system or unit testing, regression testing, smoke testing, user acceptance testing.

Change ticketing system

The primary purpose of a change ticketing system, like JIRA, is to track change requests and potential software changes. This comes before the software development cycle and is covered further in our Product Backlog post. But it's important to note in this context as the ticketing system supports various other process elements that follow. This ticketing is often used to flesh out the definition of user stories, functionality design, acceptance criteria, impact analysis, as well as to manage responsibilities and workflows for approvals and testing.

Segregation of duties

Modern approaches to software development are sometimes designed without segregation of duties in the team roles (eg. DevOps practice). This can improve the software development process and drive better coordination between the roles traditionally done by developers and operations teams separately.

Segregation of duties in some form is still expected once you get to the size and stage of supporting enterprise business customers. The way this segregation is applied in a DevOps structure is by requiring at least one independent person involved in each change. Ie. Someone that didn’t develop the code change, to independently check and approve it. That should be systematically enforced to mitigate the risk of a rogue employee and ensuring that the defined change processes are followed.

An independent review and approval is easily enforced through the source code repository; where Github, Bitbucket, etc. Have a configuration setting for this. It can also be done at a change release level (ie. group of code changes) by limiting who can deploy to production and ensuring they perform the final review and approval of the underlying changes before implementation.

Approvals

These may be part of the segregation of duties described above. The purpose of approvals is ensuring that all the change requirements have been met. This includes the actual code changes and what was required for the change in the first place, but also all the required process steps covered in this post (and the Change Management Policy). The approval adds some accountability, and a formal checkpoint to ensure each activity is performed appropriately.

Change Management Policy

Like other policies, this sets out the roles, responsibilities and formal requirements of the functional area. That's largely addressing the sections of this post and who, how, when and what needs to be done for the change management process each time a new change is initiated. See our Policies post for an expanded description of what all policies should cover.

Non-functional requirements

Non-functional requirements often take a back seat role in the earlier stages as the priority is on functionality that solves your customer pain points and strategically positions your system as a valuable service to your customers. Non-functional requirements should start being considered for all major changes, perhaps all changes, to ensure any potential reliability and security implications are considered. That’s especially important where the functionality may lend itself to security vulnerabilities, significant processing power demands, and/or user considerations that need to be considered in customer contracts, user guides or other documented forms outside the system.

Acceptance criteria

Acceptance criteria is a way to formally define change requirements that are needed to “pass”, in order to be implemented to production. This is often focused on functional perspectives but should also consider non-functional as described above, when applicable.

Impact analysis

Impact analysis is probably done intuitively from the start but becomes important to do it formally. It’s about considering whether changes will impact existing functions and users of the system. If users have set up their users, data, or configured functions in a particular way and you change the settings, configurations or design, will that throw them out?

If so, that’s important to consider to minimise the impact. That should also be communicated; these comms are covered more broadly in our Customer Communications post.

These above areas make up the bulk of your change management controls. There are others related to the use of test data, managing the continuous integration and deployment pipeline, static code scanning tools, change advisory boards, and various others that may or may not be as relevant or significant in your business context.

The SOC 2 perspective

The change management process features in a single criteria area; with some overlap and connection to several others. Although it's only one criteria it's quite sweeping in its coverage and often results in 10-20 control activities for that one criteria!

Common Criteria 8.1: The entity authorises, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

AssuranceLab's Best Practices Series

AssuranceLab's best practices series, is about highlighting the "real operational benefits" that comes from effective control practices. At best, they support your company culture, provide structure and clarity, and enable scalable growth. At worst, they tick the box of what your customers expect, reduce the reactive "firefighting" and time-wasting, and help you demonstrate your compliance with leading standards like SOC 1, SOC 2 and ISO 27001.