Owen Sound: A Four-Year City Business Plan

Home › Information, Privacy and Canadian Digital Independence › Chapter 32

Information, Privacy and Canadian Digital Independence

Chapter 32Canadian Digital Sovereignty

7,795 words · Mike Seiler · Owen Sound, Ontario

Open in the reader →

Vote on the proposals, hear the audio, read the reviews, search the whole plan.

In this chapter

A city can lose practical control of an essential public service without selling a building, a road or a water plant.

It can happen through a software contract.

A municipality may still legally own its information while becoming operationally dependent upon:

Then the vendor:

The City discovers that it technically owns the data but cannot easily operate without the supplier.

That is a form of dependency.

The original plan proposes moving map.ca into protected public ownership before any municipal adoption, treating information infrastructure as something the community should be able to control rather than merely rent indefinitely. It also proposes resident-focused data stewardship rather than advertising and tracking as the foundation of public digital systems.

That idea belongs inside a much broader principle:

Owen Sound should control the public service, the public information and the ability to continue operating, even when it does not own every piece of technology underneath them.

The Government of Canada now defines digital sovereignty in very similar terms: the ability to exercise autonomy over digital infrastructure, data and intellectual property, and to continue making independent decisions about digital assets regardless of where the underlying technologies were developed, hosted or supported.

That is the definition I would use for Owen Sound.

Digital sovereignty does not mean:

Everything must be built in Owen Sound.

It does not mean:

Every server must sit in City Hall.

It does not mean:

Never use an American company.

It means:

Never become so dependent upon one external technology company that Owen Sound cannot reasonably change direction without losing the public service underneath it.

The simplest test is:

Can we leave?

If the answer is no:

We do not fully control the system.

32.1Sovereignty Is Practical Control

A municipality can own a dataset in theory while lacking practical control over it.

For every important system, ask:

Can the City access its information?

Can the City export it?

Is the export usable somewhere else?

Can another qualified provider operate the service?

Can the City continue temporarily if the vendor disappears?

Does the City understand its critical dependencies?

Does the City control the public identity of the service?

Can Council change policy without requiring the permission of a private founder or vendor?

If not, dependency needs to be understood before the next contract is signed.

32.2Sovereignty Is Not Isolation

Owen Sound should continue using excellent technology from:

when it provides the best lawful public value.

Trying to manufacture every piece of software ourselves would be:

The objective is not technological nationalism for its own sake.

The objective is strategic independence.

The federal digital-sovereignty framework similarly treats sovereignty as something to be increased proportionately rather than requiring every technology to originate or operate exclusively inside Canada.

32.3Buy Capability, Not Captivity

A good vendor relationship can last twenty years.

That is perfectly acceptable.

The problem occurs when the relationship lasts twenty years because leaving became impossible.

A municipal contract should make it possible for Owen Sound to remain with a supplier because:

They continue providing excellent value.

Not because:

We cannot escape the system.

32.4The Municipal Sovereignty Question

Before approving significant technology, Council should be able to understand:

What part of this system does Owen Sound actually control?

That answer may include:

It may also reveal things the vendor controls.

Neither is automatically bad.

The dependency simply needs to be visible.

Municipal digital independence does not replace existing Ontario privacy and access law.

The Municipal Freedom of Information and Protection of Privacy Act establishes both public-access principles for municipal information and privacy protections for personal information held by municipal institutions.

Ontario has also created the Enhancing Digital Security and Trust Act, 2024, which establishes a legislative framework through which cybersecurity and artificial-intelligence requirements can be applied to public-sector entities, including institutions covered by municipal freedom-of-information law.

As of July 1, 2026, Ontario's current cybersecurity regulation under that Act prescribes specified education institutions, certain hospitals, children's aid societies and school boards. Municipalities are not among the entities prescribed by that particular regulation at this time.

That distinction matters.

Owen Sound should not claim:

Ontario currently requires this exact municipal cybersecurity program

when the current regulation does not.

The better approach is:

Build strong municipal practices because they are prudent, meet current municipal obligations, and prepare for an evolving provincial framework.

32.6Municipal Standard Can Exceed the Minimum

Legal compliance is the floor.

Not the strategy.

If the law requires:

the City may still decide that:

is better public stewardship.

The additional safeguards should remain:

32.7The Seven Layers of Digital Sovereignty

Every important City system should be examined across seven layers.

1. Public Service

What does the resident actually need?

2. Data

Who controls the information?

3. Identity

Who controls users, accounts and authentication?

4. Software

Who controls the application and configuration?

5. Infrastructure

Where does it operate?

6. Supplier

Who provides and supports it?

7. Knowledge

Does anyone inside or available to the City understand how the system works?

A system can fail at any layer.

32.8Start With the Service

Do not begin a technology procurement by asking:

Which software should we buy?

Begin:

What public service are we trying to provide?

Then ask:

What technology is actually necessary?

This prevents the City from buying a platform first and reorganizing public service around whatever the platform happens to do.

32.9Technology Serves Policy

Council establishes lawful public policy.

Technology implements it.

The direction should not reverse.

If a vendor says:

Our software cannot support that policy, so change the policy,

Council should ask whether:

Private software architecture should not quietly become municipal law.

32.10Classify Systems by Importance

Not every system needs the same sovereignty standard.

A tool used to design a recreational poster is different from software controlling:

Create tiers.

Critical

Failure could significantly affect:

Important

Failure materially disrupts City operations but can be tolerated temporarily.

Routine

Failure is inconvenient but does not seriously impair municipal service.

Spend resilience money according to consequence.

32.11Critical Municipal Digital Systems

The review should include systems supporting functions such as:

This is not a declaration that every system in those categories has identical risk.

The purpose is to identify where dependency matters most.

32.12The Digital Systems Index

Add a digital layer to the Infrastructure and Systems Index from Section 12.

For significant systems, record:

Do not publicly expose security details that would make systems easier to attack.

Maintain a secure internal record and publish a safe public summary.

32.13Know the Vendor

For every major digital service, Owen Sound should know:

The brand appearing on the login screen may represent only one part of the supply chain.

32.14Know the Dependency Chain

A City may buy software from Company A.

Company A may depend upon:

The City does not need to map the entire internet.

It should understand major dependencies whose failure could interrupt an important public service.

The Canadian Centre for Cyber Security specifically includes supply-chain management, interoperability, portability, data security and business continuity among the areas organizations should assess when evaluating cloud security.

32.15Supplier Concentration

Ask:

How many critical City systems fail if this one provider fails?

Using one supplier can create:

It can also create concentration risk.

The correct balance depends upon the service.

Do not diversify merely to have more vendors.

Do not consolidate merely because one vendor offers a bundle.

Understand the consequence.

32.16The Exit Test

Every major software procurement should answer before purchase:

If we decide to leave five years from now, what exactly happens?

The answer should identify:

This becomes the Digital Exit Test.

32.17Export Is Not Enough

A vendor may say:

You can export your data at any time.

Ask:

Into what?

Ten million rows inside an undocumented proprietary file may technically be an export.

It may be practically useless.

The City needs:

The test is usable portability.

32.18Export Before Renewal

Before renewing a major system, perform an export test where practical.

Do not wait until a contract dispute to discover:

A periodic export test is digital fire prevention.

32.19Open Standards

Prefer widely documented and interoperable standards where they reasonably meet the need.

Open standards can make it easier for:

The Government of Canada's current sovereignty framework similarly identifies open standards and interoperable sourcing as tools supporting continuity and reducing dependency.

32.20Open Does Not Mean Unsecured

A documented file format can be open.

The data itself can remain:

Do not confuse:

open standard

with

open access.

One concerns portability.

The other concerns permission.

32.21Application Programming Interfaces

Where systems need to communicate, prefer documented interfaces where practical.

An interface allows one system to exchange information with another without rebuilding everything manually.

Before depending upon an interface, know:

An interface controlled entirely at a vendor's discretion is still a dependency.

32.22Avoid Unnecessary Custom Lock-In

Custom software can be useful.

It can also create dependency on the only person who understands it.

If the City purchases significant custom development, establish:

The exact intellectual-property structure depends upon the procurement.

Ignorance should not be part of it.

32.23Source Code

The City does not need the source code for every commercial product it uses.

For highly customized or critical systems, however, Council should understand what happens if the developer:

Possible safeguards can include:

Choose the safeguard proportionate to risk.

32.24Documentation Is Infrastructure

A system nobody understands except one employee or contractor is fragile.

Important systems need appropriate documentation covering:

Documentation should be updated when the system changes.

Not written once and forgotten.

32.25Knowledge Concentration

Ask:

What happens if the one person who knows this system retires tomorrow?

That question applies to:

Create:

Digital sovereignty also means knowledge sovereignty.

32.26Cloud Computing

Cloud computing can provide:

The Canadian Centre for Cyber Security's guidance recognizes those benefits while emphasizing that organizations must assess and manage cloud-specific risk throughout the service lifecycle.

