Commit d68320ef authored by Marcello Evangelista's avatar Marcello Evangelista

Introducing the change management definition and processes

parent 4506204e
# Purpose
This document set the current definition of what a Change is regarding our own and managed environments.
# Scope
This policy is applicable to all infrastructure environments under our Managed Services Platform.
# Policy
## What is a Change?
A change is an event that holds approval from the Change Board Advisors (CBA), it is evaluated and implemented striving for minimised operational and financial risks, adjusts the current status of configuration whilst adding value to a business, service and its customers.
## How to Request a Change?
Currently, OlinData provides two specific models to request a change:
### Request for Change (RFC)
A request for change is a proposal that can be submitted by an internal OlinData stakeholder or by an MSP customer via our service desk (Zendesk), utilising the request fulfilment process to alter the current configuration state.
### Formal Change Proposal (FCP)
A formal change proposal is a high-level description of a potential service introduction or significant change and it is justified through a business case and implementation schedule. These proposals are usually originated from business and management strategical decisions and may include scope addition or more impactful changes to the current state of service and/or resources deployed.
### Change Types
1. Critical Change
A critical change is one that must be assessed and implemented as soon as possible to solve a major incident. Critical changes are, by nature, more disruptive and may lead to failures such as outages, lost of continuity or process breakage, so they should be kept to a minimum.
Are recognised as Critical Changes:
* Active damage mitigation.
* Zero-day mitigation.
* Removal of infected and/or exploited resources.
* Removal of alien resources.
* Major change breakages.
* Promoted patching changes.
* Customers' application security updates.
1. Major Change
A major change may have significant impact to the current state of configuration either by introducing breaking changes or by leveraging greater financial implications. Therefore, this change must be submitted for approval and should only be considered by the Change Board if it contains a detailed proposal with its justification and impact forecast.
Since OlinData deals with multiple customers, it is requested that all major changes are also approved by the costumer should they be affected by the proposed modifications.
Major Changes include:
* Major customers' application package version rollouts
* Resource/infrastructure modifications on production environments
* High-risk performance patching
1. Minor Change
A minor change is one that offers low risk, comes from a pre-established procedure and occurs frequently without introducing breaking changes. Such changes also present a
Change Model that states a documented and repeatable plan for management and execution of said change.
Minor changes are also subject to pre-approval should the CBA decide. This decision happens on a case-by-case basis and should not be seen as the customary practice.
If a minor change introduces higher compromises it may be promoted to a Major Change.
Minor Changes include:
* Minor version updates that are not related to security or performance
* Deprecation updates around configuration languages that do not affect the running state
1. Patching
A patching change is one that introduces a set of software and dependency fixes that may include security vulnerabilities, operational bugs and performance and usability improvements.
In case of security patching, an assessment is needed to determine if the flaw was exploited. In a positive case of exploitation, the patching change will be promoted to a Critical Change.
If the patching change introduces breaking changes or higher risk of outages, it should also be presented along a regression plan and be promoted to a Major Change.
Patching changes are not subject to auto-approval and should be reviewed carefully by the CBA.
Patching Changes may include:
* Package vulnerabilities fixes on non-exploited flaws
* Low risk performance improvements
1. Operational
An operation change is one that happens frequently as part of the hired services that does not introduces any significant risk to the current state of configuration and availability.
Operational Changes may include:
* Resource rotation
* General backups
* IAM management
# Policy Compliance
1. Compliance Measurement
The Infosec team and the CBA will verify compliance to this policy through the service desk requests and deployment cycles.
1. Exceptions
Any exception to the policy must be approved by the Infosec team and the CBA in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment