Owen Sound: A Four-Year City Business Plan

Home › The Public Scorecard › Chapter 55

The Public Scorecard

Chapter 55Privacy and Information: The Public Privacy and Information Scorecard

10,859 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 needs information to function.

It needs to know enough to:

But the ability to collect information does not create a reason to collect everything.

Modern municipal systems can quietly accumulate:

Individually, each dataset may appear harmless.

Combined, they can become:

a detailed profile of a resident's life.

That should not be the default condition of municipal government.

The central principle is:

The City should know enough to serve residents well, but not so much that ordinary municipal life becomes a permanent profile of the resident.

The second principle is equally important:

Information the City publishes should be accurate, attributable, current and correctable.

Privacy and public information are therefore connected.

Residents should know:

And when the City tells residents something:

They should know:

The original Safe Information proposal specifically contemplates public Wi-Fi and connection support without relying on property-tax-funded broadband expansion, as well as reuse of functional phones rather than assuming every resident must purchase new hardware.

The source framework also proposes stronger public data stewardship and community information infrastructure.

The Scorecard should determine whether those ideas improve access without creating:

55.1Purpose

The Privacy and Information Scorecard should answer:

What personal information does the City collect?

Why?

Which systems hold it?

How long is it retained?

Who can access it?

Which vendors can access it?

Which other governments or organizations receive it?

What data is no longer needed?

Is it being deleted according to lawful retention rules?

Are privacy incidents occurring?

Are they being corrected?

Can residents still obtain essential service without unnecessary digital profiling?

Is public Wi-Fi private enough for ordinary use?

Are recycled-device programs handled safely?

Are City websites collecting unnecessary analytics?

Are AI systems receiving sensitive information?

Are surveillance systems proportionate?

Is public information current and sourced?

Are corrections visible?

Can residents obtain information by phone, paper or in person?

Is public data released without exposing private residents?

Can the City leave its software vendors without losing its own information?

Those are the meaningful measures.

55.2Privacy Is an Operating Standard

Privacy should not sit solely with:

Every department that collects information owns part of the responsibility.

55.3Information Is an Asset

Municipal information has value.

It should be:

55.4Information Is Also a Liability

Data that no longer has a lawful or operational purpose can create:

More information is not automatically better.

55.5Privacy Scorecard Headline Measures

A first-page dashboard could include:

  1. Major information systems inventoried.
  2. Systems containing personal information.
  3. Systems with documented collection purpose.
  4. Systems with current retention rules.
  5. Systems with external vendor access.
  6. High-risk systems reviewed.
  7. Privacy-impact reviews completed where appropriate.
  8. Material privacy incidents.
  9. Material cybersecurity incidents affecting personal information.
  10. Unresolved privacy incidents.
  11. Access-control reviews completed.
  12. Departed-user accounts removed on time.
  13. Vendor accounts reviewed.
  14. Data-sharing arrangements reviewed.
  15. High-risk datasets reduced or eliminated.
  16. Public Wi-Fi privacy review.
  17. Public Wi-Fi uptime.
  18. Device-reuse privacy compliance.
  19. AI systems inventoried.
  20. AI systems receiving protected data.
  21. Surveillance systems reviewed.
  22. Public-information corrections.
  23. Stale public pages corrected.
  24. External program pages with verification dates.
  25. Non-digital service availability.
  26. Open-data privacy reviews.
  27. Data export tests.
  28. Vendor exit tests.
  29. Major unresolved privacy risks.

55.6No Single Privacy Score

Avoid:

Privacy Score: 94/100

One serious breach can matter more than:

Show components.

55.7Information Inventory

The City should maintain a current inventory of important information systems.

55.8System Inventory Fields

For significant systems:

System name

Department

Purpose

Information types

Personal information?

Sensitive information?

System owner

Vendor

Hosting arrangement

Access roles

Data sharing

Retention

Export capability

Last privacy review

Last security review

Contract renewal

55.9Not Every Spreadsheet Needs the Same Treatment

Use:

But important unofficial datasets should not escape inventory simply because they are:

55.10Shadow Systems

Departments may create informal tools because:

Identify significant shadow systems.

55.11Shadow System Risk

A spreadsheet containing:

can be just as sensitive as a formal database.

55.12Purpose

Every significant personal-information collection should have:

55.13Purpose Test

Ask:

What specific municipal service or legal obligation requires this information?

If the answer is unclear:

Reconsider collection.

55.14"Might Be Useful Later" Is Weak

Do not collect personal information simply because:

it could be useful one day.

55.15Purpose Limitation

Information collected for one purpose should not quietly become:

without proper authority and notice.

55.16Example

A recreation registration list exists to:

It is not automatically:

55.17Campaign Firewall

Municipal data does not become campaign data.

Ever.

55.18No Incumbent Data Advantage

An elected official should not receive privileged access to resident information for:

55.19Data Minimization

Collect:

the least amount of information reasonably necessary to perform the service.

55.20Form Review

For major public forms:

Review each field.

Ask:

Do we still need this?

55.21Required Versus Optional

Clearly distinguish:

55.22Do Not Make Optional Data Functionally Mandatory

A form should not reject submission because an optional demographic field is blank.

55.23Date of Birth

Do not collect full birthdate where:

would satisfy the purpose.

55.24Home Address

Do not collect full home address merely because a form template always has one.

55.25Phone Number

Same.

55.26Email

Same.

55.27Government Identification

Do not collect government ID numbers unless:

55.28Social Insurance Number

Collect only where legitimate legal, employment or tax administration requires it.

Never through ordinary public-interest registrations.

55.29Banking Information

Only where:

requires it.

Use secure systems.

55.30Health Information

Avoid unless a specific service requires it.

Use stronger safeguards.

55.31Accommodation Information

Collect:

rather than unnecessary diagnosis where possible.

55.32Children

Information about minors deserves additional care.

55.33Parent Information

Collect only what the program requires.

55.34Emergency Contact

May be legitimate for certain programs.

Do not reuse for unrelated purposes.

55.35Political Opinion

Ordinary municipal service should not collect it.

55.36Religious Belief

Likewise, unless a highly specific lawful purpose exists.

Ordinary service does not need it.

55.37Civic Participation

Participation in:

should not become a generalized ideology profile.

55.38Strong Vote

Any voluntary civic-participation tool should use:

55.39Verify Person, Protect Opinion

This principle applies throughout resident participation.

55.40Retention

Information should not be kept indefinitely because storage is cheap.

55.41Retention Schedule

Important information systems should have:

Some records must be kept.

Follow:

55.43Operational Retention

Some data may be needed temporarily for:

Delete or archive appropriately when that purpose ends.

55.44Historical Record

Some municipal records legitimately deserve long-term preservation.

55.45Archive Versus Operational Database

Long-term archival value does not mean:

55.46Deletion

Deletion should be:

55.47Vendor Deletion

When data is deleted by the City:

Ask whether copies remain with:

55.48Contract Requirement

Important vendors should have clear:

obligations.

55.49Backup

Backups may retain information temporarily.

Document the lifecycle.

55.50Backup Is Not Excuse for Infinite Retention

Design systems so deleted data does not persist forever without reason.

55.51Data Disposal

Old:

require secure disposal.

55.52Paper Still Matters

Privacy is not only digital.

55.53Unattended Documents

Sensitive records should not sit:

55.54Printing

Review unnecessary printing of personal information.

55.55Secure Destruction

Use appropriate processes.

55.56Access Control

Not every employee should access every dataset.