The policy should not be:

Cloud bad.

Nor:

Cloud always better.

It should be:

Choose the architecture that best manages the actual risk and cost.

32.27Self-Hosting

Running systems ourselves can provide greater direct control in some situations.

It also creates responsibilities for:

Self-hosting is not sovereignty if the City lacks the capacity to operate it safely.

32.28Hybrid Architecture

Some future municipal systems may reasonably use:

together.

The architecture should follow:

Do not make one technology model into ideology.

32.29Data Residency

Where sensitive public data is involved, the City should know where it is:

Canadian residency may reduce some legal and operational risks and may be desirable or required in particular circumstances.

But location alone does not create complete sovereignty.

32.30Residency Is Not the Same as Jurisdiction

The Government of Canada's 2026 analysis of public cloud explicitly notes that even data physically stored in a particular location may be affected by foreign law depending upon the provider and its international legal exposure.

Therefore:

Data in Canada

and

Data under exclusively Canadian legal control

are not automatically the same statement.

The City should examine:

with appropriate legal expertise.

32.31Canadian Hosting Preference

For selected sensitive or critical systems, Owen Sound should examine whether Canadian hosting materially improves:

A preference should still consider:

The objective is risk reduction.

Not a flag beside the server.

32.32Canadian Vendor Does Not Automatically Mean Sovereign

A Canadian company may itself depend almost completely upon:

That does not make the company unsuitable.

It means the underlying dependency should still be understood.

Ask one level deeper.

32.33Foreign Vendor Does Not Automatically Mean Unsuitable

Likewise, an international supplier may provide:

Evaluate the system.

Not the passport of the salesperson.

32.34Canadian Capacity

Where Canadian suppliers can provide equivalent or better:

the City should seek to ensure they have a fair opportunity to compete within applicable procurement and trade rules.

This connects directly to Section 11.

Strengthen Canadian capacity through fair opportunity, not hidden favouritism.

32.35Local Technology Companies

Owen Sound and Grey Bruce technology companies should likewise have an understandable route to public procurement.

That does not mean:

Local company automatically wins.

It means:

Public systems still require professional standards.

32.36Small Vendor Risk

A small Canadian company may provide:

It may also face:

The City can address those risks through appropriate contractual safeguards.

Supporting local technology does not require pretending risk does not exist.

32.37Large Vendor Risk

A multinational vendor may appear stable.

It can still:

Size eliminates some risks.

It creates others.

The Digital Exit Test applies to everyone.

32.38Procurement Questions

Every significant digital procurement should answer:

What public service does this support?

What information does it handle?

What is the security classification?

Where is information stored?

Who can access it?

What are the major subcontractors?

Can the City export everything?

What format?

What does exit cost?

What happens when the contract ends?

How are breaches handled?

How are backups handled?

What happens if the vendor is unavailable?

The questions belong in procurement before the purchase.

32.39Price Is Only One Cost

A software licence may cost:

$20,000 per year.

The real cost may also include:

The Financial Standard applies.

Calculate the complete lifecycle.

32.40Cheap Entry Can Mean Expensive Exit

Some platforms make initial adoption very inexpensive.

Years later, migration can become extremely costly because:

That does not mean avoid the platform.

It means include future exit cost when evaluating today's bargain.

32.41Contract Renewal Calendar

Maintain a central calendar of major technology-contract:

A City should not discover:

The contract auto-renews tomorrow

when Council wanted to examine alternatives.

32.42No Accidental Auto-Renewal

Where practical and contractually possible, important systems should receive deliberate renewal review before long commitments continue.

The review can be proportional.

Routine low-risk subscriptions do not need Council debate.

Critical multi-year systems do.

32.43Data Classification

Owen Sound should establish a clear internal approach for distinguishing information according to sensitivity and operational importance.

Broad categories might include:

The exact framework should be developed by qualified staff and legal/privacy professionals.

Different information deserves different safeguards.

32.44Not Everything Is Sensitive

Over-classification creates:

A park map is not a water-treatment control password.

Apply security proportional to consequence.

32.45Not Everything Is Public

The Open Government principle also has limits.

Information that could expose:

may require protection under applicable law.

Open by default does not mean reckless publication.

The City cannot exercise meaningful digital sovereignty if it does not know:

MFIPPA's purposes include protecting individuals' privacy concerning personal information held by municipal institutions while providing appropriate access rights.

Data governance and sovereignty therefore belong together.

32.47Data Minimization

