The Change Control Policy and Environment set the structure for controlled and high-quality software development practices.

The Consumer Data Right gives Australian’s control of their data. That enables innovation in new products and services to those consumers. To participate as a data recipient, there are five governance requirements and 24 information security requirements. These are independently audited by a qualified firm like AssuranceLab, and included in an assurance report for accreditation.

The Change Control Policy and Environment supports two of the 24 information security requirements; CDR Data in Non-production Environments and Secure Coding.

The Change Control Policy outlines the required activities to ensure software changes are appropriate and mitigating the risk of bugs and security vulnerabilities. It should also define the use of data to ensure security and privacy objectives are maintained in non-production environments. The change control environment is the supporting infrastructure and setup to support the policy objectives; including the use of version control software, continuous integration / continuous deployment (CI/CD) tools, and separate development, test and production environments.

The shift to agile software development led some to argue that its principles conflicted with those of controlled software development. Thought leaders in site reliability engineering (SRE) and secure development practices set the stage for how a balance of objectives is the best way to manage software development. This includes balancing the priority of product functionalities, bug fixes, security and reliability objectives.

The following practices should be considered in the design of the Change Control Policy and supporting environment.

The software development lifecycle

Often conducted in sprints, the following practices should be considered for each production release:

• Define acceptance criteria and a test plan;
• Perform testing of the changes;
• Peer review and approval from an independent developer or management;
• Perform an impact assessment of the changes on existing functionality and users of the system;
• Run static code analysis tools, particularly for vulnerability assessment of the code;
• Approval for the release prior to deployment into production;
• Complete a Release Management Checklist to ensure all bases are covered, including often many more detailed tasks not included here; and
• Communicate the changes to users and internal teams.

Test data in non-production

The Change Control Policy should set out the approach to using test data. There are broadly three strategies that are each appropriate from a security perspective: 

1. Prevent the use of any production data in the test environment;
2. De-identify, mask or otherwise reduce the sensitivity of production data being used in the test environment; OR
3. Apply security to the test environment that is on par with the production environment.

In either case, the purpose of this is to recognise the importance of data security that extends beyond the production environment if the production data is being used elsewhere.

The development environment 

The development environment includes the tools and practices used to support the change control practices. Version control software and continuous integration / continuous deployment tools are ubiquitous for cloud services businesses. Those can be set up with automatically applied change control practices like systematically enforced peer reviews on the code, and running static code analysis and test cases in the build prior to release into production.

Emergency changes 

Emergency changes are sometimes treated as an exception to the standard change control process, where the risk of delaying a new change release is higher than the risk of bypassing the standard process. In these cases, there may be a defined approach to retrospectively test and approve changes, or a scaled-down version of the requirements.

The CDR Perspective

The Change Control Policy and Environment support two of the 24 information security requirements: 

• CDR Data in non-production environments: CDR data should not be stored in non-production environments unless all controls are equivalent to those in in the production environment. Where an accredited data recipient must use CDR data in non-production environments, such as test or development environments, the accredited data recipient must ensure that the data is masked to ensure the ongoing confidentiality of the data.
• Secure coding: Changes to the accredited data recipient’s systems (including its CDR data environment) are designed and developed consistent with industry accepted secure coding practices, and are appropriately tested prior to release into the production environment.

About AssuranceLab

AssuranceLab is a modern cybersecurity audit firm that provides assurance reports (ASAE 3150, SOC 1/2). We're experts in the latest software and cloud providers. We guide your team through the compliance practices in a way that fits your environment and culture. We work closely with clients through our agile and collaborative approach; saving time, costs, and headaches along the way.