55.57Least Privilege

Give users only the access needed for:

55.58Role Change

When an employee changes jobs:

Review access.

55.59Departure

Remove access promptly.

55.60Contractor Access

Give temporary contractors:

55.61Vendor Support Access

Remote vendor access should be:

55.62Shared Password

Avoid.

55.63Individual Accounts

Use where practical.

55.64Administrative Accounts

Stronger controls.

55.65Privileged Access Review

High-level system access should be reviewed periodically.

55.66Dormant Accounts

Disable.

55.67Former Staff Accounts

No.

55.68Seasonal Staff

Access should expire appropriately.

55.69Student Accounts

Same.

55.70Youth Program Access

Young participants should not receive unnecessary access to personal resident records.

55.71Access Logging

For sensitive systems:

Maintain appropriate audit records.

55.72Logging Is Not Employee Surveillance by Default

Use logs for:

Do not transform them into unnecessary behavioural monitoring.

55.73Access Review Measure

Possible:

Percentage of designated high-risk systems completing scheduled access review.

55.74Authentication

Use proportionate security.

55.75Multi-Factor Authentication

Appropriate for many administrative systems.

Do not make essential resident services smartphone-only without alternative.

55.76Password Reset

Protect against:

55.77Identity Verification

Verify only as strongly as the service requires.

55.78Over-Verification

Do not require government photo ID merely to:

55.79Anonymous Access

Many public services should permit anonymous:

55.80Anonymous Reporting

Some reporting systems may permit anonymous concerns.

Use carefully.

55.81Identity When Needed

Payments, permits and formal applications may legitimately require identity.

55.82Universal Digital Identity

Do not require a universal municipal digital identity for ordinary civic life.

55.83One Account for Everything Risk

A single account can be convenient.

It can also create:

55.84Service-Specific Identity

Use where appropriate.

55.85Resident Choice

Where a unified account exists:

Residents should still be able to access appropriate public information without signing in.

55.86No Civic Profile

Do not build a single profile showing:

unless truly required for specific lawful administration.

55.87No Resident Score

Never.

55.88No Behavioural Risk Score

Never.

55.89No Civic Engagement Score

Never.

55.90No "Good Resident" Ranking

Never.

55.91Data Sharing

Some municipal services require sharing with:

55.92Sharing Register

Maintain an inventory of major recurring data-sharing arrangements.

55.93Sharing Fields

For significant arrangements:

Partner

Purpose

Data categories

Authority

Frequency

Retention

Security

Review date

55.94Minimum Necessary Sharing

Do not provide a complete dataset when:

will do.

55.95Shared Is Not Surrendered

The City should understand what happens to data after transfer.

55.96Partner Retention

Where agreements permit:

Define.

55.97Partner Reuse

Restrict unrelated reuse where appropriate.

55.98Subcontractors

Understand whether partner vendors can access the information.

55.99Cross-Border Processing

For important systems:

Understand where data may be processed.

55.100Canadian Hosting

Canadian hosting can improve jurisdictional clarity and resilience in some cases.

It is not a substitute for:

55.101Foreign Hosting

Should not be dismissed automatically.

Evaluate:

risk.

55.102Data Sovereignty

Ask:

Who controls the data, who can access it, and can we leave?

55.103Vendor Inventory

Every major personal-information vendor should be visible internally.

55.104Vendor Role

Distinguish:

Processor

Host

Software Provider

Analytics Provider

Support Contractor

as appropriate.

55.105Vendor Contract

Important contracts should address:

55.106City Owns Its Public Records

A vendor should not become the practical owner simply because:

55.107Export

The City should be able to retrieve its information in:

format.

55.108Export Test

Do not wait until contract termination.

Test periodically for high-risk systems.

55.109Export Is Not a Screenshot

A true exit requires usable:

where needed.

55.110Proprietary Format

Understand conversion risk.

55.111API Access

Where appropriate:

Use documented interfaces.

55.112Exit Cost

Include:

55.113No Hostage Data

Vendor pricing should not make leaving practically impossible.

55.114Renewal Review

Before contract renewal:

Ask:

Can we still leave?

55.115Data Portability Score

Do not reduce to a simplistic number.

Use pass/fail tests by system.

55.116Privacy Impact Review

High-risk projects should receive appropriate privacy review before launch.

55.117Privacy Review Timing

Before:

Not after controversy.

55.118High-Risk Triggers

Possible triggers:

55.119Not Every Form Needs a Formal Impact Assessment

Use proportionate thresholds.

55.120Privacy by Design

Ask early:

Can we accomplish the purpose with less data?

55.121Privacy by Default

Default settings should favour:

Do not rely on vague consent where the City is actually exercising legal authority.

Use the proper legal basis and notice.

Where an optional service genuinely relies on consent:

Make it understandable.

Avoid:

Agree to everything or receive no unrelated service.

55.125Withdrawal

Where consent is the appropriate basis:

Explain withdrawal.

55.126Privacy Notice

Forms should tell residents enough to understand:

May still be required.

Provide a plain-language summary.

55.128No False Privacy Promise

Do not say:

Your data will never be shared

if law may require disclosure.

Use accurate language.

55.129Privacy Incidents

Track material privacy incidents.

55.130Incident Definition

Use the City's applicable professional and legal framework.

55.131Examples

May include:

55.132Privacy Incident Is Not Always Cyberattack

Distinguish:

55.133Cyber Incident Is Not Always Privacy Breach

A service outage may involve no personal data exposure.

Keep categories separate.

55.134Incident Response

Every material incident should have:

55.135Notification

Follow applicable law and professional advice.

55.136No Political Suppression

A privacy incident should not be hidden because:

55.137No Premature Disclosure

Likewise, do not release unverified details that:

55.138Incident Status

Possible:

Detected

Contained

Investigating

Corrective Action

Closed

55.139Incident Closure

Do not close until:

are addressed.

55.140Root Cause

Possible:

55.141Repeat Incident

Repeated incidents of the same type require:

55.142Incident Count Is Not Complete Risk

One severe breach can matter more than:

55.143Severity

Use professionally defined severity levels.

55.144No Breach Points Game

Do not create a public game where departments hide small incidents to protect a score.

Encourage reporting.

55.145Internal Reporting Culture

Staff should report mistakes early.

55.146No Retaliation for Good-Faith Reporting

Important.

55.147Human Error

Design systems to reduce predictable errors.

55.148Auto-Complete Email Risk

For sensitive communication:

Use appropriate safeguards.

55.149Bulk Email

Use proper recipient privacy.

55.150BCC Is Not Complete Privacy Program

Use appropriate mailing systems for significant communications.

55.151Attachments

Check:

55.152Metadata

Documents can contain hidden information.

Staff training and tools should address material risks.

55.153Public Wi-Fi

The Safe Information proposal specifically includes free public Wi-Fi as an access tool.

The Privacy Scorecard must ensure access does not become surveillance.

55.154Public Wi-Fi Purpose

Possible purpose:

provide basic Internet access in selected public spaces or facilities.

55.155Public Wi-Fi Is Not Resident Tracking

Do not use it to build:

55.156Connection Logs

Retain only what:

require.

55.157Device Identifier

Avoid long-term use for:

55.158Location Analytics

Do not track devices across multiple municipal locations simply because the Wi-Fi vendor offers the feature.

55.159Marketing Analytics

Disable where unnecessary.

55.160Captive Portal

Keep simple.

Do not require residents to subscribe to:

to obtain public Wi-Fi.