The simplest way to reduce many privacy and cybersecurity risks is:

Do not collect information we do not need.

Every unnecessary field becomes another:

Good data governance begins before storage.

32.48Encryption

Appropriate sensitive information should use suitable security controls, including encryption where required by risk and professional standards.

The federal government's cloud-sovereignty work identifies encryption and control of cryptographic keys among the tools used to reduce exposure of protected information.

The technical implementation should be determined by qualified professionals.

Council should understand the governance question:

Who ultimately controls access?

32.49Encryption Keys

For especially sensitive systems, examine:

The strongest encryption in the world is not useful if:

Security requires recoverability too.

32.50Identity Is Infrastructure

A municipality increasingly depends upon digital identity:

If identity fails, many services can fail at once.

Treat identity systems as critical infrastructure where appropriate.

32.51Own the Municipal Domain

The City should maintain clear control over its official:

A public identity should not depend upon the personal account of:

Institutional infrastructure belongs to the institution.

32.52Email Continuity

Municipal email often functions as:

The City should understand:

Changing an email vendor should not erase municipal history.

32.53Multi-Factor Authentication

Appropriate high-value and administrative systems should use stronger authentication controls based on professional cybersecurity guidance.

The exact controls will evolve over time.

The principle should not:

One stolen password should not automatically unlock an essential City system.

32.54Administrative Privilege

Not every employee should have:

access.

Use:

least necessary privilege.

Access should follow:

When someone changes jobs:

Update access.

32.55Departing Employees

Digital offboarding should be as routine as collecting:

When an employee or contractor leaves:

A former worker should not remain an invisible administrator six months later.

32.56Contractor Access

External support companies may legitimately require system access.

The City should know:

Vendor support access should not be permanent and unlimited merely because that is easiest.

32.57Backup Is Sovereignty

If Owen Sound's only copy of critical information exists inside the vendor's active system, the City is highly dependent upon that vendor.

Important systems need appropriate backup strategies.

The architecture may vary.

The objective is:

A failure in one place does not erase the public record or the public service.

32.58Backup Independence

For critical systems, ask whether backups are independent enough that the same:

cannot destroy both the primary data and every backup.

The technical design belongs to professionals.

Council should require that the question has been answered.

32.59Restore Tests

A backup should periodically be tested through actual restoration where appropriate.

The useful question is not:

Do we have backups?

It is:

Can we restore the service from them?

32.60Recovery Objectives

Different systems can tolerate different downtime.

For each important service, determine professional recovery objectives.

A recreational booking system may tolerate a longer outage than a system essential to:

Spend resilience resources accordingly.

32.61Manual Continuity

For essential public services, maintain reasonable methods to continue operating when digital systems fail.

Examples may include:

The manual process may be slower.

That is acceptable.

Continuity means the service does not disappear.

32.62Cybersecurity Maturity

Owen Sound should periodically evaluate its cybersecurity maturity against an appropriate professional framework.

Ontario's current 2026 cybersecurity regulation for the public-sector entities it presently prescribes uses formal cybersecurity maturity assessment and incident-reporting concepts. Municipalities are not currently prescribed under that regulation, but the model provides a useful indication of the province's evolving public-sector direction.

Owen Sound should not wait for a crisis to ask:

How mature are our controls?

32.63Senior Accountability

Cybersecurity should have a clearly identified senior administrative owner.

That does not automatically require creating another executive position.

Someone with sufficient authority needs responsibility for ensuring:

No system should depend upon:

I thought IT was handling that.

32.64Council Oversight

Council does not need:

It does need to understand:

Governance requires enough information to make budget and risk decisions without publishing attack instructions.

32.65Cyber Risk Register

Maintain a protected internal risk register for significant technology concerns.

Examples:

Give each significant risk:

Risk that nobody owns usually remains risk.

32.66Asset Inventory

Cybersecurity begins with knowing what exists.

Maintain appropriate inventory of:

You cannot patch something you forgot exists.

32.67Shadow Technology

Employees may sometimes adopt software because it solves a problem quickly.

That can create systems the City does not know hold:

Make approved technology easy enough to use that staff do not feel forced into unsafe workarounds.

Then establish clear rules for new tools.

32.68Legacy Systems

Old software may continue working long after:

ends.

Maintain a legacy-system list.

For each:

"Still turns on" is not a lifecycle strategy.

32.69Digital Preventive Maintenance

Technology needs preventive maintenance just like:

Examples:

A municipal budget should recognize these recurring needs.

32.70Digital Debt

Postponed maintenance creates digital debt.

