Skip to content

Change Rollback And Release Management Procedure

Change rollback and release management procedure

Version history

Version Number Date Description Created By Approved By
0.1 23/Apr/2024 Initial Copy [Name]
0.2 18/Jun/2024 Approved [Name] [Name]
0.3 28/Aug/2026 Knowledge kernel, AI/agents, control alignment Knowledge steward [Name]

Purpose

The purpose of this Policy is to control the planned and unplanned changes within the environment and infrastructure of tecciance, including the cloud.

Scope

This policy applies to the entire operations of the tecciance. The following types of changes are covered under this policy:

  • Changes to IT Infrastructure

  • Changes to Networks

  • Changes to Development, Testing, and Production environments

  • Changes in Codes or Platforms

  • Changes to Physical infrastructure and facilities

Terms and definitions

Following is an explanation of various terms used within this document:

  • Change: To make the form, nature, content, future course, etc., of something different from what it is or from what it would be if left alone.

  • Standard Change: Pre-authorized, low-risk changes that follow a well-known procedure.

  • Minor Change: Any change which is non-standard and minor in nature and is relevant or impacting a single user or single system may be termed as a Minor change.

  • Major Change: Any change which is non-standard and major in nature and is relevant or impacting more than one user or systems or applications or platform shall be termed as a Major change.

  • Emergency Change: Any change, whether Minor or Major in nature, when needs to be executed on priority or urgency, can be classified as an Emergency Change. These are changes that must be implemented immediately to restore or continue services.

  • CR: Change Request – Request for making the change.

  • CAB: Change Advisory Board – Provides advice and in-principal approval to Non-Standard Major and Minor Changes. Also, decide if any Non-Standard Change shall be qualified as a Standard Change in the future.

  • E-CAB: Emergency Change Advisory Board – Provides advice and in-principal approval to Emergency Changes.

  • Change Requestor: Person(s) initiating the Change Request.

  • Change Reviewer: Person(s) involved in reviewing the Change, its type and assigning / forwarding to relevant Advisory and Approval Member / Team.

  • Change Approver: Person(s) in charge of making the Change who approves / rejects / postpones the change.

  • Change Implementer: Person(s) responsible for executing the change as per process / steps defined or involved.

Responsibilities

The primary ownership of implementing this Policy is with ISMS & Department Head (Please mention in case any other department is responsible). The IST shall implement this Procedure under the guidance of the Leadership Team and in coordination with Department Heads.

Policy

Type of Changes

  • Changes at tecciance shall be classified into the following 02 main types:

  • Standard Change

  • Non-Standard Change

  • Standard Change – Standard changes, sometimes called Routine changes, tend to be pre- authorized changes that are considered to have little to no risk associated with them. Standard Changes are also defined as pre-authorized changes that are minimal risk, common, and follow a procedure or work instruction.

  • Standard changes shall not require CAB or E-CAB review, advice, or in-principal approval.

  • Non-Standard Changes shall be further classified into:

  • Non-Standard Minor Change

  • Non-Standard Major Change

  • Emergency Change (Minor or Major)

  • Non-Standard Minor Change: Any change which is non-standard but minor in nature and is relevant or impacting Single User or Device or Process or Customer or Information System shall be termed as Non-Standard Minor Change. Such changes would be identified based on the impacts caused by the change in terms of downtime or financial impacts, or customer affected, or processes affected, or information systems affected by the change. Such changes shall go through the CAB process before approval.

  • Non-Standard Major Change: Any change which is non-standard but major in nature and is relevant or impacting multiple Users or Systems or Processes or Customers or Information Systems or Applications, etc., shall be termed as Non-Standard Major Change.

  • All changes to Core Infrastructure, Applications, Networking Devices, etc., shall be part of such a change. All Development, Production, as well as Cloud Environment-related changes, shall be part of such change. Such changes shall go through the CAB process before approval.

  • Emergency Change: Any Non-Standard Change, whether Major or Minor in nature, when needs to be executed on priority or urgency, shall be classified as an Emergency Change.

  • Emergency change is executed when the time required for change implementation is crucial and the change cannot be delayed for the formal approval process or methods. Such Changes shall go through the E-CAB process before approval. The responsibility of identifying the appropriate type of classification of change resides either with the Change Requestor or Change Reviewer.

  • Change Advisory Board (CAB) shall comprise:

  • Chairperson (Leadership Team Member)

  • Secretary (Leadership Team Member)

  • IT Team Representative

  • Development and QA Team Representative

  • Human Resource Team Representative

  • Admin Team Representative

  • Information Security Team Representative

  • Any other relevant Team Representation

  • Emergency Change Advisory Board (E-CAB) shall comprise:

  • CEO

  • Information Security Representative / IT Team Representative

Initiating Change