Obviously.

55.163Email Requirement

Consider whether an email is actually necessary.

Anonymous or low-friction access may be preferable.

55.164Terms

Use understandable terms.

55.165Security Notice

Explain that public Wi-Fi has inherent security considerations.

Do not promise:

55.166Wi-Fi Uptime

Track:

55.167Wi-Fi Coverage

Measure whether it serves the intended public locations.

55.168Usage

Aggregate usage may help planning.

55.169Unique Devices

Do not casually equate:

55.170Session Count

Not residents.

Label correctly.

55.171No Foot-Traffic Substitution

Wi-Fi connections are not:

55.172Public Wi-Fi Cost

Show:

55.173Free to User

If taxpayer-funded:

Say:

no user fee

rather than:

free to provide.

55.174Community Broadband

A community-owned broadband study should proceed only if a real:

problem is established.

The source proposal expressly frames such a study around external broadband funding rather than property-tax financing.

55.175Broadband Study Data

Do not build household-level poverty maps merely to justify a broadband project.

Use:

evidence.

55.176Public Wi-Fi and Broadband Are Different

Do not treat a few Wi-Fi hotspots as:

55.177Connectivity Support

Low-income connectivity assistance should use minimal information.

55.178Means Testing

If another program already determines eligibility:

Consider whether the City can avoid duplicative collection.

55.179No Poverty Database

Do not create a permanent municipal profile of residents receiving connectivity help.

55.180Device Reuse

The source plan also proposes reusing functional phones and devices.

Privacy must be designed into the program.

55.181Donated Device

Before reuse:

Ensure proper:

55.182Previous Owner Data

Must not transfer to recipient.

55.183Recipient Data

Should not remain with the City after distribution beyond what is necessary for program administration.

55.184Device Wipe Standard

Use a documented process appropriate to the device.

55.185Unwipeable Device

Do not redistribute.

Dispose securely.

55.186Account Lock

Check for:

55.187SIM Card

Remove prior SIM and associated data.

55.188Memory Card

Check.

55.189Photos and Messages

Must not remain.

55.190Device Recipient

Explain:

55.191Emergency Calling

Verify capability before claiming:

55.192No Tracking Software

Do not install hidden City tracking on reused devices.

55.193Support Software

If remote support is offered:

Make it:

55.194Device Program Inventory

Track:

55.195No Recipient Public List

Never.

55.196Device Donation Receipt

Where appropriate:

Provide.

55.197Donor Data

Do not keep unnecessary personal information from donors.

55.198Website Privacy

The municipal website itself should be reviewed.

55.199Analytics

Ask:

What website analytics do we actually need?

55.200Page View

Often enough.

55.201Individual Behaviour

Usually unnecessary.

55.202Advertising Tracker

Municipal websites should not casually embed:

55.203Third-Party Embed

A video, map or social feed can transmit data to:

Review significant embeds.

A banner is not proof of good privacy.

Reduce unnecessary tracking instead of merely asking residents to click:

Accept All.

55.205Essential Cookies

Use as needed.

55.206Non-Essential Tracking

Justify or remove.

Do not make:

bright and easy while:

is hidden through several screens.

Search terms may reveal sensitive concerns.

Retain only as needed.

55.209Form Drafts

Understand whether incomplete form data is stored.

55.210Abandoned Form

Do not retain indefinitely without reason.

55.211Session Replay

Avoid invasive website recording unless a compelling case exists.

55.212Heatmaps

Use caution.

Aggregate design analytics may help.

Individual behavioural replay usually offers more detail than a City needs.

55.213Social Media Pixels

Do not install political or advertising-platform tracking merely for:

55.214City Newsletter

Collect:

needed to send it.

55.215Unsubscribe

Easy.

55.216Newsletter List

Not a campaign list.

55.217Community Calendar

The public calendar should collect enough information to:

55.218Event Organizer Data

Publish only what is intended as:

55.219Internal Contact

May differ from public contact.

55.220Event Attendee Data

The City does not need attendee identity merely because an event is listed.

55.221Calendar Analytics

Aggregate.

55.222map.ca Information Infrastructure

The source proposal imagines map.ca as potential public infrastructure, with public ownership protections before municipal adoption.

Any implementation must therefore pass the same Privacy Scorecard as every other system.

55.223No Founder Exception

A system associated with the Mayor receives:

55.224Public Standard First

Define:

requirements before choosing platform.

55.225No Forced Account

Residents should be able to browse appropriate public information without:

55.226Email for Life

Any permanent-email concept must be treated as:

until governance, security, retention, portability and funding are proven.

55.227Email Is High-Risk Infrastructure

Email can contain:

information.

Do not launch lightly.

55.228Municipal Email Provider Question

Before any City-connected permanent email:

Ask whether the municipality should operate:

infrastructure at all.

55.229Independent Governance

If such a system ever proceeds:

It should not depend on:

55.230Exit

Residents must be able to:

55.231Domain Control

Long-term public email needs stable:

55.232No Lock-In Through Identity

Do not make email address the key that traps every municipal service into one platform.

55.233Data Locker

A resident-controlled data locker is an idea, not a predetermined project.

55.234Data Locker Decision Gate

Proceed only if:

are demonstrated.

55.235Data Locker Can Increase Risk

Centralizing information can create:

55.236"Resident Controlled" Must Be Real

If the City can access everything automatically:

It is not fully resident-controlled.

55.237No Data Locker by Momentum

The correct decision may be:

do not build it.

55.238Alternative

Teaching residents:

may achieve more with less risk.

55.239Safe Information

The Safe Information Program should focus on:

55.240Information Accuracy

Official City information should have:

55.241Stale Page

Old information can be dangerous.

55.242Review Date

High-impact public pages should have periodic review.

55.243External Programs

Housing, business and benefit pages describing other governments should show:

Last verified [date].

55.244No Stale Grant Promise

Remove or archive expired programs.

55.245Current Does Not Mean Permanent

Even current information can change.

55.246Source

Where possible:

Link internally to or identify the authoritative source.

55.247City Interpretation

If the City summarizes another government's program:

Label it as:

55.248Formal Rule

Where a legal rule matters:

Point residents to the authoritative legal or regulatory source.

55.249Plain Language

Provide an understandable explanation.

Do not oversimplify until it becomes wrong.

55.251Correction Log

The City should maintain a public Correction Log for material public-information errors.

55.252Correction Fields

Date

Original statement

Corrected information

Reason

Affected page or service

55.253Minor Typo

Not every typo needs the public log.

Use materiality.

55.254Material Error

Examples:

55.255Correct in Place and Record

Do both where appropriate.

55.256No Silent Rewrite of Material Error

If residents may have relied on it:

Make the correction visible.

55.257Correction Is Not Failure Theatre

Government should normalize:

we published this incorrectly and fixed it.

55.258Error Rate

Do not create incentives to hide errors by overemphasizing:

Corrections are evidence the process works.

55.259Repeat Error

Repeated error from the same source deserves process review.

55.260Public Information Owner

Every major information page should have an internal owner.

55.261Orphan Page

Old pages without an owner should be:

55.262Archive

Historical pages should be clearly labelled:

Archived. Not Current.

55.263Search Results

Archived information should not appear indistinguishable from current guidance.

55.264Date Everything Important

Particularly:

55.265Source Date

Where source data is older:

Show it.

55.266Publication Date Is Not Data Date

Distinguish.

55.267Official Versus Informal

A social-media post should not override:

55.268Social Media Correction