The City may save money for a year by delaying:

Eventually the accumulated problem becomes:

Track digital debt alongside physical infrastructure risk.

32.71Operational Technology

Systems associated with physical municipal infrastructure deserve special attention.

Technology used around:

can have consequences beyond lost files.

The Cyber Centre's cloud and risk-management guidance emphasizes lifecycle risk, continuity and security controls, principles that become even more important when digital systems support physical operations.

Operational systems should be reviewed according to professional standards appropriate to the actual infrastructure.

32.72Separate Where Necessary

Critical operational systems may require stronger separation from:

The technical architecture belongs to qualified specialists.

The policy rule is:

Convenience should not connect systems that safety requires us to separate.

32.73Water Must Not Depend on One Password

Essential municipal systems should not have obvious:

failure points where reasonable safeguards can remove them.

Resilience is layers.

32.74Financial Systems

Financial software should protect:

Controls should include appropriate:

Software convenience should not eliminate financial control.

32.75Payment Systems

If the City changes payment providers, residents should not lose access to municipal services.

Understand:

This connects to the payment-cost work in Shop Local.

32.76Records

A municipal record may need to remain available longer than the software used to create it.

Records strategy should therefore be separated conceptually from software lifespan.

A record created in 2027 may still matter when the 2027 application no longer exists.

Preserve the record.

Not necessarily the obsolete software.

32.77Maps and GIS

Geographic information can become one of the City's most valuable digital assets.

The City should retain control over core public geographic data sufficiently to:

A mapping vendor can change.

The geographic knowledge of Owen Sound should remain.

32.78Public Website

The City website is a critical public doorway even if it is not critical infrastructure in the same sense as water.

The City should control:

A website redesign should not erase:

without a migration plan.

32.79Social Media Is Not Sovereign Infrastructure

Social platforms can be valuable distribution channels.

They should not be the sole home for:

If a social platform suspends the City's account tomorrow:

The public information system should still work.

32.80Artificial Intelligence

Artificial intelligence creates a new version of the same sovereignty question.

A City employee may enter information into an AI system.

The answer may be generated by:

The first question should not be:

Can AI do this?

It should be:

What information, decision and dependency does using AI create?

32.81Ontario's AI Framework

Ontario's Enhancing Digital Security and Trust Act establishes a framework through which requirements concerning public-sector AI can be prescribed, including transparency, accountability, risk management and human oversight provisions in prescribed circumstances.

That makes it sensible for Owen Sound to build its own AI inventory and governance practices now while carefully distinguishing current municipal legal requirements from requirements that may apply only when prescribed.

32.82AI Inventory

The City should know which meaningful AI systems it is using.

The inventory might include:

Do not try to catalogue every spell-check function as a major AI system.

Focus on uses that materially affect:

32.83Low-Risk AI

Examples may include assistance with:

These uses still require:

but may justify lighter governance.

32.84Higher-Risk AI

Greater scrutiny should apply where automated tools influence matters involving:

The higher the consequence:

The stronger the human oversight.

32.85AI Does Not Receive Public Authority

A software model should not independently exercise coercive municipal power merely because it can produce a recommendation.

AI may help staff:

An accountable human or legally authorized process remains responsible for decisions requiring:

32.86No Black-Box Denial

A resident should not receive:

Application denied by algorithm

with no meaningful explanation where the decision legally or practically requires accountable human reasoning.

The public-reasons standard established earlier still applies.

Technology does not eliminate procedural fairness.

32.87AI and Personal Information

Before placing resident information into an AI service, determine:

Do not assume an AI chat box is equivalent to an internal City document.

32.88No Sensitive Data in Unapproved AI

Employees and Civic Corps participants should receive a clear rule:

Do not place protected resident or municipal information into an unapproved public AI service.

Training should explain why.

A policy employees understand is more useful than a twenty-page prohibition nobody reads.

32.89AI Training Clauses

Where the City purchases an AI-enabled service, contracts should clarify whether City information may be used to:

the provider's models.

The appropriate answer may vary by system.

It should not remain unknown.

32.90Prompt Retention

AI providers may retain:

according to service design and contract.

The City should understand those practices before using the service for municipal work.

Retention is still retention even when the interface looks conversational.

32.91AI Accuracy

Generative AI can produce:

information.

Municipal use should require appropriate source verification for consequential outputs.

The rule is:

AI may draft the answer. A responsible person owns the answer.

32.92AI and Sources

Where AI is used to help answer a resident's factual municipal question, the system should ideally point back to the authoritative:

