The Digital Sovereignty Playbook

How Canada became too dependent on technology vendors

Ever since computers became core to how government works, governments have had to fight to avoid becoming to dependent on any given technology provider.

As technology powered more and more of government service delivery, technology companies have worked hard to entice IT departments to build more within their walled gardens.

What's really at stake here?

The term "Digital Sovereignty" gets thrown around a lot, so it helps to be really clear about what we mean and what's at risk.

The main idea is that Canada’s very existence as a legitimate government depends on our ability to:

a) make independent choices about which technology to use
b) continue to operate it without interruption
c) control who can access our data
d) exit and change which technology providers we use
e) sustainably improve over time

If we can't really control our own technology in these ways, foreign governments can exert legal, technical, or political pressure to:

• force companies we rely on to stop providing security updates
• access private data without our knowledge
• run cyberattack campaigns on our services
• make us more dependent on their country's service providers

We know we're locked in, but how could we realistically do anything about it?

Leaders recognize the risks, but replacing systems that took years to implement can feel expensive and unrealistic.

These are the objections we often hear:

1. Understand where you're most dependent

You can't reduce risk if you don't know where it exists.

Taking stock of your organization's technology is a bit like cleaning out an overstuffed closet. It's tempting to keep the door closed and avoid the mess, but eventually you need to figure out what's in there, what you still need and what's taking up valuable space.

Create an inventory

From our experience, even a large organization can get a good enough big picture understanding of their risks within a week or two.

You can cover everything by starting from the top down, collecting all your technology into three categories:

• Applications: what are all the websites, productivity tools (email, document editing, spreadsheets) that you and your end users interact with?
• Platforms: the middle layer of services that connects all the applications that you use with the underlying infrastructure. Document every service that is used for hosting applications, accessing data, user identities, and shared APIs.
• Infrastructure: the actual hardware where everything is stored. Does your data stay on your own physical computers or, more likely, does it live on the cloud? Track down where the majority of information is physically stored, starting with your most sensitive.

Understand and size your risks

Now that you know what you're working with, it's time to understand where your biggest vulnerabilities lie.

Since there's no one-size-fits-all solution for every system, we have to prioritize the risks that matter most:

• Which system is most critical to your core operations?
• Which systems hold sensitive information that could undermine trust if it was exposed?
• For some systems, maybe the value for money is most important
• Does a certain system hold data that would be hard to replace if lost?

Threat modelling

The process of threat modelling is a structured way to identify what could go wrong, how serious the consequences might be and what you can do about it.

This exercise builds on a framework by David Eaves of University College London that maps different ways of storing data against the threats each one does, or doesn’t, protect against.

Below you'll find an interactive exercise to help you start to think about the relevant threats to a technology system.

1. First, mark down which threats would have the most impact
2. Based on the threats, we'll suggest which hosting option has the least amount of risk for those threats
3. Open each item in the matrix to see how it applies, and configure our default settings to fit your circumstances

Find your best opportunities to act.

Now that you understand your risk landscape, it’s time to figure out where to start.

Create a 2x2 matrix and plot your potential initiatives against two simple questions:

• Importance: How important is it to address this system? Consider its criticality, current risk score, impact on services.
• Feasibility: How likely is it that we can change it? Consider the availability of alternatives, switching costs, and most importantly organizational readiness or political will.

This will help you identify your quick wins: systems where reducing dependency could make a meaningful difference without requiring years of work or enormous investment.

We've seen over and over that the best way forward is the path of least resistance. Connect the opportunity to something leadership already cares about, whether that's reducing costs, improving cybersecurity, modernizing services or meeting new AI priorities.

A better path to Digital Sovereignty

Digital sovereignty doesn't require Canada to build everything. It requires us to make smarter tradeoffs in our technology strategy.

Canada cannot rebuild the entire global technology supply chain by itself, nor should it. Instead, the goal should be to create a competitive market for technology that makes it easy to change providers as needed.

The path to doing this is already well established: interoperability, open standards, and decoupled architecture can allow governments to use the best technology available without becoming permanently locked into it.

Unfortunately, this sounds pretty technical, so it often becomes a lower priority in practice, but if we break it down there are two principles that anyone can use to make the best choice for their situation.

1. Use the most open technology available

As you saw earlier, vendors have always tended to use their strength in one area to expand their ecosystem up or down the tech stack. A vendor with a popular app will want you to use all their apps. They'll store your data in a format only their apps can open. A cloud infrastructure provider will want you to store your data there. They'll claim that only their approved platform can securely manage access to your data.

Which app gives you the ability to export your data, or reuse your code? Which option has the lowest cost once you consider the cost of switching?

