template - british columbia€¦ · web viewapp deliveries and dba deliverables updates. 1.5...

Natural Resource MinistriesInformation, Innovation and Technology

Division

NRM Transition to Operations Checklist[Project Name]

[Project Name]Ministry:

Business Sponsor:

Project Manager/Lead:

Last Updated: May 14, 2020Version: 1.5

Document: NRM_Transition_to_Operations_Checklist.docm

Transition to Operations Checklist - [Project Name]Last Saved: 2020-05-14 8:22:00 PMCreated: 2019-12-05


Division

This page is purposely left blank.



Division

Table of Contents

1.0 Version Control................................................................................................................................4

2.0 Purpose of Document.......................................................................................................................5

3.0 Scope.............................................................................................................................................5

4.0 Assumptions....................................................................................................................................5

5.0 Checklist Process/Governance............................................................................................................6

6.0 Project Transition Overview...............................................................................................................6

7.0 Transition Deliverables Inventory........................................................................................................8

8.0 Operational Subject Matter Expert Sign-off.........................................................................................10

9.0 Operational Sponsor Transition Sign-off.............................................................................................18

10.0................................................................................................................................Project Team Sign-Off18

11.0.....................................................................................Product Owner/Project Sponsor Transition Sign-off18

Appendix A – Transition Inventory Glossary..............................................................................................19

Appendix B – Procedural Instructions.......................................................................................................24

Appendix C –Operational Service Description............................................................................................28

Appendix D –Operational/Advisory Team Acronym Definition....................................................................29

Appendix E –Operational/Advisory Team Contact Information....................................................................29



Division

1.0 Version Control

Document Version Revision Date Author Change of Reference

1.0 Original Dec 5, 2019 IIT Transition

Chris Cocker /

Bogdan Bezna

Original

1.1 Corrections/ Additions

09-Dec-2019 IIT Transition – Bogdan Bezna

Definition/Inventory Updates

1.2 Corrections/ Additions

16-Dec-2019 IIT SC Secretary – Joey Lundgren

Formatting/Content Updates

1.3 Corrections/ Additions/

Published

16-Dec-2019 IIT Transition – Chris Cocker

Accept changes, update Middle-Tier team naming convention, corrected in-document links.

1.4 Additions/

Updates

14-Jan-2020 IIT Transition – Bogdan Bezna

Definition/Inventory Updates: Information Security Data Classification. App Deliveries and DBA deliverables updates.

1.5 Additions/

Updates

13-May-2020 IIT Transition –

Chris Cocker

Added Sections 6.1/6.2, appendix D, and RTFS SME review. Added RIA/FRCR to deliverables. Updated Process workflow.



Division

2.0 Purpose of DocumentThe Transition to Operations Checklist is provided to guide and document completion of key transition deliverables outlined in the Natural Resource Ministries Systems Development Lifecycle (NRM SDLC) as well as other pertinent activities and artifacts relating to a product’s successful deployment into IIT environments and operational support.

To ensure the success in transitioning applications and services into operational support, coordination is required between the project team and the IIT operational subject matter experts (SME)1 to identify transition requirements and confirm delivery.

The objective of this document is to support awareness of transition deliverables and to provide risk identification and assessment from IIT operational teams regarding any unspecified, incomplete or missing transition acceptance criteria and/or operational support requirements. Any deferred items should be included into a backlog for the product’s lifecycle beyond the project close. The recommendations outlined in this document will form the basis of product acceptance into IIT operational support.

3.0 ScopeThis checklist tracks deliverables pertaining to requirements for accepting a new/updated application(s) into IIT operational support. Deliverables that are outside of IIT operational support concerns (e.g. project management documentation/reports) are out of scope for this checklist and sign-off.

4.0 AssumptionsThis document assumes the following conditions are met:

The project has been provided with the SDLC and defined expectations based on the size/complexity of the project for the relevant deliverables.

For large/complex projects, a stabilization period is defined for the product to assess operational readiness and transition criteria acceptance prior to the project close.

1 IIT operational support/advisory team leads or delegates


https://www2.gov.bc.ca/gov/content/governments/services-for-government/policies-procedures/im-it-standards/ministry-standards/nrs-system-development-life-cycle


Division

5.0 Checklist Process/GovernanceDeliverables in Section 7.1 of this checklist are defined by operational subject matter experts (SME). They should be reviewed in the project planning phase by the project team and any additional project specific transition deliverables identified by the project team are to be outlined in Section 7.2. Checklist items are associated with the operational areas that view the deliverable as a requirement.

