Module 8: I2R Change Control 1.1 Gatekeeper Audit

1. Module 8:I2R Change Control 1.1Gatekeeper Audit April 2007

2. Change Control Training Agenda This training will cover nine short modules on the New Change Control Process:

3. Program Change Control Objectives • The Program Change Control (PCC) audit process helps mitigate the following risks that can affect the quality, performance, or integrity of Cisco’s systems: • Unauthorized changes are promoted to production • Untested software is promoted to production By the end of this module, you will learn about: • Program Change Control (PCC) • SOX Testing Requirements • Gatekeeper Role and Responsibility • Gatekeeper Cheat Sheet: What a Gatekeeper looks for • Gatekeeper Engagement Process

4. Program Change Control Risk Management The following controls were implemented to mitigate risks:

5. REQUESTS Change Types Classifications of Change Types • All change requests for information systems must be classified into change types. In addition, the association of change requestswith change types is mandatory for all I2R system components to: • Enable consistent and objective identification of appropriate tests and test documentation for each change request • Enable consistent testing and test documentation for information system changes based on change type

6. Change Types • Each change request must be classified into one of the following change types: • Aesthetic Application User Interface GUI change • Application Code Changes • System Configurations and Setups • Business Configurations and Setups • Other Technical System Level and Performance Change • Data Changes • Application Changes That Impact Interface

7. Classification of Test Level All change requests and their associated testing must be categorized into defined test level. In addition, association of change requests with test level is mandated for all I2R system components to: • Provide external auditors with consistent test documentation • Ensure that each information system is testing similar changes in a similar fashion throughout Cisco Test Level

8. Classifications for Test Level • Each change request requires a minimum test level: • Validation Testing • IT Acceptance Testing • Business Acceptance Testing ValidationTesting ITAcceptance BusinessAcceptance Test Level

9. Minimum Level of Testing Matrix The below matrix shows the test level that your change type requires: Lowest Level Highest Level For example… if your change request is classified as an “Application Code Change”, you are required to perform “Business Acceptance Testing”. Your test documentation and tester must adhere to guidelines defined for “Business Acceptance Testing”.

10. Gatekeeper Role and Responsibilities The Gatekeeper serves as an internal auditor to ensure that I2R IT complies to and passes external audits. Gatekeeper’s responsibilities include: • Accountability for ensuring changes migrated to production environment adhere to PCC compliance requirements • Enforcing controls to ensure that unauthorized and untested changes do not get into production • Providing Kintana approval to authorize push of code to production

11. Not Role and Responsibilities of the Gatekeeper Below are notroles and responsibilities of a gatekeeper: • Recommending scenarios and test cases for your change request • Preventing defects for your change request • Authorizing production implementation and deployments unless CCB has provided production approval • Exception: Active emergency P1/P2 alliance cases • Chasing after you to provide Kintana approval

12. Gatekeeper Cheat Sheet • Before approving a change request for production, the Gatekeeper must verify that all necessary compliance items are checked off the list: • One PCC ITG Request is appropriately created with all relevant details complete • Change description in One PCC ITG request is understandable to third parties • Quality Center Requirement is associated with One PCC ITG request and completed test documentation is available • Test documentation adheres to level of test requirements based on the change request’s change type • Test executioner in Quality Center is appropriate according to the level of test requirement • One PCC ITG Request number and associated Kintana package are found in scope document or build list • The individual that implemented the change (creator/developer of Kintana package) is not the same as the individual that tested the change (tester in Quality Center) • Valid and approved One PCC ITG request number is referenced in the Kintana package • Evidence of business delegation and sign-off for IT to perform testing on behalf of the business is attached to One PCC ITG request or updated in the request notes • Justification and business sign-off as to why code with failed test steps or failed test cases should still be deployed to production is attached to One PCC ITG request or updated in the request notes

