Owen Sound: A Four-Year City Business Plan

Home › Appendices › Appendix J

Appendices

Appendix JPrivacy, Information and Digital Governance Standards

12,389 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

Open government should expose government, not unnecessarily expose residents

A modern municipality cannot operate without information.

It needs information to:

But information creates power.

The more government knows about a person, the more carefully that information must be:

Digital technology can make government:

It can also make government:

The purpose of municipal digital government should not be:

collect everything because we can.

It should be:

know enough to perform the public service well, while collecting as little unnecessary personal information as reasonably possible.

Ontario's Municipal Freedom of Information and Protection of Privacy Act, MFIPPA, deliberately combines two public objectives: access to government information and protection of individual privacy. The current statute, as of August 2026, provides the central municipal framework governing those interests.

That balance should become Owen Sound's governing principle:

Open government should expose government, not unnecessarily expose residents.

The second principle is:

Collect less. Explain why. Protect what remains. Delete or dispose of it lawfully when it is no longer required.

The third is:

Technology should serve residents. Residents should not be required to serve the technology.

The fourth is:

Digital sovereignty is not about rejecting modern technology. It is about retaining practical control over essential public systems.

The question behind every critical municipal technology contract should therefore be:

Can we leave?

J.1Purpose

This appendix establishes the operating rules for:

J.2Five Safe Information Principles

The Safe Information Program should operate according to five principles:

Access

Accuracy

Privacy

Resilience

Independence

J.3Access

Residents should be able to:

the public information needed to interact with their City.

J.4Accuracy

Official municipal information should be:

J.5Privacy

Government should collect and retain only information it can:

J.6Resilience

Residents should still be able to receive important services and information when:

J.7Independence

The City should retain sufficient practical control to:

important public information and systems.

J.8The Public Information Distinction

Separate:

Information About Government

from

Information About People.

J.9Information About Government

Default should lean toward:

J.10Information About People

Default should lean toward:

J.11Same Database Can Contain Both

Therefore:

J.12Open Books

Should expose:

J.13Open Books Should Not Expose

J.14Infrastructure Index

Should expose:

J.15Infrastructure Index Should Not Expose

J.16Public Service Dashboard

Should expose:

J.17Public Service Dashboard Should Not Expose

J.18Privacy Is Not Secrecy for Government

Important.

J.19Transparency Is Not Surveillance of Residents

Equally important.

J.20Current Ontario Framework

MFIPPA currently restricts municipal collection of personal information to circumstances authorized by statute, used for law enforcement, or necessary to the proper administration of a lawfully authorized activity. It also generally requires direct collection from the individual unless an exception applies.

J.21Collection Notice

Where the Act requires notice, the current framework includes information such as:

J.22Use

Personal information cannot simply be reused because:

Current MFIPPA limits use to specified lawful circumstances, including the purpose for which the information was obtained or a legally consistent purpose.

J.23Disclosure

Personal information cannot simply be shared because:

MFIPPA provides specific circumstances in which disclosure is permitted.

J.24Consistent Purpose

Under the current Act, where personal information was collected directly, whether another use or disclosure is a consistent purpose includes whether the individual might reasonably have expected it.

J.25Accuracy

MFIPPA requires reasonable steps regarding accuracy and currency before personal information is used, subject to the Act's exceptions.

J.26Retention

MFIPPA also regulates retention and disposal of personal information, with detailed requirements supplied through regulation.

J.27Security

Ontario Regulation 823 currently requires reasonable measures to prevent unauthorized access to municipal records, restrict access to people who need records for their duties, and protect records against inadvertent destruction or damage.

Those are legal requirements.

The policy in this appendix goes further in several areas as:

J.292027 Transition

Ontario has enacted further MFIPPA privacy obligations scheduled to take effect for municipal institutions on January 1, 2027. The Information and Privacy Commissioner of Ontario's August 2026 Privacy Impact Assessment guide expressly states that it has been updated to incorporate those future MFIPPA requirements.

J.30Breach Changes

The IPC also states that certain explicit municipal privacy-breach reporting and affected-individual notification requirements take effect January 1, 2027.

J.31Practical Response

Owen Sound should not wait until:

to prepare.

J.32Transition Standard

During the 2026 transition:

Identify future statutory obligations.

Update policies.

Train responsible staff.

Update incident procedures.

Update procurement.

Prepare Privacy Impact Assessment workflows.

J.33Current Law Versus Future Law

Every legal document should distinguish:

Current Requirement

from

Enacted Future Requirement

from

City Best Practice.

J.34Do Not Call Future Requirement Current

No.

J.35Do Not Ignore Enacted Future Requirement Either

No.

J.36Privacy by Design

Privacy should be considered:

before launch.

J.37Not After Complaint

J.38Not After Breach

J.39Not After Procurement

J.40Privacy Question One

Why do we need this information?

J.41Question Two

What legal authority supports collecting it?

J.42Question Three

What is the minimum information necessary?

J.43Question Four

Could we provide the service without identifying the person?

J.44Question Five

Who needs access?

J.45Question Six

How long must it remain?

J.46Question Seven

Who outside the City receives it?

J.47Question Eight

Where is it stored and processed?

J.48Question Nine

Can the City retrieve and delete or dispose of it according to law and policy?

J.49Question Ten

What happens if the vendor disappears?

J.50Data Minimization

Collect:

the least information reasonably necessary for the lawful municipal purpose.

J.51Optional Field

If field is genuinely optional:

Label it:

J.52Required Field

Needs:

J.53"Nice to Know"

Not sufficient.

J.54"Marketing Might Use It"

Not sufficient municipal purpose by itself.

J.55"AI Might Need It Later"

Not sufficient.

J.56"Everyone Else Collects It"

Not sufficient.

J.57Default Form Review

Every municipal form should periodically ask:

Do we still need every field?

J.58Form Creep

Forms often accumulate:

J.59Remove Them

Where lawful.

J.60Identity

Do not require identity when service can reasonably be provided:

J.61Public Information

Residents should not need an account to:

J.62Meeting Agenda

No account.

J.63Budget

No account.

J.64Road Closure

No account.

J.65Recreation Schedule

No account merely to:

J.66Public Map

No account merely to:

J.67Account May Be Needed

For:

J.68Account Must Have Purpose

Always.

J.69Universal Municipal Account

Do not create merely because:

J.70Universal Digital ID

Default should be:

No, unless compelling public need and high-threshold legal, privacy, security and accessibility review support it.

J.71Single Sign-On

Can improve:

J.72Single Sign-On Can Also Concentrate

J.73Evaluate

Do not assume.

J.74Account Linkage

Do not automatically connect:

activity into one profile.

J.75Civic Dossier

The City should expressly prohibit creation of a general:

resident dossier

that aggregates unrelated municipal interactions for behavioural analysis.

J.76No Civic Score

Never.

J.77No Social Score

Never.

J.78No "Good Resident" Score

Never.

J.79No Political Score

Never.

J.80No Community-Participation Score

Never.

J.81No Trustworthiness Score

Never.

J.82No Vulnerability Score for General Municipal Use

Never.

J.83Service-Specific Risk

Different.

Example:

may require lawful risk assessment.

J.84Do Not Turn Specific Risk Into Universal Person Rating

Critical.

J.85Purpose Limitation

Information collected for:

should not drift into unrelated:

J.86Purpose Register

For significant datasets record:

Dataset

Authority

Purpose

Required fields

Optional fields

Users

External disclosures

Retention

System

Owner

J.87Data Inventory

The City should maintain:

Municipal Data Inventory.

J.88Inventory Should Not Contain Actual Personal Information

It should describe:

J.89Data Inventory Fields

Dataset name

Business owner

System

Information type

Personal information?

Sensitive information?

Purpose

Collection source

Sharing

Location

Retention rule

Backup

Vendor involvement

Risk tier

J.90Shadow Systems

Include:

J.91Shadow IT

A major governance risk.

J.92Departmental Convenience App

Still City information system if used for:

J.93Free SaaS Account

Still creates:

issues.

J.94Personal Dropbox

Not appropriate for municipal records unless specifically approved within lawful City framework.

J.95Personal Google Account

Same principle.

J.96Personal AI Account

Same.

J.97Personal USB

Risk.

J.98Institutional Systems

Prefer.

J.99Data Classification

Municipal information should be classified according to:

J.100Classification Need Not Be Complicated

Possible:

Public

Internal

Confidential

Highly Sensitive

Security-Sensitive

J.101Public

Intended for:

J.102Internal

Ordinary operational information not intended for public release.

J.103Confidential

Contains information requiring meaningful protection.

J.104Highly Sensitive

Could create significant harm through improper access or disclosure.

J.105Security-Sensitive

Could compromise:

J.106Personal Information Can Exist at Several Sensitivity Levels

Yes.

J.107Publicly Available Personal Information

Still deserves:

J.108Public Does Not Mean

free to aggregate into government behavioural profile.

J.109Data Lifecycle

Every dataset should move through:

Need

Authority

Collection

Validation

Use

Access

Sharing

Retention

Archive

Disposal

J.110No Infinite Lifecycle

Unless law and public purpose justify:

J.111Retention Schedule

Should connect:

J.112Longer Is Not Safer

No.

No.

J.114Delete According to Authority

Overrides ordinary destruction where applicable.

J.116Access Request

Can affect disposition obligations.

