Your manager has provided you the following matrix and asked that you use it to complete the design assessment phase of your testing. The manager has already performed a preliminary survey, and has determined that the control objectives populated in the matrix will be in scope for the audit. You will need to read the attached policies, procedures, and control definition documents. From these you will need to determine which control activities from the client's control environment are relevant to our objectives, and map them to each objective. You will need to determine whether or not the control is designed effectively by looking at the control details within the policies and procedures. You will be required to document how the control is designed, and whether that control activity is designed to appropriately to meet the control objective. Make sure you document the who, what, where, when, why, and how regarding both your evidence and conclusions.

Procedure Overview The system change management process provides documented evidence with a high degree of assurance that the system consistently performs to predetermined specifications and quality attributes. Successful change control is characterized by the following: pre-planned methodical run to approved protocols requirements are traceable through the test process Design control is critical for the success and approval of a change request. It is the responsibility of all members of the development team to maintain design control. Planned releases will be utilized to ensure design control and to provide a timely, coordinated approach to change management. High Level Requirements Development activities are initiated by a logged request for change. The request for change is then assigned a priority and resources. A System Change Control document is required to track the change control process through its various phases. The Change Control Team will be responsible for reviewing the request based on the requirements definition, resource availability, priority, and impact on other sites and /or other requests. Approvals: Change Control approval must include, at a minimum, signatures from IT, Software Quality Assurance, business, and other functional areas as required. Validation activities required are determined through the review process. Promotion to the Prototype instance will be part of the production promotion process. 1.1 Raising a Request for Change 1.1.1 General ALL changes that have the potential to affect the design or architecture of any service provided by IT must be supported by a Request for Change, which has been raised prior to the change being made, using the Global Change Management system. The exception to this is an emergency change (see section Emergency Requests for Change below). Requests for Change should be raised as soon as possible - normally as soon as it is apparent that the change is required. Note: A Request for Change is required for any required change that has an impact or potential impact to any service provided by IT. For infrastructure changes, this may include changes that impact development and test environments, as well as production. Consider the following example: A change is required to the backup configuration for a development or Quality Assurance (hence QA) environment. Since the backup is a key part of the development or QA service GTS is providing, a Request for Change is required. Such changes are deemed Production changes, since they affect a live service provided by GTS to our customers. Note: Wherever possible, changes must be tested in a Development and/or QA environment first. Every effort should be made to test a change destined for production in a test environment first, in order to validate the implementation plan. (It is however understood that in certain circumstances for certain changes that this is not always possible; for example, replacing a failed disk in a production server or direct data changes to values in production.) For changes that can be tested, an advantage of GCM is that it is no longer necessary to raise an RFC for the test environment and a subsequent RFC for production - both can be done within the same single RFC in GCM as it provides the necessary workflow and approvals to support this. Note: Where a change affects only the infrastructure supporting development and/or test environments and will not be carried forward to infrastructure supporting a production environment (e.g. disk upgrade, failed hardware component replacement, backup configuration change), it is considered a Production implementation and understood that no testing may be possible. Again, such changes are deemed Production changes, since they affect a live service provided by GTS to its customers. The Global Change Management (GCM) system is accessed using an Internet browser, as part of Production. The direct/full URL is XXX. The GCM system uses Active Directory to authenticate its users, grant access to the system and for authorizations/approvals. Therefore the login to the system will be the user's network user ID and password. 1.1.2 Creating a New Request for Change - Blank RFC Form Create a new and blank request for change by selecting 'Create a Request' from the sidebar at the left hand side of the page, under the Demand Management section. Select 'GCM - Global Change Management' from the Request Type dropdown and click Create. It is likely that 'GCM - Global Change Management' will also appear in your Most Recently Created list on the Create New Request page. Complete each field necessary for the Request for Change. The fields provided on the Request for Change form are defined in section Error: Reference source not found. This section must be used in conjunction with other sections of the document to understand how to use each field. Use the \"Save Draft\" function to save an RFC you are building but which is not yet ready to be submitted for review by your Change Manager. If the business submits the request for change, the auto-population of their name, date and time stamp by is sufficient to represent approval for the initiation of the change. If IT submits the request for change on behalf of the business, an attachment is required documenting that the business initiated this request. The attachment may be in the form of an email, a printed and signed copy of the RFC, a signed Software Work Request (SWR), a CER, or any other representation of the business request. Similarly, if a support resource submits the request for change on behalf of a user, an attachment is required documenting that the business initiated this request. If IT submits the request on behalf of IT, no supplemental documentation is required. 1.1.3 Creating a New Request for Change - Copy an Existing RFC A very useful feature of for similar types of requests for change is the ability to copy an existing request for change to create a new RFC using the Make a Copy function: Locate the RFC to be copied and open it so that it is displayed on the screen. Click the Make a Copy button below the Available Actions section at the top of the form. When the Copy Request screen is displayed, uncheck Copy Request Notes and Copy Request References then click Copy. Click Save Draft to save a draft the new request. The Request Copy Confirmed screen is displayed and indicates the request draft has been created and provides the new RFC number as a link to it. (The existing/copied from request is also provided.) Click on the new request number to display the new RFC which will be populated with details from the existing/copied RFC. Review each field necessary for the new Request for Change and update accordingly. If you have copied a closed RFC, pay particular attention to the Review section and remove all Completion Comments, set Process Validation to \"No\" and Follow-up Review to \"No\". Review and set all date fields appropriately. The fields provided on the Request for Change form are defined in section Error: Reference source not found. This section must be used in conjunction with other sections of the document to understand how to use each field. NOTE: If you copy an RFC that was created by someone other than yourself, the Creator Email field will be incorrectly displayed with that person's email address. When you submit the RFC, this field will be autoupdated to correct it. Use the \"Save Draft\" function to save an RFC you are building but which is not yet ready to be submitted for review by your Change Manager. 1.1.4 Pre-Authorized Requests for Change A Pre-Authorized Request for Change is a change that is covered in its entirety by an existing Work Instruction, Standard Operating Procedure or Technical Document. A Pre-Authorized change is typically performed regularly or is common. This supporting document MUST be clearly referenced in the System Installation Checklist Text Area field in the Implementation section, indicating at least the document reference number. It is useful to also provide the document title. Additionally, the Change Builder must specify that he/she requires the request for change to be executed as a 'Pre-Authorized Change' by selecting this in the impact field of the RFC at the bottom of the Analysis section. The Change Manager confirms that the change is Pre-Authorized at Step 1 - Collaborate - in the workflow. The RFC bypasses all Analysis/Design, Build and Test steps and moves directly to Step 28 - Implement Change Using Standard Procedure. The Change Manager may also decide that the change is not PreAuthorized at Step 1 - Collaborate, in which case the RFC follows the normal workflow. Best practice is to have the pre-authorized SOP logged through DCO (Document Control Organization). 1.1.5 Emergency Requests for Change When a change is urgent and needs to be implemented quickly in order to resolve an issue or problem that is affecting the availability of a service, an Emergency Request for Change may be raised. Wherever possible, the emergency request for change should be raised in advance of the change actually being implemented. The Priority field in the RFC must be set to \"Emergency\". Before implementation, the Emergency RFC must be discussed with all relevant team members available, the relevant Change Managers and business/service area owners for the services impacted to ensure the validity and integrity of the change. This includes assuring that implementation of the change cannot wait for the normal implementation time required for its impact. It is, however, understood that, under certain circumstances, an emergency change may have to be implemented before an emergency RFC can be raised. This is normally the case when immediate action is required to fix a system or application problem. In these cases, an emergency RFC is raised retrospectively, but as soon after the change as possible. The Priority field in the RFC must still be set to \"Emergency\". However, prior to execution of the emergency change, it must be fully discussed with all relevant team members available, the relevant GTS Managers, business/service area owners for the service impacted, and relevant service area executives as appropriate, prior to its execution. Email approvals must be sent wherever possible to back up the decision to implement a change without an approved RFC (and subsequently attached to the RFC). Emergency RFCs follows the same workflow as all other RFCs, except Pre-Authorized and Direct Data Change. 1.1.6 Direct Data Change Requests for Change A Direct Data Change Request for Change is a change requesting IT intervention to change data in the production system by means other than a standard business process. A Direct Data Change request for change is typically performed at the request of the business stakeholder of the service area. This supporting document MUST be clearly referenced in the System Installation Checklist Text Area field, indicating at least the document reference number. It is useful to also provide the document title. Additionally, the Change Builder or Change Manager must specify that he/she requires the request for change to be executed as a 'Direct Data Change' by selecting this in the impact field of the RFC. The Change Manager confirms that the change is a Direct Data Change at Step 1 - Collaborate - in the workflow. Direct Data Change then moves to Step 2 - Prepare Pre-Build Documentation. Once the design is approved, the RFC bypasses all Build and Test steps and moves directly to Step 17 - Decide Approval for Implement. From this step forward Direct Data Change requests for change follows the normal workflow. The Workflow of a Request for Change In the Global Change Management system, the change is driven through its lifecycle via an automated workflow, which ensures that the change is properly approved and reviewed throughout. The following paragraphs list the workflow steps which a change passes through, the information which must be completed and the responsibilities of the change stakeholders (Change Builder, Change Manager, etc.) at each stage. A graphical view of the workflow is provided in section Error: Reference source not found - Appendices. Items highlighted in Bold show the points at which an action button can be selected in to move the RFC through the workflow. Items referring to a 'step' are referencing the workflow steps - see Error: Reference source not found. Use this section in conjunction with section Error: Reference source not found Error: Reference source not found to understand what each field on the Request for Change form means and how it is used. 1.1.7 Initiating and Submitting an RFC (CB or Change Requester) The Change Creator begins the change management process by filling in the Header-Summary section of the RFC form and submitting the request for change for review. The change creator is in practice usually the same person as the Change Builder (CB) since it is the CB who typically interprets a service request from an IT customer as a change and documents the request for change. If the Change Requester is authorized to GCM, he/she may enter the RFC him/herself. This is likely to happen more and more often, particularly between IT groups, as GCM is deployed globally. If the Change Builder is creating the RFC, he/she should specify the name of the actual requester of the change in the Change Requester field. If the Change Requester is creating the RFC, he/she should specify his/her own name in the Change Requester field. The Change Requester field cannot be the Change Builder, since the Change Builder will be assigned the RFC and will perform the build, test and implementation of the change; this is a segregation of duties issue. Typically, however, the CB will enter as much detail as possible in all sections. He/she may use the Save Draft function while obtaining the information required for the form. If the Change Requester is not the CB, he/she may enter less information than a CB; the CM will then ask the CB to review and complete the form as necessary at a later step. Change Requester/CB Action: Submit When an RFC is submitted, the RFC will move to step 1 'Collaborate'. Miminum requirements to Submit an RFC: All fields in the Summary section must be completed. The Justification field in the Analysis section must be completed. IMPORTANT: The submission process will auto-generate an email to individuals named in the To Inform field. This is an easy way to create awareness of submitted request. 1.1.8 Step 1 - Collaborate: Initial Review, Collaborate and Assess Impact (CM) Request Status: 01 Initiation - 10 Collaborate At workflow step 1 (Collaborate), the CM reviews the details entered and discusses the RFC with the requester, the proposed CB and other stakeholders, as necessary. Appropriate fields in any section of the RFC are updated by the CB or CM as necessary based on these discussions and information received. The CM decides which CB will be responsible for the RFC and ensure the 'Assigned To' field reflects this. The CM then Rejects or Assigns the RFC. Service Areas leveraging a Change Control Team shall present and review RFCs per agreed upon schedule. If the business stakeholder does not enter the RFC directly, evidence of the appropriate business stakeholder's authorized request shall be evidenced via email, minutes, etc. The Change Manager or designee performs an impact analyst and records analysis. The assigned resource determines the detailed requirements of the request. The detailed requirements include the impact of the request, software and documents associated with the request, and identification if change is required to software and /or documents. This may require the analyst to have additional discussions with the requestor and / or other users and / or other developers to ensure clarification and completeness of the request. The analyst will fill out a Report Request Form for any RFC requiring a new report or significant layout changes to existing reports and update the appropriate SRS. The analyst will fill out a Schedule request form for any RFC requiring that a job be automated and update the appropriate SRS. The analyst will update the appropriate SRS and fill out an SDD for any major software functionality changes. The analyst will update the appropriate SRS for any existing functions that will be implemented but which were not previously validated. The analyst will update the appropriate SRS for vendor software enhancements that will be implemented but which were not previously validated The analyst forwards the RFC with the system impact analysis and requirements documents to the Change Manager or designee. CM Action: Reject If the change is rejected, the RFC will be moved to a Cancelled status. Prior to cancelling the request, the system will prompt the user to confirm that the recommendation field is complete. This is to insure that the explanation as to why the request is being cancelled is documented. The CM should detail any additional information required in a Note and, or attach reference material. CM Action: Assign When assigning the RFC, the CM is required to assess the impact of the change based on discussions and information received so far. Impact values of Pre-Authorized, Minor, Significant, Major and Direct Data Change are available. See section Error: Reference source not found for an explanation of these values and their usage. When Minor, Significant or Major is selected, the RFC will move to step 2 'Prepare Pre-Build Documentation'. When Pre-authorized is selected, the RFC will move to step 28 'Implement Change using Standard Procedure'. When Direct Data Change is selected, the RFC will move to step 2 'Prepare Pre-Build Documentation'. The next step for a Direct Data Change impact RFC is step 17 'Decide Approval for Implementation' (status -'06 Implement - 10 Decide Approval for Implementation'). Minimum requirements to Assign an RFC: Analysis section of the RFC form should be filled out as much as possible based on information received during this step; If the impact is Pre-authorized, Analysis, Design-Development and Implementation sections must be fully filled out. If the impact is Direct Data Change Analysis, Design-Development and Implementation sections must be fully filled out. 1.1.9 Step 2 - Prepare Pre-Build Documentation (CB) Request Status: 02 Analysis/Design - 10 Prepare Documentation At workflow step 2 (Prepare Pre-Build Documentation), the CB prepares all documentation required before the change can be performed in its first target environment (development, test or production). All required details in the Analysis, Design-Development and Implementation sections of the form must be completed and all documentation required to allow the change to be performed in its first target environment must be completed and attached to the appropriate field in the RFC. CB Action: Complete When satisfied that the pre-build documentation requirements are complete, the CB clicks Complete to pass the RFC to the CM for review. The RFC will move to step 3 'Decide Approval for Testing'. Note - PEER REVIEW: For complex changes and those which have a Significant or Major impact, it is recommended that another CB within the same Service Area perform a peer review of the RFC and associated documentation on behalf of the assigned CB. This second CB should indicate that a peer review has occurred by selecting Complete on the pre-build documentation workflow step and adding a Note to the RFC indicating that peer review has been completed.. Note: Change Manager Authority: The CM also has authority to select Complete as this step. During review, if the CM is satisfied that the RFC has been fully completed and required documentation has been provided, he/she may click through this step in order to move to the next without the need to go back to the CB. This typically occurs for Minor impact RFCs and is provided to make the system more efficient. Minimum requirements to Complete this step: Analysis, Design-Development and Implementation sections must be completed. All appropriate required documentation must be completed and attached to the relevant field. Draft training materials and SOPs should be considered at this step. Final training material and updated SOPs are required prior to the promotion to production. Start Date/Time and Finish/Date time must reflect the dates and time when the change is being performed in its first target environment (development, test or production). 1.1.10 Step 3 - Decide Approvers for Design Phase (CM) Request Status: 02 Analysis/Design - 20 Decide Approvers for Design Phase At workflow step 3 (Decide Approval for Design Phase (formerly Testing)), the CM reviews the change and its associated documentation. The CM must review the Start Date/Time and End Date/Time fields to ensure they are set appropriately for executing the change in its first target environment (development, test or production). The CM then assesses the need to obtain approvals for the change to be tested, and updates appropriately the IT Approver(s), Business Approver(s), Quality Approver(s) and Service Area Executive Approver(s) fields. Note: The CM Approval at this point is approval to execute the change. The steps to execute will vary based on the design. At a minimum, this step indicates approval of the design. Based on this approval, build / development activity can start in the development instance if available, in test / prototype instances if available. Approval at this step does not give approval to implement in Production (that is step 66 (formerly 17), see below). The CM must consider at this point therefore whether additional approval is required for performing the change in development and, or test first based on the design and requirements of the involved service areas. It is the responsibility of each CM to judge this correctly; approvals at the design phase stage may be appropriate and prudent where the change affects or could affect how an application functions in the environment being used for testing. CM Action: Approve - Request Additional Approval The CM approves the RFC to be executed in Development and, or Test stipulating that additional IT, business, quality and/or service area executive approvals are required to proceed with build activities and Test implementation. Re-authentication is required to support electronic signature requirements. The CM decides and confirms the required Approvers for the RFC: o For an RFC designated Minor impact, at least additional IT Approvers (site IT managers, other GTS managers, managers of other IT groups) are typically required. Business, Quality and Service Area Executive Approvers may be required, if appropriate. o For an RFC designated Significant or Major impact, IT Approvers, Business Approvers and Service Area Executive Approvers are typically required. Quality Approvers may be required, if appropriate. The RFC will move to steps 4, 5, 6 and 7 - IT Approval to Test, Business Approval to Test, Quality Approval to Test and Service Area Executive Approval to Test respectively. Email notification will be sent to the approvers. CM Action: Approve - No Additional Approval Required The CM approves the RFC to be executed in Development and, or Test; additional IT, business, quality and/or service area executive approvals are not required for Build and Test implementation. Re-authentication is required to support electronic signature requirements. OR The RFC is a No Test Possible RFC to be indicated so at the next workflow step, so no approvals for test are necessary. Re-authentication is required to support electronic signature requirements. The RFC will move to step 8 'Decide Path to Production'. 1.1.11 Steps 4/5/6/7 - IT/Business/Quality/Service Area Executive Approval to Test (Approvers) Request Status: 02 Analysis/Design - 30 Test Approval At workflow steps 4/5/6/7 (IT/Business/Quality/Service Area Executive Approval to Test), the designated Approvers approve the RFC for implementation to Test environment(s) including any perquisite Build activities. This is now done in parallel; it is no longer necessary for approvers to wait for the previous approver to approve before they can approve. Approvers are required to re-authenticate on approval or disapproval to support electronic signature requirements. Approver Action: Approved The RFC is approved for execution in the Test environment by the Approver. When all approvals have been received, the RFC will move to step 8 'Decide Path to Production'. Approver Action: Not Approved The RFC is not approved for execution in the Test environment by the Approver. If any one Approver does not approve the RFC, there is no consensus and the RFC will move back to step 3 'Decide Approval for Testing' Approver Action: Delegate Decision The approver decides to delegate the decision to approve to someone else. The Delegate To field is promoted and must be completed. A note can be added. The delegate can select Approved, Not Approved or Delegate Decision. 1.1.12 Step 8 - Decide Path to Production (CM) Request Status: 02 Analysis/Design - 40 Decide Path to Production At workflow step 8 (Decide Path to Production), the CM decides whether this RFC is a: Three Tier Change that needs to go through Development and Test environments before going to Production. A few GTS changes will be Three Tier changes, such as a change to an in-house written systems management script or utility. Three Tier is the typical path to production for application teams. Two Tier Change that needs to go through the Test environment only before going to Production; most GTS changes are of this type - wherever possible, a Test implementation must be performed. Service Areas that leverage an ASP (Application Service Provider) will often use a Two Tier path since development is done on the vendor's development environment. No Test Possible Change that goes directly to the Production environment because it is not possible to implement in Test; GTS changes may often fall into this category, particularly installing or removing a server, replacing failed hardware, ad-hoc saves or restores, where the configuration does not exist in a test environment, or where the change affects test and production environments on the same configuration item. CM Action: Three Tier Change The RFC needs to go through Development and Test and then into Production. The RFC will move to step 11 'Build Changes in Development Environment'. CM Action: Two Tier Change The RFC needs to go through Test and then into Production. The RFC will move to step 9 'Build Changes in Testing Environment'. CM Action: No Test Possible Change The RFC needs to go directly into Production. The RFC will move to step 66 (formerly 17) 'Decide Approval for Implementation'. Note: The following steps assume a Three Tier Change. Jump to step 66 (formerly 17) for a No Test Possible Change. The transition between Build/Migrate and Validate Testing steps in a Two Tier Change is similar to a Three Tier Change, it just skips the step 11 Build in Development step 12 Validate Unit Testing and then mirrors testing with step 15 Migrate to UAT step 16 Validate UAT to get to step 66 (formerly 17). 1.1.13 Step 11 - Build Changes in Development Environment (CB) Request Status: 04 Build - 10 Build Changes Development At workflow step 11 (Build Changes in Development Environment), the CB executes the change in the development environment per the RFC and any attached documentation. CB Action: Complete The change has been installed or executed in the development environment. The RFC will move to step 12 'Review Unit Test Results'. The Change Builder executes unit test plans necessary to validate the change in the Development environment using appropriate forms for the Service Area. Unit testing shall verify and document: o Explicit and derived requirements are met o Limits and exceptions (error conditions, etc.) are executed o Data is properly initialized o Housekeeping (closing files, memory reallocations, etc.) functions are performed o Output / Input formats are correct The change builder will attach (preferably together in a zip file) all objective evidence of the implementation to Development, including the results of the unit test plan and associated objective evidence, to the Reference section in the RFC using the Attachment Add function with a Description (see section Error: Reference source not found). Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the installation to Test has been completed. This functionality is provided to make the system more efficient. 1.1.14 Step 12 - Review Unit Test Results (CM) Request Status: 04 Build - 20 Review Unit Test Results At workflow step 12 (Review Unit Test Results), the Change Manager performs a review of the unit test results and evidence. The RFC may hold at this step until the CM is satisfied with the results and evidence provided. Test results should be summarized in a test matrix showing tests performed, dates and results. Test matrix and supporting documentation are submitted for review and approval. CM Action: Success The testing was successful and has been validated following review of the test results and the objective evidence. The back-out plan documented on the RFC, which may be required after production implementation, has been validated. The RFC will move to step 15 'Migrate Changes to UAT Environment'. Minimum requirements for testing Success: Test results and sufficient evidence of them must be attached to the RFC. The Start Date/Time and End Date/Time fields must be appropriately set to indicate when the change will be executed in the Production environment, even if this is an estimation. CM Action: Fail The testing failed and the change needs to be backed-out and then re-executed, or fixed, in the test environment before the RFC can proceed. Re-execution of the unit test must be performed. The RFC will move back to step 11 'Build Changes in Development Environment'. Minimum requirements for testing Fail: The back-out plan documented on the RFC has been validated. 1.1.15 Step 15 - Migrate to UAT Environment (CB) Request Status: 05 Test - 30 Migrate to UAT / Quality At workflow step 15 (Migrate Changes to UAT Environment), the CB or CMig migrates the change into the UAT / Quality environment per the RFC and any attached documentation. Notification of the need for migration may be completed by the CM via a dashboard agreed upon with the CB and CMig, an email or service desk ticket. CB Action: Complete The change has been installed or executed in the UAT / Quality environment. The RFC will move to step 16 'Validate UAT Testing & Back-out Plans'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the installation to Test has been completed. This functionality is provided to make the system more efficient. 1.1.16 Step 16 - Validate UAT Testing & Back-out Plans (CM) Request Status: 05 Test - 40 User Acceptance Test Changes At workflow step 16 (Validate UAT Testing & Back-out Plans), the designated Change Tester executes test plans necessary to validate the change in the Test environment. Regression testing of existing components must be considered at this point. The change tester will attach (preferably together in a zip file) all objective evidence of the implementation to Test, including the results of any test plan and associated objective evidence, to the Reference section in the RFC using the Attachment Add function with a Description (see section Error: Reference source not found). The CM may then perform a review of the test results and evidence. The RFC may hold at this step until the CM is satisfied with the results and evidence provided or proceed based on the direct approval of the RFC by a Business Stakeholder. CM Action: Success The testing was successful and has been validated following review of the test results and the objective evidence. The back-out plan documented on the RFC, which may be required after production implementation, has been validated. The RFC will move to step 66 (formerly 17) 'Decide Approval for Implementation'. Minimum requirements for testing Success: Test results and sufficient evidence of them must be attached to the RFC. The Start Date/Time and End Date/Time fields must be appropriately set to indicate when the change will be executed in the Production environment, even if this is an estimation. CM Action: Fail The testing failed and the change needs to be backed-out and then re-executed, or fixed, in the test environment before the RFC can proceed. The RFC will move back to step 11 'Build Changes in Development Environment'. Minimum requirements for testing Fail: The back-out plan documented on the RFC has been validated. The CB executes the back-out plan detailed in the RFC to back-out the change from the production environment. The back-out plan shall include a section for system impact analysis. If not completed prior to the execution of the back-out plan, a system impact analysis shall be completed as part of the back-out activities. Evidence of successful back-out is attached to the RFC, preferably in a zip file. Note: The following steps assume a Two Tier Change. Jump to step 66 (formerly 17) for a No Test Possible Change. The transition between Build/Migrate and Validate Testing steps in a Three Tier Change is similar to a Two Tier Change, it just repeats them as in step 11 Build in Development step 12 Validate Unit Testing step 15 Migrate to UAT step 16 Validate UAT to get to step 66 (formerly 17). As the RFC moves from each of the Validate Testing steps to a Migrate/Implement step, the CB and CM shall ensure that the Start Date/Start Time and End Date/End Time fields are appropriately set to indicate when the change will be executed in each environment. 1.1.17 Step 9 - Build Changes in Testing Environment (CB) Request Status: 04 Build - 15 Build Changes Test At workflow step 9 (Build Changes in Testing Environment), the CB or CMig executes the change in the test environment per the RFC and any attached documentation. Notification of the need for build / migration may be completed by the CM via a dashboard agreed upon with the CB and CMig, an email or service desk ticket. CB / CMig Action: Complete The change has been installed or executed in the test environment. The RFC will move to step 10 'Validate Testing & Back-out Plans'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the installation to Test has been completed. This functionality is provided to make the system more efficient. 1.1.18 Step 10 - Validate Testing & Back-out Plans (CM) Request Status: 05 Test - 20 Test Changes At workflow step 10 (Validate Testing & Back-out Plans), the designated Change Tester executes test plans necessary to validate the change in the Test environment. Regression testing of existing components must be considered at this point. The change tester will attach (preferably together in a zip file) all objective evidence of the implementation to Test, including the results of any test plan and associated objective evidence, to the Reference section in the RFC using the Attachment Add function with a Description (see section Error: Reference source not found). The CM then performs a review of the test results and evidence. The RFC may hold at this step until the CM is satisfied with the results and evidence provided. CM Action: Success The testing was successful and has been validated following review of the test results and the objective evidence. The back-out plan documented on the RFC, which may be required after production implementation, has been validated. The RFC will move to step 66 (formerly 17) 'Decide Approval for Implementation'. Minimum requirements for testing Success: Test results and sufficient evidence of them must be attached to the RFC. The Start Date/Time and End Date/Time fields must be appropriately set to indicate when the change will be executed in the Production environment, even if this is an estimation. CM Action: Fail The testing failed and the change needs to be backed-out and then re-executed, or fixed, in the test environment before the RFC can proceed. The RFC will move back to step 9 'Build Changes in Testing Environment'. Minimum requirements for testing Fail: The back-out plan documented on the RFC has been validated. The CB executes the back-out plan detailed in the RFC to back-out the change from the production environment. The back-out plan shall include a section for system impact analysis. If not completed prior to the execution of the back-out plan, a system impact analysis shall be completed as part of the back-out activities. Evidence of successful back-out is attached to the RFC, preferably in a zip file. 1.1.19 Step 66 (formerly 17) - Decide Approval for Implementation (CM) Request Status: 06 Implement - 10 Decide Approval for Implementation At workflow step 66 (formerly step 17) (Decide Approval for Implementation), the CM reviews the details in the RFC and its associated documentation. This includes reviewing and approving the final system installation checklist, Back-out Plan, updates to Disaster Recovery Plans, Work Instructions and SOPs if impacted and performing training if required. The CM must review the Start Date/Time and End Date/Time fields to ensure they are set appropriately for executing the change in the Production environment. The CM then assesses the need to obtain approvals for the change to be implemented, and updates appropriately the IT Approver(s), Business Approver(s), Quality Approver(s) and Service Area Executive Approver(s) fields. CM Action: Request Additional Approval The CM approves the RFC to be executed in Production; additional IT, business, quality and/or service area executive approvals are required for Production implementation. Re-authentication is required to support electronic signature requirements. The CM decides and confirms the required Approvers for the RFC: o For an RFC designated Minor impact, at least additional IT Approvers (site IT managers, other GTS managers, managers of other IT groups) are typically required. Business, Quality and Service Area Executive Approvers may be required, if appropriate. o For an RFC designated Significant or Major impact, IT Approvers, Business Approvers and Service Area Executive Approvers are typically required. Quality Approvers may be required, if appropriate. The RFC will move to steps 18, 19, 20 and 21- IT Approval to Implement, Business Approval to Implement, Quality Approval to Implement and Service Area Executive Approval to Implement respectively. Email notification will be sent to the approvers. CM Action: Approve - No Additional Approval Required Note: This situation will be rare for implementing a change in Production! The CM approves the RFC to be executed in Production; additional IT, business, quality and/or service area executive approvals are not required for Production implementation. Reauthentication is required to support electronic signature requirements. The RFC will move to step 22 'Build/Migrate Changes to Production Environment'. CM Action: Not Approved Note: This situation also will be rare for implementing a change in Production The CM will reject the execution of the RFC in Production only if new information becomes available after the completion of testing, but prior to implementing the change in production. The RFC will move back to step 16 Validate UAT Testing and Back-out Plans. 1.1.20 Steps 18/19/20/21 - IT/Business/Quality/Service Area Executive Approval to Implement (Approvers) Request Status: 06 Implement - 20 Implementation Approval At workflow steps 18/19/20/21 (IT/Business/Quality/Service Area Executive Approval to Implement), the designated Approvers approve the RFC for implementation to the Production environment. This is now done in parallel; it is no longer necessary for approvers to wait for the previous approver to approve before they can approve. Approvers are required to re-authenticate on approval or disapproval to support electronic signature requirements. Approver Action: Approved The RFC is approved for execution in the Production environment by the Approver. When all approvals have been received, the RFC will move to step 22 'Build/Migrate Changes to Production Environment'. Approver Action: Not Approved The RFC is not approved for execution in the Production environment by the Approver. If any one Approver does not approve the RFC, there is no consensus and the RFC will move back to step 66 (formerly 17) 'Decide Approval for Implementation' Approver Action: Delegate Decision The approver decides to delegate the decision to approve to someone else. The Delegate To field is promoted and must be completed. A note can be added. The delegate can select Approved, Not Approved or Delegate Decision. 1.1.21 Step 22 - Build/Migrate Changes to Production Environment (CB) Request Status: 06 Implement - 30 Promote to Production At workflow step 22 (Build/Migrate Changes to Production Environment), the CB executes and implements the change in the production environment per the RFC and any attached documentation. CB Action: Complete The change has been executed/implemented in the production environment. The RFC will move to step 23 'Production Process Validation/Test'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the implementation to Production has been completed. This functionality is provided to make the system more efficient. Additional considerations for Promote to Production: For Service Areas utilizing service desk to cross coordinate with change migrators in other Service Areas, a ticket shall be created to request the migration documented in the approved RFC. Upon completion of the migration, change migrators may be requested to notify the Change Manager. 1.1.22 Step 61 (formerly step 23) - Production Process Validation/Test (CM) Request Status: 06 Implement - 40 Production Process Validation At workflow step 61 (Production Process Validation/Test), the designated persons execute test plans and/or perform activities necessary to validate the change in the Production environment: perform production process validation. Objective evidence relating to both the implementation to Production and the validation that the change is working as expected in Production will be attached (preferably in a zip file) to the Reference section in the RFC using the Attachment Add function with a Description (see section Error: Reference source not found). The CM then performs a review of the implementation and production process validation results and evidence. The RFC may hold at this step until the CM is satisfied with the results and evidence provided. CM Action: Success The implementation was successful and has been validated following review of the results and the objective evidence. The RFC will move to step 25 'Record Changes and Report Results'. Minimum requirements for implementation Success: Implementation evidence and results and evidence of production process validation must be attached to the RFC. The Process Validation field on the RFC is set to 'Yes' manually by the CM. Additional considerations for implementation Success: For Service Areas utilizing document control, the completed change package shall be submitted to document control. For Service Areas subject to Validation requirements, the validation must be completed and approved prior to completion of the Implementation steps. Typical activities in the Production Process Validation / Test step include first piece inspection where barcode or labeling may have been impacted, execution of a limited number of production transactions prior to commencement of full volume transaction processing and controlled execution of background / system processes. For Direct Data Changes evidence of the data values before and after the change shall be captured through printouts, screen capture or alternate objective means. The Change Builder or Change Migrator and a qualified second party will verify the data change. CM Action: Fail - Perform Corrective Action NOTE: Do not fail the implementation if there is insufficient evidence: Hold at this step, communicate and wait for sufficient evidence to be provided. When satisfied, click Success. Choose this action if the change was implemented and there are problems as a result, which do not necessitate a back-out as they can be corrected. Selecting this action move sthe RFC to Step 62 Implement Corrective Actions. Perform the corrective actions while the RFC is at this step, adding comments and further evidence as necessary. When satisfied, click Success. (In a subsequent GCM release, it is anticipated that there will be actions available to indicate both a failure requiring full back-out of the change and a failure requiring only corrective actions to be performed.) The implementation failed and the change must be backed-out from Production using the documented back-out plan. Minimum requirements for implementation Fail - Perform Corrective Action: The change has failed in production and can be corrected without first backing it out fully. CM Action: Fail - Perform Back-out NOTE: Do not fail the implementation if there is insufficient evidence: Hold at this step, communicate and wait for sufficient evidence to be provided. When satisfied, click Success. NOTE: Do not fail the implementation if the change was implemented and there are problems as a result, which do not necessitate a back-out as they can be corrected. Perform the corrective actions while the RFC is at this step, adding comments and further evidence as necessary. When satisfied, click Success. (In a subsequent GCM release, it is anticipated that there will be actions available to indicate both a failure requiring full back-out of the change and a failure requiring only corrective actions to be performed.) The implementation failed and the change must be backed-out from Production using the documented back-out plan. The RFC will move to step 24 'Implement Back-out Plans'. Minimum requirements for implementation Fail: The change has completely failed in production and cannot be easily corrected without first backing it out fully. See important notes above. 1.1.23 Step 62 - Implement Corrective Actions (CB) Request Status: 06 Implement - 60 Implement Corrective Action At workflow step 62 (Implement Corrective Action), the CB troubleshoots the issues and executes corrective actions which are detailed in the RFC. If not completed prior to the execution of the corrective action, a system impact analysis shall be completed as part of the corrective action activities. Evidence of successful corrective action is attached to the RFC, preferably in a zip file. Once completed, the RFC moves to step 25. 1.1.24 Step 24 - Implement Back-out Plans (CB) Request Status: 06 Implement - 80 Implement Back-out Plans At workflow step 24 (Implement Back-out Plans), the CB executes the back-out plan detailed in the RFC to back-out the change from the production environment. The back-out plan shall include a section for system impact analysis. If not completed prior to the execution of the back-out plan, a system impact analysis shall be completed as part of the back-out activities. Evidence of successful back-out is attached to the RFC, preferably in a zip file. CB / Cmig Action: Complete The change has been backed out from the production environment. The RFC will move to step 25 'Record Changes and Report Results'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the back-out has been successfully implemented. This functionality is provided to make the system more efficient. 1.1.25 Step 25 - Record Changes and Report Results (CB) Request Status: 07 Close Out - 10 Record Changes At workflow step 25 (Record Changes and Report Results), the CB ensures that all the details provided on the RFC are correct and that all necessary documentation is present. This includes any documentation required to close out the change that has not yet been attached, in particular completed system installation checklist(s), discrepancy reports and evidence of their close-out, as well as completion of the documentation updates identified in the Documentation / Policies and Procedures table in the DesignDevelopment section of the RFC. CB / CMig Action: Complete The change has been fully recorded and all results have been fully reported and documented. The RFC is ready for review and close-out. The RFC will move to step 26 'Review Changes'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step without going back to the CB if he/she is satisfied that all information has already been provided. This typically occurs for Minor impact RFCs or those with no additional documentation requirements, and is provided to make the system more efficient. 1.1.26 Step 26 - Review Changes (CM) Request Status: 07 Close Out - 20 Review Changes At workflow step 26 (Review Changes), the CM performs the final review of the change for close-out. He/she reviews all information on the RFC, including completed system installation checklists and discrepancy reports that he/she will ensure are closed out, and documentation/policy and procedures updates. CM Action: Approve The change and all supporting documentation have been reviewed and the RFC is approved for close-out by the CM. The RFC will move to step 27 'Closed (Success)' and the RFC is closed. CM Action: Reject Information and/or documentation required for close-out are missing or incomplete. The RFC moves back to step 25 'Record Changes and Report Results' where the CB must provide the missing or incomplete information/documentation. 1.1.27 Step 27 - Closed (Success) Request Status: Closed (Approved) At workflow step 27 'Closed (Success)' the RFC has been closed and no further updates to it are possible. No attachments or notes can be added. The RFC remains in this status until it is archived from . 1.1.28 Step 28 - Implement Change Using Standard Procedure (CB) Request Status: 06 Implement - 05 Implement Pre-authorized Change At workflow step 28 (Implement Change Using Standard Procedure), the CB executes and implements the pre-authorized change in the production environment per the referenced Work Instruction, Standard Operating Procedure or Technical Document. Objective evidence relating to the implementation of the change in Production is attached to the RFC. CB / CMig Action: Complete The change has been executed/implemented in the production environment. The RFC will move to step 25 'Record Changes and Report Results'. Note: Change Manager Authority: The CM also has authority to select Complete at this step. This allows the CM to click through this step if he/she knows that the implementation of the preauthorized change to Production has been completed. This functionality is provided to make the system more efficient. Creation, Modification of User Accounts and Passwords Standard Operating Procedure Title: Version #: Effective Date: Creation, Modification of User Accounts and Passwords 1.3 February 19, 2011 1.0 Purpose The foundation of a secure IT environment is the appropriate and timely assignment of access privileges. Changes in job responsibilities and other employee changes must take place quickly and accurately in order to make sure that each employee has the access privileges they need to perform their jobs without the exposure that could result from granting excessive privilege. Similarly, the single most important step that an employee can take to secure his/her accounts is the use of a good quality password. The purpose of this standard operating procedure (SOP) is to describe the process for the creation, modification and deletion of User Accounts and Passwords. It also provides for periodic review of the privileges and correction of any deficiencies noted. 2.0 Scope This document includes policies and procedures relating to: The management of access privileges to XXXX Interactive electronic information resources. The use of passwords. 3.0 Responsibility The Vice President of IT Operations and the Vice President of Finance and Corporate Controller (U.S.) will be responsible for assuring company compliance with this SOP. The Manager of Network Operations will be responsible for assuring the implementation of the procedures specified within this SOP. 4.0 Definitions N/A 5.0 Requirements/Policies 5.1 Requirements for User Accounts - All systems User accounts must be unique and identifiable by user. o A User Name consists of his/her first initial and last name. o If two individuals have the same first initial and last name, the middle initial will be also be utilized. Expiration Days - User Accounts, which are inactive for 6 months, will first be disabled for a month. o If no further action is necessary the account will be deleted from the security system. SOP Creation, Modification of User Accounts and Passwords Page 1 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure 5.2 Access Attempts - User Accounts will be locked out for an hour after a maximum of 6 consecutive, invalid access attempts. Requirements for Passwords - All systems Passwords must contain a minimum of 7 characters. Passwords must contain strong encryption. Passwords must contain at least 3 of the following 4 characteristics: o Numbers o Special characters o Lower case letters o Upper case letters Passwords are only valid for 45 days. The system will ensure all new passwords are different from the previous 12 passwords used for that User ID. Users will be locked out of the system for an hour after 6 unsuccessful attempts. 5.3 General Policies Access requests must originate with the User's supervisor. Access requests that meet the criteria of a Profile may be approved by the IT Network Operations Manager Out-of-Profile access requests must be approved by the IT Network Operations Manager. Access Profiles must be approved by the IT Network Operations Manager or VP IT Operations System administrator access must be approved by the IT Network Operations Manager or higher All access privileges and Profiles must be reviewed periodically. Except as approved by the IT Network Operations Manager, or higher, shared accounts are prohibited. All accounts are protected by passwords. Financial System administrator access must be approved by the Chief Financial Officer. Users are not allowed to share their user name and passwords with other users 5.4 Requirements for User Accounts User accounts must be unique and identifiable by user. o A User Name consists of his/her first initial and last name. o If two individuals have the same first initial and last name, the middle initial will be also be utilized SOP Creation, Modification of User Accounts and Passwords Page 2 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure 6.0 Procedures Creation of User Accounts and Passwords - Network Accounts Step 1 2 3 4 Action HR daily updates the spreadsheet that is stored on \\\\XXXX\\general\\us\ ochester\\general\\ HR submits a request via a form on the Intranet that submits an email request to the helpdesk. IT Helpdesk creates a ticket for the new user and adds the assignment for appropriate the Network Administrator. IT Network Administrator creates the user account and grants general network access IT Network Administrator closes their assignment Responsibility Human Resources IT Helpdesk Analyst IT Network Administrator IT Network Administrator The IT department is notified of the need for new User Accounts and Passwords through the New Hire Process within the Human Resources Department. The HR spreadsheet is stored on \\\\XXXX\\general\\us\ ochester\\general\\HRReports and an email is sent when updates to it. The task of creating a new User Account and Password is then assigned to an appropriate individual within the IT Department. If modification of an existing User Account and/or Password is necessary, the Help Desk is contacted directly by the owner of the account. Modification of User Accounts and Passwords - Network Accounts Step 1 2 3 4 Action The user's department manager notifies the helpdesk of the access request change. IT Helpdesk creates a helpdesk ticket and assigns it to a Network Administrator Network Administrator changes the requested access and notes change in helpdesk call and closes the call. Network Administrator notifies user of change in access and verifies with user SOP Creation, Modification of User Accounts and Passwords Responsibility User's Manager IT Helpdesk Analyst Network Administrator Network Administrator / Page 3 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure User If modification of an existing User Account and/or Password is necessary, the Help Desk is contacted directly by the owner of the account. If modification of an existing User Account is for more access, the manager of the effected user must make the request to the helpdesk directly. Creation & Modification of SQL User Accounts and Passwords - Financial Applications Step 1 2 Action The user's department manager notifies the helpdesk of the access request Helpdesk requests approval from Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) 3 4 Helpdesk creates an assignment for SQL DBA SQL DBA creates a SQL account for the user and goes to the Vice Presidnet of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) desktop and setups the ODBC connection with the SA password through the Application 5 Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) verifies connectivity and SQL DBA closes the ticket Responsibility User's Manager Helpdesk analyst/ Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) Helpdesk analyst SQL DBA/ Vice Presidnet of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) / SQL DBA Creation & Modification of Application User Accounts and Passwords - Financial Applications Step 1 2 Action The user's department manager notifies the Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.)via email Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) grants SOP Creation, Modification of User Accounts and Passwords Responsibility User's Manager Vice President of Finance and Page 4 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure access or assigns to a Financial Application Administrator to grant access. 3 User verifies access and emails Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) or Financial Application Administrator of acceptance. Corporate Controller (U.S.)/Financial Director (U.K.) Financial Application Administrator User Access Privilege and Profile Review - Network and Financial Applications Step 1 Action Review access Profiles, including the privileges and job functions of each Profile. Go to step 2. 2 Review each User's access privileges for appropriateness. Go to step 3. 3 Prepare list of any changes required to remediate any problems found. Go to step 4. 4 Implement changes, record changes in appropriate file, notify User and User's manager. End of procedure. SOP Creation, Modification of User Accounts and Passwords Responsibility VP of IT & Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) VP of IT & Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) VP of IT & Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) VP of IT & Vice President of Finance and Corporate Controller (U.S.)/Financial Director (U.K.) Page 5 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure SOP Creation, Modification of User Accounts and Passwords Page 6 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure 7.0 Document Approval _________________________________________ Approval by (signature) _______________ Date _________________________________________ Reviewed by (signature) _______________ Date _________________________________________ Reviewed by (signature) _______________ Date SOP Creation, Modification of User Accounts and Passwords Page 7 of 8 Version 1.3 Creation, Modification of User Accounts and Passwords Standard Operating Procedure 8.0 Version Number 1.0 1.1 Document History Effective Date Author 1.2 1.3 SOP Creation, Modification of User Accounts and Passwords Reason Original issue of SOP Update to meet SOX requirements See: track changes Yearly updates for SOX compliance: See track changes Page 8 of 8 Version 1.3 Test Matrix Number ITGC Domain 1 Change Management Control Objective System changes are approved by the appropriate level of business management prior to being made in production. Control Activity Manual or emergency modifications to systems require management review and approval in accordance with documented change control procedure. 2 Change Management Data changes are approved by the appropriate level of business management prior to being made in production. Manual or emergency modifications to data outside of application by the IT organization are authorized by appropriate business management. 3 Change Management Individuals who are responsible for coding changes do not have the ability to make changes in production. Design Assessment Auditor Pinch inspected the IT Change Management Process document (Ref.2, obtained from client IT Policies intranet site) and noted that for all systems changes, there is a 28 stage process for ensuring changes are initiated, approved, coded, tested, reviewed by sr. management, and implemented according to a standard process. This process is outlined in detail in Ref.2, but the following steps reflect the high risk areas of the process: Step 1 - Collaborate: Initial Review, Collaborate and Assess Impact Step 11 - Build Changes in Development Environment (CB) Step 12 - Review Unit Test Results (CM) Step 15 - Migrate to UAT Environment (CB) Step 16 - Validate UAT Testing & Backout Plans (CM) Steps 18/19/20/21 - IT/Business/Quality/Service Area Executive Approval to Implement (Approvers) Step 22 - Build/Migrate Changes to Production Environment (CB) 4 Access to Programs Passwords settings are designed and Data to prevent unauthorized access to systems. 5 Access to Programs Employees have their access and Data promptly removed upon notification of termination. 6 Access to Programs A process is in place to ensure and Data user access is granted only upon documented business needs. 7 Access to Programs User access privileges are and Data reviewed for appropriateness on a regular basis. Page 1 Operational Effectiveness Conclusion Testing Procedures Assessment As a 1) Determine how documented many changes were process is in made in fiscal year. place and 2) Select a designed to representative ensure sr. sample of changes. management 3) ensure each approval prior change was signed to any off by business system management prior to implementati production ons, no improvement s needed. Tested By References Reference Number Obtained from? Description Date Received Ref.1 Ref.2 Client Intranet Site Client Intranet Site IT Se