Applicable Doc. 16 - VA OIT Change Control SOP.pdf

OFFICE OF

INFORMATION

AND TECHNOLOGY

VA OIT Change Control

Standard Operating Procedure

April 2023 | Department of Veterans Affairs (VA)

v. 1.50 (sync with VA Directive 6004)

OFFICE OF INFORMATION AND TECHNOLOGY

Revision History

Date Version Description Author

5/01/2019 .08 Draft completion Todd Levitt

3/03/2020 1.26 Approved version sync with SNoW Sprint

John Frazier

4/14/2023 1.50 Audit/Revision to coincide with VA 6004 Lori Fedor

Table of Contents

Introduction Purpose Scope

Types of Change Requests Normal Change Request Standard Change Request Emergency Change Request

Expedited Change Approval Process Change Management Process Flows

Process Overview Activity 1.0 Initiate Request for Change (RFC) (If Applicable) Activity 2.0: Review, Assess, and Authorize Activity 3.0: Package and Test Activity 4.0: Plan and Schedule Activity 5.0: Approve for Implementation Activity 6.0: Coordinate Implementation Activity 7.0: Review and Close

Post Implementation Review (PIR) Incidents Caused by Change (ICC)

Other Change Management Requirements Change Request Documentation (Change Artifacts) Delinquent Change Requests CIO Weekend Changes Report Cloud Implementations and VA OIT Change Control

Change Management Metrics and Reporting Approval Appendix A – Acronyms Appendix B – Reviews

Enterprise Change Control Management Process Document | i

List of Figures

Figure 1: Type of Change Request – Normal Figure 2: Normal Change Request in the New State Figure 3: Type of Change Request – Standard Figure 4: Standard Change Request Advanced from New to Scheduled State Figure 5: Emergency Change Advanced from New to Implement State Figure 6: Change Request as It is Elevated from New to Authorize, Scheduled, and Implement States Figure 7: Change Management High-Level Process Flow Figure 8: Change Request in the New State Figure 9: Change Request in the Review and Assess State Figure 10: Change Request in the Authorize State Figure 11: Change is Packaged and Tested Figure 12: Change is Planned and Scheduled Figure 13: Change Request in the Scheduled State Figure 14: Change Goes Through Approval for Implementation Figure 15: Approved Changes are Coordinated and Implemented Figure 16: Change Request in the Implement State Figure 17: Completed/Canceled/Backed-out Changes are Reviewed Figure 18: Change Request in the Review State Figure 19: Change Request in the Closed State

List of Tables

Table 1: Acronyms

Enterprise Change Control Management Process Document | ii

Enterprise Change Control Management Process Document | 1

Introduction

Purpose The purpose of Office of Information Technology (OIT) Change Control is to plan and govern the lifecycle of all changes to production configuration items (CI) in our enterprise environment.

Change Control enables production environment changes to be planned, scheduled, approved, and implemented with minimal disruption to Information Technology (IT) services. This Standard Operating Procedure (SOP) will provide a more detailed process review and help link policy with specific work instruction guidance from Change Request initiation to change closure.

Scope The scope of this OIT Change Control SOP covers processes for all of the Department of Veterans Affairs (VA) OIT and the entire lifecycle of Normal, Standard, and Emergency Change Requests in ServiceNow.

In addition, the scope of this SOP outlines how Change Requests are initiated, planned, approved, coordinated, implemented, and closed. This document includes links to artifacts required by applicable Federal and VA policies. The scope also includes procedures for Post- Implementation Reviews (PIRs) on emergency and failed changes to identify areas of improvement for Continuous Service Improvement process efforts.

Change Requests for Development, Test, Pre-Production, and other non-production environments are not required by Policy and are considered out of scope for purposes of this SOP unless these environments impact production CI infrastructure, applications, or data.

Enterprise Change Control Management Process Document | 2

Types of Change Requests

Normal Change Request A change that follows all steps of the Change Request lifecycle and includes completion of all Change Request processes.

This type of change allows enough time for the planning, approval, and implementation steps.

These changes are low to moderate impact and risk and must be approved by the Change Control Management Division (CCM) prior to implementation.

In cases where there is a high/very high/critical Risk or Impact, the change will be escalated to the Change Advisory Board (CAB) for proper review and approval. These Change Requests must also be formally approved by the management chain submitting the change.