J.117Litigation

Can affect.

J.118Investigation

Can affect.

J.119Archive

Different from:

J.120Dormant Data

Still creates:

J.121Backup Copy

Still data.

J.122Vendor Backup

Still relevant.

J.123Disaster-Recovery Copy

Still relevant.

J.124Data Deletion

Vendor contract should explain treatment of:

copies where material.

J.125"Deleted"

Need actual meaning.

J.126Secure Disposal

Physical and digital.

J.127Paper

Shred or otherwise securely dispose according to:

J.128Storage Device

Secure erase or destroy.

J.129Returned Laptop

Wipe before:

J.130Phone Reuse

Same.

J.131Device Reuse Program

Require verified:

J.132Resident Device Donations

No City tracking software left behind.

J.133Data Accuracy

The City should identify:

for important municipal facts.

J.134Example

Property address.

J.135Asset ownership.

J.136Permit status.

J.137Council decision.

J.138Event date.

J.139Source of Truth

Prevents:

J.140Official Information Owner

Every important public information category should have:

J.141Owner Responsible For

J.142"Last Updated"

Publish where information changes frequently.

J.143"Effective Date"

Use for:

J.144Correction Versus Update

Different.

J.145Update

Information was accurate but circumstances:

J.146Correction

Prior information was:

J.147Material Correction

Record in:

J.148Quiet Fix

Fine for:

where meaning unaffected.

J.149Material Error

Do not silently erase.

J.150Official Information Standard

Every important public page should ideally identify:

Owner

Last Updated

Source

Contact

J.151Website as Public Infrastructure

The municipal website should be treated as:

J.152Not Brochure

Not merely:

J.153Website Priority

First:

J.154Branding

Second.

Should work.

J.156Navigation

Should use resident language.

J.157Department Structure

Residents should not need to understand City organizational chart to:

J.158No Wrong Door

Applies digitally.

Service failure.

J.160Outdated Page

Information failure.

J.161Duplicate Contradictory Page

Information failure.

J.162Website Inventory

Maintain:

J.163Stale Content

Archive or update.

J.164Search Engine Indexing

Consider when retiring old pages.

J.165Do Not Leave Obsolete Instructions Searchable Without Warning

J.166Archive Label

Use.

J.167Public Documents

Should remain findable.

J.168Records Versus Current Guidance

Different.

J.169Accessible Digital Information

Ontario's current Integrated Accessibility Standards Regulation requires designated public-sector organizations to meet specified accessibility requirements for websites and web content, including WCAG 2.0 Level AA requirements within the regulation's framework.

J.170Compliance Is Floor

The practical standard should be:

Can residents actually use it?

J.171Automated Accessibility Scanner

Useful.

J.172Not Sufficient Alone

No.

J.173Manual Keyboard Testing

Useful.

J.174Screen Reader Testing

Useful.

J.175Lived Experience

Useful.

J.176PDF Accessibility

Important.

J.177Scanned Image PDF

Often poor public access.

J.178Provide Accessible Alternative

Where practical and required.

J.179Captions

For public video.

J.180Transcripts

Useful.

J.181Plain Language

Useful.

J.182Language Translation

Can improve access.

But automated translation should be labelled appropriately where:

J.183No App-Only Service

Basic City information should not depend on:

J.184No Social-Media-Only Notice

Important City notice should not depend solely on:

J.185Social Media Is Distribution Channel

Not official archive by itself.

J.186Municipal Website

Should remain authoritative for:

subject to legal requirements.

J.187Phone

Maintain.

J.188Print

Maintain where important.

J.189In Person

Maintain reasonable route.

J.190Emergency Information

Needs multiple channels.

J.191Internet Outage

Plan.

J.192Power Outage

Plan.

J.193Vendor Outage

Plan.

J.194Cyber Incident

Plan.

J.195Printed Emergency Information

Useful.

J.196Community Radio

Potentially useful.

J.197Public Notice Boards

Potentially useful.

J.198Redundancy

Communication resilience.

J.199Digital Systems Index

Maintain a:

Digital Systems Index.

J.200Digital Systems Index Fields

System

Purpose

Business owner

Vendor

Hosting

Data types

Personal information

Criticality

Authentication

Integrations

Contract expiry

Export capability

Exit tested?

Backup

Restore tested?

Accessibility

Privacy review

Security review

J.201Critical Digital System

One whose loss materially affects:

J.202Criticality Should Drive

J.203Website Can Be Critical During Emergency

Yes.

J.204Payroll

Critical.

J.205Water Controls

Highly critical.

J.206Recreation Newsletter

Less critical.

J.207Treat Accordingly

J.208Cloud

Cloud services can be:

J.209Cloud Is Not Automatically Loss of Sovereignty

No.

J.210On-Premises Is Not Automatically Sovereign

No.

J.211Badly Managed Local Server

Can be:

J.212Good Cloud Contract

Can provide:

J.213Cloud Decision

Should examine:

Data

Metadata

Administrative control

Geography

Vendor access

Subprocessors

Security

Backup

Portability

Exit

J.214Federal Guidance as Reference

Canadian Centre for Cyber Security guidance for federal institutions emphasizes that cloud risk involves more than obvious user content. It also identifies infrastructure, configuration, metadata and access-control information, and recommends understanding provider responsibilities, provider access, data locations and risk. That guidance is directed to Government of Canada organizations, not legally binding on Owen Sound, but its risk-management principles are useful municipal reference points.

J.215Canadian Hosting

Can be a legitimate:

factor.

J.216Canadian Hosting Is Not Complete Answer

No.

J.217Server in Toronto

Does not answer:

J.218Foreign Hosting

Also not automatically:

J.219Risk-Based Decision

Use:

J.220Canadian Preference

Where lawful and good value:

Can support:

J.221But Do Not Sacrifice Security Merely for Flag

No.

J.222Canadian Company

Can still have:

J.223Foreign Company

Can still have:

J.224Evaluate Real Controls

J.225Data Location

Know where material information may be:

J.226Management Plane

Also matters.

J.227Support Access

Also.

J.228Subprocessor List

Review.

J.229Change Notification

Contract should address where material.

J.230Vendor Access

Use least access necessary.

J.231Support Engineer

Should not receive permanent unrestricted access because:

J.232Privileged Vendor Access

Log.

J.233Temporary Access

Prefer where practical.

J.234Data Export

Every critical system should answer:

Can the City export its information in a usable format?

J.235"Download PDF"

Not sufficient for many systems.

J.236Structured Data

May be required.

J.237Metadata

May be needed.

J.238Attachments

May be needed.

J.239Audit History

May be needed.

J.240Configuration

May be needed.

J.241Exit Test

Do not wait until cancellation to discover:

J.242Test Before Renewal

For critical systems.

J.243Migration Drill

High-risk systems may warrant:

J.244Exit Documentation

Should state:

Export process

Format

Cost

Time

Dependencies

Vendor assistance

Data deletion

Replacement needs

J.245Exit Cost

Part of:

J.246Egress Fee

Know.

J.247Professional Services Fee

Know.

J.248Licence Termination Fee

Know.

J.249Replacement Integration

Know.

J.250Exit Is Not Necessarily Cheap

But it should be:

J.251Vendor Lock-In

Not automatically bad.

Sometimes specialized service justifies:

J.252Accidental Lock-In

Bad governance.

J.253Intentional Dependency

Should be:

J.254Open Standards

Prefer where practical.

J.255Open API

Useful.

J.256Open File Format

Useful.

J.257Proprietary Standard

May sometimes be justified.

J.258Document Why

J.259Open Source

Can improve:

J.260Open Source Does Not Mean

J.261Source Code

Needs:

J.262Municipal Build

Same.

J.263Custom Software

Creates obligation.

J.264Developer Leaves

What happens?

J.265Documentation

Essential.

J.266Source Repository

Institutional ownership.

J.267Credentials

Institutional.

J.268Deployment Instructions

Document.

J.269Dependency List

Document.

J.270Licence Compliance

Document.

J.271Backup

A backup is not useful unless it can be:

J.272Backup Exists

Activity.

J.273Restore Works

Outcome.

J.274Restore Testing

Critical.

J.275Backup Separation

Consider:

J.276Offline / Isolated Copy

May be appropriate for:

J.277Recovery Time

Define.

J.278Recovery Point

Define.

J.279Not Every System Needs Same Recovery Target

No.

J.280Criticality Drives

J.281Business Continuity

A digital outage should not automatically make:

J.282Manual Fallback

Where practical.

J.283Paper Fallback

Where practical.

J.284Emergency Contact List

Offline copy.

J.285Critical Procedures

Offline.

J.286Cybersecurity

Cybersecurity should protect:

Confidentiality

Integrity

Availability

The federal Cyber Centre similarly frames cloud and information-security risk around these dimensions.

J.287Confidentiality

Information not exposed to:

J.288Integrity

Information not improperly:

J.289Availability

Information and systems available when:

J.290Security Is Not Only Confidentiality

A ransomware attack can protect confidentiality but destroy:

J.291Security Is Not Only IT

Includes:

J.292Identity and Access Management

Critical.

J.293Least Privilege

People receive access needed for:

J.294Not More

J.295Role Change

Access should change.

J.296Employee Departure

Access removed promptly.

J.297Contractor Departure

Same.

J.298Shared Accounts

