Operating Systems in Canadian Government IT

Government organizations in Canada rely on a mix of commercial operating systems for both end-user computing and server infrastructure. Microsoft Windows is the standard for desktop and laptop computers across most federal, provincial, and municipal offices. The federal government has undertaken large-scale migrations to keep Windows environments up to date – for example, Shared Services Canada (SSC) recently led an initiative to upgrade 23,000+ Windows Server 2008 instances to newer Windows Server versions. On the server side, both Windows Server and Linux/Unix systems are widely used. SSC has a multiyear Linux/Unix Operating System Modernization Initiative (OSMI) aimed at eliminating outdated Unix variants and standardizing on supported Linux distributions. This suggests a strategic move toward fewer, standardized Linux OS flavors (such as Red Hat Enterprise Linux or Ubuntu) rather than any custom government-specific distro.

Table 1 summarizes the typical OS usage across different government domains:

Government Environment	Common Operating Systems Used
Federal Departments & Agencies	Desktop: Windows 10/11 (standard for public service workstations). Server: Windows Server (2016 and later) and enterprise Linux distributions (e.g. Red Hat Enterprise Linux). A government-wide initiative is in place to update legacy OS and enforce standard Linux/Unix builds. Additionally, IBM mainframes running z/OS host critical legacy systems (e.g. tax and benefits systems using COBOL/DB2 on z/OS).
Canadian Armed Forces & Security Agencies (e.g. DND/CAF, CSIS)	Desktop: Primarily Windows, hardened for secure networks (for classified work, systems are air-gapped but still use commercial OS). Server: Mix of Windows Server and Linux/Unix. There is no public indication of a bespoke military OS (unlike Russia’s Astra Linux); Canadian defence and intelligence agencies use standard supported OS platforms with additional security hardening. For example, DND’s Defence 365 platform uses Microsoft’s cloud suite (see §4) with customized security controls.
Provincial Governments (e.g. BC, AB)	Desktop: Windows is the de facto standard for office productivity in provincial ministries. Server/Web: Combination of Windows Server for certain enterprise apps and Linux-based servers for web and open-source applications. Provinces like B.C. have embraced open-source solutions; many public-facing sites run on Drupal CMS atop Linux/Apache stacks. There is no evidence of province-specific OS forks – commercial Linux distributions (RHEL, Ubuntu, etc.) with vendor support are preferred over developing custom OS.
Municipal Governments	Desktop: Windows (for administration across cities and towns). Server/Web: Varied – smaller municipalities often use third-party hosting or off-the-shelf solutions. Many city websites are hosted on Linux-based web servers or utilize cloud hosting. There is wide diversity, from proprietary systems to open-source platforms, depending on local capacity. Like other levels, no custom OS; reliance on commercial OS and cloud services is common.

Across all these levels, custom operating system development is not a focus – unlike some nations, Canada does not maintain a sovereign OS. Instead, government institutions leverage widely used OS platforms and obtain enterprise support for open-source systems when needed. For instance, the Treasury Board Secretariat’s Open Source guidance notes that agencies can purchase commercial support for Linux from vendors like Red Hat or Canonical rather than creating their own distribution. The emphasis is on keeping software patched and supported: SSC’s mandate includes ensuring no Government of Canada systems run “outdated software and operating systems”. This approach, coupled with security hardening (e.g. using approved cryptographic modules and configurations), allows the use of mainstream OS even in sensitive environments. High-security networks (for classified data) are typically isolated physically or by design (per CSE’s network zoning guidance ITSG-22) rather than using obscure operating systems.

Another important component is the continued use of mainframe systems. Major federal services – revenue, pensions, immigration, etc. – still rely on IBM mainframes running IBM z/OS. These mainframes are valued for their reliability and security in handling millions of transactions. Mainframe programming (COBOL, CICS, DB2 on z/OS) remains a vital skill in government IT. For example, the Canada Revenue Agency and Employment Services rely on mainframe applications that are now the target of modernization efforts (e.g. re-hosting COBOL systems to modern platforms). In summary, Canada’s government OS landscape is heterogeneous – Windows dominates user endpoints; Linux and Unix (AIX, Solaris in older systems) power many servers; and legacy z/OS mainframes handle critical workloads. All are COTS (commercial off-the-shelf) systems with no evidence of a Canada-specific Linux fork.

Hosting and Web Development Technologies

Canadian government websites and applications are built on a variety of platforms, with a notable trend toward open-source content management and common development frameworks in recent years. Web content management systems (CMS) are prevalent for departmental and program websites. The Federal Government, under the Canada.ca initiative, has standardized much of its web presence on the Drupal CMS. In fact, the Government of Canada has its own Drupal distribution called Drupal WxT (Web Experience Toolkit), which integrates the accessibility and bilingual requirements of Canada.ca into a reusable theme and module set. This means many federal websites share a common codebase and design system. The benefit is a consistent, accessible experience and easier maintenance of standards across hundreds of sites. For example, recall and safety alert sites, Canada.ca informational pages, and various departmental sub-sites leverage Drupal WxT. Drupal’s strengths in multilingual content (English/French) and security have made it a platform of choice in federal and also some provincial web projects.

Other web platforms are also in use. Some departments have adopted WordPress or Microsoft SharePoint for specific purposes (especially internally or for smaller scale sites), though these are less uniform. The question mentions ConcreteCMS as well – while not an official standard, it is an open-source CMS known for its use in military contexts in the U.S. (e.g. DoD web modernization). In Canada, no widespread adoption of ConcreteCMS is documented in federal sites; however, individual municipalities or agencies could choose it. Overall, open-source CMS solutions (Drupal in particular) have strong momentum due to community support and the Government’s “Open First” directive, whereas proprietary web CMS solutions are used in niche cases. Provincial governments mirror this trend: British Columbia has been actively transitioning sites to Drupal and other open frameworks, and Alberta has issued tenders for Drupal-based web redesigns. Many municipal websites are developed by third-party firms that often rely on open-source CMS (Drupal, Joomla, or WordPress), though the choices vary widely by municipality.