If a material wrong post was widely distributed:

Correct there too.

55.269Screenshot Persistence

Deleting a wrong post does not mean residents did not see it.

Publish correction.

55.270Misinformation About City Services

The City may correct false claims about:

55.271No Truth Ministry

The City should not become arbiter of:

55.272Scope

Correct:

55.273Opinion

Do not label disagreement:

55.274Criticism

Not misinformation simply because:

55.275Data Interpretation

Residents may interpret the same statistics differently.

Publish:

55.276Deepfakes and Impersonation

The City may need protocols for false:

55.277Verification Page

Maintain a simple official place to verify major:

55.278Cryptographic Verification

Could be explored for high-value documents if practical.

Do not complicate ordinary communication unnecessarily.

55.279Official Domains

Residents should know which domains and accounts are official.

55.280Domain Inventory

Maintain control of:

55.281Account Succession

Credentials belong to the institution.

Not one employee.

55.282Mayor Account

Official mayoral channels remain municipal records and institutional assets where applicable.

Campaign channels remain separate.

55.283Social Media Archive

Follow applicable record rules.

55.284Deleted Post

Do not assume deletion eliminates record obligations.

55.285Direct Messages

Public business conducted through official social channels may create records.

Use proper systems.

55.286Personal Account

Do not conduct sensitive municipal business through a personal social account when official channels should be used.

55.287Text Messaging

Likewise.

55.288Messaging Apps

Convenience does not eliminate:

responsibilities.

55.289Records Management

Privacy and transparency sometimes pull in different directions.

Both must be handled properly.

55.290Public Record Is Not Public Personal Data

A municipal record may exist without every part being:

55.291Access to Information

Respond under the applicable legal framework.

55.292Open by Default

For non-sensitive public information:

Publish proactively where useful.

55.293Redaction

Protect information that should not be disclosed.

55.294Over-Redaction

Do not hide embarrassing public information merely because disclosure is uncomfortable.

55.295Under-Redaction

Do not expose private residents merely to appear transparent.

55.296Privacy Versus Open Government

The principle is:

Open government should expose government, not unnecessarily expose residents.

55.297Contracts

Publish appropriate public contract information.

55.298Employee Personal Information

Protect appropriately.

55.299Individual Service Request

Do not publish a resident's complaint with identifiable personal details merely to show transparency.

55.300Aggregate Service Data

Usually sufficient.

55.301Open Data

Public data should maximize usefulness while minimizing re-identification risk.

55.302Direct Identifier

Remove where unnecessary.

55.303Indirect Identifier

Be careful.

A dataset with:

can identify someone even without name.

55.304Small Cell

Suppress or aggregate where appropriate.

55.305Vulnerable Population

Extra caution.

55.306No Vulnerability Map

Do not map:

at household level.

55.307Neighbourhood Aggregation

Can support planning where privacy is protected.

55.308Open Data Review

Before publishing a dataset:

Ask:

Could this reasonably identify a person when combined with other public information?

55.309Mosaic Effect

Multiple harmless datasets can become identifying when combined.

Consider that.

55.310Property Data

Some property information may already be public through lawful systems.

That does not justify publishing every personal detail the City possesses.

55.311RealMap

Any property-information platform must distinguish:

55.312Property Is Not Person

Do not turn property information into:

55.313Real Estate Listings

Public listing information should come from:

sources.

55.314No Resident Behaviour Layer

Do not add:

to property profiles.

55.315RealMap Access

Basic browsing should not require:

unless necessary for a specific feature.

55.316YouthMap

Maps opportunities.

Not youth.

55.317Seniors Map

Do not create a public map of:

55.318Snow Brigade

Assignments can be managed privately.

55.319Safety Maps

Aggregate incidents.

Protect victims.

55.320Infrastructure Map

Public information should exclude:

55.321Indigenous Knowledge

Information shared by Saugeen Ojibway Nation or knowledge holders does not automatically become:

Respect:

55.323Archaeology

Sensitive site information may require protection.

55.324No Open Data Absolutism

Some information should remain:

55.325Data Classification

Use a practical classification model.

Possible:

Public

Internal

Confidential

Highly Sensitive

Use actual City policy terminology if adopted.

55.326Classification Is Not Secrecy Button

Departments should not label embarrassing material:

without basis.

55.327Sensitive-by-Default Fields

Certain data types deserve stronger controls.

55.328Public-by-Default Fields

Other records should be easier to release proactively.

55.329Classification Review

Old classifications may need review.

55.330AI Inventory

Every material municipal AI system should appear in a public or internal inventory appropriate to risk.

55.331AI Definition

Avoid arguing endlessly about marketing labels.

If software uses automated models to:

in a meaningful municipal process, review it.

55.332AI Use Categories

Possible:

Drafting Assistance

Search

Summarization

Translation

Customer Service

Decision Support

Automation

Image or Video Analysis

55.333High-Impact AI

Systems affecting:

need stronger review.

55.334Low-Risk AI

Drafting a first version of:

may be lower risk.

Still requires records and accuracy rules.

55.335AI Input

Staff should know what information can be entered.

55.336Protected Data

Do not enter protected resident data into public consumer AI tools unless:

55.337Vendor Training

Understand whether vendor may use prompts or outputs for:

55.338Default Assumption

Do not assume:

AI vendor cannot see it.

Verify the contract and architecture.

55.339AI Data Retention

Understand:

55.340AI Output

Review before using for:

decisions.

55.341Human Accountability

There must be a human or authorized institution responsible for the final decision.

55.342No AI Excuse

Do not say:

the algorithm decided.

Government remains accountable.

55.343AI Hallucination

Track material errors where AI was used in public information.

55.344AI Correction

Correct publicly if the error affected residents.

55.345AI Source

For factual municipal answers:

Point to official sources where practical.

55.346AI Records

Determine which AI interactions constitute municipal records under applicable rules.

55.347AI Procurement

Require:

terms.

55.348AI Pilot

Pilot before broad deployment.

55.349AI Stop Condition

Stop if:

outweighs value.

55.350AI Is Not Modernization by Itself

A bad process with AI can remain:

55.351AI Reduction

Automation may reduce repetitive work.

Measure actual service impact.

55.352No Employee Surveillance AI

Do not use AI to create:

without compelling lawful purpose and governance.

Default should be no.

55.353No Resident Emotion Detection

No.

55.354No Political Sentiment Profiling

No.

55.355Surveillance

Cross-reference Section 51.

55.356Surveillance Inventory

Maintain.

55.357Camera Purpose

Document.

55.358Retention

Document.

55.359Access

Document.

55.360Facial Recognition

No default use.

55.361Licence Plate Recognition

Any use requires:

review.

55.362Drone

Municipal drone use can support:

It can also create privacy concerns.

55.363Drone Purpose

Define mission before flight.

55.364No Casual Residential Surveillance

Do not fly simply to:

55.365Incidental Capture

Minimize and handle appropriately.

55.366Body-Worn Cameras

If used by any municipal enforcement function:

Follow the applicable legal and operational governance framework.

Do not duplicate police policy through mayoral direction.

55.367Audio Recording

More intrusive than ordinary visual observation.

Review accordingly.

55.368Meeting Recording

Public Council meetings may appropriately be recorded.

That does not mean every interaction with City staff should be.

55.369Call Recording

If service calls are recorded:

Tell callers as required and define purpose.

55.370Call Analytics

Do not use voice recordings for:

by default.

55.371Biometric Data

High-risk.