Avoid for sensitive systems where individual accountability is important.

J.299Multi-Factor Authentication

Use according to:

J.300Administrator Account

Higher protection.

J.301Ordinary Account

Do not use administrator rights unnecessarily.

J.302Privileged Account

Monitor.

J.303Access Review

Periodic.

J.304Dormant Accounts

Disable.

J.305Vendor Account

Review.

J.306Service Account

Document.

J.307API Key

Protect.

J.308Password in Spreadsheet

Avoid.

J.309Password in Source Code

Avoid.

J.310Public Repository Secret

Critical incident.

J.311Cybersecurity Training

Useful.

J.312Training Completion

Activity.

J.313Reduced Risk

Outcome.

J.314No Staff-Shaming Phishing Program

Training should improve:

J.315Phishing Simulation

Can be useful.

J.316Do Not Publicly Rank Employees

No.

J.317Report Button

Easy.

J.318Incident Reporting

Encourage early:

J.319Zero Reported Incidents

Not proof of:

J.320Incident Response Plan

Maintain.

J.321Privacy Incident Plan

Maintain.

J.322Cyber Incident Plan

Coordinate.

J.323Not Every Cyber Incident Is Privacy Incident

Correct.

J.324Not Every Privacy Incident Is Cyber Incident

Correct.

J.325Examples

Wrong email recipient:

J.326Malware without personal information exposure:

J.327Incident Triage

Define.

J.328Severity

Define.

J.329Escalation

Define.

J.330Containment

First.

J.331Evidence Preservation

Important.

Where required.

J.333Notification

Follow current law and, from January 1, 2027, the new municipal MFIPPA requirements as applicable.

J.334Post-Incident Review

Ask:

What happened?

Why?

What information?

Who affected?

What failed?

What changes?

J.335No Blame Theatre

Fix:

J.336Repeat Incident

More concerning than:

J.337Vendor Incident

Contract must require:

J.338Vendor Cannot Decide Alone Whether City Needs to Know

No.

J.339Subprocessor Incident

Also.

J.340Breach Register

Maintain according to:

J.341Privacy Impact Assessment

A PIA is a structured way to identify privacy risks before or during design.

J.342Current 2026 Position

As of August 2026, Owen Sound should distinguish today's MFIPPA obligations from the additional PIA requirements enacted to take effect for municipal institutions January 1, 2027. The IPC's August 2026 guide is specifically written to support that transition.

J.343Do Not Wait

Use PIA methodology now as:

even before every future statutory requirement takes effect.

J.344PIA Trigger

Consider for:

J.345PIA Is Not Checkbox

No.

J.346PIA Should Influence Design

If result is:

high risk

change:

J.347Privacy Approval

Not same as:

technology approved.

Other reviews remain.

J.348Security Review

Separate.

J.349Accessibility Review

Separate.

J.350Procurement Review

Separate.

Separate.

J.352Architecture Review

Separate.

J.353Combine Proportionately

Do not create five disconnected bureaucracies.

J.354Technology Review Card

For major systems:

ReviewStatus
Public purposeConfirmed / Pending
PrivacyComplete / Pending
SecurityComplete / Pending
AccessibilityComplete / Pending
RecordsComplete / Pending
ProcurementComplete / Pending
Data ownershipConfirmed / Pending
Export / ExitTested / Pending
HostingConfirmed / Pending
Complete CostComplete / Pending

J.355Artificial Intelligence

AI should be governed by:

not hype.

J.356AI Inventory

Maintain list of material City AI uses.

J.357AI Use Record

Tool

Purpose

Department

Data allowed

Data prohibited

Human reviewer

Vendor

Retention / training terms

Consequence level

J.358Low-Risk AI

Examples might include:

J.359Medium Risk

Could include:

J.360Higher Risk

Could include decisions affecting:

J.361Higher Risk Requires Higher Review

Always.

No.

J.363AI Recommendation

Human remains accountable.

J.364"The Algorithm Decided"

Never acceptable institutional answer.

J.365Explainability

The City should understand:

J.366Black Box

Higher risk.

J.367Generative AI

Can produce:

J.368Human Verification

Required before official publication.

J.369AI Citation

Verify underlying source.

J.370AI Financial Number

Verify with Finance.

Verify current law.

J.372AI Engineering Claim

Qualified professional.

J.373AI Translation

Review risk according to consequence.

J.374Emergency Translation

May be better than none.

But label where:

J.375Personal Information

Do not enter into unapproved generative AI systems.

J.376Confidential Information

Same.

Same.

J.378Security Configurations

Same.

J.379Indigenous Knowledge

Same, with consent and governance considerations.

J.380AI Vendor Training

Know whether data is used to:

vendor models.

J.381Opt-Out

Know.

J.382Retention

Know.

J.383Subprocessors

Know.

J.384Model Location

May matter.

J.385Audit Logs

May matter.

J.386AI Procurement

Do not buy because:

J.387Problem First

Ask:

What problem does AI solve better than a simpler tool?

J.388No AI Requirement

A plain form may be:

J.389No Chatbot Requirement

Sometimes a good searchable page is:

J.390Human Escalation

Essential for resident-facing AI.

J.391Chatbot Must Be Able to Say

I do not know.

J.392No False Authority

Do not let chatbot sound like:

Provide.

J.394Chat History

Decide retention deliberately.

J.395Do Not Keep Forever

Because:

J.396Resident Profiling

No.

J.397Sentiment Analysis

Do not use to classify individual residents politically or emotionally.

J.398Emotion Detection

Do not use for:

J.399Predictive Policing

Outside ordinary municipal innovation.

Any proposal would require:

review.

J.400Automated Fraud Detection

May have legitimate uses.

But requires:

J.401Automated Hiring

High risk.

J.402Employee Monitoring AI

High risk.

J.403Productivity Scoring

Avoid simplistic:

J.404Workplace Technology

Respect:

J.405AI Does Not Replace Managers

No.

J.406Surveillance

Municipal surveillance should begin with:

What specific problem are we trying to solve?

J.407Camera Installation Is Not Safety Outcome

No.

J.408Surveillance Ladder

Before collecting more information consider:

Better lighting

Physical design

Staffing

Maintenance

Access control

Targeted non-recording sensor

Camera

More intrusive technology

J.409Least Intrusive Effective Option

Prefer.

J.410CCTV

May be justified in:

J.411Purpose

Define.

J.412Location

Define.

J.413Field of View

Limit.

J.414Retention

Limit.

J.415Access

Limit.

J.416Signs / Notice

Where required or appropriate.

J.417Audit

Review access.

J.418Outcome

Measure.

J.419Camera Expansion

Not automatic after:

J.420Facial Recognition

Default:

Do not use.

J.421Exception

Any proposal should require:

J.422Biometrics

Same high threshold.

J.423Voiceprint

Biometric.

J.424Gait Recognition

Biometric-like high risk.

J.425Emotion Recognition

Do not use for resident assessment.

J.426Licence-Plate Recognition

Separate review.

J.427Drone Recording

Separate review.

J.428Audio Recording in Public Space

Separate review.

J.429Wi-Fi Tracking

Separate review.

J.430Bluetooth Tracking

Separate review.

J.431Mobile Advertising ID

Do not collect for ordinary municipal analytics.

J.432Location History

Do not collect without compelling service reason.

J.433Public Wi-Fi

Public Wi-Fi should be designed primarily as:

J.434Not Data-Harvesting Infrastructure

J.435Wi-Fi Principles

No marketing signup by default.

Minimum logging.

No behavioural advertising.

No sale of usage data.

No unnecessary persistent device profiling.

Clear acceptable-use rules.

Security proportionate to service.

J.436Anonymous Access

Prefer where feasible.

J.437Account Requirement

Needs reason.

J.438Email Harvesting

Not necessary for:

J.439Analytics

Use aggregate information where enough.

J.440"Unique Devices"

Can become tracking.

Use carefully.

J.441MAC Address

Can be identifying or linkable.

Treat cautiously.

J.442Public Wi-Fi Vendor

Must not monetize residents through:

without explicit lawful policy.

J.443Captive Portal

Keep simple.

J.444Terms

Readable.

Do not put 9,000-word legal agreement in front of resident and pretend that creates meaningful:

J.446Broadband Study

Do not build household poverty database simply to determine:

J.447Use Aggregate Need

Where sufficient.

J.448Low-Income Support

Eligibility can be administered with:

J.449Do Not Publish Recipient Map

No.

J.450Device Reuse

Recipient identity collection should be limited to:

J.451Do Not Track Device After Transfer

No.

J.452Asset Ownership Transfer

Document.

J.453Secure Wipe

Verify.

J.454Battery Safety

Check.

J.455Warranty

Explain.

J.456Community Calendar

Should be:

J.457Calendar Entry

Needs only:

J.458Organizer Contact

Do not publish personal phone number without:

J.459Public Email

Use organizational contact where possible.

J.460Neutrality

Calendar inclusion should not depend on:

agreement with City.

J.461Lawful Event

Apply published rules.

J.462No Paid Basic Ranking

Public calendar should not quietly become:

J.463Sponsored Promotion

If ever used:

Separate clearly.

J.464Emergency Calendar Override

Can prioritize:

J.465Open Data

Open data should expose:

J.466Open Data Does Not Mean

publish everything.

J.467Open Data Review

Ask:

Is it lawful?