Figure 1: Type of Change Request – Normal

Figure 2: Normal Change Request in the New State

Standard Change Request A change to a service or infrastructure is categorized as low-impact and low-risk, for which the approach is pre-approved by the CAB and requires no additional CAB approvals prior to implementation.

These changes have an accepted and established procedure for business approval, testing, back out, and PIR. These are routine changes implemented on a regular basis with no history of issues or failure.

If standard changes begin to fail in a certain area, pre-approvals may be revoked and change originators will need to submit them as normal changes until they are approved by the CAB to be submitted as standard changes again.

Enterprise Change Control Management Process Document | 3

If the risk or impact is changed to high/very high/critical on any given Standard change request, it will automatically change the Type to Normal and flag it for CAB review and approval.

Figure 3: Type of Change Request – Standard

Figure 4: Standard Change Request Advanced from New to Scheduled State

Emergency Change Request A change that is initiated in response to a major incident (break-fix), patient safety, or security event, and must be implemented immediately to sustain normal business operations.

This type of change occurs outside the normal change window and is reserved for changes intended to restore services.

Furthermore, the Emergency Change Request is NOT the emergency, especially for approval purposes; the Incident Management restoration effort is the emergency, not the Change Request. Emergency Change Requests must be submitted within 24 hours of the initial incident.

Figure 5: Emergency Change Advanced from New to Implement State

See Work Instruction – How to Open a Change Request for further information.

Expedited Change Approval Process

An Expedited Change is NOT a change type. It is a NORMAL change that must be approved before the next scheduled CAB meeting and implemented as soon as possible, per its scheduled implementation date. This elevation is usually a proactive measure to avoid incidents caused by change in our production environment.

Figure 6: Change Request as It is Elevated from New to Authorize, Scheduled, and Implement States https://dvagov.sharepoint.com/:b:/s/OITECRCM/EXKhEm2tun9Hu6ACxuZPHw8BzBTk4RiX7hKl46ojMqHRNg?e=zSraz0

Enterprise Change Control Management Process Document | 4

See Work Instruction – How to Open a Change Request for further information.

Change Management Process Flows A process flow diagram is commonly used in process engineering to indicate the general flow of processes with respect to steps and interfaces (inputs, outputs, and resources). The process flow displays the relationship between activities within a sequence and does not typically include detailed descriptions.

For detailed descriptions of process activities, please refer to the process activity descriptions below each process flow diagram.

Figure 7: Change Management High-Level Process Flow

The Change Management Process Flow above in Figure 7 is important to fully understand because it outlines the complete lifecycle of a Change Request. It is especially important at a high level to understand where key Team collaborations occur. Configuration Control Board meetings (CCBs) and Change Advisory Board Meetings (CAB) are very key events in this lifecycle.

This is covered below, in the Activity 2.0 section of this document.

Enterprise Change Control Management Process Document | 5

Process Overview

The Process outlined below is to be followed by all OIT staff and Contractors responsible for implementing changes to VA’s production IT infrastructure. Based on the scope outlined in the Enterprise Change Management Policy, the steps associated with the lifecycle of the Change Requests are listed below.

Activity 1.0 Initiate Request for Change (RFC) (If Applicable)

Figure 8: Change Request in the New State

The need for a change is recognized as a “Request,” not a Change Request. Only Change Requestors or Change Originators can open Change Requests for the configuration items which they own or manage. In other words, if you do not own a system or application, then you cannot change it. Therefore, personnel who do not own a system or software application must submit a Request for Change (RFC) to initiate the change process.

New Requests can be submitted through the ServiceNow Request Management Agent. New requests are assigned to the IT Service Owner who assumes the role of Change Requestor or Change Originator for review and collaboration with personnel submitting requests for change (RFCs). If approved, the IT Service Owner will create a new Change Request from the Request.

Similarly, Change Requestors or Change Originators can create new Change Requests from new or existing Incidents, Problems, and other Change Requests. This is the typical scenario. It is not

Enterprise Change Control Management Process Document | 6 often that Change Requestors or Change Originators get official Requests for Changes (RFCs) to the systems or software they own.

Change Request is a record in the VA OIT-approved Change Management System (CMS), ServiceNow, containing the details and artifacts required to properly manage any given change.

