A.12.1.2 Resolver Hosted Platform Change Control Policy

1. Purpose, scope, and users

The purpose of this document is to define how changes to information systems are controlled within the Resolver Hosted Platform.

This policy covers the requirements needed to document, communicate, and control changes to Resolver Hosted Platform applications, systems, and devices. This will help ensure that changes occur reliably, with proper authorization and with notification.

The scope of this policy applies to all Resolver Employees involved in Resolver’s Hosted Platform customer-facing production applications, including the software and infrastructure.

2. Reference documents

  • ISO/IEC 27001:2013 standard, controls A.12.1.2, A.14.2.4
  • EU GDPR Article 32
  • Information Security Policy

3. Policy

Resolver Hosted Platform Change Control Process governs the implementation of modifications to the Resolver Hosted Platform. The procedure will emphasize appropriate documentation and authorization of the change.

There are three types of production changes:

  • Normal changes
  • Urgent changes
  • Work items

4. Normal changes

The R&D ticketing system, Jira, will house all information relating to changes, incorporating information such as priority, target date, and authorization information.

All Normal Changes will occur in the following stages.

The change will be scripted, performed, and tested on a non-production environment

  1. A DevOps “Change” ticket is created in Jira detailing the change.
  2. The ticket is assigned to a DevOps Engineer.
  3. The DevOps Engineer creates a git branch for the change, named after the JIRA ticket.
  4. The DevOps Engineer scripts the change locally.
  5. The DevOps Engineer tests the change in a Pre-Production environment.
  6. The DevOps Engineer commits changes to the branch and pushes to Source Control.
  7. The DevOps Engineer documents all the steps required for the change in the Jira ticket and links their Source Control commit to the Jira ticket.
  8. The DevOps Engineer creates a Roll Back Plan to reverse the change in the event deployment problems are encountered.
  9. The DevOps Engineer marks the Change ticket “Ready for Peer Review” and creates a pull request in the source code repository, Source Control.
  10. The source code is reviewed by a peer before merging to master.
  11. The ticket is marked “Ready for Committee Approval”.
  12. The Change Control Committee (including CISO, CTO, Director of DevOps) reviews all “Ready for Approval” tickets and sets status to “Approved for Production”.
  13. The DevOps Manager coordinates with the VP of Customer Success to apply the production changes, typically during the monthly maintenance window.
  14. The change is applied to production by checking the code out of Source Control and executing it in Production by a DevOps Engineer.
  15. The DevOps Engineer updates the Jira ticket to “Deployed to Production” with any applicable notes about the deployment.

Candidates for Normal Change are changes for which:

  • There is a defined trigger to initiate the Request for Change.
  • The tasks within the Change are well understood and documented.
  • Authority can effectively be given in advance.
  • The risk surrounding the change is well understood.

Many changes may be grouped into one Release if they can be designed, tested, and released together.  The QA team tests in the QA environment as well as a Staging environment at which time any defects must be noted and resolved, accepted, or the cause of the defect pulled.

5. Urgent changes

An Urgent Change is initiated by the Director of DevOps, Director of Customer Service, the VP Product, the CTO, or the CISO to make a required time-sensitive change to production systems.

An Urgent Change will occur in the following stages:

  1. An “Urgent Change” ticket is created in Jira detailing the change.
  2. The ticket is assigned to a DevOps Engineer.
  3. The DevOps Engineer scripts or manually perform the change in a non-production environment.
  4. Appropriate resource tests the change.
  5. The ticket is marked “Ready for Production”.
  6. The CTO or CISO review and approve the ticket.
    1. If neither is available, the Director of DevOps has the authority to circumvent this step to address a critical issue.
  7. The Director of DevOps coordinates with the VP of Customer Success to apply the change and notify customers.
    1. If the VP of Customer Success is not available, the Director of DevOps has the authority to circumvent this step to address a critical issue.
  8. A DevOps Engineer applies the change in Production.
  9. The DevOps Engineer updates the Jira ticket to “Ready for Post-Implementation Review”.
  10. The DevOps Engineer adds any relevant documentation to the ticket, filling in details that may not have been previously provided due to time constraints.

6. Work items

Work Items are routine, standardized activities performed in any environment that has previously established and tested scripting to perform and do not require in a material configuration changes (for example, setting up a new site or copying a database).

The list of work items will be maintained in the Resolver Confluence and will be maintained by the change control committee on a quarterly basis.

A Work Item will occur in the following stages:

  1. A “Work Item” ticket is created in Jira.
  2. The ticket is assigned to a DevOps Engineer.
  3. The DevOps Engineer carries out the work.
  4. The ticket is updated as “Complete”.

7. Post-change

A Post-Implementation Review shall be conducted on all Urgent Changes by the Change Control Committee on a weekly basis. Lessons learned shall be fed back into future Changes and/or other operations processes may be required to be modified.

8. Change control committee meeting agenda

  • Review changes that are marked as Completed from the previous week.
  • Flag recurring changes as recurring work items (if any). If appropriate, add those types of tasks to the list of work item-type tasks.
  • Review work items marked as Completed from the previous week.
  • Ensure all items comply with the current definition of work items.
  • Discuss and Review urgent changes marked as Completed from the previous week.
  • Discuss, Review, and Approve proposed changes for the upcoming week.

9. Validity and document management

This document is valid as of July 2020.

The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.

When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:

  • The number of incidents arising from the unclear definition of the ISMS scope.
  • The number of corrective actions taken due to an inadequately defined ISMS scope.

EFFECTIVE ON: September 2020

REVIEW CYCLE: Annual at least and as needed

REVIEW, APPROVAL & CHANGE HISTORY: Last time reviewed and approved in August 2020 by Resolver’s Information Technology Security team.