Is personal information present?

Is security affected?

Can datasets be combined to re-identify someone?

Does third party own rights?

Is data sufficiently accurate?

J.468Mosaic Effect

Several harmless-looking datasets can combine into:

J.469Vulnerable-Person Mapping

Do not publish.

J.470Homelessness Heat Map

High concern.

J.471Domestic Violence Location

Never as general open data.

J.472Youth Locations

Protect.

J.473Critical Infrastructure

Protect technical vulnerability.

J.474Open Asset Map

Can publish appropriate high-level:

J.475Open Procurement

Can publish:

subject to legitimate protections.

J.476Open Performance

Can publish:

J.477Open Complaints

Aggregate.

J.478Open Enforcement

Aggregate where appropriate.

J.479Open Staff Data

Protect personal employment information beyond lawful public reporting requirements.

J.480Data Licence

Use clear terms for open data.

J.481Machine-Readable

Useful.

J.482Accessible Human Version

Essential.

J.483No API-Only Transparency

No.

J.484Data Stewardship

Someone should own:

J.485Department Ownership

Good.

J.486Corporate Standards

Also.

J.487No Central Data Empire

Data governance does not require one office to:

J.488Distributed Stewardship

Can work.

J.489Common Rules

Essential.

J.490Data Sharing

Before sharing personal or sensitive information ask:

Why does the receiving party need it?

J.491Minimum Necessary

Share:

J.492Whole File

Not default.

J.493No Wrong Door

Does not mean:

J.494Warm Handoff

Can often happen without transferring:

J.495Resident Control

Where practical:

Allow resident to decide what:

Some sharing may be:

J.497Agreement

Should describe:

Purpose

Authority

Fields

Access

Security

Retention

Further sharing

Incident response

Termination

Again.

J.499Multi-Agency Database

High threshold.

J.500One Resident, One Taxpayer

Does not mean:

One giant government dossier.

J.501Grey County

Share only what is:

J.502Ontario

Same.

J.503Canada

Same.

J.504Police

Same within applicable legal framework.

J.505Health Partner

Same, with appropriate health-information framework.

J.506Schools

Same.

J.507Community Organization

Same.

J.508Faith Organization

Same.

J.509Vendor

Same.

J.510Data Broker

No ordinary municipal purpose for sharing resident information with commercial data brokers.

J.511Advertising Platform

Do not upload municipal resident lists for:

J.512Campaign

Never.

J.513Campaign Firewall

Municipal information systems must be completely separated from:

J.514City Email List

Not campaign list.

J.515City Event Registration

Not campaign list.

J.516Civic Corps participant list

Not campaign list.

J.517Business contact list

Not campaign list.

J.518Senior program list

Not campaign list.

J.519Strong Vote list

Not campaign list.

J.520Resident Pulse data

Not campaign microtargeting data.

J.521No "Publicly Available Anyway" Excuse

Institutional access carries:

J.522Youth Data

Higher protection.

J.523YouthMap

Map:

Not:

J.524Youth Account

Only if program genuinely needs:

J.525Youth Profile

Do not create permanent profile across:

J.526Youth Skills Passport

If developed:

J.527No Civic Score

Again.

J.528No Employability Score

No.

J.529No Political Participation History

No.

J.530Photos

Do not force.

Separate from service eligibility where possible.

J.532Volunteer Participation

Do not automatically authorize:

Use where law or program context requires.

J.534Safeguarding Data

Protect.

J.535Background Checks

Do not retain copies longer or more broadly than necessary.

J.536Health Information

City should avoid collecting health information unless:

J.537Accessibility Accommodation

Do not ask for diagnosis when functional accommodation information:

J.538Seniors

Do not create general:

J.539Snow Brigade

Could operate through:

J.540No Public Map of Vulnerable Seniors

Never.

J.541Emergency Registry

If any specialized registry is considered:

Requires:

case.

J.542Participation Should Not Become Surveillance

J.543RealMap

RealMap creates a particularly important distinction between:

property information

and

information about people.

J.544Property Information

Could include:

subject to lawful source and rights.

J.545Personal Information

Could include:

J.546Do Not Mix Casually

No.

J.547Free Listing

Does not justify:

J.548Public Browsing

Should not require:

for ordinary property viewing if municipal or public-standard role ever exists.

J.549No Paid Basic Ranking

Already established.

J.550No Behavioural Advertising

If RealMap ever participates in public municipal infrastructure.

J.551No Cross-Property Resident Profile

No.

J.552No Tracking Homebuyer Behaviour Into Municipal Dossier

No.

J.553Listing Analytics

If used:

Prefer:

J.554Private Seller

Same privacy standard.

J.555Professional Seller

Same.

J.556Public Record

Do not imply every RealMap field is:

J.557Source Label

Important.

J.558map.ca

Any municipal relationship with map.ca must meet:

the same or stronger privacy, security, accessibility, procurement and exit standards as any unrelated vendor.

J.559Founder Connection

No exemption.

J.560Public Standard First

Again.

J.561Platform Second

Again.

J.562Founder Last

Again.

J.563Public Ownership

Before municipal adoption determine:

What does City own?

What does founder own?

What is licensed?

What is transferred?

What remains private?

J.564Data Ownership

Explicit.

J.565Administrative Control

Explicit.

J.566Domain Control

Explicit.

J.567Source Code

Explicit.

J.568Database

Explicit.

J.569Brand

Explicit.

J.570User Accounts

Explicit.

J.571Analytics

Explicit.

J.572Email-for-Life Concept

Should remain:

until high-threshold review.

J.573Persistent Municipal Email

Could create:

obligations.

J.574"For Life"

Very long commitment.

J.575Never Promise Before Business Case

No.

J.576Data Locker

Also high threshold.

J.577Central Personal Document Store

Creates:

J.578City Need

Must be compelling.

J.579Safer Alternative

May be:

J.580Do Not Build Giant Personal Vault for Prestige

No.

J.581map.ca Public Map

Should map:

J.582Not People

Default.

J.583No Resident Location Tracking

No.

J.584No Youth Location Tracking

No.

J.585No Vulnerable-Person Layer

No.

J.586No Political Affiliation Layer

No.

J.587No Faith Affiliation Layer

No.

J.588Public Institution Directory

Fine if:

J.589Business Directory

Fine under neutral rules.

J.590Personal Home Data

Higher concern.

J.591Community Event

Fine.

J.592Emergency Map

Protect sensitive detail.

J.593Digital Sovereignty

Define as:

the practical ability of the City to understand, control, secure, move and continue operating its essential digital systems and information.

J.594Sovereignty Is Not

J.595Sovereignty Is

Know what we have.

Know where data goes.

Control access.

Maintain backups.

Export data.

Avoid unnecessary dependency.

Preserve options.

J.596Canadian Digital Independence

Municipal contribution can include:

J.597Municipal Scale

Owen Sound should not attempt to become:

J.598Capability Before Prestige

Always.

J.599Shared Municipal Technology

Could be valuable where municipalities face:

J.600Open Municipal Playbook

Share:

J.601Another Municipality Should Be Able to Reuse

Where lawful.

J.602No Vendor Trap in Playbook

Do not make:

open Canadian system

that secretly requires:

J.603Interoperability

Essential.

J.604Shared Standard

Could outlive:

J.605Technology Procurement

Every important technology RFP should consider:

Privacy

Security

Accessibility

Data location

Vendor access

Interoperability

Portability

Exit

Records

Complete Cost

J.606Lowest Price

Not enough.

J.607Best Demo

Not enough.

J.608Biggest Company

Not enough.

J.609Canadian Company

Not enough.

J.610Incumbent Vendor

Not enough.

J.611New Startup

Not disqualifying.

J.612Evidence

Use.

J.613Proof of Concept

May help.

J.614Pilot

May help.

J.615Reference Customer

May help.

J.616Security Attestation

May help.

J.617Independent Assessment

May help.

J.618Contractual Obligation

Essential.

J.619Vendor Claim

Not enough.

J.620"Military Grade"

Meaningless without:

J.621"Bank-Level Security"

Marketing.

J.622"AI Secure"

Marketing.

J.623"Canadian Cloud"

Define.

J.624"Anonymous"

Verify.

J.625"Encrypted"

Ask:

J.626Encryption

Important.

Not entire security program.

J.627Key Management

Important.

J.628Vendor Holds Keys

Different risk.

J.629City-Controlled Keys

Different.

J.630Choose according to risk.

J.631Vendor Contract Minimums

For critical systems consider:

Incident notice

Data ownership

Use restrictions

Subprocessors

Security obligations

Audit / assurance

Accessibility

Backup

Recovery

Export

Termination assistance

Deletion

Renewal

Price escalation

J.632Privacy as Procurement Requirement

Before purchase.

J.633Accessibility as Procurement Requirement

Before purchase.

J.634Exit as Procurement Requirement

Before purchase.

J.635Security as Procurement Requirement

Before purchase.

J.636Do Not Negotiate These Only After Vendor Selected

Too late.

J.637Vendor Concentration

Track.

J.638One Vendor Across Everything

Can create:

J.639Single Identity Provider

Can create:

J.640Single Cloud

Can create:

J.641Single Telecom Carrier

Can create:

J.642Redundancy

Consider for:

J.643Supplier Failure Drill

Could be useful for:

J.644What if Vendor Stops Operating Tomorrow?