Each change record documents the lifecycle of a single change. A change record (A ServiceNow Change Request or CR) is created for every change to a production CI. Change records should reference the configuration items (CIs) that are affected by the change. Change records are always entered and properly managed so change documentation standards can be upheld and meet all requirements of the change control lifecycle process flow.

Activity 2.0: Review, Assess, and Authorize

Figure 9: Change Request in the Review and Assess State

Figure 10: Change Request in the Authorize State

Enterprise Change Control Management Process Document | 7

Configuration Control Boards (CCBs)

The CCB serves an oversight committee made up of technical and business representatives that enforce requirements on RFCs, and authorizes them with regard for technical, business, and organizational considerations. The CCB conducts these reviews prior to a change being released into development. It is chaired by the Release Manager or Change Coordinator and meets as needed, usually weekly, with emergency activities conducted via email and the Incident Management process. Specific responsibilities include:

• Assess the impacts to whom/what and risk associated with each request – adequately assessed from a business and technical viewpoint – provides comments where RFC is “Rejected.”

• Ensure the change will meet customer requirements and abides by architectural standards.

• Authorizes changes to move forward to packaging and testing activities.

• Reviews information regarding potential impacts and affected Configuration Items (CI).

• Assures the completeness of the RFC and all supporting documentation.

• Ensures a satisfactory testing plan has been prepared.

• Attends CAB meetings where applicable.

• Provides feedback and recommendations on the process and/or tool where necessary.

Enterprise Change Advisory Board (CAB)

The CAB provides final approval or rejection of changes for further progress at several checkpoints in the change control process. The board provides the final prioritization, scheduling, and conflict management of normal Change Requests. Certain tasks may be delegated to Change Coordinators. A CAB is comprised of appropriate representatives from all areas within OIT and the VA Product Lines. Specific responsibilities include:

• Reviews Change Requests for proper prioritization, scheduling, and initiates any conflict resolution issues that still may be present, performs relevant pre-meeting activities, and provides feedback.

• Manages the expedited and emergency change control process.

• Solicits additional information, technical reviews, impact assessments, and risk reviews as necessary.

• Provides final approval/scheduling of changes presented at the CAB meeting.

• CAB members participate in post-implementation reviews for failed changes and all emergency changes.

Enterprise Change Control Management Process Document | 8

Activity 3.0: Package and Test

Figure 11: Change is Packaged and Tested

Within this activity, the change is packaged and tested according to the developed plans.

Packaging and testing activities are facilitated by the Release and Deployment Management Process. Packaging and testing results are reviewed to determine whether the change needs to be rebuilt, canceled, or sent for the next phase.

Activity 4.0: Plan and Schedule

Figure 12: Change is Planned and Scheduled

The Plan and Schedule activity describes the planning and scheduling activities for Change Requests prior to their implementation.

Change Management Activity 3.0 - Package & Test

1.0 Initiate RFC 2.0

Review, Assess

& Authorize

3.1

Assign Resources 3.2

Coordinate & Support Package & Test

Activities Tests

Successful? Cancel Change?

4.0 Plan &

Schedule 7.0

Review & Close Release & Deployment Management

1.0

No Yes Yes

No

Change Management Tool & Policy

Configuration Data

( ) CMDB

Deployment Team Completes Testing

VIP

Change Management Activity 4.0 - Plan & Schedule

3.0 Package & Test

4.1 Ensure Required Documentation Is

Submitted i.e. test results ( )

4.2 Update RFC as

Necessary Based on

Package &Test Outcome

4.3 Review Forward

Schedule of Change and Identify Potential

Collisions

4.4 Identify and Confirm

Change Deployment Participants 4.6

Determine Level of Required Approval

5.0 Approve for

Implementation Release &

Deployment Management

3.0

Forward Schedule of

Changes

( FSC )

Change Management Tool & Policy

Type of Change Standard

Normal or Expedited

Coordinate 6.0 Implementation

4.5 Schedule Change Implementation

Tasks

Enterprise Change Control Management Process Document | 9

Figure 13: Change Request in the Scheduled State

Activity 5.0: Approve for Implementation

Figure 14: Change Goes Through Approval for Implementation

The Approve for Implementation activity facilitates obtaining approvals for the Change Requests via a weekly CAB meeting. Note a standard change does not require a CAB meeting. Once approval is obtained from the CAB, the Change Request is updated, and the decision is communicated to all the stakeholders.

CAB guidelines are established via the Directive 6004 Configuration Change and Release Management Prog 29 Dec 22.pdf. The requirements outlined within that documentation are leveraged during the execution of the CAB meeting.

https://dvagov.sharepoint.com/:b:/r/sites/OITECRCM/ECM%20Public%20Documents/Directive%206004%20Configuration%20Change%20and%20Release%20Management%20Prog%2029%20Dec%2022.pdf?csf=1&web=1&e=AaF5HB https://dvagov.sharepoint.com/:b:/r/sites/OITECRCM/ECM%20Public%20Documents/Directive%206004%20Configuration%20Change%20and%20Release%20Management%20Prog%2029%20Dec%2022.pdf?csf=1&web=1&e=AaF5HB https://dvagov.sharepoint.com/:b:/s/OITECRCM/EelJkmljxIpDsbUx5fwT4FsBm1RptRvFMz6OT90xoWzJuQ?e=RLRqN9

Enterprise Change Control Management Process Document | 10

Activity 6.0: Coordinate Implementation

Figure 15: Approved Changes are Coordinated and Implemented

The Coordinate Implementation activity describes activities and checkpoints to coordinate and implement approved changes. The Change Coordinator is responsible for planning and coordinating Change Request tasks and managing communication on task progress and issues.

The change is implemented and tested as defined in the Change Request plans.

Figure 16: Change Request in the Implement State

Change Management Activity 6.0 – Coordinate Implementation

6.1 Coordinate & Review

Implementation Activities

Release & Deployment Management

3.0

Implementation Successful?

6.2 Monitor Change Detected any

change issues?

6.3

Communicate completion status

Back-out Successful?

5.0 Approve for

Implementation

Success No

Incident Management

0.0 7.0

Review & Close

Backed Out No

Yes

Yes

Change Management Tool & Policy

Release & Deployment Management

4.0

Enterprise Change Control Management Process Document | 11

Activity 7.0: Review and Close

Figure 17: Completed/Canceled/Backed-out Changes are Reviewed

The activity for Review and Close ensures completed/canceled/backed out changes are reviewed, and all required documents are in place. Any possible RFCs are closed and communicated back to end users who originally submitted any RFCs associated with the Change Request. Additional approvals may be required to close the Change Request depending on the type of change. This phase completes the Change Management Lifecycle.

Figure 18: Change Request in the Review State

Figure 19: Change Request in the Closed State

Enterprise Change Control Management Process Document | 12

Post Implementation Review (PIR) PIRs can be performed on Change Requests (CRs) closed as successful with issues, unsuccessful, backed-out/rolled back, or when a CR caused a major Incident to identify the causes and provide recommendations to prevent the same situation from re-occurring. This also includes unauthorized changes where a non-documented change caused an incident.

See the Post Implementation Review document for specific instructions and information concerning post-implementation reviews: WI - ECM PIR Instructions.

Incidents Caused by Change (ICC) Major Incidents are processed by the Major Incident Management (MIM) Team during Major Incidents. Once services are restored, MIM engages the Problem Management Team to perform a Root Cause Analysis and provide preventative measures. If Problem Management determines the Incident was caused by a Change Request, they validate it as a Problem Caused by Change through their investigation. The Incident is marked as an Incident Caused by Change (ICC) and delivered to Enterprise Change Management for Post Implementation Review (PIR) processing. Change Management performs the PIR and notifies the responsible Change Request owner of the results and recommendations. All PIRs are briefed on the twice-weekly Change Advisory Board (CAB) meeting metrics maintained on the Change Management Executive Summary dashboard.

Other Change Management Requirements

Change Request Documentation (Change Artifacts) When initiating a Change Request, the Change Management System has been designed to help speed up the requirements of documenting your work. These artifacts are typically presented as part of the release phase but can also be added to the change record. Until the ServiceNow Release module is available and updated to include OIT’s specific needs, a complete Change Request that is ready for approval and implementation will contain information about your specific change that includes:

Implementation Plan: Define timeframe, resources, cost, and effort on the quality of service.

Provide requirements and a detailed description. How will the change be installed/implemented, and what step-by-step procedures? This can be in the form of installation guides, manuals, or white papers that are attached or referenced in the Change Request.