Any type of Changes can be proposed or initiated by any User or Department through Change Request (CR). Change Requests (CR) shall be raised using the prescribed Change Request Form (CRF) or through emails. Change Requests shall contain minimum information about:

  • Nature of Change

  • Need or reason for Change.

  • Type of Change (Standard / Non-Standard Major / Non-Standard Minor / Emergency)

  • Impacts caused by the change include downtimes, financial impacts, etc.

  • Affected Departments, Customers, Information Systems, Applications, etc., by the proposed change.

  • Date and Time (Proposed) for Change (if applicable)

  • Process / Procedure for implementing change.

  • Responsibility of change implementation and testing

  • Rollback plans in case of change failure.

  • Testing methods and success criteria (post-implementation)

The Change Request shall be sent to the Change Reviewer (assigned person / email address) for review and confirming the classification. The Change Reviewer shall review the change request, whether all required information is available within CRF and check and confirm the Classification / Type of Change.

Based on the Change Type, the Change Reviewer shall forward it to either of the below stakeholders:

  • For Standard Changes: Change Approver

  • For Non-Standard Minor Changes: Change Advisory Board (CAB)

  • For Non-Standard Emergency Changes: Emergency Change Advisory Board (E-CAB)

Standard Changes Process

  • Standard Changes shall be pre-approved changes that are of repetitive or routine type which are not required to be going through CAB or E-CAB process every time.

  • The Standard Changes Register shall be maintained for listing all pre-approved Standard Changes, which shall be referred by Change Reviewer as well as Change Approver. Standard Changes, once approved by Change.

  • Approver or Change Manager shall be assigned to implementer for executing the change.

  • Change once completed shall be informed to Change Requestor / Initiator.

Minor and Major Change Process

  • Minor or Major Changes shall go through the Change Approval Board review process. Minor or Major Changes shall be reviewed by CAB during their scheduled meetings.

  • CAB shall provide their primary approval or recommendations based on the impacts and other factors detailed within CR.

  • CAB shall reject or send back the CRs where the impacts are not acceptable or the need for the change is not found appropriate.

  • CAB reviewed and approved Changes shall be sent to the Change Manager for final approval.

  • The Change Manager may approve, reject, or postpone the Changes.

  • The Change Manager's decision shall be conveyed to the Change Requestor / Initiator and CAB.

  • Approved Changes shall be assigned to the Implementer for execution.

  • The Change Implementer, after implementing the change, shall inform the Change Approver / Manager as well as the Change Requester.

  • Changes once implemented shall be analyzed for any adverse impacts, effectiveness, or risks by the Change Manager / Approver. Records of Changes shall be maintained in the Change Register.

Emergency Change Process

  • Emergency Changes shall be initiated only when the Major or Minor Change needs to be implemented without any delay and cannot wait for the CAB approval process.

  • Emergency Changes shall be reviewed by E-CAB on a priority basis considering the urgency nature.

  • Approvals from E-CAB can be provided over email or any possible medium.

  • E-CAB may also reject the CR or can change it from Emergency Change to Non-Standard Major or Minor Change Request, which will then go through the CAB process.

  • E-CAB approved CR shall be sent to the Change Manager / Approver for final approval.

  • The Change Manager may approve or reject the Change.

  • Rejected Changes shall be informed to the Change Requestor, and Approved Changes shall be assigned to the Change Implementer.

  • The Change Implementer, after implementing the change, shall inform the Change Manager and E-CAB.

  • Emergency Changes shall be reviewed for effectiveness as well as for any impacts or risks by the Change Manager, post-implementation. Records of Emergency Changes shall be maintained within the Change Register.

Enforcement

  • Template – Change Request Form

  • Change Approval Records

  • Template – Change Register

Artificial intelligence, software agents, and organizational knowledge

This section is added in version 0.3 so the policy applies equally to employees and to software agents, and so reusable knowledge stays provenanced.

Software agents, bots, service accounts, CI jobs, and coding assistants are identities. They are in scope of this policy wherever people are.

Every retrieve or use of organizational knowledge or classified data requires a verified identity, a stated purpose, and a classification ceiling. Missing purpose is deny.

AI may extract, draft, rank, or propose. AI shall not approve access, classify or reclassify information, set reuse rights, waive a control, merge to a protected branch, or treat search ranking as truth.

Approved reusable knowledge is a governed claim with source, owner, lifecycle, applicability, and limitations. Raw chat, tickets, and scanner output are not approved knowledge.

Embeddings, summaries, caches, and compiled agent skills are derivatives. Withdrawal, reclassification, or destruction of a source shall propagate to derivatives.

Secrets, credentials, production data dumps, and Restricted (including client/PHI) material shall not be pasted into public generative-AI services or stored in vector indexes unless an authorized path and agreement exist.

HIPAA-regulated PHI is out of default scope. Enable the HIPAA pack and a business-associate path before any PHI is processed by agents or knowledge indexes.

Change to a must procedure (including knowledge used by agents) is a change under the Change / Release procedure and SOC 2 CC8.1. Agents cannot approve that change.

Changes to approved must procedures, hardening baselines, and agent tool allowlists are changes to procedures under this document and SOC 2 CC8.1.

CI evidence (review, tests, scans, deploy log) is the primary evidence of change control for software. Wiki or email-only approval is insufficient for production software change.

Agents may open a change request. A human with delegated authority must approve.