This change management policy intends to ensure changes made to application code and relevant systems are subject to necessary and appropriate controls. Its purpose is threefold:

Attempt to mitigate unexpected side effects, the introduction of defects, and other negative effects of changes through due review;
Increase awareness of changes across relevant teams; and
Provide a record of changes made to systems and repositories in its scope, where possible.

Scope

This policy covers:

Application code changes for Breezy ATS and all sub-services therein. Specifically, changes made to any project within the Breezy HR GitHub repository.
Changes made to the “Infrastructure as Code” definitions used for Amazon Web Services. Specifically, changes made to the GitHub repository “breezy-terraform,” and the AWS CodeCommit repositories “breezy-infrastructure“ and “eu-breezy-infrastructure“. These repositories control system-level infrastructure resources in Amazon Web Services (AWS).
Changes made to underlying information assets used to facilitate product offerings from Breezy Software. This includes any changes made to supporting services like Amazon Web Services, Pingdom, Solar Winds, or any other service listed on the third-party vendor registry relevant to these product offerings.
Changes made to any business process affecting Information Security.
Changes made to any documents affecting Information Security.
Changes made to the Breezy organization that affect Information Security.

Responsibilities

The following roles are defined:

Administrator: A Breezy HR employee who has been given administrative authority to a relevant system. See the third-party vendor registry for a list of administrators for each system.
Engineer: A Breezy HR employee whose primary job function is to make changes to relevant systems.
Team Members: Architects and Engineers who are a member of a particular team at Breezy, like the infrastructure team (informally “Breezy Infrastructure”).

Implementation

Application Code Changes

GitHub repositories containing application code, as defined in Scope Item 1, must use GitHub’s “Branch Protection” feature to mark the repository’s base branch, and any other branches to be released for end-user consumption, as protected. These protected branches prevent direct, unreviewed modification by engineers.

As a result, any changes to protected branches must first be submitted for review through GitHub’s “Pull Request” system. Each pull request must be approved by another engineer before it can be merged into a protected branch.

When reviewing code, engineers should consider:

the scope and impact of the change and whether the scope/impact is clearly and correctly communicated.
any unexpected or unintended side effects of the change.
any security implications of the change, following the guidelines set in the Secure Engineering Principles.

In emergency situations, on a case-by-case basis, a repository administrator may elect to bypass the usual pull request review process. Such cases shall be reported to the Information Security Manager for further review.

Infrastructure as Code Changes

GitHub and CodeCommit repositories containing “Infrastructure as Code”, as defined in Scope Item 2, must similarly have one or more protected branches preventing users from directly making changes.

Changes to these repositories must also be submitted for review through the repository “Pull Request” system. These changes must be reviewed by at least one other Team Member before being merged into a protected branch.

However, to promote expediency of changes, a Cloud Architect may short-circuit the review process and deploy changes in an unprotected, submitted-for-review branch.

Infrastructure as Code changes may be deployed using the unprotected, submitted-for-review branch if one of the following conditions is met:

The environment is an environment for internal use at Breezy;
or the environment is intended for eventual customer use, but access to the environment has not yet been given to a customer (i.e., it is still being prepared);
or the change is authored by a Cloud Architect.

Otherwise, the change must be submitted for review, approved by another Cloud Architect, then merged into the relevant protected branch for deployment.

For clarity, this situation requires review before deployment, as per the above rules:

Any changes to an active customer environment

Any changes short-circuiting review before deployment must eventually be reviewed and merged into the relevant protected branch of the repository. This review, though often cursory for changes, still meets the objectives of promoting change awareness and providing a record of change.

Changes to Breezy ATS environment configurations for production systems should typically be driven by a specific customer (internal or external) or a customer support request.

Other System Changes

Application and infrastructure code, i.e. Scope Items 1 and 2, cover the majority of changes relevant to the proper operation of Breezy systems.

Scope Item 3 is broad. It is intended to cover both manual changes to systems normally controlled by “Infrastructure as Code” definitions, like Amazon Web Services (AWS) changes, as well as changes to supporting systems like third-party status pages, monitoring systems, etc.

Generally speaking, Breezy strives to define infrastructure and applications in code whenever reasonable, using the longevity and severity of systems and changes as guides. However, for some systems, particularly third-party systems, it’s simply the most realistic to manually set up or change them.

In these cases, intended to be covered by Scope Item 3, we use the following guidelines when making changes:

If there is a reasonable chance a change may directly affect customer or production systems or data, the change should be supervised by at least one other employee of Breezy HR. This supervising employee should have the knowledge and context necessary to understand and evaluate the change in question, or the employee should refuse to sign off on the change without first acquiring the knowledge and context. This supervision might take the form of watching over someone’s shoulder, viewing a screen-share on a remote call, describing the change through instant messaging, or even approving a pull request prior to the change’s deployment, as the situation warrants.

When in doubt, employees should err toward having another person sign off on their changes.