During the transition phase, prior to project close-out, operational SME will complete the review outlined in Section 8 to:

Validate the delivery of the identified items Outline any items that are incomplete or missing Comment on the status of the product (accepted, not accepted) outlining any

outstanding/associated risk and if necessary, mitigation strategy

Following completion of the assessment provided by the operational teams, acceptance of transition to operational support is provided by the operational support sponsors in Section 9. Final sign-off and acknowledgement of the product transition review and, if applicable, any outstanding risk is provided in Section 10 by the project team lead and Section 11 by the product owner/project sponsor. Successful completion of this checklist and review process constitutes formal acceptance of a product into IIT operational support.

See Appendix B for step-by-step instructions on completing the document.

6.0 Project Transition Overview

Complete this section to give context of the product(s) the project is transitioning into IIT operational support, including any known relationships or dependencies to other existing NRM projects as well as the targeted infrastructure (e.g. ISSS, AWS Cloud, etc.). It should speak to high-level goals and objectives to be achieved during the transition phase. Link to external sources of project data (Project Charter, etc.) as necessary.

The overview should consider the kind of transition approach taken, such as:

Big Bang – implementation happens in a single deployment Phased – implementation in phases over an extended period with multiple deployments Parallel – legacy and new system run at the same time.

o A decommission plan should be considered for legacy systems that are being replaced Combinations of the above

*Please remove this instruction text from the final document*



Division

6.1 Operational Services

The following table outlines the standard operational services involved in helping deliver the project and/or supporting project outputs as well as the operational support/advisory teams involved. This list will help define the operational scope of the project and the teams required to review transition deliverables.

See Appendix C for Operational Service definitions and see Appendix D for operational team acronym definitions.

In Scop

eStandard Operational Services

Operational Team(s)

☐ Business Application Support BSD, RTFS

☐ Application Hosting ServicesBSD, AD, AIMT, QA

☐ Database Administration BSD, DBA☐ Workstation Hardware Management – under development RTFS☐ Workstation Software Management – under development RTFS☐ Radio and Weather Station Services – under development RTFS

6.2 Additional Operational Requirements

Complete this section should any additional operational requirements from the project need to be outlined. Remove heading 6.2 if not applicable.

*Please remove this instruction text from the final document*



Division

7.0 Transition Deliverables Inventory7.1 Standard Deliverables

The following table(s) outlines deliverables that are typically considered for transition to IIT operations. See Appendix A for descriptions and interested support teams for each transition deliverable. The ‘Comments & Location’ section of the table should describe the current state of the deliverable and provide a link to its repository location where appropriate.

Note: A copy of the table below is required for each application involved in the project.

[Application Name]COMPLETED /ENABLED

TRANSITION DELIVERABLE COMMENTS & LOCATION (LINK)

Choose an item. Choose an item.Access Requirements

Choose an item. Choose an item.Architecture Diagram(s)

Choose an item. Choose an item.Data Model (Logical/Physical)

Choose an item. Choose an item.Database Capacity Plan

Choose an item. Choose an item.Database Operations Guide

Choose an item. Choose an item.Database Environment Rebuild Guide

Choose an item. Choose an item.Defect BacklogChoose an item. Choose an item.Deployment

PreparationChoose an item. Choose an item.Design

DocumentationChoose an item. Choose an item.Developer GuideChoose an item. Choose an item.External

contracts for support [in place]

Choose an item. Choose an item.Financial Risk and Control Review

Choose an item. Choose an item.Incident Management Process

Choose an item. Choose an item.Information Security Classification of Data

Choose an item. Choose an item.IRS UpdatesChoose an item. Choose an



Division


TRANSITION DELIVERABLE COMMENTS & LOCATION (LINK)

item.Licensing/Hardware/Software – transfer existing & renewal plan

Choose an item. Choose an item.Network Diagrams

Choose an item. Choose an item.Operations Manual

Choose an item. Choose an item.Privacy Impact Assessment (PIA)

Choose an item. Choose an item.Records Impact Analysis (RIA)

Choose an item. Choose an item.Requirements Documentation

Choose an item. Choose an item.Resourcing Readiness

Choose an item. Choose an item.Role Based Access Control Definitions

Choose an item. Choose an item.Security Threat and Risk Assessment (STRA)