13. One PCC and Application Configurations • There must be evidence of approval for application configuration work to proceed. The change requester must ensure that Change Control Board (CCB) production approval is obtained for application configuration deployment requests. • If the application configuration work is part of a project request or tactical request, make sure that application configuration QC Defect Issue number references a parent One PCC ITG request number • The parent change request must have created a One PCC ITG request and pass PCC audits. Else, the dependent application configuration request cannot be deployed to production • Approved parent One PCC ITG request will be used for deployment of the dependent application configuration setup

14. One PCC and Cross Functional Patches The CA-IT patch lead is only required to create One PCC ITG Request for all patches going into a planned release. The Functional Track is responsible for: • Ensuring that the Gatekeeper has been given the QA sign-off evidence that the patching has resolved issues, enhanced functionality, or did not break existing functionality • Attaching evidence in One PCC ITG request or updating the request notes • Associating Quality Center Requirement with One PCC ITG request and providing completed test documentation QA

15. How to Request a Gatekeeper Audit • To request a gatekeeper audit, the change requester must follow these steps: • Upon completion of the last test cycle, send an email to I2R-Gatekeepers@cisco.com. For details to include in the email, see detailed gatekeeper audit email info • See standard release exception production approval cut-off time or non-standard release exception production approval cut-off time for Gatekeeper review and approval turnaround expectations • During Release planning and scope identification, the Release Manager schedules a meeting with the Gatekeepers

16. Planned Release Production Approval Flow

17. Release Exception Production Approval Flow

18. Emergency Bug Fix Production Approval Flow

19. Notes Quarterly vs. Monthly Release Test Cycles • Quarterly and Monthly releases have different test cycles. To ensure that a change request is included in a release, the following must be confirmed: • Quarterly Releases – Release Manager must end the last test cycle 2 - 3 weeks before the Readiness Review • Monthly Releases – Release Manager must end the last test cycle 1 week before the go-live date • The change requester is responsible for ensuring that all cut-off times are met • The change requester must adhere to Gatekeeper engagement procedures • If the change request misses the intended deployment window, the change requestor must re-seek CCB approval for deployment in another deployment window If you do not adhere to the Gatekeeper engagement procedure, your request will not be deployed to production

20. Emergency Bug Fix Deployment • Since Emergency Bug Fix (EBF) often requires immediate deployment without adequate time to go through the regular approval cycle, it has slightly different requirements outlined below: • EBF deployment is only available for active P1/P2 alliance case • Requires Gatekeeper approval based on verbal certification • Requires post deployment Change Control Board (CCB) review of the change request • Requires post deployment CCB approval documented in change request notes • Requires change requester to provide Gatekeeper with completed PCC template and relevant test case documentation (in Quality Center) no later than 24 hours after the change was deployed into production

21. PCC Download and Upload Directories for EBF • For an EBF, download PCC template: • https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId=10871606&objAction=Open • Remember to follow instructions in PCC template to… • Adhere to file naming conventions • Link completed PCC template to the One PCC ITG request number • Completed PCC documents can be uploaded to:

22. Module 8: Quiz • 1. A Gatekeeper does not do what? • A. Serves as an internal auditor • B. Prevents defects • C. Recommends test cases and test case scenarios • D. Verifies that implementer of the change is not the same as the tester for the change • 2. What is the total number of Gatekeeper engagement processes? • A. 1 • B. 2 • C. 3 • D. 4

23. Module 8: Quiz Cont. • 3. Evidence of testing should not look like what? • A. Only state an approval of testing completion • B. Provide who, what, when, how in the test case • C. Show test case with results recorded • D. Show failed test steps/cases without justification for code push • What is the minimum level of testing required by SOX for System Configuration and Setup change type? • A. Validation Testing • B. IT Acceptance Testing • C. Business Acceptance Testing • D. Validating Testing and Business Acceptance Testing

24. Gatekeeper Audit Summary As we conclude this module, we hope that you have a thorough understanding of the following three key points: • The purpose of the Program Change Control (PCC) process is to audit and ensure that unauthorized and untested software are not put into production • The Gatekeeper does not recommend testing scenarios for your change request or prevent defects. However, the Gatekeeper might indirectly reduce the chances of defects because of Project Change Control (PCC) audits • If you do not adhere to the Gatekeeper engagement procedure, your request will not be deployed to production

