|
|
| Line 1: |
Line 1: |
| | | | |
| − | Version Date Principal Changes
| |
| − |
| |
| − | V4: 2020-10-28 Collapsed Appendices B and C into X. Sections have been removed to be posted as separate pages.
| |
| − |
| |
| − | V3: 2020-01-14 Incorporated feedback from departments and SSC.
| |
| − |
| |
| − | V2: 2019-09-30 Feedback from GC enterprise publish on GCcollab
| |
| − |
| |
| − | V1: 2019-09-16 Initial Draft, converted from ITPIN
| |
| − |
| |
| − | Appendix X: Standard on At-Risk Information Technology (IT)
| |
| − |
| |
| − | A.1 Effective date
| |
| − |
| |
| − | A.1.1 This standard takes effect on April 1, 202X.
| |
| − |
| |
| − | A.1.2 Departments must implement section A.2.2.6 by April 1, 202X.
| |
| − |
| |
| − |
| |
| − | A.2 Standards
| |
| − | Technology Management
| |
| − | A.2.1 This standard provides details on the requirements set out in section 4.4.3.16 and section 4.4.2.2 of the Directive on Service and Digital.
| |
| − |
| |
| − |
| |
| − | A.2.2 Departmental Chief Information Officers (CIO) must:
| |
| − |
| |
| − |
| |
| − | A.2.2.1 Update and keep departmental business applications current, such that they have an Aging IT assessment value of ‘minimal attention required’, as recorded in the TBS Application Portfolio Management (APM) tool.
| |
| − |
| |
| − |
| |
| − | A.2.2.2 Identify the technology version state as either current, supported, future, or unsupported for each business application and other technology which the department manages.
| |
| − |
| |
| − |
| |
| − | A.2.2.2.1 Departmental business application versions are assessed based on their departmental technology roadmaps.
| |
| − |
| |
| − |
| |
| − | A.2.2.2.2 Assess applications composed of multiple technologies based on the oldest component in their technology stack to determine the version of a technology.
| |
| − |
| |
| − |
| |
| − | A.2.2.3 Apply major and minor updates and keep technologies patched and current while:
| |
| − |
| |
| − |
| |
| − | A.2.2.3.1 Prioritizing critical and major updates per the GC Patch Management Guidance.
| |
| − |
| |
| − |
| |
| − | A.2.2.3.2 Following the departmentally prepared and approved patch management plan.
| |
| − |
| |
| − |
| |
| − | IT Progress Reporting
| |
| − |
| |
| − | A.2.2.4 Ensure that the technology version field in application portfolio management (APM) reporting for any departmental business applications is complete and accurate.
| |
| − |
| |
| − |
| |
| − | A.2.2.5 Complete for inclusion in the departmental plan for the integrated management of service, information, data, IT, and cyber security:
| |
| − |
| |
| − |
| |
| − | A.2.2.5.1 a migration activity report for technologies that are no longer a current version;
| |
| − |
| |
| − |
| |
| − | A.2.2.5.2 a rationalization report which identifies opportunities for the department to leverage common departmental or enterprise architectures and to reduce the overall number of departmental platforms; and
| |
| − |
| |
| − | A.2.2.5.3 the departmental patch management plan.
| |
| − |
| |
| − |
| |
| − | Use of Unsupported Technologies
| |
| − |
| |
| − |
| |
| − | A.2.2.6 Prohibit the use of unsupported technologies and the technologies listed on the Deprecated Government of Canada Technologies page.
| |
| − |
| |
| − |
| |
| − |
| |
| − | Definitions
| |
| − |
| |
| − |
| |
| − | Current Version
| |
| − |
| |
| − |
| |
| − | This is the version of the technology that the provider markets, promotes and supports. The provider could be a company that sells a particular technology, a department (for a tool that it has built for itself) or a community that maintains an open-source technology. For in-house applications, this is the version that is used in the production environment and for which most updates, patches and other maintenance efforts are designed. This version is also known as the production version, release-to-manufacture version, general availability release or gold build.
| |
| − |
| |
| − |
| |
| − | Supported Version
| |
| − |
| |
| − |
| |
| − | An older version of the technology that has been replaced by the current version, but that is still supported. The technology provider may have announced when support will end. The provider will encourage users to update to the current version. In some cases, the provider may extend support, often at a price, to give users time to migrate to the current version. This version is also known as the minus-X version or legacy supported version.
| |
| − |
| |
| − | Future Version
| |
| − |
| |
| − |
| |
| − | A version of the technology that:
| |
| − |
| |
| − |
| |
| − | a) has not yet been fully released;
| |
| − |
| |
| − |
| |
| − | b) contains new or modified features; and
| |
| − |
| |
| − |
| |
| − | c) may not have undergone full quality control
| |
| − |
| |
| − |
| |
| − |
| |
| − | This version is also known as the alpha version, pre-alpha version, beta version, pre-release candidate or prototype.
| |
| − |
| |
| − |
| |
| − |
| |
| − | Unsupported Version
| |
| − |
| |
| − |
| |
| − | An older version of the technology that has been replaced, eliminated or deprecated, and is no longer supported. The technology provider will:
| |
| − |
| |
| − |
| |
| − | a) be actively promoting the current version
| |
| − |
| |
| − |
| |
| − | b) not offer support or patches for this version
| |