2. Open doesn't always mean D.I.Y.

There's a common misconception that if you don't build everything yourself in-house, you have to accept being locked in with a vendor.

But in reality, there is no technical reason that choosing a vendor means choosing lock-in.

Technologically strong organizations don't build everything themselves, but they also don't think that one or two vendors will solve all their problems.

So there's actually huge demand for solutions that don't lead to lock in, and there's a healthy market of vendors that specialize in enterprise-friendly open source solutions for almost every domain.

Managed open-source can give you the benefits of control and ownership with the assurances around security and privacy that governments need.

Below you can see some examples of the range of open vs. closed and self-managed vs. vendor-managed options.

We often hear government teams say, "We don't have developers!" And we get it.

Many governments have spent decades outsourcing their technology needs in order to reduce costs. Some have had to reduce staff, while others have lost the people who understood their legacy systems. In many cases, hiring expensive full time staff to maintain systems simply doesn't make financial sense.

And that's okay. We're not suggesting governments need to build everything themselves. We're suggesting they need to know enough to be dangerous (or at least to not get taken advantage of).

One of the best investments you can make is in the people you already have. Helping them understand your technology, make informed decisions and develop new skills can gradually reduce your dependence on vendors.

But where do you start?

1. Invest in Technical Talent

In our view, there has never been a better time to invest in bringing in more technical talent. Salaries have flattened out, while at the same time AI has made technologists more impactful than ever.

All the jurisdictions who are leading in their digital maturity are already investing in teams to build the platform that the rest of the organization can build on.

This is very distinct from traditional IT departments whose focus is help desk, software licensing, and integration.

The role of a good technologist now should be building or setting up systems that enable the rest of the organization to help themselves create their own services securely and easily.

Attracting and keeping that talent means changing how government hires and pays technologists. Amanda Clarke and Sean Boots of Carleton University’s School of Public Policy and Administration lay out a practical agenda in A Guide to Reforming Information Technology Procurement in the Government of Canada (2022). It was written for the federal government, but three of their recommendations apply at every level:

• Pay technologists what the market pays. Clarke and Boots recommend a separate classification with competitive pay for software developers and cybersecurity experts, distinct from IT support and system administration roles. They argue this saves public money over time by reducing reliance on costly consultants and lowering the risk of expensive project failures.
• Let experts advance without becoming managers. They call for “dual-stream” career paths, so senior technical staff can reach the highest pay scales as individual contributors, the way most modern tech companies work.
• Hire from anywhere in Canada. They recommend hiring technology staff who can work from anywhere in the country, which opens up a much wider talent pool.

Their guide also covers spend controls, modular contracting and open source, all of which support digital sovereignty. Read the full guide.

2. Make technology a core competency for all roles

Here's the thing about digital sovereignty: it isn't just IT's responsibility.

Technology decisions happen across government every day. Procurement teams negotiate contracts. Program managers choose software. Executives approve investments. Privacy and security teams establish requirements. And increasingly, employees across the organization are creating documents (and even code) using AI.

Organizational competence means setting high expectations for digital literacy, and creating frequent learning opportunities.

Our favourite way to do this? Learning by doing.

3. Build capability through real projects

Now comes the fun part. With the right guidelines, you can help people put their ideas into practice.

Traditional training has its place, but you don't build technology capability just by attending presentations or reading policy documents.

People need opportunities to try things, make decisions and solve real business problems.

AI is making it easier for people with different backgrounds to participate in making their own software. That doesn't mean everyone can suddenly build and maintain secure software without oversight.

Our tip? Start with a small, hands-on learning program built around real organizational challenges.

Here's one way to approach it:

Bring together a small group. Identify people across your organization who are interested in learning and have opportunities to influence technology decisions. They don't all need technical backgrounds.

Give them a real problem. Choose a small project from your existing priorities. Maybe it's a manual process that could be automated, a small internal application, or an opportunity to test an alternative to an expensive vendor product.

Give them the tools and guidance to experiment. Combine practical training in digital sovereignty, AI and modern software delivery with hands-on exercises.

While the team learns together, IT's focus should be less on the business problem and more on learning the technical guardrails for tools and frameworks that teams are using. This allows everyone to learn and experiment together.

Make the learning stick. At Code for Canada, we use the classic mantra: “Demos, not memos.” Show your work, get feedback, make mistakes and learn together. Host regular demos, whether every other week or once a month. Encourage teams to share what they've built and how they've made decisions that strengthen digital sovereignty. Over time, people will feel more confident, experimentation will become part of the culture, and sovereignty will become second nature until "it's just the way you do things around here".