55.372Fingerprint

Do not collect for ordinary public service.

55.373Face

Same.

55.374Voiceprint

Same.

55.375Convenience Is Not Enough

Biometrics require a much stronger justification than:

faster login.

55.376Location Data

Precise location can be highly revealing.

55.377City App

Do not request continuous location unless the feature genuinely needs it.

55.378"Always Allow"

Avoid unless essential.

55.379Service Request

A resident may voluntarily mark:

That does not mean the City needs their movement before or after.

55.380Photo Metadata

Uploaded photos may contain:

Understand whether the system strips or retains it.

55.381Minimum Needed Location

Use:

rather than:

where sufficient.

55.382Parking Apps

If used:

Review:

55.383Payment Information

The City should not store complete payment-card information unnecessarily.

Use secure payment processors.

55.384Payment Token

Where modern systems allow:

Use safer mechanisms.

55.385Financial Analytics

A municipal payment system does not need to infer:

55.386Utility Data

Water or utility usage can reveal:

Treat appropriately.

55.387No Behavioural Inference

Do not use utility data to infer:

without legitimate operational purpose.

55.388Leak Detection

Operational use can be beneficial.

Keep purpose narrow.

55.389Smart Infrastructure

Sensors can improve:

55.390Sensor Inventory

High-risk sensors should be inventoried.

55.391Sensor Purpose

Define.

55.392Aggregate First

Prefer:

over identifiable vehicle tracking where possible.

55.393Smart City

Do not adopt technology because:

smart city

sounds modern.

55.394Public Benefit Test

Every sensor should answer:

What real municipal decision improves because this data exists?

55.395Delete Useless Data

If nobody uses a dataset:

Review whether collection should continue.

55.396Information Debt

Old:

create operational debt.

55.397Data Cleanup

Yearly cleanup can reduce:

55.398Duplicate Data

The same resident information may exist in:

Understand the pattern.

55.399Master Resident Database

Do not create one merely to eliminate duplication.

Centralization can create greater privacy risk.

55.400Federated Approach

Sometimes separate systems with:

are safer.

Evaluate architecture.

55.401Data Quality

Privacy also means not keeping:

about someone.

55.402Correction Request

Residents should have an appropriate route to correct personal information where applicable.

55.403Identity Check

Verify sufficiently before changing protected records.

55.404No Impossible Correction

Do not require residents to navigate an obscure legal process for a simple administrative typo where staff can lawfully correct it.

55.405Audit

For material records:

Preserve appropriate history of changes.

55.406Personal Data Accuracy

Do not reuse outdated address or contact information blindly.

55.407Data Source

Know which system is authoritative.

55.408Duplicate Source Conflict

If two systems disagree:

Resolve.

55.409One Source of Truth

Useful for specific data categories.

Not a justification for a universal resident dossier.

55.410Non-Digital Service

Privacy and inclusion intersect.

Residents should not be forced to create digital accounts for every essential service.

55.411Phone

Maintain.

55.412In Person

Maintain where service context requires.

55.413Paper

Maintain where reasonable.

55.414Assisted Digital

Staff can help a resident complete digital process without forcing them to become digitally independent first.

55.415No Penalty for Non-Digital Access

Do not impose an unnecessary higher fee solely because someone:

If cost differences justify a fee structure:

Council should explain it transparently and review accessibility implications.

55.416Digital Convenience

Offer it.

Do not make convenience become compulsion.

55.417Paper Privacy

Paper forms require:

55.418Phone Privacy

Staff should avoid discussing sensitive details where others can overhear.

55.419Public Counter

Design spaces for reasonable confidentiality.

55.420Translation

Translation services may require third-party access to information.

Use appropriate controls.

55.421AI Translation

Do not feed protected resident information into unapproved translation tools.

55.422Interpreter

Professional interpreters may need confidentiality agreements or professional standards.

55.423Accessibility and Privacy

Accommodation should not require residents to disclose more than necessary.

55.424Open Books and Privacy

Open Books applies to:

It does not mean publishing private residents' information.

55.425Grant Recipients

Public money may justify disclosure about:

Do not publish unnecessary participant data.

55.426Procurement

Vendor payments can be public.

Employee or customer records remain protected.

55.427Conflict Disclosure

Officials may need to disclose:

Do not use privacy as excuse to hide conflicts that law or policy requires to be public.

55.428Privacy Is Not Secrecy

Important distinction.

55.429Secrecy Is Not Privacy

Another important distinction.

55.430Privacy Protects People

Transparency exposes:

55.431Security

Privacy requires good cybersecurity.

55.432Cybersecurity Scorecard

Cross-reference Digital Sovereignty.

Use high-level measures.

55.433Patch Status

For critical systems:

Track high-risk unsupported systems.

55.434Unsupported Software

High concern.

55.435End-of-Life System

Needs remediation plan.

55.436Backups

Test.

55.437Restore Test

A backup that cannot be restored is:

55.438Ransomware

Prepare.

55.439Offline or Segmented Backup

Where appropriate.

55.440Incident Plan

Maintain.

55.441Tabletop Exercise

Test.

55.442Vendor Breach

Contracts should require timely notification.

55.443Supply Chain

A software vendor's breach can become:

55.444Cyber Insurance

If held:

Understand requirements and exclusions.

55.445Insurance Is Not Security

No.

55.446Phishing

Train staff.

55.447Training Click Rate

Use cautiously.

Do not publicly shame employees.

55.448Simulated Phishing

Can help.

Do not turn it into punitive surveillance.

55.449Report Button

Make suspicious-message reporting easy.

55.450Cyber Culture

Early reporting matters more than embarrassment.

55.451Public Cyber Claims

Do not say:

unhackable.

No system is.

55.452Resilience

The realistic goal is:

55.453Privacy Scorecard Table

A headline table could use:

MeasureBaselineCurrentTarget / StandardTrendStatusOwner

Possible rows:

55.454Data Inventory Table

SystemPersonal DataVendorRetention DefinedExport TestedLast Review

Public version may summarize sensitive systems.

55.455Privacy Incident Table

MeasureCurrent YearPrevious YearTrend

Possible:

Do not publish exploitable details.

55.456Vendor Table

MeasureCurrent

Possible:

55.457Public Information Table

MeasureCurrentTrend

Possible:

55.458Public Wi-Fi Table

MeasureCurrent

Possible:

55.459Device Reuse Table

MeasureCurrent

Possible:

55.460AI Table

SystemPurposeRisk LevelProtected Data?Human ReviewLast Review

Public version can omit sensitive security detail.

55.461Data Sharing Table

Partner TypePurposeAgreement ReviewedData MinimizedNext Review

55.462Traffic Lights

Green

Current controls meet the adopted standard.

Amber

Material remediation or review required.

Red

Significant unresolved privacy or information risk.

Grey

Not yet assessed or insufficient evidence.

55.463Green Is Not "No Risk"

It means:

55.464Red Is Not Automatic Public Disclosure of Technical Details

Report the risk responsibly.

55.465Grey Is Better Than False Assurance

If a legacy system has never been properly reviewed:

Use:

Grey: assessment required.

55.466Anti-Gaming Rule One

Do not count systems inventoried as systems secured.

55.467Anti-Gaming Rule Two

Do not count privacy policies written as privacy risks resolved.

55.468Anti-Gaming Rule Three

Do not count training completed as privacy incidents prevented.

55.469Anti-Gaming Rule Four

Do not lower reported breach numbers by discouraging internal reporting.