Ask.

J.645What if Vendor Doubles Price?

Ask.

J.646What if Vendor Is Acquired?

Ask.

J.647What if Vendor Changes Terms?

Ask.

J.648What if Internet Fails?

Ask.

J.649What if account is compromised?

Ask.

J.650What if City administrator leaves?

Ask.

J.651Digital Succession

Critical.

J.652Administrative Accounts

Should have at least:

J.653One-Person Control

Avoid.

J.654Two-Person Safeguard

For critical changes where appropriate.

J.655Break-Glass Account

May be useful.

J.656Document securely.

J.657Domain Renewal

Track.

J.658Certificate Expiry

Track.

J.659Licence Expiry

Track.

J.660Contract Renewal

Track.

J.661Backup Failure

Track.

J.662End-of-Life Software

Track.

J.663Unsupported Operating System

Track.

J.664Technical Debt

A real asset risk.

J.665Technical Debt Is Not Always Bad

Sometimes deliberate.

J.666Unknown Technical Debt

Risk.

J.667Digital Maintenance

Budget.

J.668Cybersecurity

Budget.

J.669Accessibility remediation

Budget.

J.670Migration

Budget.

J.671Digital Complete Cost

Always.

J.672Analytics

Analytics should answer:

J.673Vanity Analytics

Avoid.

J.674Page Views

Can help.

J.675But page views are not:

J.676Clicks

Not:

J.677Session Duration

Can mean:

J.678Analytics Purpose

Define.

J.679Tracking Technology

Inventory:

J.680Session Replay

High privacy concern.

Avoid unless compelling need and review.

J.681Advertising Pixel

Generally unnecessary on municipal service pages.

J.682Cross-Site Tracking

Avoid.

J.683Behavioural Advertising

No ordinary municipal purpose.

J.684Social-Media Embed

Can create third-party tracking.

Review.

J.685Video Embed

Same.

J.686Map Embed

Same.

J.687Payment Provider

Necessary third party in some services.

Govern.

J.688CAPTCHA

Can create:

issues.

J.689Alternative

Provide where necessary.

Not substitute for:

J.691"Accept All"

Should not become:

Define.

J.693Optional Analytics

Consider privacy-friendly configuration.

J.694Do Not Collect Fine-Grained Analytics Because Vendor Includes Them for Free

No.

J.695Public Search Logs

Can contain:

J.696Retention

Limit according to purpose.

J.697Chatbot Queries

Same.

Same.

Same.

J.700Public Map Searches

Same.

J.701Information Access

Privacy policy should not become barrier to:

J.702MFIPPA's dual purposes matter:

J.703Open Government

Expose:

J.704Privacy

Protect:

J.705Procurement Confidentiality

Protect where lawful.

J.706Then disclose appropriate award information.

J.707Security Confidentiality

Protect actual vulnerabilities.

J.708Then disclose high-level risk management.

Protect.

J.710Then disclose public rationale where possible.

J.711Information Request

Residents should not be treated as:

for requesting public records.

J.712Informal Access

Use where appropriate.

J.713Formal FOI

Still available under:

J.714Routine Disclosure

Can reduce:

J.715Publish Frequently Requested Records

Where lawful.

J.716Proactive Disclosure

Useful.

J.717Do Not Publish Personal Information Merely to Reduce FOI Work

No.

J.718Disclosure Review

Still.

J.719Information Retention

Open government also requires retaining important institutional records.

J.720Privacy Minimization Does Not Mean Deleting Government Accountability Records

Correct.

J.721Distinguish

Personal data minimization

from

public institutional record preservation.

J.722Council Decision History

Preserve.

J.723Contract History

Preserve according to schedule.

J.724Financial Records

Preserve.

J.725Major project decisions

Preserve.

J.726Public correction history

Preserve.

J.727Campaign Data

Not municipal record merely because person later becomes Mayor.

J.728Municipal Data

Not campaign property merely because Mayor initiated service.

J.729Transition

Campaign-to-City data should not be casually:

J.730Campaign Contacts

Do not import into City CRM.

J.731City Contacts

Do not export to campaign CRM.

J.732Publicly Submitted Campaign Idea

Can be considered politically.

But formal municipal use may require:

J.733Strong Vote

If created municipally:

Needs privacy architecture.

J.734Verify Person

Only to extent needed.

J.735Protect Opinion

Separate verification data from:

data where practical.

J.736Ballot Secrecy Analogy

Useful principle where civic consultation requires:

J.737Do Not Build Permanent Political Preference File

No.

J.738Participation History

Minimize.

J.739Delete or anonymize according to:

J.740Published Results

Aggregate.

J.741Small Groups

Protect re-identification.

J.742Resident Pulse

Same.

J.743Petition

Different legal and public context.

J.744Signature Publication

Review applicable law and notice.

J.745Consultation Submission

Tell residents whether:

may become public.

J.746No Surprise Publication

Important.

J.747Public Delegation

Different.

Residents speaking at public meeting should understand:

J.748Recording

Notify.

J.749Livestream

Notify.

J.750Archive

Explain.

Never.

J.752Employee Information

Digital governance must protect staff too.

J.753HR Data

Sensitive.

J.754Performance Data

Sensitive.

J.755Access Logs

Can protect security.

J.756Access Logs Should Not Become

without legitimate purpose.

J.757GPS Fleet Data

Can improve:

J.758It Can Also Track Employees

Govern.

J.759Purpose

Define.

J.760Retention

Define.

J.761Supervisor Access

Define.

J.762Discipline Use

Define according to:

J.763No Continuous Employee Surveillance by Default

J.764Keylogging

High threshold.

J.765Screen Capture

High threshold.

J.766Webcam Monitoring

Extremely high threshold.

J.767Productivity AI

High threshold.

J.768Labour Consultation

Where applicable.

J.769Public Safety Employees

Special operational contexts may apply.

J.770Still govern.

J.771BYOD

Personal devices for City work create:

complexity.

J.772City Device

Prefer where risk warrants.

J.773Remote Work

Secure.

J.774Home Network

Risk manage.

J.775Printed Personal Information at Home

Protect.

J.776Device Loss

Incident process.

J.777USB

Control.

J.778Personal Messaging App

Avoid for sensitive municipal records unless approved.

J.779Text Messages

Can still be municipal records.

J.780Deleting Chat

Not records strategy.

J.781Information Governance Roles

Assign:

Clerk / records function

Privacy responsibility

IT / security responsibility

Business owner

Procurement

Accessibility

J.782No Single "Data Czar" Required

Avoid unnecessary bureaucracy.

J.783Clear Responsibility

Required.

J.784Business Owner

Owns:

J.785IT

Owns:

not automatically legal authority for data.

J.786Privacy Role

Advises on:

J.787Clerk / Records

Supports:

framework.

J.788Cybersecurity

Protects:

J.789Accessibility

Ensures:

J.790Procurement

Creates contractual enforceability.

Interprets law.

J.792Council

Sets:

J.793Mayor

Leads policy but should not receive:

J.794Councillor

Same.

J.795Constituency Assistance

Need-to-know.

May support transfer of details to staff where appropriate.

J.797Councillor CRM

Municipal versus political role needs:

J.798Election Period

Heightened care.

J.799Councillor Newsletter

Official versus campaign communication:

J.800No Political Targeting

Again.

J.801Privacy Incident Metrics

Public Scorecard may report:

Incidents

Serious incidents

People affected where appropriate

Repeat causes

Time to containment

Remediation completed

J.802Do Not Publish Details That Re-Expose Victims

No.

J.803Do Not Publish Exploit Details Before Fixed

No.

J.804Incident Count Alone

Not enough.

J.805Rising Incidents

Could mean:

J.806Falling Incidents

Could mean:

J.807Context.

J.808Information Accuracy Metrics

Could include:

Pages with identified owners

Pages reviewed on schedule

Material corrections

Stale service pages

J.809More Corrections

May mean:

J.810Do Not Set "Zero Corrections" Target

That could incentivize:

J.811Digital Sovereignty Metrics

Could include:

Critical systems inventoried

Data location known

Export capability confirmed

Exit tested

Restore tested

Contract expiry known

Institutional admin control

Unsupported systems

J.812Privacy Metrics

Could include:

High-risk systems with current privacy review

Unnecessary fields removed

Retention schedules verified

Dormant accounts removed

Vendor access reviewed

Incidents remediated

J.813Do Not Create One Privacy Score

No.

J.814One Green Badge

Can hide:

J.815Digital System Traffic Lights

Green

Controls and ownership sufficiently understood.

Amber

Known risk requiring planned action.

Red

Material unresolved risk requiring decision.

Grey

Important facts not verified.

J.816Grey Vendor

If City does not know:

that is not:

J.817Privacy Review Frequency

Risk-based.

J.818Annual Review

For critical systems may be appropriate.

J.819Event-Based Review

After:

J.820Contract Renewal

Review trigger.

J.821New AI Feature

Review trigger.

J.822New Tracking Feature

Review trigger.

J.823Vendor Update

Review if material.

J.824Scope Change

Review.

J.825First 30 Days

Establish a:

Privacy and Digital Governance Baseline.

J.826First 30-Day Inventory

Identify:

Critical systems

Personal-information systems

Major vendors

Cloud systems

Unsupported software

Public analytics

AI tools

Public Wi-Fi