Beyond CMS, the application development stack in government ranges from long-standing enterprise technologies to newer cloud-native frameworks. Historically, many internal applications were built in Java (J2EE) or Microsoft .NET (C#), aligning with government-wide IT standards of the 2000s. These remain in use for large systems (benefits processing, licensing systems, etc.). For example, departments have teams of developers working in Java/Spring or ASP.NET for line-of-business applications. However, modern digital services are increasingly using lighter-weight, open-source stacks. The Canadian Digital Service (CDS) notes that while many departments are “.NET or Java shops,” their own projects often use Laravel (PHP) and Node.js/React for agility. Indeed, languages like Python and JavaScript/Node.js have grown in popularity for new development, especially for web APIs, data services, and automation within departments reddit.com. Front-end development has likewise embraced modern frameworks: solutions are built with Angular or React for rich interactive web apps in some agencies. In summary, there is a blend of stacks: legacy apps in COBOL, PowerBuilder, or Oracle Forms; enterprise apps in Java/.NET; and new services using open-source languages and frameworks. This mix is evident in practice – one recent overview noted government teams using “Node, Python, Java, and C# for backend and Angular/React for front end,” often depending on the team’s mandate reddit.com.

Deployment and DevOps practices in government have gradually evolved to mirror industry trends, albeit with some lag due to security and skill constraints. Containerization is recognized as a key technology: Docker is used by many teams for packaging applications, and there’s growing interest in Kubernetes for orchestration. Shared Services Canada has been piloting enterprise container platforms – in fact, SSC issued a tender in 2024 for “Enterprise Kubernetes Platforms” to support containerized workloads government-wide. Some departments already deploy containerized applications on cloud platforms (e.g. using AWS Elastic Container Service or Azure Kubernetes Service). However, full Kubernetes adoption is still emerging; as one government DevOps practitioner observed, Kubernetes can be “overkill” for smaller apps and requires specialized expertise, so simpler cloud services or basic Docker scripts are often favored initially. Nonetheless, momentum is building: SSC’s container security guidance explicitly covers securing Docker containers and K8s orchestration, indicating that these tools are part of the target state. Deployment automation tools like Terraform (Infrastructure as Code) and pipeline tools like GitLab/GitHub CI or Azure DevOps are also in use for managing cloud infrastructure, although adoption varies by department. For example, the CDS helped launch the government’s first GitLab instance years ago, and now CI/CD pipelines are increasingly common in project delivery.

Hosting environments for government applications span on-premises data centers and cloud services. Traditionally, federal data centers (now consolidated under SSC) host many core systems. The Government of Canada has been consolidating over 720 legacy data centers down to a handful of modern Enterprise Data Centres (EDCs). These EDCs, such as SSC’s facilities in Borden and Gatineau, are Tier III certified (for high availability) and provide the primary on-premises hosting for federal applications. At the same time, there is a “Cloud First” policy (discussed more in Section 3) – meaning new applications are evaluated for cloud deployment unless there’s a compelling reason to host internally. As a result, many public-facing web services and newer apps are now hosted in cloud environments (AWS, Azure, etc.), while older systems or those requiring mainframes remain in government-run data centers. Provinces similarly have central data centers (e.g., Alberta’s government data centre, BC’s Kamloops and Calgary data centers for core IT) but are also extending into cloud. Municipalities often rely on external hosting providers; larger cities may have their own data center for internal apps but use commercial hosting for web services.

In terms of web hosting and deployment, a noteworthy initiative at the federal level is the use of “GCcloud” or cloud brokered services by SSC. This provides departments with a catalog of pre-approved cloud hosting options (IaaS/PaaS) to deploy their applications (see Section 3). Many departmental websites are now served via cloud-based infrastructure rather than physical web servers on premises. For example, the ArriveCAN travel app was built and hosted in an AWS cloud environment tpsgc-pwgsc.gc.ca. We also see widespread adoption of managed platforms: for internal collaboration, Microsoft’s cloud (M365) hosts email and SharePoint; for external sites, Software-as-a-Service solutions like Salesforce CRM are used by some programs (Salesforce is one of the approved cloud services and has seen significant government uptake). Container platforms, once fully implemented via the aforementioned SSC Kubernetes RFP, will allow more apps to be deployed in a cloud-agnostic way (portable between data center or cloud).

To summarize, the Canadian government’s web and application technology stack is in transition: moving from a heavy on-prem, proprietary approach to a more cloud-based, open-source-friendly model. Content management has largely standardized on Drupal open-source CMS for web content. Application development is polyglot, with legacy systems being modernized or wrapped in APIs, and new digital services using contemporary frameworks. Deployment practices are catching up to DevOps norms, introducing containers and continuous delivery, albeit moderated by strict security requirements. This hybrid approach aims to combine the stability of enterprise IT with the agility of modern cloud-native development – a balance that is reflected in current Government of Canada IT directives and toolchains.

Cloud and Compute in Government

Cloud computing now plays a central role in Canadian government IT strategy at all levels. The federal government formalized a “Cloud-First” strategy, meaning departments must consider cloud solutions (public or hybrid) as the preferred option for new deployments. To enable this, Shared Services Canada established framework agreements with 8 leading cloud service providers, creating a Government of Canada cloud brokerage ecosystem. The providers on this list (as of 2022) include: Amazon Web Services, Microsoft Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud, Salesforce, ServiceNow (via a partner), and a Canadian cloud provider ThinkOn Inc. These framework agreements set standardized terms and ensure each provider’s services meet federal security requirements (assessed by the Cyber Centre and PSPC’s Contract Security Program).

Under this multi-vendor cloud strategy, departments can procure cloud resources quickly through a centralized portal. The impact has been significant – cloud usage skyrocketed from under $1.4M in 2019 to over $100M in 2021-22 in annual spend, and it continues to grow. Table 2 provides an overview of major cloud providers and their use in government:

Cloud Platform	Government Adoption and Notes
Microsoft Azure	The most-used cloud in GC by spend, accounting for approximately $204 million of GC cloud expenditure from FY2019–2023. Azure’s popularity is boosted by the government’s use of Microsoft 365 (email, Office apps) and Azure’s data centers in Canada. Many departments host applications on Azure, and the Office 365 platform (Teams, Exchange Online) for federal users is built on Azure cloud. (Notably, Defence uses a secured “Defence 365” instance of O365 for Protected A data.) Azure meets Canada’s Protected B (PBMM) requirements and is cleared for sensitive but unclassified data.
Amazon Web Services (AWS)	Extensively used for federal digital services and agile projects. AWS hosted high-profile solutions like the ArriveCAN app for traveler screening tpsgc-pwgsc.gc.ca. As of 2022, 132 AWS services in the Canada region have been assessed by the Canadian Centre for Cyber Security for compliance with the government’s PBMM security profile aws.amazon.com. This makes AWS a viable option up to Protected B level. GC spending on AWS was about $49.5 million (FY2019–2023) – less than Azure’s, but AWS is still a core part of many departments’ cloud deployments (especially for innovative projects and when AWS’s specific services, like AI or IoT, are needed).
Google Cloud Platform (GCP)	Also an approved provider, though with a smaller footprint in Canadian government so far. GCP is used in some data analytics, mapping, or machine learning pilots. Spending is comparatively low (“Others” including GCP amounted to ~$12.5M over 2019–2023). GCP has a Canada region and has passed security assessments for use up to Protected B.
IBM Cloud and Oracle Cloud	Both are on the SSC framework, mainly to support workloads needing those vendors’ technologies (e.g. IBM for legacy modernization or specialized services, Oracle for database and ERP-related cloud offerings). Their adoption is limited; however, some cloud-based modernizations of mainframe apps have used IBM Cloud, and Oracle’s cloud is considered for Oracle-based workloads. Combined spend is modest (part of the “others” category).
Salesforce (Software-as-a-Service)	The inclusion of Salesforce.com on the cloud list underscores the use of Cloud SaaS for CRM and case management in government. Salesforce has been used for solutions like managing COVID-19 vaccine appointment systems and other citizen service portals. It represented roughly $44 million of GC cloud spend (2019–2023) – nearly equal to AWS in that period – showing that SaaS solutions are a major component of cloud adoption. Salesforce is delivered as a cloud service but must be configured to meet government data residency rules (Salesforce hosts Canadian client data in Canadian data centers).
ThinkOn (Canadian Cloud)	ThinkOn Inc. is a Toronto-based cloud and data management provider, notable as the only domestic SME on the cloud list. It offers storage, backup, and IaaS with all data kept in Canada (marketed as a “sovereign cloud” option). A few federal organizations have tried ThinkOn – total consumption through SSC was about $587k by late 2022 tpsgc-pwgsc.gc.ca, which is relatively small. However, its presence indicates an effort to support Canadian providers and address sovereignty concerns for certain data.

These cloud services are used in a multi-cloud fashion. Departments choose the platform that best fits a project’s needs or leverage multiple clouds (for redundancy or different capabilities). The SSC Cloud Brokering Service allows direct call-ups to any of the approved providers and imposes guardrails for security. For example, for moderate procurements (>$500k), departments must compare at least 3 providers to ensure best value, and all cloud usage must implement mandatory security guardrails (common security configurations) for Protected B data tpsgc-pwgsc.gc.ca. One such guardrail framework is the Secure Cloud Enablement and Defence (SCED) service by SSC, which provides network connectivity and security monitoring for departments using public cloud.

At the provincial level, cloud adoption is also accelerating. Provinces often leverage the federal contracts or set up their own arrangements. In fact, other jurisdictions can piggyback on the SSC cloud agreements – Ontario, BC, and even a Vancouver school board have used the federal cloud procurement vehicles tpsgc-pwgsc.gc.ca. British Columbia has a “Cloud Smart” approach, supporting both AWS and Azure for ministries. B.C. configured a centralized AWS Landing Zone with provincial guardrails so ministries can deploy to AWS securely. B.C.’s landing zone enforces Canadian data residency (only AWS Canada region is accessible) and pre-approved services. It’s certified to the same PBMM security standard as the federal government’s profile. This allows B.C. to host up to Protected B data in AWS, though Protected C (very sensitive or classified) remains disallowed in public cloud. Provinces like Alberta and Ontario similarly use a mix of cloud – for example, Alberta has migrated some government web applications to the cloud and even re-hosted legacy mainframe apps onto cloud infrastructure. Many provinces utilize Microsoft 365 for email and collaboration, effectively embracing Microsoft’s cloud at an enterprise level.

Municipal governments vary widely in cloud use. Larger cities (like Vancouver, Calgary) are increasingly using cloud-hosted solutions for things like open data platforms, city websites, and CRM for 311 services. They may use AWS or Azure through their vendors. Small municipalities might rely on SaaS (e.g. a cloud-based municipal ERP or GIS system) rather than building their own IT infrastructure. One driving factor for municipal cloud adoption is cost and scalability, but they must comply with provincial privacy laws (some provinces until recently required municipal data to stay in Canada, influencing cloud choices).

An important aspect of cloud in Canada’s public sector is cost management and contracts. Cloud pricing for government is typically pay-as-you-go, but SSC’s brokerage adds a slight fee (initially 2% of usage) to fund security oversight. As cloud spend grew, SSC actually waived fees when they exceeded operational cost (e.g. suspending the broker fee in late 2020 due to high uptake). The government tracks consumption closely: in FY2022-23, 91 organizations were using SSC’s cloud services, with the largest consumers (Communications Security Establishment and Statistics Canada) each spending ~$19M+ that year on cloud. Most others spend far less, but about 38% of cloud users have spent over $1M cumulatively. The pattern suggests initial hesitation has given way to broad adoption across many departments.

We also see hybrid cloud strategies. Not everything moved to public cloud – SSC continues to invest in on-premise compute for certain needs (for example, a High Performance Computing (HPC) solution for Environment Canada’s weather forecasting was procured as a dedicated system, given its specialized nature and cost efficiency on prem). The Government’s approach is to use cloud “for the right workload” and maintain internal capacity for others. Over time, the line is shifting cloud-ward; indeed, TBS announced in late 2023 a new cloud strategy to centralize oversight and potentially “repatriate” some workloads to a more controlled hybrid model under SSC. This suggests future cloud usage will be managed more centrally to optimize costs and security, rather than leaving each department to independently ramp up usage.

In terms of compute resources and costs, public details are limited to high-level spend and capacity. We know, for instance, that the weather supercomputer contract was in tens of millions and provided a massive increase in compute power for meteorological data. For cloud, costs are monitored but not published per-unit (as they vary by service). Instead, benchmarks are often about aggregate usage. One notable stat: by 2023, Microsoft Azure usage in GC was four times that of AWS, highlighting that enterprise agreements like Office 365 can drive significant cloud consumption (Azure likely includes a lot of M365 SaaS spend in those figures). Each cloud provider offers discounted pricing to government via the framework agreements, but the exact pricing is protected by procurement confidentiality. However, departments are encouraged to architect cost-effective solutions – e.g., use auto-scaling to only pay for what is needed, and leverage price advantages of one cloud vs another for specific services. There is also attention to specialized compute (GPUs, AI services): agencies like NRC and universities (via Compute Canada) engage in GPU computing in the cloud for research, but production use of GPU instances (for AI or GIS) in federal operations is still emerging, with some projects leveraging cloud AI platforms on a case-by-case basis.

In summary, cloud computing in Canadian government has moved from experimental to mainstream in the last few years. The federal cloud framework has enabled a multi-cloud environment with competition among providers and a dramatic rise in consumption (over $150M in FY2022-23). Cloud is used for everything from public web apps to internal dev/test environments and commercial SaaS like email. Provincial and local governments similarly are adopting cloud within the boundaries of security and privacy regulations. The focus now is on governance and cost-control – ensuring that the ease of cloud doesn’t lead to sprawl or security lapses. Efforts like centralized guardrails (12 mandatory security controls for all cloud deployments) tpsgc-pwgsc.gc.ca and new oversight by SSC are in place to manage this. As cloud technology evolves (e.g. toward serverless computing or edge computing), governments are expected to incorporate those options too, always tempered by risk management needs in the public sector context.

Data Management and Cybersecurity Standards

Managing data securely is paramount for government IT, and Canada has a well-defined set of cybersecurity standards and compliance frameworks that all government systems must adhere to. These standards cover everything from risk management processes to network architecture, data handling, and cloud security profiles. Below we outline the key frameworks and regulations:

ITSG-33 – IT Security Risk Management: The cornerstone of federal IT security is the Information Technology Security Guidance 33, published by the Communications Security Establishment (CSE) Cyber Centre. ITSG-33 provides a lifecycle approach to managing risk, including a catalogue of security controls and baseline control profiles for different sensitivity levels. Under ITSG-33, departments follow a process to categorize their information systems (by confidentiality, integrity, availability requirements) and then apply a corresponding set of controls. It’s essentially the Canadian equivalent to NIST SP 800-53 / Risk Management Framework in the U.S., adapted to the GC context. ITSG-33 defines controls in areas like access control, incident response, encryption, personnel security, etc. There are predefined Security Control Profiles in ITSG-33 Annexes (e.g., Profile 1 for low-sensitivity, Profile 2 for medium, etc.), which serve as baseline requirements. The Treasury Board’s policies mandate ITSG-33 compliance – meaning every federal system must undergo security assessment and authorization (SA&A) aligned to these controls. Many provinces also mirror ITSG-33 principles for their own systems or use it as a guideline.

ITSG-22 – Network Security Zoning: Another crucial guideline is ITSG-22, which covers network security zone architecture. This guidance defines how government networks should be segmented into zones (e.g., public zone, operational zone, restricted zone, etc.) with strong controls at each boundary. The idea is to limit access such that sensitive systems are tucked behind multiple layers of defense (“defence-in-depth”). For example, public-facing servers might sit in a Public Access Zone (DMZ), separated from internal databases in a Restricted Zone by firewalls and application gateways. ITSG-22 has been adopted as a reference model across departments – it’s essentially a blueprint ensuring that, say, a tax filing system’s database isn’t directly reachable from the internet, but only via properly secured intermediate systems. Adherence to ITSG-22 is checked during architecture reviews and is often baked into procurement (vendors must design solutions consistent with GC zone-based security). The Cyber Centre also extended this concept to cloud: even in cloud deployments, equivalent zoning (using virtual networks, subnet segregation, etc.) is required.

GC Security Control Profile (Protected B / PBMM): Building on ITSG-33, the government has defined a specific Security Control Profile for Cloud-based GC Services at Protected B, Medium Integrity, Medium Availability (PBMM). This profile is essentially the set of ~130 security controls that a cloud service must implement to be trusted with sensitive (but unclassified) data. It was developed jointly by CSE, Treasury Board, and SSC, and is heavily influenced by the U.S. FedRAMP moderate baseline. The PBMM profile is the standard for most cloud systems since Protected B covers personal information and government business data that is not public. According to this profile, cloud providers (CSPs) have certain controls they must fulfill (physical security of data centers, encryption at rest, etc.) and departments (cloud consumers) have their own controls (identity management, monitoring, incident response, etc.). The profile delineates responsibilities in a shared responsibility model. Practically, before a department can deploy a Protected B workload to cloud, they must ensure the CSP has been assessed against PBMM controls. This is exactly what the Cyber Centre does: through its Cloud Security Assessment program, it evaluates providers like AWS, Azure, etc. against PBMM. As noted earlier, AWS had 132 services certified against the PBMM (CCCS Medium) profile aws.amazon.com. Microsoft Azure and others have similar assessments (Microsoft refers to this as the “CCCS Medium Cloud Profile” in its compliance documentation). The existence of an official PBMM profile streamlines cloud adoption – departments can leverage these assessments rather than doing it all in-house, and simply add any extra controls unique to their application.

For non-cloud systems, the equivalent baseline is often called the “GC Security Control Profile for internal systems,” which maps to ITSG-33 controls and the level of the system (Protected A, B, or Classified). There are also profiles for higher security (Protected C / Secret), but those are used in special cases (and likely not on public cloud at this time – classified systems remain on dedicated networks).

Privacy and Data Residency Regulations: Alongside security controls, Canada has laws and policies to ensure data sovereignty and privacy. Federally, the Privacy Act and policy on government data localization require that personal information under government control is stored in Canada unless an exception is granted. This is one reason the approved cloud providers all have Canadian regions and why cloud contracts stipulate data must reside in those regions. At the provincial level, some have had even stricter rules: British Columbia’s FOIPPA law historically mandated that public sector data be stored and accessed only in Canada (to prevent exposure to foreign jurisdiction). B.C. amended FOIPPA in 2021 to relax this for certain services, but still prioritizes Canadian hosting. Similarly, Nova Scotia had data residency requirements. These regulations affect cloud adoption – e.g., a municipality in B.C. using an American cloud service would need to ensure data residency in Canada. Governments also often require that vendors disclose if any data will leave the country or be accessible by foreign authorities. The Government of Canada’s Cloud Strategy explicitly states that Canadian data residency should be the default for cloud services handling sensitive data.

Encryption and Information Handling Standards: The Cyber Centre issues specific technical standards like ITSP.40.xx series – for instance, approved cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and B are listed in ITSP.4006, mandating the use of FIPS-140 validated crypto modules. All government systems are expected to use approved encryption (e.g. AES, TLS configurations as per CSE guidance). Email systems must use encryption for sensitive attachments (the government has a Secure Electronic Documents standard) and classify emails according to their sensitivity. There is also a Guideline on Data Classification that instructs how to mark and handle information at different levels (Protected A vs B, etc.). Under policies like the Policy on Government Security, Protected B data (such as an individual’s tax or health information) must be stored encrypted and within accredited IT facilities; Protected C (Secret) data cannot be processed on public/commercial infrastructure at all, it must be on dedicated secret networks.

Secure Procurement and Supply Chain: The government has mechanisms to ensure suppliers meet security standards. The Contract Security Program (CSP), run by Public Services and Procurement Canada, requires any company handling sensitive government information to have a security clearance. For example, if a cloud provider or an IT outsourcing firm will host Protected B data, that company must be cleared to at least Protected B level, with all personnel cleared and facilities approved. This often involves an inspection of the data center by authorities and personnel checks. Additionally, the Cyber Centre sometimes evaluates products under programs akin to Common Criteria (for example, they might evaluate a security appliance or a cloud service’s security as we saw with CCCS assessments). There is also growing attention to supply chain integrity – ensuring that hardware and software procured for government are from trusted sources. For critical systems, departments may require vendors to disclose sub-contractors and foreign components.

Guidance from the Cyber Centre: CSE’s Canadian Centre for Cyber Security publishes guidance on many of these areas. For cloud, beyond the security profile, they have guidance on secure cloud configuration, identity and access management, and incident response in cloud. They also emphasize Continuous Monitoring – under ITSG-33, after a system is authorized, it must be continuously monitored and reassessed periodically. The government has a Cyber Security Event Management Plan and centralized monitoring (through CCCS sensors on networks) to detect threats. For handling data, the Cyber Centre provides best practices like Data Loss Prevention and secure disposal.

Email and Collaboration Security: As the government moved to cloud email (Microsoft 365), specific standards were applied. For instance, GCemail (the email system for most federal employees) requires that all data is in Canadian data centers and that the system meets Protected B security controls. The Treasury Board Secretariat endorsed Microsoft 365 as the recommended platform only after it was verified to meet GC security and integrity requirements. Departments using it must still enforce policies such as requiring encryption for emails with sensitive attachments (e.g., using MS Purview (formerly Azure Information Protection) labels to encrypt files). The Cyber Centre also released an Office 365 security configuration guide to harden tenant settings (covering multi-factor authentication, data retention, etc.). Beyond email, any data storage – be it on cloud platforms, portable media, or contractor systems – must comply with the Policy on Information Management and Security. This includes ensuring backups of Protected data are encrypted and stored in Canada, and that cloud storage buckets are not left open to the internet (misconfigurations being a big risk). Regular audits (both internal and by the Office of the Auditor General) often check for compliance with these standards.

To illustrate compliance frameworks, consider a department launching a new web application handling citizen data. They would: perform a Security Threat and Risk Assessment (STRA) and Privacy Impact Assessment, classify the system as Protected B, then choose a cloud provider that’s approved for PBMM. They’d apply the GC PBMM control profile, implementing controls like SIEM logging, secure account management, encryption, etc., either using built-in cloud services or additional tools. The cloud environment itself would be configured according to guardrails (for example, in B.C.’s AWS setup, any service not pre-assessed through an STRA/PIA is blocked by guardrails until it’s reviewed digital.gov.bc.ca). Once deployed, the system would undergo vulnerability assessments, perhaps by the Cyber Centre, and only then be given Authority to Operate. All these steps trace back to the frameworks mentioned (ITSG-33 process, ITSG-22 zoning, PBMM controls, and privacy law compliance).

Summary of Key Security Frameworks and Standards:

ITSG-33: Risk management framework and control catalog used to baseline security controls for all GC systems. Defines profiles (e.g., PBMM).
ITSG-22: Mandatory network zoning principles for GC systems (segregating public, private, and secure zones).
PBMM Cloud Control Profile: Specific set of security controls for cloud systems handling Protected B data, aligning with FedRAMP Moderate.
Cyber Centre Cloud Assessments: CCCS evaluates cloud providers against PBMM; compliance is required for a provider to host GC workloads aws.amazon.com.
Data Residency & Privacy: Laws and policies requiring Canadian storage for sensitive personal data (federal and some provincial laws) and strict privacy impact assessments for any new system.
Contractor Requirements: Companies must have facility and personnel security clearances to handle Protected/Classified info. Data centers should be certified (Tier III for reliability, ISO 27001 or similar for security management is often expected), and suppliers often need to demonstrate certifications like SOC 2, ISO 27001, or compliance with standards (e.g., for cloud SaaS, having FedRAMP or ISO certs helps in the security assessment process).
Secure Configuration Baselines: Government maintains baseline configs (e.g., for Windows hardening, O365 tenant configuration, network devices) that align to the above policies. Departments must implement these or get exceptions.

By adhering to these layered standards, the government ensures that whether data is stored in a GC-owned data center or in the cloud, it is protected to a level commensurate with its sensitivity. The approach is one of defense-in-depth combined with compliance checkpoints (e.g., you cannot go live with a system until it meets ITSG-33 controls and passes a security assessment). These cybersecurity requirements can be stringent, but they are continuously updated to address emerging threats. For instance, there is increasing guidance on supply chain security (in light of recent concerns about foreign equipment and software vulnerabilities) and on Zero Trust Architecture – the Cyber Centre has published guidance encouraging departments to move toward zero-trust principles for future state networks. All these efforts underscore a strong culture of security and data protection in Canadian government IT.

Requirements for Hosting Government Services (Policy and Compliance)

For a company or organization to host government data or provide IT infrastructure to Canadian public sector clients, there are strict eligibility and compliance requirements. Governments will only entrust their systems and information to hosting providers that demonstrably meet high standards for security, reliability, and compliance with public sector values (such as data sovereignty). This section outlines what is required to be a qualified hosting provider for municipal, provincial, or federal government in Canada.

1. Security Clearances and Trustworthiness: Providers must typically be cleared under the federal Contract Security Program (CSP) or equivalent provincial processes if they are to handle sensitive (Protected) data. This means the company may need to obtain a Facility Security Clearance (for the company entity) and ensure that key personnel have at least a Reliability Status or Secret clearance (depending on the level of data). For example, a data centre operations team managing servers that store Protected B data may all need reliability status (security screening) at minimum. If a provider cannot obtain these clearances, it will not be allowed to host sensitive government workloads. In practice, major cloud providers have obtained such clearances in Canada for their operations teams, and smaller providers like ThinkOn have as well, since it’s a prerequisite in many contracts.

2. Data Centre Certifications (Reliability and Security): Government hosting RFPs often mandate that the data center facilities meet certain Uptime Institute Tier certifications – commonly Tier III or higher. Tier III certification means the data centre offers redundant capacity components and no single outage should cause downtime (99.982% availability). For instance, Shared Services Canada’s own enterprise data centre in Borden achieved Tier III Gold certification for operational excellence, reflecting the level of quality expected. A commercial provider offering co-location or private cloud to government would strengthen their bid by demonstrating Tier III or Tier IV facilities. Beyond uptime, standards like ISO/IEC 27001 (information security management) are often required or strongly preferred. An ISO 27001 certification indicates the provider follows internationally recognized security management practices – this is particularly expected for cloud data centers and SaaS providers working with government. Other attestations like SOC 2 Type II reports, PCI-DSS (if handling payment data), and ISO 22301 (business continuity) can also be part of the compliance package. Essentially, a hosting provider must prove robust physical security (guards, biometrics, CCTV), redundant power/HVAC, fire suppression, and strict access control to facilities – all of which an ISO 27001 audit or Tier certification would cover. Public sector clients may ask for copies of these certificates or audit reports during procurement.

3. Compliance with Government Security Policies: As discussed in Section 4, any environment hosting government data must align with government security policies (ITSG-33 controls, PBMM profile if cloud, etc.). For cloud providers, this means passing a CCCS security assessment. For traditional hosting companies or data centre service providers, it may mean undergoing a Security Assessment & Authorization by the client department. For example, if a province contracted a private data center to host health data, the province’s security auditors would assess that facility against their security control framework. Common requirements include: encryption of data at rest and in transit (FIPS 140-2 validated), secure network architecture (segregating government servers from other tenants, perhaps using virtual private cloud setups or dedicated subnets/VLANs), robust identity and access management (unique user accounts, MFA for admins), 24/7 monitoring and incident response, and documented secure software development practices if the provider also does application management. Cloud providers on the federal list have already attested to many of these – e.g. AWS and Azure maintain documentation on how they meet ITSG-33 control objectives, available to government via secure portals. A smaller hosting firm must similarly align to those expectations, even if not formally assessed by CCCS; otherwise they won’t be competitive in bids.

4. Data Sovereignty Guarantees: To host Canadian government data, providers must ensure data residency in Canada and protection from unauthorized foreign access. Practically, this means guaranteeing that all data and backups remain on Canadian soil (in facilities under Canadian jurisdiction). Many RFPs include clauses about where data can be stored and accessed. For cloud providers, having a Canada region is essential (which all major ones now do). Providers may also be asked about their exposure to foreign legislation – for instance, U.S.-based cloud companies are sometimes asked how they handle U.S. Patriot Act/FISA requests. While no provider will exempt themselves from their home country laws, they often provide contractual commitments to notify and resist where possible any foreign legal demands. Some Canadian agencies might favor a domestic provider (like ThinkOn or provincial Crown corporation data centres) for particularly sensitive data to mitigate this risk. Additionally, providers are expected to have Canadian support personnel for the account, especially if they will handle sensitive incident tickets or have admin access to systems. An example at DND: they use a segregated O365 cloud (Defence 365) for which Microsoft ensures only screened admins can access and that the service is operated to government security standards.

5. Vendor Stability and Performance: Governments conduct due diligence on the financial and operational stability of hosting providers. A company must demonstrate it has the capacity and reliability to serve a government client over the long term. This includes showing sufficient insurance (cyber liability insurance is often mandated), a solid track record (references from other government or large enterprise clients), and meeting service level requirements. Typical SLAs for government hosting are 99.9% or higher uptime, with penalties for non-compliance. Providers should have documented disaster recovery and continuity plans, and ideally multiple Canadian data center locations for redundancy. They may need to show audit results or certifications for those as well (e.g. Tier III for both primary and backup site).

6. Privacy and Legal Compliance: If hosting personal data, providers must comply with Canadian privacy laws. This could mean signing agreements to abide by the Privacy Act or provincial privacy acts, agreeing to data breach notification clauses, and participating in privacy impact assessments. They should also have clear policies on data ownership (government retains ownership of all data), data return/destruction at contract end, and restrictions on data mining or secondary use. Governments will often include clauses forbidding the provider from using the data for any purpose other than providing the service.

7. Ability to Meet Specific Certifications or Programs: In some cases, governments will specify needed certifications like FedRAMP (for cloud) or others. In Canada, the FedRAMP equivalent is the CCCS medium assessment, but for specialized contexts, there may be others. For instance, if a provider will host law enforcement data, they might need to comply with RCMP’s technical security standards or CJIS (Criminal Justice Information Services) requirements if applicable. Another example: Health data hosting may require compliance with health information regulations (like HIPAA-equivalent or Canadian Health Information privacy principles). While not a formal certification, demonstrating experience with those regimes is often necessary.

8. Procurement Process Requirements: Beyond technical criteria, to do business with government a provider must navigate procurement rules. They need to be on the right supply arrangements or win competitive bids. SSC’s cloud framework itself was a result of a competitive process – only providers who qualified (meeting all the above security and capacity criteria) got onto the vehicle. For other contracts, a provider might have to respond to RFPs that include extensive security questionnaires and architectural requirements. They must agree to audits: government clients usually reserve the right to audit the provider’s facilities and operations (or see third-party audit reports) on an ongoing basis. Also, providers must adhere to government accessibility and official languages requirements if their service includes user interfaces (for example, a SaaS app must be available in both English and French for federal use).

To illustrate, if a company in Western Canada wants to offer cloud storage to municipalities for data backup, to win municipal contracts they should: host the data in Canada (ideally in-province if important to the client), have ISO 27001 certification and perhaps Uptime Institute Tier certification for their data center, ensure all staff are screened as required by the city, sign strict privacy protection agreements, and show they have a strong security program (firewalls, monitoring, incident response). They should be prepared for the city’s IT security team to audit their controls or request documentation. Similarly, a global cloud provider like Microsoft had to meet a host of requirements before the Canadian federal government trusted its O365 cloud – including building data centers on Canadian soil and undergoing an assessment that showed it met all PBMM controls.

In short, the bar to host government systems is high. The environment must be secure, certified, monitored, resilient, and legally compliant. Companies often invest heavily in certifications and Canadian infrastructure to meet these needs. Once they do, however, they gain access to large contracts – as evidenced by the tens of millions spent on AWS, Azure, and others once they were approved tpsgc-pwgsc.gc.ca tpsgc-pwgsc.gc.ca. The Government of Canada and its provincial/municipal counterparts thereby mitigate risk by only partnering with providers that demonstrably uphold the confidentiality, integrity, and availability of government data. Any hosting provider that cannot prove such capabilities will be filtered out either in the procurement phase or the security authorization phase.

Conclusion and Future Outlook

This survey of current technologies and policies in Canadian government IT highlights a landscape in transformation. Legacy operating environments (Windows desktops, Unix servers, mainframes) remain critical, but they are being modernized continuously – unsupported systems are being phased out and open-source platforms are embraced where they make sense. There is a clear trend toward open-source adoption: from the widespread use of Drupal for websites to increasing use of languages like Python and JavaScript for new applications. The Government’s “Open First” stance canada.ca means we can expect even more use of open technologies, provided they meet security needs. The Enterprise Architecture Review Board (EARB) now maintains a list of approved open-source software for departments, and this list is growing. One can foresee more custom government software being released as open source, following the lead of countries like the UK – Canada has already open-sourced components like the COVID Alert mobile app.

Cloud-first policy is firmly in place and likely to strengthen. In late 2023, Treasury Board refined the cloud strategy to improve oversight and cost controls, moving from a “light-touch” broker model to a more centralized model where SSC will “oversee hosting for the entire GC, including both cloud and data centres”. This indicates that hybrid cloud management will mature – with SSC possibly offering more common cloud platforms (like a managed Kubernetes service or platform-as-a-service) to all departments. The ongoing Kubernetes platform procurement hints that the government is building capacity for containerized workloads, which aligns with future trends of cloud-native development and portability between cloud providers. Departments will likely use containers to avoid lock-in and improve scalability of applications across different cloud infrastructures.

We also see a push for development and DevOps modernization. Initiatives like the Canadian Digital Service and various digital innovation labs in departments are introducing practices like agile development, continuous integration, and human-centered design into government projects. This cultural shift means future IT projects will likely have shorter development cycles and more iterative updates (facilitated by cloud and DevOps toolchains). The adoption of serverless computing and managed services is expected to grow as well – already some teams use AWS Lambda or Azure Functions for certain tasks, and this could expand as confidence in cloud security grows.

In terms of cybersecurity trends, the government is moving towards Zero Trust Architecture. The traditional network perimeter model (as embodied in ITSG-22 zones) is evolving to assume breach and verify every access. The Cyber Centre has issued zero trust guidance and some departments are piloting zero trust implementations (for example, SSC and CSE are collaborating on enterprise identity and network segmentation projects beyond physical zoning). Over the next few years, we might see requirements for multi-factor authentication, device posture checks, and micro-segmentation become even more mandatory across the board – even for internal networks. Additionally, supply chain security will remain a hot topic: procurement may include requirements for software bill of materials (SBOMs) from vendors and assurance that no unauthorized components are in use (especially after incidents like SolarWinds).

Digital sovereignty will also continue to be important. Canada, like other countries, is balancing use of global cloud providers with the need to control its data. The inclusion of a Canadian cloud provider in the mix and new guidance (there was a recent Government of Canada white paper on data sovereignty) suggest that future strategy could involve encouraging more domestic cloud capacity or at least ensuring that contractual terms with big providers give Canada more control (e.g., customer-managed encryption keys, strict data residency and deletion guarantees). The provinces too will revisit their privacy laws; some, like BC, already updated residency rules to be more flexible, but public sentiment and geopolitical events could swing the pendulum toward stricter sovereignty if needed.

On the hosting front, any entity wishing to host government services will need to stay aligned with these trends. This means obtaining relevant certifications (perhaps StateRAMP or equivalent if targeting provincial clients, or new cloud security marks the CCCS might introduce), and investing in green IT (the government is also starting to include energy efficiency and GHG reduction requirements in IT contracts). The Government of Canada has tied cloud procurement to greening targets since 2022, so future hosting solutions must also demonstrate sustainable operations.

Finally, as technology evolves, the government is eyeing emerging tech: artificial intelligence, big data analytics, and quantum computing are areas of active exploration (with policies ensuring they are used ethically and securely). The national research councils and defence are experimenting with AI for service delivery and cyber defense. These new workloads often demand specialized compute (GPUs, TPU pods, etc.), likely accelerating government’s reliance on cloud where such resources are readily available. Expect new policy frameworks around AI data management and perhaps updates to security profiles to cover AI services and higher performance computing in multi-tenant environments.

In conclusion, the Canadian government’s IT environment is becoming more unified and standardized (through shared platforms and common standards) while simultaneously embracing innovation (through cloud services, open-source software, and modern dev practices). IT architects in the public sector must navigate a rich tapestry of technologies old and new: maintaining critical legacy systems even as they deploy cloud-native microservices; enforcing strict compliance while fostering agile experimentation. The guiding principles, however, remain constant: protect data (security and privacy by design), ensure reliability of services to Canadians, and obtain value for money (via competition and cloud economics). With the robust policy foundation in place – from ITSG-33 to PBMM and beyond – and a clear strategic direction (cloud-first, open-first, secure from the start), Canada’s government IT is well-positioned to continue its digital transformation in the coming years, delivering modern services on a bedrock of trusted technology.

Sources:

Shared Services Canada – modernization initiatives for OS and data centres
SSC QP Notes on Windows and Linux OS modernization
Evolving Web on Government of Canada Drupal adoption
Canadian Digital Service on tech stacks (PHP/Node vs .NET/Java in government)
Reddit thread (CanadaPublicServants) – tech stack anecdotal info reddit.com
SSC Guidance on Secure Containers & Microservices (mention of Kubernetes)
SSC Standing Committee on OGGO – Cloud framework agreements and usage
SSC Standing Committee on OGGO – Cloud spend increase (2019–2022)
SSC Standing Committee on OGGO – Cloud providers list and guardrails tpsgc-pwgsc.gc.ca
SSC Evaluation of Cloud Services – Cloud spend, Azure vs AWS usage
SSC Evaluation of Cloud Services – Cloud consumption growth table
SSC Evaluation – Most-used cloud providers graph (Microsoft 4× AWS)
SSC Standing Committee on OGGO – Example of AWS usage (ArriveCan on AWS) tpsgc-pwgsc.gc.ca
CCCS Assessment of AWS – 132 services approved for PBMM aws.amazon.com
Defence 365 FAQ – TBS recommended O365 and security for Protected A/B
BC Government Cloud Security – AWS guardrails and PBMM compliance
Open First Whitepaper – Commercial support for Linux (Red Hat/Canonical)
Aardvark Infinity (Medium) – Mainframe tech in GC (z/OS, COBOL, etc.)
PSC Cloud White Paper – GC Security Control Profile (PBMM/FedRAMP alignment)
AWS Security Blog – CCCS assessment requirement for cloud providers
Cyber.gc.ca – ITSG-22 Network zoning guidance (zones)
SSC OGGO Brief – Cloud framework usage by other governments (Ontario, BC) tpsgc-pwgsc.gc.ca
SSC OGGO Brief – Spending on AWS (example $24.6M in one year) tpsgc-pwgsc.gc.ca t psgc-pwgsc.gc.ca
SSC Cloud Evaluation – Cloud portal procurement thresholds (direct < $500k)
Cyber.gc.ca – Guidance on cloud categorization and profiles
BC Digital Gov – Cloud security (STRA/PIA, guardrails for Canada region)
SSC OGGO Brief – ThinkOn usage and ArriveCan clarification tpsgc-pwgsc.gc.ca t psgc-pwgsc.gc.ca
Cyber.gc.ca – Annex 3A of ITSG-33 (mention ITSG-22 in context)
SSC QP Notes – Data centre consolidation and Tier certification
SSC Cloud Evaluation – Partner usage and fees suspension
SSC Cloud Evaluation – Number of orgs using cloud and top spenders
SSC Cloud Evaluation – Cloud spending categories (very high spenders etc.)
Microsoft Learn – Canadian compliance (PBMM evolved into CCCS Medium)
AWS Artifact blog – CCCS assessment summary (AWS 132 services) aws.amazon.com
Cyber.gc.ca – Cloud Security Assessment Process (CCCS Medium profile)
SSC OGGO Brief – Guardrails and secure cloud to ground (mention 12 guardrails) tpsgc-pwgsc.gc.ca
Privacy Matters (UBC) – FOIPPA data residency amendments in BC
PSPC Tender Notice – Kubernetes platform RFP (closing 2025)