25. Gatekeeper Audit Backup Slides

26. 1. Select the Request option under the create menu 2. Select the request type from the drop down menu 3. Fill in all required information denoted by a red asterisk Creation of a Request

27. Testing Information Associating a Test Case to a Requirement • Test cases need to be associated to their corresponding requirement so that testing information will flow to ITG and be visible for approvals • The test cases must be associated to the systematically generated requirement in order to be associated to the correct request in ITG. ITG Request

28. Click on the Select Reqs button Associating a Test Case to a Requirement • On the Reqs Coverage tab • Once you select the Reqs Coverage button the Requirements tree will appear on the right side of the screen

29. 1. Highlight the systematically generated requirement that the test case needs to be associated to Associating a Test Case to a Requirement 2. Click the Green Arrow to associate the Requirement

30. Associating a Kintana Package to an ITG Request • To associate a Kintana Package to the corresponding One PCC ITG request, the One PCC Request ID field located on the User Data tab of the Kintana package must be populated with the One PCC ITG request number • Prior to the package’s deployment into a test environment, the Kintana workflow will automatically perform the validation to ensure that the package’s associated One PCC ITG request has been initially approved by CA CCB • Prior to the package’s deployment into production, the Kintana workflow will automatically perform the validation to ensure the One PCC ITG request has been finally approved by CA CCB

31. Associating a Kintana Package to an ITG Request In the One PCC ITG Request ID field on the User Data tab of the Kintana Package click the Table Icon to display all the One PCC ITG requests that the Kintana Package can be associated to. The pick list shows all ITG requests that have been approved and are not in a closed status

32. PCC Control # 1

33. PCC Control # 2 Back to slide #4: PCC Risk Management

34. PCC Control # 3 Back to slide #4: PCC Risk Management

35. PCC Control # 4 Back to slide #4: PCC Risk Management

36. PCC Control # 5 Back to slide #4: PCC Risk Management

37. Change Type - Aesthetic Application User Interface GUI Change Back to slide #6: Change Types

38. Change Type - Application Code Changes Back to slide #6: Change Types

39. Change Type - System Configurations and Setups Back to slide #6: Change Types

40. Change Type - Business Configurations and Setups Back to slide #6: Change Types

41. Change Type - Other Technical System Level and Performance Changes Back to slide #6: Change Types

42. Change Type - Data Changes Back to slide #6: Change Types

43. Change Type - Application Changes That Impact Interface Back to slide #6: Change Types

44. Test Level – Validation Testing Back to slide #8: Classifications for Test Level

45. Test Level – IT Acceptance Testing Back to slide #8: Classifications for Test Level

46. Test Level – Business Acceptance Testing Back to slide #8: Classifications for Test Level

47. Detailed Gatekeeper Audit Email Info • To request a gatekeeper audit, the change requestor can send an email to I2R-Gatekeepers@cisco.com with the information below: Email Subject: • Release Exception Audit for <yourOne PCC ITG request number> Go-Live < yourintended go-live date> or • <Month + Year> Release Audit for <yourOne PCC ITG request number> Email Body: • One PCC ITG Request number • Contact person for One PCC ITG request (for e.g. IT PM) • Intended go-live date Back to slide #16: How to Request a Gatekeeper Audit

48. Referencing Change Request to Kintana Package Kintana package description must be named as follows: <Release Month + Release Year> + Release + <rest of your package description information> <Release Exception> + <rest of your package description information> December 2007 Release - This is a description of my package Release Exception - This is a description of my package In the User Data area for the Kintana package, the developer must reference One PCC ITG Request number in One PCC Request ID field Back to slide #12: Gatekeeper Cheat Sheet

49. Release Exception – Standard Production Approval Cutoff Time Back to slide #16: How to Request a Gatekeeper Audit

50. Release Exception – Non-Standard Production Approval Cutoff Time Back to slide #16: How to Request a Gatekeeper Audit