Major data-sharing arrangements

Contract renewals

Known incidents

J.827Do Not Attempt to Replace Everything

No.

J.828First Goal

Know:

what exists.

J.829Shadow-System Discovery

Include departments.

J.830No Punishment-First Approach

Employees may use workaround tools because:

J.831Learn Why

Then secure.

J.832First 30 Days Also

Confirm preparation for:

J.833First 60 Days

Publish safe high-level:

Digital Systems and Privacy Baseline.

J.834Public Baseline Should Not Publish

J.835First 60-Day Actions

Remove obvious unnecessary trackers.

Review abandoned accounts.

Confirm critical domains.

Confirm major backups.

Check major contract expiries.

Identify unsupported systems.

J.836Low-Risk High-Value Fixes First

Good.

J.837First 100 Days

Adopt or update:

Data Inventory

Digital Systems Index

Privacy Review Trigger

AI Use Standard

Vendor Exit Standard

Incident Response Standard

Public Information Correction Standard

J.838January 2027 Readiness

Ensure the municipal organization is prepared for enacted MFIPPA requirements that come into force at the start of 2027.

J.839Year One

Focus on:

J.840Year One Data-Minimization Review

Choose:

forms first.

J.841Remove Unnecessary Fields

Measure.

J.842Year One Public Wi-Fi

If pursued:

Pilot under privacy-first rules.

J.843Year One Device Reuse

If pursued:

Small controlled pilot.

J.844Year One map.ca

No municipal adoption until:

J.845Year One RealMap

Same.

J.846Year Two

Strengthen:

J.847Year Two AI Review

Audit what actually entered City operations.

J.848Remove Unapproved Uses

Where necessary.

J.849Year Two Open Data

Expand only where:

support it.

J.850Year Three

Address:

J.851Year Three Migration

Where evidence supports.

J.852Do Not Migrate for Fashion

No.

J.853Year Three Shared Municipal Tools

Could develop or adopt where:

exist.

J.854Year Four

Publish:

Four-Year Privacy, Information and Digital Governance Audit.

J.855Four-Year Audit

Should answer:

What systems did we begin with?

What systems were retired?

What data collection was reduced?

What privacy incidents occurred?

What repeated causes were fixed?

What major vendor dependencies remain?

What exits were tested?

What systems were migrated?

What public information became easier to access?

What digital services remained non-digital accessible?

What AI uses were approved?

What AI uses were rejected?

What surveillance was added?

What surveillance was rejected?

J.856Name the Largest Personal-Data Collection Reduced

Where appropriate.

J.857Name the Highest-Risk Legacy System Replaced

J.858Name the Highest Remaining Digital Lock-In

J.859Name the Most Important Successful Vendor Exit

J.860Name the Most Important Restore Test

J.861Name the Most Serious Privacy Incident

At an appropriate public level.

J.862Name What Changed Because of It

J.863Name a Proposed Data Collection Stopped

If applicable.

J.864Name an AI Use Rejected

If applicable.

J.865Name an AI Use That Demonstrably Improved Service

If applicable.

J.866Name a Surveillance Proposal Stopped

If applicable.

J.867Name a Public Website Improvement

J.868Name a Major Information Correction

J.869Name the Largest Remaining Unknown

J.870Name the Largest Remaining Unsupported Digital System

J.871Name the Most Important Non-Digital Service Route Preserved

J.872Name the Most Reusable Municipal Digital Tool Shared With Another Community

If applicable.

J.873Handoff

The next Council should inherit:

Data Inventory

Digital Systems Index

Privacy review records

High-risk systems

Contract renewals

Vendor exit documentation

Restore results

Incident history

AI inventory

Surveillance inventory

Public information owners

Major unresolved privacy risks

J.874No Digital Surprise

The next Council should not discover:

The vendor owns our data.

J.875Or

Nobody knows the administrator password.

J.876Or

The contract renewed automatically for five years.

J.877Or

Backups have never been restored.

J.878Or

Resident data is being sent to an advertising platform.

J.879Or

An AI tool has been receiving confidential information for two years.

J.880Or

The City website has no owner for half its service pages.

J.881Anti-Gaming Rule One

Do not call:

better government.

J.882Rule Two

Do not collect information because:

J.883Rule Three

Do not collect information because:

J.884Rule Four

Do not make optional information functionally:

J.885Rule Five

Do not require identity to read:

J.886Rule Six

Do not create universal digital identity merely for:

J.887Rule Seven

Do not combine unrelated resident files merely because:

J.888Rule Eight

Do not create:

J.889Rule Nine

Do not call consent:

when service cannot reasonably be refused.

J.890Rule Ten

Do not call purpose:

when it is merely interesting.

J.891Rule Eleven

Do not retain data forever because:

J.892Rule Twelve

Do not delete records required for:

J.893Rule Thirteen

Do not call archive:

J.894Rule Fourteen

Do not call backup:

unless restore works.

J.895Rule Fifteen

Do not call Canadian hosting:

J.896Rule Sixteen

Do not call on-premises:

merely because server is local.

J.897Rule Seventeen

Do not call cloud:

merely because it is cloud.

J.898Rule Eighteen

Do not call encryption:

J.899Rule Nineteen

Do not call security certification:

J.900Rule Twenty

Do not allow vendor sole administrator control over:

J.901Rule Twenty-One

Do not allow employee personal account to control:

J.902Rule Twenty-Two

Do not call a PDF export:

when structured data is needed.

J.903Rule Twenty-Three

Do not call vendor exit:

without actually testing material export or migration steps.

J.904Rule Twenty-Four

Do not call open source:

J.905Rule Twenty-Five

Do not call proprietary:

J.906Rule Twenty-Six

Do not buy technology because:

J.907Rule Twenty-Seven

Do not use AI output as:

without verification.

J.908Rule Twenty-Eight

Do not put personal, confidential, privileged or security-sensitive information into:

J.909Rule Twenty-Nine

Do not let AI make consequential decisions without:

J.910Rule Thirty

Do not use AI sentiment to rank:

J.911Rule Thirty-One

Do not use emotion detection for:

J.912Rule Thirty-Two

Do not call camera installation:

J.913Rule Thirty-Three

Do not expand surveillance because:

J.914Rule Thirty-Four

Do not use facial recognition by default.

J.915Rule Thirty-Five

Do not call a device identifier:

without analysis.

J.916Rule Thirty-Six

Do not turn public Wi-Fi into:

J.917Rule Thirty-Seven

Do not require marketing signup for:

J.918Rule Thirty-Eight

Do not publish maps of:

J.919Rule Thirty-Nine

Do not publish critical infrastructure attack details.

J.920Rule Forty

Do not use security to hide:

J.921Rule Forty-One

Do not use privacy to hide:

J.922Rule Forty-Two

Do not use transparency to expose:

J.923Rule Forty-Three

Do not treat City resident lists as:

J.924Rule Forty-Four

Do not use City analytics for:

J.925Rule Forty-Five

Do not turn youth programs into:

J.926Rule Forty-Six

Do not map youth.

Map:

J.927Rule Forty-Seven

Do not create public senior-vulnerability lists.

J.928Rule Forty-Eight

Do not force residents to provide health diagnosis when functional information:

J.929Rule Forty-Nine

Do not call RealMap property data:

unless it actually is.

J.930Rule Fifty

Do not allow RealMap or map.ca to receive weaker privacy treatment because:

J.931Rule Fifty-One

Do not allow founder veto over:

J.932Rule Fifty-Two

Do not promise Email for Life before:

business case.

J.933Rule Fifty-Three

Do not create personal data locker merely because:

J.934Rule Fifty-Four

Do not call municipal data sharing:

when it becomes indiscriminate file sharing.

J.935Rule Fifty-Five

Do not call one giant cross-agency record:

without proving necessity.

J.936Rule Fifty-Six

Do not use advertising pixels on municipal service pages without:

J.937Rule Fifty-Seven

Do not use session replay casually.

J.938Rule Fifty-Eight

Do not require social media to receive:

J.939Rule Fifty-Nine

Do not treat a website redesign as:

unless residents can actually find and complete services more easily.

J.940Rule Sixty

Do not measure digital success by:

J.941Rule Sixty-One

Do not measure AI success by:

J.942Rule Sixty-Two

Do not measure privacy success by:

J.943Rule Sixty-Three

Do not measure cybersecurity success by:

J.944Rule Sixty-Four

Do not punish employees for:

J.945Rule Sixty-Five

Do not hide breaches because:

J.946Rule Sixty-Six

Do not rush favourable technology announcement before:

review.

J.947Rule Sixty-Seven

Do not create digital dependency to:

J.948Rule Sixty-Eight

Do not renew critical vendor automatically without:

review.

J.949Rule Sixty-Nine

Do not treat collection notice as substitute for:

J.950Rule Seventy

Do not assume data-sharing agreement creates:

J.951Rule Seventy-One

Do not call future 2027 MFIPPA obligations current 2026 law before they take effect.

J.952Rule Seventy-Two

Do not wait until 2027 to prepare for obligations already enacted to begin then.

J.953The Purpose Test

Ask:

What public service requires this information or technology?

J.954The Authority Test

What lawful authority supports the collection, use or disclosure?

J.955The Minimization Test

What is the least information we actually need?

J.956The Anonymous Test

Can the service work without identifying the resident?

J.957The Notice Test