Choose an item. Choose an item.TrainingChoose an item. Choose an item.Transfer of

testing documentation and artefacts

Choose an item. Choose an item.User Acceptance Testing Sign-Off

Choose an item. Choose an item.Vulnerability Scan

7.2 Additional/Project Specific Deliverables

The following table(s) lists any project specific deliverables key to the transition phase and outlines the operational support area(s) that would consume the specified deliverable. A copy of the table below is required for each application involved in the project that has project specific transition deliverables.


TRANSITION DELIVERABLE

DESCRIPTION OPERATIONAL SUPPORT TEAM(S)

COMMENTS & LOCATION (LINK)

Choose an item. Choose an item.




Division



Division

8.0 Operational Subject Matter Expert Sign-offThis section is to be completed by the IIT Operations/Advisory teams. For each item, please consider if it has been delivered/enabled appropriately for your team. Comments should speak to current state and any recommendations, residual risks and workarounds/risk mitigation strategy. Deliverables marked not accepted require a comment.

8.1 Information Security:

Team Review Applicable: Choose an item.Choose an item.Team

Lead/Representative:Date: Click or tap to enter a date.

DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSInformation Security Classification of Data


Security Threat and Risk Assessment (STRA)


Vulnerability Scan Choose an item. Choose an item.Additional Comments:

8.2 Information Privacy:



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSPrivacy Impact Assessment (PIA) Choose an item. Choose an item.Additional Comments:



Division

8.3 Radio, Technology & Field Services (RTFS):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Architecture Diagram(s) Choose an item. Choose an item.Deployment Preparation Choose an item. Choose an item.Design Documentation Choose an item. Choose an item.Developer Guide Choose an item. Choose an item.Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Network Diagrams Choose an item. Choose an item.Operations Manual Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

8.4 NRS Business Service Desk – Tier 1 Operational Support (BSD):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.External contracts for support [in place]


Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Licensing/Hardware/Software – transfer existing & renewal plan


Operations Manual Choose an item. Choose an item.

Resourcing Readiness Choose an item. Choose an item.

Training Choose an item. Choose an item.

Project Specific Deliverables Choose an item. Choose an item.

Additional Comments:



Division

8.5 Maintenance & Support - Tier 2 Operational Support (MaS):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Architecture Diagram(s) Choose an item. Choose an item.Deployment Preparation Choose an item. Choose an item.Design Documentation Choose an item. Choose an item.Developer Guide Choose an item. Choose an item.Defect Backlog Choose an item. Choose an item.Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Network Diagrams Choose an item. Choose an item.Operations Manual Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

8.6 Application Deliveries - Tier 3 Operational Support (AD):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Architecture Diagram(s) Choose an item. Choose an item.Deployment Preparation Choose an item. Choose an item.Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Network Diagrams Choose an item. Choose an item.Operations Manual Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

8.7 Application Infrastructure & Middle-Tier - Tier 3 Operational Support (AIMT):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Architecture Diagram(s) Choose an item. Choose an item.Deployment Preparation Choose an item. Choose an item.Design Documentation Choose an item. Choose an item.Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Network Diagrams Choose an item. Choose an item.Operations Manual Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

8.8 Database Administration – Tier 3 Operational Support (DBA):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Architecture Diagram(s) Choose an item. Choose an item.Deployment Preparation Choose an item. Choose an item.Design Documentation Choose an item. Choose an item.Incident Management Process Choose an item. Choose an item.CMDB/IRS Updates Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Database Capacity Plan Choose an item. Choose an item.Data Model (Logical/Physical) Choose an item. Choose an item.Database Environment Rebuild Guide


Database Operations Guide Choose an item. Choose an item.Role Based Access Control Definitions


Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

8.9 Quality Assurance & Testing (QA):



DELIVERABLE ACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess Requirements Choose an item. Choose an item.Defect Backlog Choose an item. Choose an item.Design Documentation Choose an item. Choose an item.Requirements Documentation Choose an item. Choose an item.Resourcing Readiness Choose an item. Choose an item.Training Choose an item. Choose an item.Transfer of testing documentation and artefacts


User Acceptance Testing Sign-Off


Project Specific Deliverables Choose an item. Choose an item.Additional Comments:



Division

9.0 Operational Sponsor Transition Sign-off

NAME - ROLE

ACCEPTED

(YES/NO) COMMENTS DATE FUNCTION REPRESENTED