The resident should be able to verify.

32.93AI Translation

AI translation may make City information more accessible.

For important:

communications, use an appropriate level of human verification.

Ease of translation should not create false confidence in accuracy.

32.94AI Vendor Exit

Ask the same sovereignty question of AI providers:

What happens if this model disappears?

Can the City:

Do not build a critical municipal service around one proprietary model without understanding the exit.

32.95Model Independence

Where practical, system architecture should separate:

from any particular AI model.

Then the underlying model may be replaceable later.

Designing for substitution creates leverage.

32.96Open-Source Software

Open-source software can sometimes provide:

It can also create:

responsibilities.

The City should evaluate open source on:

Not ideology.

32.97Open Source Does Not Mean Free

Software licence cost may be zero.

Operating cost may include:

Compare complete cost.

32.98Proprietary Does Not Mean Bad

Commercial proprietary software can provide:

The sovereignty question remains:

Can we get our information out?

Can we continue the public service if this relationship changes?

32.99Build Versus Buy

For each substantial digital need, consider:

Buy

When mature products already solve the problem efficiently.

Build

When the requirement is unique enough to justify ownership and development.

Partner

When another public organization shares the same need.

Open Source

When an existing community solution provides strong value.

Do not build because building sounds innovative.

Do not buy because buying is easier this month.

32.100Shared Municipal Technology

Many Canadian municipalities solve similar problems.

They all need versions of:

Owen Sound should explore whether selected public-interest systems can be:

That is one path to Canadian digital capacity.

32.101Grey County Partnership

Before duplicating major technology, ask:

Does Grey County already operate something we can lawfully and practically share?

Likewise:

Could Owen Sound create something the County and neighbouring municipalities could reuse?

Digital infrastructure can cross municipal boundaries more easily than physical infrastructure.

32.102Shared Procurement

Several municipalities may sometimes gain:

through collaborative procurement.

That needs:

Shared purchasing should not create a regional system that becomes even harder to leave.

Apply the Exit Test at the shared level too.

32.103Canadian Municipal Open Playbook

When Owen Sound develops a useful:

publish reusable versions where legally appropriate.

A small municipality elsewhere in Canada should not have to reinvent the same governance from scratch.

32.104Digital Sovereignty Is Bigger Than map.ca

The map.ca proposal is one example.

The principle applies equally to:

No platform receives exemption because the City likes:

Same questions.

32.105map.ca Must Pass the Hardest Test

Because map.ca is associated with the person proposing this plan, any future municipal consideration should face particularly strong scrutiny.

The system should have to demonstrate:

The public objective comes first.

32.106No Founder Dependency

A platform cannot be genuine public infrastructure if it depends permanently upon:

Call Mike. He knows how it works.

If map.ca or any related system is ever transferred into public operation:

The founder becoming unnecessary to daily operation is a sign of successful institutionalization.

32.107No Founder Veto

Public infrastructure cannot remain subject to private approval over:

Once governed publicly, public governance decides.

This remains true even if the founder strongly disagrees.

32.108No Hidden Royalty

Any continuing:

connected to a public platform must be disclosed and independently reviewed.

The cleanest public-interest model is one where residents can see that public adoption did not create a private political windfall.

32.109map.ca Cannot Be Required

Residents should not need a map.ca account to:

If map.ca eventually provides useful features:

Good.

Essential municipal access still requires appropriate alternatives.

Public infrastructure should reduce dependence.

Not create a new one.

32.110The Public Identity Question

If residents eventually receive permanent civic digital identities or addresses through a public-interest system, those identities should be:

The City should not create one account that becomes a universal dossier of a resident's:

Convenient integration can become dangerous concentration.

32.111Separate Data by Purpose

Even where one public portal provides access to several services, underlying information should remain governed by purpose.

A recreation registration does not need to merge with:

One Door

does not require

One Giant Profile.

32.112Resident-Controlled Connections

Where different services can be connected, the resident should understand:

The most convenient technical design is not always the best civic design.

32.113Digital Sovereignty for Residents

Municipal digital sovereignty should ultimately support personal digital independence too.

Residents should increasingly understand:

A digitally sovereign community begins with capable citizens.

32.114Youth Challenge

Young people should be invited into this work.

Ask Civic Corps participants:

If Owen Sound had to replace this service tomorrow, how would we do it?

That teaches:

It also invites a generation raised inside digital platforms to question dependency adults may no longer notice.

32.115Digital Apprenticeships

Civic Corps could eventually support paid learning opportunities involving:

Students work under qualified supervision.

They do not receive unrestricted access to sensitive systems merely because they are technically talented.

32.116Canadian Technology Education

Schools, colleges, businesses and Civic Corps partners can expose young people to:

The goal is not:

Stop using foreign technology.

It is:

Build enough Canadian capability that we have choices.

32.117Sovereignty Comes From Skills Too

Buying Canadian software without Canadian workers capable of:

it does not produce durable sovereignty.

Invest in people.

A country capable of building and maintaining systems has more options than one that can only purchase them.

32.118Local Innovation

The City's role can include creating appropriate opportunities for local companies and students to solve defined public challenges.

Example:

Can someone create an open way to publish this dataset?

Then use fair procurement or challenge rules.

Innovation should be:

Not:

32.119Public Test Environments

Where practical, create safe non-production environments for:

Do not give experimental code access to:

Innovation needs a sandbox.

Public service needs protection.

32.120Do Not Build a Municipal Data Centre for Prestige

Digital sovereignty should not be used to justify building an expensive server facility merely because:

Then we own the servers.

Before any local hosting facility:

Physical ownership can create new dependency on local expertise and capital.

The objective is resilient service.

Not a room full of blinking lights.

32.121Use Existing Capacity First

Before new infrastructure, examine:

The best sovereign solution may be contractual and architectural.

Not physical construction.

32.122Geographic Redundancy

For genuinely critical systems, keeping every copy in one building may be less resilient than appropriately distributed infrastructure.

Sovereignty should not be confused with:

Everything located beside the Mayor's office.

A flood, fire or outage can affect local infrastructure too.

Resilience may require geographic separation.

32.123Supply-Chain Resilience

Technology hardware depends upon global supply chains.

Owen Sound will not manufacture:

Digital sovereignty therefore cannot mean total self-sufficiency.

It means understanding which dependencies require:

Practical resilience beats impossible independence.

32.124Critical Spares

For selected infrastructure, maintaining:

may reduce downtime.

The inventory should follow:

Do not warehouse expensive technology that will become obsolete before it is needed.

32.125Vendor Outage Exercise

For critical providers, periodically ask:

What if this vendor is unavailable for a day?

A week?

Conduct tabletop exercises where the consequence justifies them.

The purpose is not predicting every failure.

It is finding the first obvious dependency before the real outage.

32.126The Annual Exit Drill

For a selected major system each year, conduct a practical sovereignty review.

Attempt to:

Ask:

Could we actually leave?

That transforms vendor exit from a paragraph in a contract into an operational fact.

32.127Renewal Review

Before renewing significant technology, score:

Performance

Does it work?

Cost

Is it still good value?

Security

Is risk acceptable?

Privacy

Is information appropriately handled?

Portability

Can we leave?

Canadian Resilience

Are there jurisdictional or supply dependencies worth changing?

User Experience

Does it serve residents and staff well?

A long-running vendor should not receive automatic renewal simply because change is inconvenient.

32.128Technology Reserve

Large digital replacements should be planned financially.

A municipality that knows:

This major system likely needs replacement in four years

should begin budgeting before the emergency.

Digital replacement belongs in long-term capital and operating planning just like physical assets.

32.129Avoid Subscription Creep

Small software subscriptions can multiply.

Once each year, review:

Ask:

Are we paying three companies to perform essentially the same task?

Cancel what is unnecessary.

Efficiency applies digitally too.

32.130Licence Utilization

For major subscription software:

can help identify waste.

Do not use employee surveillance to determine productivity.

Measure whether the licence itself is needed.

32.131Digital Sovereignty Scorecard

The public scorecard should include safe high-level measures.

Systems

Contracts

Portability

Backup

Legacy

Canadian Capacity

Cybersecurity

Privacy

AI

Cost

Do not expose vulnerabilities merely to make the dashboard detailed.

32.132Sovereignty Risk Rating

Each critical system can have an internal sovereignty-risk rating.

Possible factors:

A low score does not mean:

Vendor bad.

It means:

Dependency requires attention.

32.133Publish the Problem, Protect the Vulnerability

The public can be told:

Three critical systems require improved vendor-exit planning.

The public does not need:

Here are the exact unpatched systems and administrator endpoints.

Transparency and security are not enemies.

Good governance knows what belongs in each category.

32.134First 100 Days

The first 100 days should establish the baseline.

1. Digital Systems Inventory

Identify significant municipal:

2. Criticality Review

Classify systems according to service consequence.

3. Contract Calendar