Does the resident understand why information is being collected?

J.958The Access Test

Who can see it?

J.959The Sharing Test

Who outside the City receives it and why?

J.960The Retention Test

How long should it remain?

J.961The Accuracy Test

What is the source of truth?

J.962The Correction Test

How will errors be fixed?

J.963The Security Test

What happens if someone gains unauthorized access?

J.964The Integrity Test

What happens if information is altered?

J.965The Availability Test

What happens if the system stops working?

J.966The Accessibility Test

Can people actually use it?

J.967The Non-Digital Test

What happens to the resident without a smartphone or Internet connection?

J.968The Cloud Test

Where does the information go, including metadata and administrative access?

J.969The Vendor Test

What can the vendor do with City information?

J.970The Subprocessor Test

Who else can receive it?

J.971The Canadian Test

What practical difference would Canadian ownership, hosting or support make to this specific risk?

J.972The Portability Test

Can we export the information in a usable form?

J.973The Exit Test

Can we leave?

J.974The Restore Test

Can we recover?

J.975The AI Test

Does AI genuinely improve this service, and who remains accountable?

J.976The Surveillance Test

Can we solve the problem with less intrusive means?

J.977The Youth Test

Are we collecting more information about a child or youth than the opportunity requires?

J.978The Campaign Test

Could this municipal information be improperly useful to an election campaign?

If yes:

Strengthen firewall.

J.979The Founder Test

Would the City accept these same privacy and control arrangements from a vendor with no relationship to the Mayor?

J.980The Future Mayor Test

Would we be comfortable if the next administration inherited and used this exact data capability?

J.981The Breach Test

If every record in this system became public tomorrow, how serious would the harm be?

J.982The Dependency Test

If the vendor shut down tomorrow, how long could the City continue?

J.983The Public Trust Test

Would a reasonable resident consider this collection and use proportionate to the service being provided?

J.984The Privacy and Digital Governance Commitment

Owen Sound should commit to:

Use Access, Accuracy, Privacy, Resilience and Independence as the five principles of municipal information governance.

Keep government transparency and resident privacy as complementary rather than opposing goals.

Use the standard: Open government should expose government, not unnecessarily expose residents.

Collect less information where the same lawful service can be delivered with less.

Identify lawful authority before collecting personal information.

Explain why information is being collected and who residents may contact about it where law requires.

Use personal information only for lawful purposes.

Do not disclose information merely because sharing is administratively convenient.

Maintain reasonable accuracy before using personal information for consequential municipal purposes.

Retain and dispose of records according to current law, municipal retention rules, legal holds and legitimate operational requirements.

Use reasonable security measures to prevent unauthorized access, destruction and damage.

Limit access to people who genuinely require the information for their duties.

Distinguish current MFIPPA requirements from additional requirements already enacted for January 1, 2027.

Prepare during 2026 for the municipal privacy-impact and breach-management obligations taking effect in 2027.

Use Privacy Impact Assessment methodology proactively rather than waiting for a legal deadline or privacy incident.

Conduct privacy review before significant systems launch.

Ask whether every required field on a municipal form remains necessary.

Remove fields retained only because somebody might want the information someday.

Do not require identity merely to read public municipal information.

Avoid universal resident accounts and digital identity systems unless compelling public need justifies them.

Never create a general civic dossier combining unrelated municipal interactions.

Never create social, political, civic-participation, trustworthiness or generalized vulnerability scores for residents.

Keep service-specific risk assessments confined to the lawful service purpose for which they were created.

Maintain a Municipal Data Inventory describing important datasets without putting the personal data itself into the inventory.

Include spreadsheets, shadow databases, unofficial cloud accounts and other shadow systems in governance reviews.

Do not assume free software or free cloud accounts are outside municipal privacy and records responsibilities.

Use practical information classification based on sensitivity and operational importance.

Manage information through a defined lifecycle from need and collection through archive or disposal.

Do not retain information indefinitely merely because storage is inexpensive.

Do not delete government accountability records merely in the name of minimization.

Distinguish active information, archival information, backups and vendor-held copies.

Require secure disposal of paper and digital records.

Securely wipe municipal devices before reuse or disposal.

Use secure wiping and clear ownership transfer in any community device-reuse program.

Identify the authoritative source of important municipal information.

Give important public information an institutional owner responsible for accuracy and updates.

Distinguish an update caused by changing circumstances from a correction of a prior error.

Maintain the public Correction Log for material errors.

Treat the municipal website as service infrastructure rather than merely a communications brochure.

Prioritize service information, accuracy, accessibility and navigation ahead of decorative redesign.

Use resident language rather than requiring residents to understand the City's organizational structure.

Apply No Wrong Door to digital service navigation.

Assign owners and review dates to important municipal web pages.

Label archived or superseded information clearly rather than leaving obsolete instructions appearing current.

Meet current Ontario digital-accessibility requirements and treat legal compliance as a floor rather than the complete resident experience.

Use automated, manual and lived-experience accessibility testing where appropriate.

Provide accessible alternatives to inaccessible documents where required and practical.

Use captions, structured documents and plain language.

Never make basic municipal service app-only, smartphone-only, QR-only or social-media-only.

Maintain reasonable phone, print and in-person access.

Design emergency information to survive Internet, power and vendor outages.

Maintain a Digital Systems Index covering purpose, owner, vendor, hosting, data, contract, backup, accessibility and exit.

Classify digital systems by criticality so cybersecurity and recovery effort follows actual public consequence.

Do not assume cloud services are either inherently secure or inherently insecure.

Do not assume locally hosted systems are inherently sovereign or secure.

Evaluate cloud systems according to data sensitivity, provider access, metadata, jurisdiction, security, portability and continuity.

Use Canadian hosting and Canadian suppliers as legitimate resilience considerations where lawful, but never as substitutes for actual security and control.

Verify where sensitive information may be stored, processed, backed up and administratively accessed.

Review relevant subprocessors and vendor access.

Use least-privilege access for both City and vendor personnel.

Require critical systems to support usable data export.

Do not confuse a printable report with full data portability.

Test export and exit before dependence becomes irreversible.

Include exit and migration cost in Complete Cost.

Treat deliberate vendor dependency differently from accidental lock-in.

Prefer open standards, interoperable formats and documented APIs where they improve public control.

Do not assume open-source software is free, secure or maintained.

Keep custom municipal source code, repositories, documentation and credentials under institutional control where the City owns them.

Reduce key-person dependency in custom systems.

Treat backups as useful only when restoration can actually succeed.

Test restoration for critical systems.

Set recovery expectations according to system criticality.

Maintain manual or offline continuity procedures where failure of a digital system would otherwise stop an essential service.

Protect confidentiality, integrity and availability rather than treating cybersecurity only as secrecy.

Use least privilege, account reviews, prompt offboarding and stronger protection for administrative accounts.

Avoid shared privileged accounts where individual accountability matters.

Protect API keys, credentials and administrative secrets.

Train staff without using cybersecurity exercises as public employee-shaming exercises.

Make incident reporting easy and encourage early reporting.

Maintain coordinated cyber and privacy incident procedures.

Distinguish cyber incidents from privacy incidents while recognizing that one event can be both.

Require vendors to notify the City promptly of relevant security and privacy incidents.

Prepare municipal breach-response processes for the explicit MFIPPA obligations scheduled to begin January 1, 2027.

Conduct post-incident root-cause reviews and track repeated causes.

Use Privacy Impact Assessments to change design, not merely to document that a risky design already exists.

Coordinate privacy, cybersecurity, accessibility, records, procurement, architecture and legal reviews rather than creating disconnected approval bureaucracies.

Maintain an inventory of material municipal AI uses.

Classify AI use according to consequence rather than novelty.

Use stronger review where AI may affect enforcement, employment, permits, eligibility, public safety or youth.

Never allow The Algorithm Decided to become a municipal accountability defence.

Keep responsible humans accountable for consequential decisions.

Verify generative AI outputs before they become official municipal information.

Verify AI-generated legal, financial and technical claims against appropriate authoritative sources.

Do not enter personal, confidential, privileged, security-sensitive or protected Indigenous information into unapproved AI tools.

Understand whether AI vendors retain or train on municipal information.

Give residents human escalation from AI-assisted services.

Do not retain chatbot histories indefinitely merely to improve models.

Do not use AI to create individual sentiment, emotion, trustworthiness or civic-worth profiles.

Do not purchase technology merely because it carries an AI label.

Start every AI proposal with the public problem rather than the technology.

Begin surveillance proposals with a defined problem and examine less intrusive alternatives first.

Do not treat camera installation as proof of increased safety.

Limit surveillance purpose, field of view, access and retention according to actual need.

Treat facial recognition, biometrics, licence-plate recognition, audio surveillance, persistent location tracking and drone surveillance as high-risk technologies requiring separate review.

Use facial recognition only after an exceptional and explicit legal, rights, privacy, security and public-necessity review rather than as a routine municipal tool.

Do not use emotion-recognition technology to judge residents.

Design public Wi-Fi as public-access infrastructure rather than data-harvesting infrastructure.

Do not require marketing signup for ordinary public Wi-Fi without a compelling reason.

Minimize persistent device logging and behavioural tracking.

Do not permit public Wi-Fi vendors to monetize residents through behavioural advertising as an unnoticed condition of access.

