7.2 Change Management Policy

Purpose and Scope

This Change Management Policy defines how changes to applications and systems are planned and implemented. The goal of change management is to increase awareness and understanding of proposed changes across Sord and ensure that all changes are made in a thoughtful way that minimize negative impact to services and customers.

From time to time, Sord may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to Sord including applicable laws and regulations.

This policy applies to all Sord assets and personnel acting on behalf of Sord or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all Sord policies and plans.

Change Management

All change requests must be documented end-to-end via the Sord change management and ticketing tools.

Change management should be conducted according to the following procedure:

(1) Product Roadmap

The Sord product management team evaluates which change requests and features will be implemented based on their alignment with the business plan and the overall level of effort required. All change requests should be prioritized in terms of benefits, urgency, effort required, security impacts, and other potential impacts on the organization’s operations.

A ticket should be created to track a change request at the onset. If the change is part of an existing ticket the original ticket may be used and modified appropriately.

(2) Planning and Evaluation

Plan and evaluate the change. This may include design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan. During planning, wire-frames, mockups, and functional requirements may be created and reviewed among the applicable team members. The team may set priority levels of the service and may determine any risk that the proposed change introduces to the system.

The scope and impact of the change should be determined during this phase. If possible, specific use cases should also be determined.

(3) Build, Test, and Document

In this step Sord sprints may be defined and the overall software design and development happens.

UI/UX and other optimizations should occur to enhance the performance and security of the change across all platforms.

The changes must be tested in the Sord staging environment before release to production. Test setups and scenarios are built for operational, performance, and security testing. Automated test scripts should be developed, used, and updated as changes occur.

The appropriate teams work to create documentation such as release notes, help articles, and blog posts applicable to the changes. Existing documentation is updated to ensure that team members and customers have the most up-to-date and accurate information. Customer-facing documentation should be provided to Sord customers as applicable.

(4) Code Review

Sord uses code reviews to maintain the quality of Sord code and products. Code reviewers should look at:

Design

Is the code well-designed and appropriate for your system?

Functionality

Does the code behave as intended by the plan? Is the way the code behaves good for its users?

Complexity

Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?

Tests

Does the code have correct and well-designed automated tests?

Security

Are there any security risks in the code as identified by the latest OWASP Top 10?

Naming

Are there clear names for variables, classes, methods, etc.?

Comments

Are the comments clear and useful?

Style

Does the code follow Sord style guides?

Documentation

Was the relevant documentation updated or created?

How to do a code review? Google Engineering Practices Documentation provided under the CC 3.0 License.

Secure Coding

Secure coding practices are incorporated into the development lifecycle and security architecture of Sord. Engineers at Sord are responsible for defining security requirements early in the software development life cycle and then evaluating for compliance with those requirements.

All engineers at Sord are responsible for reviewing the OWASP top 10 web application security risks.

(5) Approval and Implementation

Once the new release is ready and the appropriate documentation is in place, the new release may be pushed to the production environment after the appropriate review and approval by the appropriate product owner. Automation test suites should be used across all production environments.

Access to push changes to production at Sord must be restricted to a limited set of authorized team members and the engineer responsible for coding the change should not also be responsible for pushing the change to production, unless approved by management.

(6) Communication

Implemented changes should be communicated to all applicable team members and externally as appropriate.

(7) Post-Change Review

Sord continuously measures the success of new releases and identifies areas that can be enhanced further in the future.

The appropriate team may conduct a post-implementation review to determine how the change is impacting Sord and our customers, either positively or negatively. Discuss and document any lessons learned with product management and other appropriate team members.

Hotfixes / Critical Issues / Emergencies

The following are potential emergencies that may require a hotfix:

• A customer is completely out of service

• There is severe degradation of service needing immediate action

• A system/application/component is inoperable and the failure causes a significant negative impact

• A response to a natural disaster

• A response to an emergency business need

• A critical vulnerability or security issue is identified

If a hotfix is required, the applicable manager should be immediately notified.

The notification should include at a minimum the following information:

• Will the change cause an interruption in service?

• What additional customers will be affected (in the event a change is needed to fix an outage) and who needs to be notified?

• What is the possible workaround until the problem is resolved?

• What is the approximate length of the outage?

• Notification of resolution.

• Submission of a ticket to accurately describe the outage.

Emergencies after normal business hours, on the weekend, or on holidays, will be resolved as soon as possible. A ticket may be generated and team members may need to notify affected customers, as determined by management. A completed ticket should be submitted through the regular reporting process promptly following when the change was made.

Management may review all emergency submissions to ensure the change met the criteria for an “emergency change” and to prevent the process from becoming normal practice to circumvent the Change Management Policy. Any questions will be directed to the manager who approved the change.

Exceptions

Sord business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other Sord policy. If an exception is needed, Sord management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other Sord policy or procedure may result in disciplinary action, up to and including termination of employment. Sord reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. Sord does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of Sord as soon as possible.

​The disciplinary process should also be used as a deterrent to prevent employees and contractors in violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

Sord reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is maintained by Jonathan Gautsch.

This document was last updated on 03/27/2024.