How_to_Manage_Change_Management_On_Sprinto
What is Change Management?
Change management is about documenting changes that affect the organization's critical aspects, such as offered services or products, internal structures, processes, operations, etc.
Implementing change management is a data governance step and crucial to track all minor and significant changes in the functional areas.
Organizations mainly manage the changes within the organization by the following means:
Ticketing System: A ticketing system logs an incident ticket whenever a product or organizational structure-related change is required. Every incident ticket gets assigned to a stakeholder to review the ticket information, update the ticket status, and get the correct point of contact involved. The incident ticket plays a crucial role in ticketing system-based change management. It keeps track of the involved stakeholders and stages the changes seen before the deployment or implementation.
Code Repositories: Code repositories are the cloud-based storage and hosting platform for codes. Most modern code repositories are based on the Version Control System (VCS). VCS helps to compare the previously stored copy of code to the latest copy of code and highlight the changes made. Later, these changes are reviewed and tested for functionality before the merge on the main branch of the repo. This functionality helps organizations to ensure all the code changes pushed to repositories directly contributing to the product/service are reviewed and validated.
Why Change Management Is Important?
Change management is a data governance step; hence, most data security compliance frameworks post the requirement to implement a robust change management system to the organization's core. The main idea behind a robust change management implementation is to ensure all the changes made to the crucial functional areas of the organization are thoroughly analyzed, reviewed, and implemented.
Below mentioned are a few of the essential aspects of a change management system:
The peer reviews and verifies all changes to the product/service or organization structure.
Code changes get validated for any possible errors or vulnerabilities.
Assignees associated with the change tickets always ensure and track the change's progress, ensuring a shorter turnaround time.
An authorized person gets notified each time any of the assigned developers creates a pull request to the classified repositories.
How Sprinto Manages Change Management System?
You can kick-start your change management journey under the dedicated Change mgmt section on the Sprinto app. Sprinto has features like native integration with the most widely used ticketing systems and code repositories. All the changes pushed to the respective system get tracked and reflected on the Sprinto platform to meet the compliance framework-related requirements.
Following are change management options Sprinto offers:
Note: It is not mandatory to integrate the ticketing system and code repositories simultaneously. You can integrate either or both change management services per your use case.
Ticketing System: Ticketing system is a service that logs tickets for any incident within an organization; in terms of change management, any change to the product, service, org structure, operations, etc., can log a ticket on the ticketing system.
Following are the ticketing systems, Sprinto integrates with:
Ticketing System (Available Integration)
JIRA
Trello
Linear
Asana
ClickUp
Azure DevOps
GitHub Issues
Shortcut
Integrate your Sprinto account with the ticketing service you use.
Note: You might encounter integrated ticketing system status in “Currently syncing projects”. The project syncing process takes time depending on the database size from the ticketing system. Once syncing is completed you can find the number of available projects.
On successful integration, select the project for which the change-related tickets must track.
Note: By default, none of the projects is tracked from the integrated ticketing system. You must select the project that requires ticket tracking.
Once the project is selected, configure the project details:
Note: The ticket database refreshes automatically every 24 hrs for updates from the ticketing system.
Purpose of the tickets logged to the projects.
Ticket closing status.
Ticket Sync date. The date on which onward logged tickets needs to fetch on Sprinto.
Once the project is defined and configured from the ticketing system, you can review the tickets details, assignee, status, creation date, and last update from the Sprinto app.
Code Repositories: Code repositories are the services that help you to store and host your product/service code. All the code repositories offer a version control system that allows you to highlight the code change from the last saved copy.
Following are the code repositories, Sprinto integrates with:
Code Repositories (Available Integration)
Gitlab
Bitbucket
Azure DevOps
AWS Code Commit
Connect and integrate your code repositories on Sprinto.
Note: Various code repositories behave differently upon integration. Refer to the respective integration guide and configuration guide to learn more.
Classify the code repositories as production or non-production. Only the production-marked code repos are tracked for changes to meet the compliance requirement.
Note: As part of the requirement for compliance framework, repositories that store or host code that directly helps the product or service to work need to be reviewed for every change made to them. They also need to be classified as "Production".
Review the following code repos configurations on the repositories platform:
Classify all the tracked code repos marked as "Production" or "Non-Production" on the Sprinto app.
Enable branch protection rule from the repository platform.
Enforced peer review for code changes on the "Production" marked repositories.
On successful integration and configuration of code repositories on Sprinto, you can track the following details:
Track the repos for any changed code pushed to them for validation and peer review.
Managing Change Management With Workflow Checks: Users with code repositories or ticketing systems that do not integrate natively with Sprinto can configure the applicable workflow checks based on the desired compliance framework’s requirements. The workflow checks help the user run the required compliance activity on time to submit the process adherence evidence and meet the compliance goals. Refer to how to add workflow check and run workflow check to learn more.
Setting-up Change Management Systems:
Get started with change management by adding the code repositories and ticketing systems on Sprinto. Following are the setting up activities for the change management system:
Note: Refer to the respective user guides for each activity to learn more about how to set up these systems.
Setting up code repositories/ ticketing System.
Classify entity to be tracked for the integrated code repository or ticketing system.
Start or stop tracking any classified entity on code repository or ticketing system.
User Guides:
How to Set Up Code Repositories On Sprinto?
How to Classify Code Repositories?
How To Stop Tracking a Code Repo?
How to Set up a Ticketing System on Sprinto?
How to Classify Workspace/Project on Ticketing System?
How to Stop Tracking a Ticketing System?
Available Checks For Change Management
Sprinto comes built-in with a set of checks that helps the users get notified about a pending action, missing information, or adhering to a periodic process to meet the desired security compliance requirements.
Following are the two types of checks available in the check management on Sprinto:
Workflow Checks: Workflow checks cannot be passed automatically by checking the system configuration and needs a manual evidence submission to pass the check. The workflow checks typically associate with a process that needs to run periodically per compliance requirements.
The following is the list of workflow checks available on Sprinto:
Workflow Checks
Description
Required Action
Peer review of all planned application code changes
A peer reviewer must review all the planned application code changes. The peer reviewer must be different from the author (who made the code changes).
Run the workflow check and upload the evidence to pass the check. Typical evidence consists the “Peer Review number”, “Pull requests”, etc. If required, you can download the template copy to fill in the required details and submit as evidence.
List of code repositories
Maintain a list of code repositories marked as “Production”. These code repositories must be maintained, reviewed, and logged along with all the changes to the application coded.
Run the workflow check and upload the evidence to pass the check. Typical evidence consists “repo names”, “integration branch”, etc. If required, you can download the template copy to fill in the required details and submit as evidence.
Deployment notifications
Configured the notification to the relevant stakeholders whenever the deployment of the code changes happens.
Run the workflow check and upload the evidence to pass the check. You can take a screen capture showcasing the deployment notification configuration is set up.
System Status Checks: System status checks are the continuous system monitoring type of check. The check look for any configuration status or missing data in the system that required to be updated or in the desired state. The user must update the missing data or the desired setting to pass this check.
Following are the system-status checks applicable to code repos and ticketing systems respectively:
System Status Check
Description
Change management tickets should have an assignee
All the tickets logged trough the change management system should have an assignee. Assignee is a responsible stakeholder in tracking the status of the tickets and eventually getting the tickets closed.
Code repos should be classified
All the code repos from the code repositories should be classified in the following categories: * Production: Code repos storing or hosting the code contributing directly to the critical services/product/application. * Non-production: Code repos that do not contribute directly to the service/product/application.
Enforce admins for the branch protection rules
Assign an admin to the branch protection rule on the integrated code repositories systems on Sprinto.
Enforce a peer review for any code changes
Assign a peer reviewer for any code changes pushed to the repositories. The assigned peer reviewer should be different from the author.
Merging of code changes should require passing status checks
The code changes must be validated and passed for errors and vulnerabilities before the deployment.
Access requests tickets should have an assignee
All incident tickets logged to grant or revoke access from any organization's resource must have a valid assignee. A valid assignee could be any stakeholder in the organization that holds the admin credentials and is responsible for managing any particular resource's access.