55.470Anti-Gaming Rule Five

Do not classify a material privacy breach as:

to protect statistics.

55.471Anti-Gaming Rule Six

Do not classify a service outage as personal-data breach if no evidence supports it.

Accuracy works both ways.

55.472Anti-Gaming Rule Seven

Do not count vendor policy language as proof of vendor deletion.

55.473Anti-Gaming Rule Eight

Do not count a successful one-time export as permanent vendor independence if the format is unusable.

55.474Anti-Gaming Rule Nine

Do not call public Wi-Fi anonymous if persistent device tracking remains enabled.

55.475Anti-Gaming Rule Ten

Do not call a device securely reused without documented data wiping.

55.476Anti-Gaming Rule Eleven

Do not call website tracking minimal while third-party advertising scripts remain embedded.

55.477Anti-Gaming Rule Twelve

Do not count cookie consent as proof that unnecessary tracking is acceptable.

55.478Anti-Gaming Rule Thirteen

Do not call AI anonymous if prompts contain identifiable resident information.

55.479Anti-Gaming Rule Fourteen

Do not call a dataset anonymous merely because names were removed.

55.480Anti-Gaming Rule Fifteen

Do not publish granular information that allows easy re-identification.

55.481Anti-Gaming Rule Sixteen

Do not call deleted data gone if the vendor contract permits indefinite retention.

55.482Anti-Gaming Rule Seventeen

Do not count archived stale pages as current information.

55.483Anti-Gaming Rule Eighteen

Do not silently correct material errors without recording them.

55.484Anti-Gaming Rule Nineteen

Do not use privacy as an excuse to hide:

that should lawfully be public.

55.485Anti-Gaming Rule Twenty

Do not use transparency as an excuse to expose residents unnecessarily.

55.486Anti-Gaming Rule Twenty-One

Do not count public social-media followers as informed residents.

55.487Anti-Gaming Rule Twenty-Two

Do not count email subscribers as unique residents without evidence.

55.488Anti-Gaming Rule Twenty-Three

Do not count AI answers generated as questions resolved.

55.489Anti-Gaming Rule Twenty-Four

Do not count surveillance equipment installed as privacy management completed.

55.490Anti-Gaming Rule Twenty-Five

Do not change incident-severity definitions before an election to reduce reported privacy failures.

55.491Election-Year Integrity

Privacy failures remain reportable during:

55.492No Data Access Expansion for Campaign

Do not give elected officials broader resident-data access because:

55.493No Campaign Export

Municipal:

do not migrate to campaigns.

55.494Campaign Data Goes the Other Direction Too

Campaign-collected resident information should not be imported into municipal systems after election.

Separate organizations.

Same.

55.497Official Account Transition

After an election:

Transfer official municipal accounts institutionally.

55.498Campaign Account

Remains separate.

55.499No Data Purge Before Transition

Do not delete municipal records because:

Follow records rules.

55.500No Data Hoarding After Leaving Office

Former officials do not retain personal copies of municipal resident databases.

55.501Baseline

Year One should establish:

55.502Unknown Baseline

Where information has not previously been organized:

Say:

Not previously measured consistently.

55.503Do Not Pretend Legacy Systems Are Known

Unknown:

should be documented as unknown until verified.

55.504Year One Objective

Know:

55.505Year Two Objective

Reduce unnecessary:

55.506Year Three Objective

Migrate or remediate the highest-risk:

systems.

55.507Year Four Objective

Leave the next Council:

municipal information systems.

55.508Four-Year Core Measures

Strong candidates:

55.509Do Not Set "Zero Privacy Incidents" as Only Goal

A zero count can encourage:

Better goal:

reduce preventable incidents, detect quickly, report honestly and correct root causes.

55.510Serious Incident Goal

Aim for:

But report reality honestly.

55.511Incident Trend

Use multi-year context.

55.512New Reporting System

If incidents rise after reporting improves:

Explain that possibility.

55.513Four-Year Privacy and Information Audit

At term end publish:

Systems inventoried

Personal-data systems

High-risk systems

Vendor access

Retention improvements

Data deleted or reduced

Access reviews

Privacy incidents

Repeat causes

Data-sharing reviews

Public Wi-Fi privacy

Device reuse

AI governance

Surveillance governance

Public-information corrections

Stale information retired

Non-digital access

Export and vendor exit

Major unresolved risks

55.514Name the Biggest Privacy Improvement

Use evidence.

55.515Name the Biggest Privacy Failure

Use evidence.

55.516Name the Highest-Risk Legacy System

At a safe level.

55.517Name the Biggest Unnecessary Dataset Removed

If appropriate.

55.518Name the Most Important Retention Reform

55.519Name the Most Important Vendor Exit Improvement

55.520Name a Vendor Relationship That Remains Too Dependent

If one does.

55.521Name the Most Important Public-Wi-Fi Privacy Improvement

55.522Name the Device-Reuse Result

55.523Name the Most Important AI Governance Decision

55.524Name an AI Use That Was Stopped

If evidence showed:

55.525Name the Most Important Information Correction

Government should be willing to show it.

55.526Name the Most Persistent Stale-Information Problem

55.527Name the Largest Privacy Liability Handed to the Next Council

55.528Collection Test

Ask:

Are we collecting only what the service actually requires?

55.529Purpose Test

Ask:

Can we explain why each significant personal dataset exists?

55.530Retention Test

Ask:

Are we deleting information when its lawful purpose ends?

55.531Access Test

Ask:

Can only appropriate people access the information?

55.532Vendor Test

Ask:

Do we know which vendors can access resident data and what they do with it?

55.533Exit Test

Ask:

Can the City leave the vendor and take its records with it?

55.534Sharing Test

Ask:

Are we sharing only what the partner actually needs?

55.535Wi-Fi Test

Ask:

Can a resident use public Wi-Fi without becoming a movement or marketing profile?

55.536Device Test

Ask:

Can donated devices be reused without exposing either the donor's or recipient's private information?

55.537AI Test

Ask:

Are staff using AI without quietly sending protected resident data into systems we do not control?

55.538Surveillance Test

Ask:

Can the City justify every significant surveillance system it operates?

55.539Open Data Test

Ask:

Does public data expose government performance without unnecessarily exposing residents?

55.540Information Accuracy Test

Ask:

Can a resident tell when important City information was last verified?

55.541Correction Test

Ask:

When government is wrong, can residents see that it corrected itself?

55.542Non-Digital Test

Ask:

Can residents still obtain essential municipal service without creating an unnecessary digital profile?

55.543Campaign Test

Ask:

Could any candidate use municipal data to gain a political advantage?

The answer should be:

No.

55.544Rights Test

Ask:

Does the information system respect privacy, expression, conscience, due process and equal treatment?

55.545Resilience Test

Ask:

If the vendor, Internet connection or cloud service disappeared tomorrow, could the City continue essential service and recover its information?

55.546Independence Test

Ask:

Does the City control its data, domains, credentials and institutional accounts?

55.547Institution Test

Ask:

Would the information system operate safely if a completely different Mayor took office tomorrow?

It must.

55.548What Success Looks Like

Privacy and information success does not mean:

Success means:

55.549What Failure Looks Like

Failure includes:

55.550The Privacy and Information Scorecard Commitment

Owen Sound should commit to:

Know what information the City collects, where it is stored and why it exists.

Treat municipal information as both a public asset and a potential liability.

Maintain an inventory of significant information systems.

Include informal high-risk spreadsheets and shadow databases where appropriate.