Use aggregate analytics where aggregate information is sufficient.

Do not build household poverty profiles merely to study broadband access.

Use minimum necessary information for low-income connectivity support.

Never publish maps of program recipients or vulnerable residents.

Design the community calendar as neutral public information infrastructure rather than an advertising marketplace.

Collect only the information needed to list an event.

Protect private organizer contact information where publication is unnecessary.

Use neutral rules for community, cultural and faith events.

Open government datasets where lawful, accurate, safe and useful.

Review open datasets for re-identification, mosaic effects, security, privacy and third-party rights.

Never publish vulnerable-person heat maps as ordinary municipal open data.

Protect sensitive critical-infrastructure details.

Publish aggregate service, financial, asset and procurement information instead.

Use clear licences and machine-readable formats for open data where useful while keeping human-readable access essential.

Assign data stewards without creating unnecessary centralized bureaucracy.

Use minimum-necessary principles when sharing information with Grey County, Ontario, Canada, police, health organizations, schools, nonprofits and other partners.

Recognize that No Wrong Door does not mean One Giant Government Dossier.

Use warm handoffs without automatically transferring whole files.

Use data-sharing agreements where appropriate while recognizing that contracts do not create legal authority that does not otherwise exist.

Do not share resident information with commercial data brokers for ordinary municipal purposes.

Do not upload municipal resident lists to behavioural-advertising platforms.

Maintain an absolute operational firewall between municipal information and political campaign targeting.

Never use City email lists, event registrations, business contacts, youth participants, senior programs, Resident Pulse or Strong Vote information as campaign lists.

Apply higher safeguards to youth information.

Use YouthMap to map opportunities rather than individual young people.

Do not create persistent youth employability, civic-participation or political profiles.

Keep media consent separate from program participation where practical.

Collect health information only where genuinely required and lawfully governed.

Ask for functional accessibility needs rather than diagnosis where diagnosis is unnecessary.

Do not create broad vulnerability registries of seniors or other residents merely because a program could technically support one.

Keep RealMap property information distinct from personal resident information.

Do not use RealMap as a pathway to behavioural advertising, cross-property resident profiling or municipal tracking of private buyer behaviour.

Clearly identify whether RealMap data is private-platform information, public information or official municipal information.

Apply the same or stronger privacy, security, accessibility and exit standards to map.ca as to any unrelated vendor.

Give map.ca no founder exemption.

Use Public Standard First, Platform Second, Founder Last.

Resolve municipal ownership, licensing, administrative control, source code, domains and data rights before any public adoption.

Never permit a private founder to retain a personal veto over municipal information infrastructure.

Treat persistent municipal email and personal data-locker concepts as high-risk proposals requiring complete legal, privacy, security, records and financial review before any promise of implementation.

Do not create a large centralized personal-data vault merely because it is technologically possible.

Use map.ca to map places and public opportunities rather than people by default.

Never map residents according to political affiliation, faith, vulnerability or youth status.

Define digital sovereignty as practical control rather than isolation from foreign technology.

Ask Can We Leave? of every critical digital vendor.

Support Canadian digital capability through lawful procurement, open standards, interoperability and shared municipal tools.

Do not attempt to turn Owen Sound into a national cloud provider or data-centre project without a compelling business case.

Choose capability before technological prestige.

Share reusable non-sensitive municipal schemas, templates, procurement clauses and code where doing so creates Canadian public value.

Ensure shared municipal standards can outlive individual vendors.

Require major technology procurements to address privacy, security, accessibility, portability, data ownership, hosting, records, interoperability and exit before selection.

Do not treat the lowest price, best demo, largest company, Canadian ownership or incumbent status as sufficient procurement evidence by itself.

Verify marketing claims such as secure, anonymous, encrypted, Canadian or AI-powered.

Understand encryption scope and key control for sensitive systems.

Use contractual incident, data, subprocessor, security, accessibility, backup, export, termination and deletion obligations where appropriate.

Build privacy, accessibility, security and exit into procurement before the winning vendor is selected.

Monitor concentration risk where one supplier controls multiple essential municipal systems.

Ask what happens if a critical supplier fails, is acquired, changes terms or increases prices materially.

Maintain institutional recovery control for critical accounts, domains and cloud tenants.

Track domain renewals, certificates, licences, support dates and contract expiries.

Budget for digital maintenance, cybersecurity, accessibility remediation and future migration rather than treating software as one-time capital.

Use web analytics only for defined public-service purposes.

Avoid advertising pixels, cross-site behavioural tracking and unnecessary session replay on municipal service pages.

Review third-party embeds for tracking and accessibility impacts.

Do not treat cookie banners as substitutes for data minimization.

Limit retention of search logs, chatbot queries and other potentially sensitive service analytics.

Use routine and proactive disclosure to make government information easier to obtain while still protecting personal information.

Never publish personal information merely to reduce freedom-of-information workload.

Preserve important institutional records even while minimizing unnecessary personal data.

Keep campaign records and municipal records institutionally separate.

Do not import campaign contacts into City systems or export City contacts into campaign systems.

Design Strong Vote and Resident Pulse so verification information is separated from political or policy opinion wherever practical.

Never create a permanent municipal political-preference database from civic consultation.

Inform public participants when comments, names, recordings or delegations will become public.

Recognize that participation in a public meeting does not authorize unrelated profiling.

Protect employee information and purpose-limit monitoring technologies.

Use GPS, access logs and other workplace technologies for defined operational purposes rather than secret generalized productivity surveillance.

Apply high scrutiny to keylogging, screen capture, webcam monitoring and AI productivity scoring.

Respect collective agreements and employment law when introducing workplace monitoring.

Govern personal devices, remote work, messaging applications and portable media according to security and records risk.

Assign clear roles to business owners, IT, privacy, records, cybersecurity, accessibility, procurement and legal functions.

Do not give the Mayor or Councillors unrestricted access to resident databases merely because they are elected.

Keep constituency service information proportionate to the case being assisted.

Apply heightened information safeguards during election periods.

Measure privacy incidents, serious incidents, repeat causes and remediation rather than incident count alone.

Do not set a target of zero reported privacy incidents if doing so may discourage honest reporting.

Measure official information quality through ownership, review, broken links, stale pages and corrections rather than pretending zero corrections means perfect accuracy.

Measure digital sovereignty through inventory, control, export, tested exit, restore capability, contract awareness and unsupported-system reduction.

Do not reduce privacy and digital governance to a single Green score.

Use risk-specific Green, Amber, Red and Grey indicators with Grey meaning important information remains unknown.

Use contract renewal, major system change, incidents, new AI functionality and new integrations as review triggers.

Use the first 30 days to establish the Privacy and Digital Governance Baseline.

Use the first 30 days to identify critical systems, personal-information systems, vendors, cloud services, AI tools, public analytics, Wi-Fi, major sharing arrangements and approaching contract renewals.

Use the first 30 days to confirm readiness for January 1, 2027 municipal privacy obligations already enacted by Ontario.

Use the first 60 days to publish a safe high-level Digital Systems and Privacy Baseline without exposing vulnerabilities.

Use the first 60 days to remove obvious unnecessary trackers, abandoned accounts and uncontrolled critical administrative dependencies.

Use the first 100 days to establish the Data Inventory, Digital Systems Index, privacy-review trigger, AI standard, vendor-exit standard and incident-response framework.

Use Year One to inventory systems, reduce unnecessary collection, review major vendors and establish accurate public-information ownership.

Use Year Two to strengthen portability, restore testing, digital accessibility, retention and analytics minimization.

Use Year Three to address legacy systems, unsupported applications, high vendor lock-in and identity concentration.

Use Year Four to publish a Four-Year Privacy, Information and Digital Governance Audit.

Name privacy and digital failures rather than reporting only technological successes.

Give the next Council the Data Inventory, Digital Systems Index, contract renewals, privacy reviews, incident history, AI inventory, surveillance inventory, vendor exits and unresolved risks.

Never let the next Council discover after taking office that the City cannot access, restore, export or control one of its own critical systems.

Never measure digital success by app downloads, AI-tool counts or data volume.

Measure whether residents received easier, safer, more resilient and more independent public service.

Apply the final privacy and digital test to every significant system: Why do we need it, what information does it collect, what law and public purpose justify that information, who can access it, where does it go, how long does it remain, can residents still obtain service without unnecessary digital compulsion, can the City recover it, and can the City leave?

The privacy and digital-governance framework can ultimately be reduced to ten rules:

Collect less.

Explain why.

Keep access narrow.

Keep information accurate.

Protect what remains.

Delete or dispose of it lawfully when its purpose ends.

Keep essential service available without unnecessary digital compulsion.

Own or control the public information and systems that matter.

Test the backup and the exit.

Never turn ordinary municipal life into a permanent resident profile.

Digital government should make Owen Sound:

It should not make residents:

The City does not need to know everything.

It needs to know:

enough to do its job well.

And when information genuinely is required:

government should be able to explain why it has it, who can use it, how it is protected, how long it will remain and what happens when the system holding it fails.

That is digital stewardship.

Open government should expose government, not unnecessarily expose residents. Collect less. Protect what remains. Keep the system recoverable. Keep the resident free to live an ordinary civic life without becoming a permanent government profile.

← Appendix I: Legal Review and Decision StandardsAppendix K: Accessibility Standards and the Complete Accessible Journey →