Test Plan/Results: All Department of Veterans Affairs (VA) ServiceNow Change Requests (CRs) must have an associated test plan, pre-production test results, and post-production testing validation attached to the CR. The test plan and results must be added to the CR prior to approval, for auditing purposes, and the validation results must be added after implementation https://dvagov.sharepoint.com/sites/OITECRCM/ECM%20Public%20Documents/Forms/AllItems.aspx?FilterField1=Category&FilterValue1=Change%20Control%20Management&FilterType1=Choice&FilterDisplay1=Change%20Control%20Management&FilterField2=Sub&FilterValue2=Approved%20Documentation&FilterType2=Choice&FilterDisplay2=Approved%20Documentation&id=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents%2FWI%20%2D%20ECM%20PIR%20Instructions%2Epdf&viewid=e9c0bfc4%2D299a%2D4017%2Dbf68%2D9d19656c54d4&parent=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents https://dvagov.sharepoint.com/:b:/s/OITECRCM/EdMV_4KYPFlLlJ4Q3MerlaoBSpTQFIu1g7bzm2mpcunTtQ?e=GNvt6r https://yourit.va.gov/$pa_dashboard.do?sysparm_dashboard=748afd7e1b9e011077e287b8624bcb0d&sysparm_tab=130bf9f21bde011077e287b8624bcbfc&sysparm_cancelable=true&sysparm_editable=false&sysparm_active_panel=false https://yourit.va.gov/$pa_dashboard.do?sysparm_dashboard=748afd7e1b9e011077e287b8624bcb0d&sysparm_tab=130bf9f21bde011077e287b8624bcbfc&sysparm_cancelable=true&sysparm_editable=false&sysparm_active_panel=false

Enterprise Change Control Management Process Document | 13 and before final closure. For any changes which cannot be tested before and after production deployment, the change owner must attach a narrative explaining why testing could not be completed and include mitigating actions or controls in place to reduce the impact and risk of the deployment. This is a National Institute of Standards and Technology (NIST) 800-53 r.5 CM- 3, para. (2) requirement.

Back-Out Plan: Development of the back-out plan is essential to ensuring effective recovery in the event of a failed change. The back-out plan is primarily based on the technical, customer, and security impact analysis and the implementation plan. System restoration steps should be clear and included in the back-out plan. Other considerations include:

• Document back-out criteria time constraints and procedures to return the service, system, application, or database to the previously working environment if the implementation fails.

• How is the change to be removed?

• At what point is the decision made to back out the change?

• What information should be gathered before back-out occurs to determine why the change needed to be backed out or why it affected the resources adversely?

• Part of a back-out plan should consist of a Management Escalation plan. The following guidelines and procedures should be followed when a Change Request requires Management Escalation.

These documents are essential for implementation and for pre/post-auditing functions from internal and external (Inspector General (IG)) auditing teams. All questions related to these artifacts must be answered in the Change Request on the tabs provided.

Delinquent Change Requests The Change Management Ops Team does the internal audits for delinquent changes. They provide a ServiceNow Dashboard which is used to report on changes considered delinquent for implementation, delinquent for review, and delinquent changes that are completed but have not been properly closed: WI - Delinquent Change Processing.

CIO Weekend Changes Report Each week the CAB Team is responsible for briefing the OIT Chief Information Officer (CIO) and other Senior Leaders on upcoming Production Changes. In support of this, the CIO Weekend Changes Report is processed weekly. The final report, which is processed on Tuesday afternoons, is used to populate the slides for the CIO briefing.

Specific instructions for processing the CIO Weekend Changes Report can be found in the Work Instruction WI - CIO Weekend Change Report.

https://dvagov.sharepoint.com/:b:/s/OITECRCM/ERwrwxT3c_xMkN7iuIUlSuABj0Sh5KEHmaDMY2zH5MC7HA?e=wIYAkd https://dvagov.sharepoint.com/:b:/s/OITECRCM/ERwrwxT3c_xMkN7iuIUlSuABj0Sh5KEHmaDMY2zH5MC7HA?e=wIYAkd https://dvagov.sharepoint.com/sites/OITECRCM/ECM%20Public%20Documents/Forms/AllItems.aspx?FilterField1=Category&FilterValue1=Change%20Control%20Management&FilterType1=Choice&FilterDisplay1=Change%20Control%20Management&FilterField2=Sub&FilterValue2=Approved%20Documentation&FilterType2=Choice&FilterDisplay2=Approved%20Documentation&id=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents%2FWI%20%2D%20CIO%20Weekend%20Change%20Report%204%2D0%2Epdf&viewid=e9c0bfc4%2D299a%2D4017%2Dbf68%2D9d19656c54d4&parent=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents https://dvagov.sharepoint.com/:b:/s/OITECRCM/ESlWU2zyFz5Cir6nTsx2LDsB9wBYYuvcXjpj-djPqRrCmw?e=mkDgfg