Pete Walter, Director Business Service Desk & Product Transition

Choose an item.

Choose an item Click or tap to enter a date.

Error: Reference source not found

Tier 1 & Tier 2 Operational Support: Error: Reference source not foundMaintenance & Support.

Adam Dewey, DirectorInfrastructure Services

Choose an item.


Tier 3 Operational Support: Error: Reference source notfoundError: Reference source notfound, Error: Reference source notfoundies, Error: Reference source notfound, QA

Joel Murphy, DirectorRadio, Technology & Field Services

Choose an item.

Choose an item. Click or tap to enter a date.

Radio, Technology & Field Services

10.0Project Team Sign-Off

NAME - ROLE

APPROVED


[PM/ AEA/ MaS/ VENDOR LEAD]

Choose an item.


Project Team

11.0Product Owner/Project Sponsor Transition Sign-off



Division

NAME - ROLE

APPROVED


[PRODUCT OWNER/ SPONSOR]

Choose an item.


Business Area



Division

Appendix A – Transition Inventory GlossaryThe following glossary outlines transition deliverables typically required by operational teams as outlined in Section 6 - Transition Deliverables Inventory. Standards, guidelines and templates that may apply to certain deliverables can be found on the NRS Standards Inventory webpage.

See Appendix D for operational team acronym definitions.

Deliverable DescriptionOperational

Team(s)Access Requirements: Access for all support team members to necessary tools/sites such

as: Jira Project Application/infrastructure (servers) Code Repository Automation tools Application id’s/users SiteMinder/profile info Password pass-off (completed) Access management plan/documentation (who has access

where)

BSD, MaS,AD, DBA, AIMT, QA, RTFS

Architecture Diagram(s) Architectural diagrams show the relationship and/or interactions between different software and/or hardware components.

MaS, AD, DBA, AIMT, RTFS

Data Model (Logical/Physical)

Data Modeling aims to establish the entities, their attributes, and their relationships. Logical data model defines the structure of the data elements and set the relationships between them. Physical Data Model describes the database specific implementation of the data model.

DBA

Database Capacity Plan This plan should consider the following: Initial data size, Expected data growth, Backup requirements, Archiving Requirements, Data Classification, Data Replication (Warehousing), and Data Retention Policy.

DBA

Database Operations Guide

This guide should consider the following: Data Refresh cycles [identified], Scheduled DB jobs/maintenance, and Database deployment/refresh procedures.

DBA

Database Environment Rebuild Guide

Create/update the procedures and SQL scripts for recreating the application database. This guide can be used to rebuild an environment if the database is lost and there is no backup.

DBA

Defect Backlog Location of identified backlog of defect/bug lists – defining what has been deferred/addressed/accepted for the product.

QA, MaS

Deployment Preparation As per TRCM Process which should include:-RFC/RFD-Deployment package-Deployment walkthrough

MaS, AD, DBA,AIMT, RTFS


https://nrm.sp.gov.bc.ca/sites/CSNR/TCRMC/Shared%20Documents/TCRM%20Process%20Guide.pdf

https://www2.gov.bc.ca/gov/content/governments/services-for-government/policies-procedures/im-it-standards/ministry-standards/nrs-system-development-life-cycle/nrs-standards-inventory


Division


Team(s)Design Documentation Design documentation includes: wire-frames/screen mock-ups,

individual modules/components, and what the responsibilities, functions of the modules and classes are. Also, what they can/can’t do and what design patterns can be used.

MaS, AD, DBA, AIMT, QA, RTFS

Developer Guide A developer guide provides insight into developer on-boarding, API references, and other technical components. The guide should be useful to developers for continuous development as well as for troubleshooting purposes.

MaS, RTFS

External contracts for support [in place]

Any support agreements to external parties are completed and in place.

BSD

Financial Risk and Control Review

A Financial Risk and Control Review must be conducted for any system that records financial transactions. Mark this as ‘Not Applicable’ for systems that do not.

If the application will contain financial transactions, a Financial Risk and Controls Review must be conducted which requires involvement of Ministry of Finance resources and verifies that Chapter 13 of core policy is being followed.

Tracked for completion, but not reviewed by operational teams.

Incident Management Process

Incident Management process has been mapped for the application. Ideally, this should fit the current IIT standard (contact the Business Service Desk team if a copy of this standard is required).

Any new process/procedures (break/fix, incident, problem, etc.) need to be identified and migrated into the current process as part of the transition to operations.