Give every significant personal-information collection a specific purpose.

Do not collect information merely because it might be useful one day.

Limit information reuse to legitimate and lawful purposes.

Never convert municipal service data into campaign data.

Never give incumbents privileged resident-data access for political targeting.

Collect the least information reasonably necessary for the service.

Review major forms field by field.

Clearly distinguish required and optional information.

Do not collect exact birthdates, home addresses, telephone numbers, identification or banking information when less information will serve the purpose.

Use stronger safeguards for health, financial and information involving minors.

Collect accommodation needs rather than unnecessary diagnoses wherever possible.

Do not collect political or religious opinion through ordinary municipal service.

Do not turn civic participation into ideology profiling.

Apply the principle: Verify person. Protect opinion.

Maintain lawful and operational retention rules.

Do not keep information forever merely because digital storage is inexpensive.

Separate long-term archival records from active production databases where appropriate.

Delete or securely dispose of records when their lawful purpose ends.

Require vendors to address data return and deletion.

Understand how backups affect deletion.

Securely destroy obsolete physical and digital media.

Treat paper privacy as seriously as digital privacy.

Apply least-privilege access to personal information.

Review access when employees change roles.

Remove access promptly when staff, contractors or students leave.

Limit vendor support access.

Avoid shared privileged passwords.

Maintain appropriate access logs for sensitive systems.

Use access logs for security and accountability rather than unnecessary employee surveillance.

Use authentication proportionate to the service.

Do not require high-level identity verification for low-risk public information.

Allow anonymous browsing of ordinary public information.

Do not impose a universal municipal digital identity on ordinary civic life.

Do not create a single resident profile connecting unrelated municipal activities merely for convenience.

Never create resident, behavioural, civic-engagement or good-citizen scores.

Maintain an inventory of major data-sharing arrangements.

Share the minimum necessary information with other governments and partners.

Understand partner retention, reuse and subcontractor access.

Review where major City data is hosted and processed.

Treat Canadian hosting as one resilience and jurisdiction factor, not proof of security by itself.

Ask of every important system: who controls the data, who can access it, and can we leave?

Require important vendors to address ownership, access, security, breach, export, deletion, subcontractors and termination.

Keep City records under practical City control.

Test data export before a contract ends.

Do not accept screenshots or unusable proprietary files as meaningful portability.

Include migration and conversion costs in complete vendor cost.

Review vendor exit capability before contract renewal.

Perform appropriate privacy-impact review before high-risk systems are deployed.

Treat surveillance, biometrics, high-impact AI, location tracking and cross-department profiling as high-risk triggers.

Use Privacy by Design and ask whether the same outcome can be achieved with less data.

Use minimum collection and minimum sharing as default settings where possible.

Do not misuse vague consent when the City is actually exercising statutory authority.

Make optional consent understandable and separate from unrelated essential service.

Provide accurate privacy notices.

Do not make promises about absolute confidentiality that the law does not support.

Track material privacy incidents.

Distinguish privacy incidents from cybersecurity outages.

Contain, investigate, correct and report incidents according to applicable obligations.

Do not hide privacy failures for political reasons.

Do not release unverified breach information that creates additional harm.

Track repeat incident causes and correct systems, not merely individual mistakes.

Encourage staff to report privacy mistakes quickly.

Do not punish good-faith early reporting.

Design communication systems to reduce predictable human error.

Use proper bulk-mail and secure-document practices.

Review document metadata when it creates disclosure risk.

Use public Wi-Fi as an access service rather than a resident-tracking system.

Do not create persistent device or movement profiles through public Wi-Fi.

Disable unnecessary location and marketing analytics.

Do not require marketing consent to access taxpayer-supported Wi-Fi.

Do not collect an email address for Wi-Fi unless there is a real need.

Publish understandable Wi-Fi security information.

Measure public Wi-Fi uptime, coverage and complete cost.

Do not equate devices or sessions with unique residents.

Do not use Wi-Fi analytics as a substitute for foot-traffic measurement.

Treat public Wi-Fi and universal broadband as separate policy questions.

Require evidence of a real access, affordability or resilience problem before considering municipal broadband infrastructure.

Do not create household poverty maps to justify connectivity programs.

Collect minimal information from residents receiving connectivity support.

Avoid duplicating income verification where another lawful program already establishes eligibility.

Do not create a permanent poverty database.

Securely wipe every reused phone or device before redistribution.

Never transfer donor data to recipients or recipient data to donors.

Do not redistribute devices that cannot be reliably wiped.

Remove SIM cards, memory cards, account locks and old personal data appropriately.

Do not place hidden City tracking software on reused devices.

Make any remote-support capability transparent.

Verify emergency-calling claims before promoting reused phones as safety tools.

Track device receipt, wiping, redistribution and secure recycling.

Protect the identity of device recipients.

Review the municipal website for unnecessary analytics and third-party trackers.

Prefer aggregate page-use information over individual behavioural tracking.

Avoid advertising trackers on municipal websites unless an exceptional public case exists.

Review third-party videos, maps and social embeds for data leakage.

Do not treat a cookie banner as a substitute for minimizing tracking.

Avoid consent interfaces designed to manipulate residents into accepting unnecessary tracking.

Treat municipal website search terms and abandoned forms as potentially sensitive data.

Avoid invasive session-replay technology without compelling justification.

Do not install campaign-style social-media tracking pixels on City websites.

Keep newsletter lists out of campaigns.

Use community-calendar data only for the calendar's legitimate purpose.

Do not collect attendee identities merely because an event is publicly listed.

Apply the full privacy, procurement, conflict and portability standard to map.ca or any other proposed civic platform.

Give Mayor-associated technology more independent scrutiny, not less.

Define public standards before choosing the platform.

Do not force residents to create accounts to browse ordinary public information.

Treat any permanent public-email concept as high-risk infrastructure requiring independent governance, cybersecurity, privacy, portability and funding review.

Do not build municipal identity around one email provider.

Do not create a Data Locker merely because centralization sounds convenient.

Require a compelling resident need, strong governance, security, portability and public benefit before any Data Locker proceeds.

Recognize that centralizing resident records can increase catastrophic risk.

Allow the responsible decision to be not to build it.

Use Safe Information to improve access, accuracy, privacy, resilience and independence.

Give important public-information pages a responsible owner.

Date high-impact information.

Show when external programs were last verified.

Remove or archive expired grants, loans and benefits promptly.

Distinguish City summaries from authoritative outside sources.

Use plain language without changing the actual legal meaning.

Maintain a public Correction Log for material City information errors.

Correct important errors where residents actually encountered them, including social media where appropriate.

Do not silently rewrite material errors residents may have relied upon.

Normalize public correction rather than hiding mistakes.

Review repeated information errors for root causes.

Assign or retire orphaned public web pages.

Clearly label archived information as not current.

Distinguish publication date from underlying data date.

Use official channels as the authoritative municipal source.

Correct false information about City services and material emergency matters without trying to become an arbiter of every political disagreement.

Never label ordinary criticism or policy disagreement misinformation merely because City Hall dislikes it.

Maintain a simple official verification location for major alerts and notices.

Protect official domains, accounts and credentials as institutional assets.

Do not let official digital accounts depend on one employee's personal credentials.

Keep official mayoral channels separate from campaign channels.

Treat public business conducted through social media, text or messaging tools according to applicable records and privacy obligations.

Do not hide public business in personal accounts.

Remember that open government should expose government, not unnecessarily expose residents.