Enterprise Change Control Management Process Document | 14

Cloud Implementations and VA OIT Change Control Infrastructure that hosts services for VA OIT personnel and VA customers remotely (not owned or managed by VA OIT) must still adhere to VA OIT Change Management Policy. We must make sure changes affecting VA personnel and customers are properly approved, and scheduled, and do not conflict with other priorities or create issues when VA-owned, and Non-VA owned systems are dependent on each other for proper operation.

Change Management Metrics and Reporting

Metrics are a system of parameters or methods for quantitative and periodic assessment of a process that is to be measured. It includes procedures necessary to carry out such measurement, and procedures for the interpretation of the assessment in the light of previous or comparable assessments.

Metrics are usually specialized by the subject area; in which case they are valid only within a certain domain and cannot be directly benchmarked or interpreted outside it. The collection and analysis of metrics provide a factual method of evaluating the quality of the product or system.

Monthly, the ASR Team will provide metrics for:

1. Enterprise Open Change Requests for any Fiscal Year that has Open Change Requests.

2. Operational Metrics.

3. Key Performance Indicators (KPIs).

a. Critical Success Factors.

4. Late Changes.

The ASR Team maintains the Change Control Customer Metrics dashboard. Monthly charts, available via the dashboard, provide Change Request information about implemented, rejected/canceled, and backed-out changes. In addition, there are charts for Change Type, Average Processing Time, Change Success Rate, KPI charts, internal Change Request audit results, and Stale Change Requests.

https://yourit.va.gov/now/nav/ui/classic/params/target/%24pa_dashboard.do%3Fsysparm_dashboard%3D03bd6c0e1b7a5190e510eca8624bcb5d%26sysparm_tab%3Dd0dd244e1b7a5190e510eca8624bcbe5%26sysparm_cancelable%3Dtrue%26sysparm_editable%3Dundefined%26sysparm_active_panel%3Dfalse

Enterprise Change Control Management Process Document | 15

Approval

Todd Levitt Associate Director, IT Change Control Management (CCM) Enterprise Service Governance (ESG), Enterprise Service Management (ESM) Infrastructure Operations (IO), Office of Information and Technology (OIT)

Enterprise Change Control Management Process Document | 16

Appendix A – Acronyms Table 1: Acronyms

Acronym Definition

ASR Audit, Standards, and Reporting

CAB Change Advisory Board

CCB Configuration Control Board

CCM Change Control Management

CI Configuration Item

CIO Chief Information Officer

CMDB Configuration Management Database

CMS Change Management System

CR Change Request

ESG Enterprise Governance Management

ESM Enterprise Service Management

FSC Forward Schedule of Changes

ICC Incident Caused by Change

IG Inspector General

IO Infrastructure Operations

IT Information Technology

KPI Key Performance Indicators

MA Major Application

NIST National Institute of Standards and Technology

OIT Office of Information and Technology

PIR Post Implementation Review

RFC Request for Change

SOP Standard Operating Procedure

VA Department of Veterans Affairs

VBA Veterans Benefits Administration

VHA Veterans Health Administration

Enterprise Change Control Management Process Document | 17

Appendix B – Reviews

The Enterprise Change Control Management (CCM) Division reviews Change Requests (CRs) to ensure changes are entered in accordance with Federal and other VA policies. Reviews are conducted on a daily, weekly, and monthly basis.

See WI – ServiceNow Change Audits for more information.

https://dvagov.sharepoint.com/sites/OITECRCM/ECM%20Public%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents%2FWI%20%2D%20ServiceNow%20Change%20Audits%20%2D%20ASR%20CCM%2Epdf&parent=%2Fsites%2FOITECRCM%2FECM%20Public%20Documents https://dvagov.sharepoint.com/:b:/s/OITECRCM/EakIC8dzc3hEsrtE_Q9JPOUBa9Q3n7vGF2GYLR3_kUw5qw?e=xi03yw