Consider the following items: Incident workflow & incident logging requirements Application criticality assessment Vendor requirements/responsibilities Security incident management

BSD, MaS, AD, DBA, AIMT, RTFS

Information Security Classification of Data

The Information Security Classification of Data ensures government information and systems are protected in relation to value, sensitivity, and public need. The classification of the data is completed by the business units and stored and tracked by the Information Security team. This information, for example, may be used as part of a data move (PROD to DEV) in order to know what data needs to be sanitized.

A completed Information Security Classification of Data template (available from the IIT Information and Security team) constitutes the completion of this deliverable.

Information Security


https://apps.nrs.gov.bc.ca/int/confluence/display/MAS/Incident+Management+Process


Division


Team(s)CMDB/IRS Updates Updates to any relevant CMDB. All IIT managed applications

should be catalogued in the Infrastructure Reporting System (IRS), the inventory management tool used by IIT to keep track of application dependencies and related infrastructure information. All information should be correct and up-to-date.

IRS is used by support teams to ensure: Key Contacts are communicated to for application changes:

(Vendor, Data custodian, App owner, stakeholders(s) Identifying integration points and identifying dependent

applications: Servers, Environments (INT, TEST, PROD) Any Technical Change freeze periods are respected

(Critical/Dark Periods)


Licensing/Hardware/Software – transfer existing & renewal plan

Ownership of any licenses, hardware or software has been transferred to IIT (IMIT Financial and Contract Management), the length of validity has been identified and a plan is in place for upcoming renewals.

BSD

Network Diagrams Firewall information, proxy/reverse proxy, ports, protocols MaS, AD, AIMT, RTFS

Operations Manual Technical Documentation for troubleshooting, FAQ, known issues and exceptions, maintenance activities (security certificate renewals, etc.), application/error log locations, scheduled jobs (cron, etc.).


Privacy Impact Assessment (PIA)

A PIA is created to ensure compliance with the Freedom of Information and Protection of Privacy Act when collecting, using or disclosing personal information.

A privacy impact assessment must be completed for any new or changes to applications. The initial assessment must be completed for all initiatives to determine whether personal information is involved.

Information Privacy

Records Impact Analysis (RIA)

A Records Impact Analysis (RIA) provides a structured manner of identifying the records that are used as inputs to the system and records and reports generated from the system.

Additional information and templates are available on the NRM SDLC.

Tracked for completion, but not reviewed by operational teams.

Requirements Documentation

Business Requirements, Functional Requirements (include storage requirements and tier of SAN), Non-Functional Requirements.

Link to Business Requirements Document, Software Requirements Specification Document and/or User Stories.

MaS, AD, DBA, AIMT, QA, RTFS


https://www2.gov.bc.ca/gov/content/governments/services-for-government/policies-procedures/im-it-standards/ministry-standards/nrs-system-development-life-cycle/deploy-phase

https://www2.gov.bc.ca/gov/content/governments/services-for-government/policies-procedures/im-it-standards/ministry-standards/nrs-system-development-life-cycle/deploy-phase

http://www.cio.gov.bc.ca/cio/priv_leg/foippa/pia/pia_index.page

http://www.cio.gov.bc.ca/cio/priv_leg/foippa/pia/pia_index.page

https://a100.gov.bc.ca/int/irs/


Division


Team(s)Resourcing Readiness Any additional resourcing requirements to implement operational

support are in place. Link to resource plan.BSD, MaS, AD, DBA, AIMT, QA, RTFS

Role Based Access Control Definitions

Define access privileges assigned to roles and the user types that should be assigned these roles.

DBA

Security Threat and Risk Assessment (STRA)

A STRA must be conducted when developing, implementing major changes to, or acquiring an information system.

The Security Threat and Risk Assessment is a component of overall Risk Management. The STRA pertains to information, whereas the Risk Assessment covers all aspects of a project including equipment, funding, resources, etc.

A signed Statement of Acceptable Risk (SOAR) constitutes the completion of an STRA. The SOAR documents all risks identified in the STRA, their ratings and planned treatment action, and that appropriate reviews and acceptance has occurred.


Training Training on the product, procedures & technology completed for all operational support areas.

Provide a link to training plan and any training documentation.

BSD, MaS, AD, DBA, AIMT, QA, RTFS

Transfer of testing documentation and artefacts

Including: Test Plan Test Strategy Requirement Traceability Report Software Test Scenarios and Test Cases Test Data Defect Report/Bug Report Test Metrics Test Execution Report Test Scripts (automation) Test Trace-ability Matrix Configuration & Installation Guide User Guide Test Execution Report Bugs/Defects Report Release Notes Final (Test Project Closure) Test Status report

QA

User Acceptance Testing Sign-Off

Client sign-off accepting User testing as being completed and accepting any outstanding defects as being deferred.

QA


https://www2.gov.bc.ca/gov/content/governments/services-for-government/information-management-technology/information-security/security-threat-and-risk-assessment

https://www2.gov.bc.ca/gov/content/governments/services-for-government/information-management-technology/information-security/security-threat-and-risk-assessment


Division


Team(s)Vulnerability Scan Vulnerability scans (finds vulnerabilities in your web application

dynamically):

Required by policy (Information Security Policy) and standards (Security Standards for Web Development and Deployment)

Scans are to happen anytime there is significant change (OCIO defines significant as “requires a contractor/skilled employee to develop the change”)

Scans should happen annually even if no changes have been done

Remediation timelines for found vulnerabilities should be based off risk (higher risk should equate to faster remediation)

Recommend vulnerabilities be ranked based off CVSS score (Common Vulnerability Scoring System)

Consideration of risk should include other applications if in a shared environment (i.e. your application is low sensitivity, but you share the environment with a highly sensitive application)

CVSS scores of 9 to 10 (critical) are expected to be remediated immediately




Division

Appendix B – Procedural Instructions

In this appendix, the procedure for completing the checklist, operational team review and sponsor sign-off is outlined. A workflow diagram is provided as are step-by-step procedural instructions.

Workflow:In Figure 1 below, the high-level workflow outlines a visual representation for the intended process for completing this document and achieving review and sign-off from all stakeholders.

Figure 1: Transition to Operations Workflow



Division

Transition to Operations Checklist Procedure:

Project Team Process:

1. Update the document metadata from the template: a. Rename this template to include the application name: Transition to Operations

Checklist – [PROJECT NAME].b. Update the fields on the title page and document footer (Application Name, Ministry

Name, PM/Lead name, Business Sponsor Name).c. Update Section 10 with the PM/Project Lead information.d. Update Section 11 with the Product Owner/Project Sponsor information.

2. As project planning progresses, complete the Transition Overview (Section 6), identify the operational service requirements (Section 6.1), review the Transition Deliverables Inventory (Section 7) and determine what deliverables are/are not applicable for the project.

a. For non-applicable deliverable, update the Section 7.1 deliverable(s) status’ with ‘Not Applicable’. Enter a comment to provide support for this decision.

Example:

Completed /Enabled

Transition Deliverable Comments & Location (Link)

Not Applicable Choose an item.Database Operations Guide

Project has no database dependencies.

* Tip: Contact the operational/advisory teams to assist with questions regarding specific deliverable(s)

3. Update Section 7.2 with any project specific deliverables not already included in the inventory outlined in Section 7.1.

4. As the project work progresses: a. Update the checklist for each deliverable:

i. Update the status field with Yes/Partial/No as applicable.ii. If applicable, provide a link to the artefact’s repository location (or alternatively

provide a comment on status or location).iii. Provide any additional comments that may help guide operations teams in

reviewing the deliverable.iv. Add and update any other project specific deliverables as required to Section

7.2 and update the fields as described above in steps a, b and c.b. Update Section 6 as required.



Division

5. Prior to anticipated go-live/production deployment (ideally 2-4 weeks), collaborate with the operational/advisory teams identified in Appendix E for completion of their review.

6. Be prepared and available to answer questions that may arise during the review and sign-off process and aggregate the reviews into a master document when completed.

7. Once all operations teams have completed their review, collaborate with the operational sponsors identified in Appendix E for their review.

* Tip: Reviews can be assigning to teams/assignees using IMB Jira tasks. SharePoint or other collaboration tools can also be used as appropriate for teams/sponsors to add their reviews.

8. Complete the project team sign-off in Section 10 and coordinate with the Product Owner/Project Sponsor for the sign-off in Section 11.

9. Once final sign-off is completed, notify stakeholders as appropriate and archive this document along with all other project documentation.

IIT Operational/Advisory SME Review

This section is to be completed by the Operation Support Teams identified in Section 8.

1. On receiving the assignment to complete the transition review, a team member will action the team lead to complete or delegate review of the checklist document per the defined action items found in Section 5 (Checklist Process & Governance):

2. The assigned reviewer will then:a. Update the relevant section on behalf of your area in Section 8:

i. Confirm review is applicable for your team (review Transition Overview in Section 6 and Section 6.1 if necessary). Provide a comment if review is not necessary.

ii. Add their name.iii. Add the current date.iv. If review is required, for each item, confirm if it is an acceptable state for your

team/area and add appropriate comments regarding any residual risk, recommended next steps and/or workarounds/mitigation strategies.

v. Add any additional comments at the bottom of the section.b. Notify the project team that the review has been completed on behalf of your

team/area and return the completed document. 3. The team/reviewer should be prepared and available to answer questions and escalate issues

back to the project team that may arise during the sign-off process.



Division

Operational Sponsors Sign-Off:

Once all operational SMEs have completed their assessments, the project team will notify the operational sponsors identified in Section 9 to:

1. Review the operational SME assessments from their area of responsibility.2. Follow up with the SME should any additional questions or clarification be required. 3. Provide Yes/No for acceptance of transition of the outlined applications into IIT support.4. Provide any additional comments that should be documented as part of the transition

acceptance/rejection.5. Notify the project team that your sign-off has been completed.

Product Owner/Project Sponsors Sign-Off:

Following Operational Sponsor sign-off, the project team will coordinate with the product owner/project sponsor to:

1. Review all assessments as necessary.2. In Section 10 and Section 11:

a. Provide Yes/No for confirmation of review/acceptance of the transition to IIT operations and acknowledgement of any identified risks.

b. Provide any additional comments that should be documented as part of the transition.



Division

Appendix C –Operational Service Description

Standard Operational Services DescriptionBusiness Application Support Application support calls are directed to the IIT Business Application

Support Desk. Requests will be triaged and potentially escalated to other support teams (internal and external to IIT) as needed.

Application Hosting Services Applications will be deployed and hosted on IIT managed infrastructure (e.g. ISSS) and supported by the various tiers of IIT operational support/advisory teams.

Database Administration Project output(s) include a database component (e.g. database change, deployment, data insertion, data refresh).

Workstation Hardware Management

Includes: Workstation/Printer/Plotter/MFD Deployments Testing and Packaging Special Hardware Requests Workstation Refreshes Hardware Inventory Mobile Training Lab IT Asset Disposal Management Workstation Test Environment

Workstation Software Management

Includes: Software License Management Special Software Requests Testing and Packaging One-off Software Installs Software Inventory

Radio and Weather Station Services

Includes: Natural Resource Sector (NRS) Radio Repeater System BC Wildfire Service Fire Weather Stations (FWx) Handheld portable radios Mobile vehicle radios Radio accessories Radio base stations Portable Fire Repeaters Fire Quick Deploy Weather Stations Fire Camp radio communications Radio Over IP (ROIP) Vehicle GPS tracking units NRS Radio Training



Division

Appendix D –Operational/Advisory Team Acronym Definition

Operational Support/Advisory team acronyms used in this document are defined in the table below.

Acronym Operational TeamAD Application Deliveries - Tier 3 Operational SupportAIMT Application Infrastructure & Middle-Tier - Tier 3 Operational SupportBSD Natural Resource Sector Business Service Desk – Tier 1 Operational SupportDBA Database Administration – Tier 3 Operational SupportMaS Maintenance & Support - Tier 2 Operational SupportQA Quality Assurance & TestingRTFS Radio, Technology & Field Services

Appendix E –Operational/Advisory Team Contact Information

Operational Support/Advisory teams and sponsors are outlined in the tables below.

Note, this list is up to date at time of publication, roles and contact information are subject to change.

Team Team Lead(s) Team ContactAD Andreas Wilson [email protected] Lucas Montebello [email protected] James Pinske [email protected] Raja Pethanasamy [email protected] Matt Brandwood/

Stuart [email protected]

QA Lizette Monteiro [email protected] Dan Stoelwinder/

Ewon Rose/Blaine Anderson

[email protected]

Security Eric Valikoski [email protected] Eileen Padgett [email protected]

Operational Sponsor ContactPete Walter, Director Business Service Desk & Product Transition

[email protected]

Adam Dewey, DirectorInfrastructure Services

[email protected]

Joel Murphy, Director [email protected]



Division

Radio, Technology & Field Services