Publish public records proactively where appropriate while protecting private information.

Do not use privacy as an excuse to conceal public contracts, spending or lawful conflict disclosures.

Do not use transparency as an excuse to publish resident complaints, health information or other protected details.

Review Open Data for re-identification risk.

Recognize that names are not the only identifiers.

Suppress or aggregate small cells where needed.

Never publish household-level maps of vulnerable residents.

Consider the mosaic effect when several datasets can be combined.

Keep property information separate from household behavioural profiles.

Apply strong privacy standards to RealMap and any property-information platform.

Never add residents' complaints, politics or unrelated service use to public property profiles.

Keep YouthMap focused on opportunities rather than young people.

Do not create public maps of vulnerable seniors.

Protect sensitive infrastructure and archaeological information where appropriate.

Respect Indigenous knowledge and agreed information governance rather than assuming all information received by the City becomes Open Data.

Use practical information classifications without turning "confidential" into a shield against public accountability.

Maintain an inventory of material AI use.

Review AI systems according to what they actually do rather than vendor marketing labels.

Apply stronger governance to AI affecting eligibility, enforcement, employment, benefits or safety.

Tell staff what information may and may not be entered into AI systems.

Do not place protected resident information into unapproved public AI services.

Understand whether AI vendors retain or train on municipal prompts and outputs.

Do not assume vendor privacy protections, verify them.

Require human accountability for significant municipal decisions.

Never tell a resident that "the algorithm decided."

Correct material AI-generated public misinformation openly.

Determine appropriate records treatment for municipal AI use.

Include privacy, security, accessibility, retention, deletion, export and model-use terms in relevant AI procurement.

Pilot AI before broad high-impact deployment.

Stop AI systems whose cost, error, privacy or bias risk outweighs their benefit.

Do not confuse adding AI with modernizing a bad process.

Do not use AI to create employee emotion, productivity or behavioural scores by default.

Never use municipal AI for resident political-sentiment profiling.

Maintain surveillance purpose, retention and access rules.

Do not introduce facial recognition by default.

Require separate high-threshold review for biometrics and other highly intrusive identification technology.

Do not allow surveillance capabilities to appear quietly through vendor software updates.

Review automated licence-plate, drone, body-camera and audio systems according to actual municipal authority and risk.

Do not use drones for casual residential surveillance.

Do not use voice or emotion analytics merely because the software can.

Treat biometric convenience claims as insufficient justification for biometric collection.

Collect precise location only when the service actually needs it.

Do not request continuous device location for a one-time service report.

Review location metadata contained in uploaded photos.

Use incident location rather than resident live location where that is sufficient.

Review parking, utility and smart-infrastructure data for unnecessary behavioural inference.

Do not use utility consumption to build lifestyle profiles.

Use infrastructure sensors only when the data supports a real municipal decision.

Do not install technology merely to appear like a smart city.

Delete datasets that no longer have sufficient value or legal purpose.

Treat duplicate spreadsheets and obsolete databases as information debt.

Do not solve duplication automatically by building one giant resident database.

Consider federated systems where they better protect privacy and resilience.

Give residents an appropriate route to correct inaccurate personal information.

Make simple administrative corrections simple where lawful.

Know which system is authoritative for important data.

Resolve conflicting duplicate records.

Do not mistake a specific authoritative dataset for a justification to create a universal resident dossier.

Maintain phone, paper and in-person alternatives where appropriate for essential municipal services.

Offer digital convenience without making it compulsory.

Do not penalize non-digital residents without a clear lawful and public rationale.

Protect paper, telephone and public-counter privacy too.

Review privacy when translation or interpretation services require third-party access.

Do not send protected information into unapproved AI translation tools.

Keep Open Books focused on government money rather than residents' personal information.

Treat public grant and procurement information transparently while protecting participant and employee privacy.

Do not confuse privacy with secrecy or secrecy with privacy.

Use cybersecurity as a foundation for privacy.

Identify unsupported and end-of-life systems.

Maintain and test backups.

Test restoration rather than merely confirming that backup files exist.

Maintain ransomware and cyber-incident plans.

Require relevant vendors to report breaches promptly.

Recognize that vendor security failures can become City failures.

Do not treat cyber insurance as a replacement for cybersecurity.

Train staff against phishing without turning training into public employee shaming.

Make suspicious-message reporting easy.

Never describe a municipal system as unhackable.

Aim to prevent, detect, contain and recover.

Publish Privacy, Vendor, Incident, Wi-Fi, Device Reuse, AI, Data Sharing and Public Information Scorecard tables.

Use Green, Amber, Red and Grey with clear published definitions.

Never call a system secure merely because it is inventoried.

Never count policies written as risks resolved.

Never count training as incidents prevented.

Never discourage incident reporting to improve the score.

Never misclassify privacy or cybersecurity events to make the statistics look better.

Never accept vendor contractual language as proof that data was actually deleted.

Never call public Wi-Fi privacy-preserving while persistent tracking remains enabled.

Never redistribute devices without documented secure wiping.

Never call a dataset anonymous merely because names were removed.

Never use privacy to hide public accountability.

Never use transparency to expose private residents.

Never count AI responses generated as municipal problems solved.

Never change privacy incident definitions before an election.

Keep privacy reporting active through the election year.

Never export municipal resident data into campaign systems.

Never import campaign resident profiles into municipal systems.

Treat campaign and municipal consent as completely separate.

Transfer official accounts and credentials institutionally after elections.

Do not destroy public records before a political transition.

Do not allow departing officials to retain copies of municipal resident datasets.

Use Year One to understand what information exists and who can access it.

Use Year Two to reduce unnecessary collection, access, tracking and vendor exposure.

Use Year Three to remediate high-risk legacy and locked-in systems.

Use Year Four to leave the next Council a documented, portable and governed information environment.

Publish the full Four-Year Privacy and Information Audit.

Name the biggest privacy improvement.

Name the biggest privacy failure.

Name the highest-risk legacy system.

Name unnecessary datasets that were removed.

Name the most important retention reform.

Name the strongest vendor-exit improvement and any remaining dependency.

Name the Public Wi-Fi privacy result.

Name the Device Reuse privacy result.

Name the most important AI governance decision and any AI system that was stopped.

Name the most important public-information correction.

Name the most persistent stale-information problem.

Name the largest privacy liability being handed to the next Council.

Judge the final record by whether Owen Sound became better informed without becoming more intrusive.

A strong Privacy and Information Scorecard should allow a resident to ask:

Why does the City need this information?

Do I really need to provide it?

Who can see it?

How long will it exist?

Does a private vendor have access?

Can that vendor use it for anything else?

Can the City take its data back?

Can I use the service without being tracked?

Can I use public Wi-Fi without creating a movement profile?

Was this donated phone actually wiped?

Is an AI system reading my information?

Is a camera identifying me?

Can I get the service without a smartphone?

Is this public information still current?

When was it verified?

What happens when City Hall publishes something wrong?

And the City should be able to answer those questions without:

Privacy does not require weak government.

It requires disciplined government.

Open government does not require exposing residents.

It requires exposing:

Information technology should not make residents surrender more of themselves simply because computers make collection easy.

Collect less. Explain why. Protect what remains. Delete what is no longer needed. Control vendor access. Keep public information current. Correct mistakes openly. Preserve non-digital choice. Use technology to serve residents, not to profile them.

← Chapter 54: Accessibility: The Public Accessibility ScorecardChapter 56: Environment: The Public Environmental Stewardship Scorecard →