Map:

4. Data Map

Identify which major systems hold:

information.

5. Vendor Dependency Map

Identify major hosting, identity and support dependencies.

6. Backup and Recovery Review

Ask whether critical systems can actually be restored.

7. Portability Review

Choose several important systems and test whether data can be exported usefully.

8. AI Inventory

Identify material AI currently used by the City and establish an interim employee-use rule.

Confirm current obligations under:

10. Publish a Safe Baseline Report

Do not publish attack details.

Show:

32.135Year One

During Year One:

The goal is not to replace everything.

It is to know what we depend upon.

32.136Year Two

During Year Two:

32.137Year Three

During Year Three:

If evidence supports a community-owned or shared infrastructure project:

Bring the full business case to Council.

Do not build it merely because Year Three arrived.

32.138Year Four

By Year Four, Owen Sound should be able to answer:

Do we know every major digital system we depend upon?

Do we know what each costs?

Do we know when each contract expires?

Do we know where important information is stored?

Do we understand major foreign and domestic dependencies?

Can we export our information?

Have we tested that export?

Can critical systems be restored?

Do important systems have continuity plans?

Are unsupported legacy systems declining?

Do we know which AI systems materially affect public operations?

Is sensitive information protected from inappropriate AI use?

Have Canadian suppliers had fair opportunities?

Have we shared useful municipal technology practices with other communities?

Could Owen Sound leave its most important vendors without losing the public service itself?

The last question is the heart of the entire section.

32.139What Success Looks Like

Success does not mean:

Owen Sound owns every server.

Success means:

Owen Sound owns its decisions.

It means the City can say to a technology supplier:

We would like to continue working with you because you are providing good value.

Rather than:

We have no realistic option but to stay.

It means:

That is sovereignty.

32.140What This Is Not

Canadian Digital Sovereignty is not:

It is practical independence.

The Canadian Digital Sovereignty Commitment

Digital infrastructure increasingly determines whether government itself can function.

The public should therefore know that the City's information and essential services cannot quietly become the permanent property of a software relationship.

The commitment is:

Define digital sovereignty as practical control, not technological isolation.

Start every technology decision with the public service rather than the software.

Classify digital systems by actual consequence.

Create a Digital Systems Index.

Know who owns every important system internally.

Know the major vendor and supply-chain dependencies.

Ask how we leave before we sign.

Test whether exported information is actually usable.

Prefer open and interoperable standards where they provide good value.

Document custom systems.

Protect against one-person knowledge dependency.

Use cloud technology where it makes sense.

Self-host where it makes sense.

Treat neither approach as ideology.

Know where sensitive data is stored and processed.

Recognize that Canadian data residency and Canadian legal control are related but not identical questions.

Give capable Canadian technology suppliers fair opportunity within the law.

Judge every supplier on security, resilience, lifecycle value and exit.

Minimize the personal information government collects.

Protect identity systems as important infrastructure.

Maintain independent, tested recovery for critical information.

Test restoration, not merely backup.

Maintain reasonable manual continuity for essential services.

Track and reduce unsupported legacy technology.

Treat digital maintenance as infrastructure maintenance.

Track digital debt rather than allowing it to become an emergency.

Protect operational systems supporting physical infrastructure.

Inventory meaningful AI use.

Keep accountable humans responsible for consequential public decisions.

Never put sensitive resident information into unapproved public AI systems.

Understand whether an AI provider uses municipal information for training.

Design AI systems so the underlying model can be changed where practical.

Evaluate open-source and proprietary technology by complete lifecycle value.

Share useful municipal digital systems and governance tools with other Canadian communities.

Work with Grey County where shared infrastructure makes more sense than duplication.

Never build a server facility merely for the appearance of independence.

Develop Canadian skills as well as Canadian technology.

Give young people practical pathways into cybersecurity, data and civic technology.

Apply the same sovereignty test to map.ca that we apply to every other provider.

Give no private founder permanent control over public digital infrastructure.

Never use one convenient public portal to build one giant resident surveillance profile.

Review major technology before renewal rather than after lock-in.

Conduct real vendor-exit and recovery exercises.

Publish the governance without publishing the vulnerability.

A sovereign city does not have to make everything itself.

It needs to know that it can still govern itself when the technology changes.

Own the public purpose. Control the public information. Understand the dependencies. Keep the ability to leave. Build Canadian capacity where it makes us stronger. Never let convenience quietly become captivity.

← Chapter 31: The Safe Information ProgramChapter 33: map.ca as Public Infrastructure →