Municipal track · Resident engagement

Resident surveys for Canadian municipalities

Built on your municipality's own web address, on Canadian servers, security-assessed and privacy-reviewed in writing before they open, and delivered back to Council as a written report, not a spreadsheet.

Book a 20-minute call See the County of Minburn engagement

layers assessed in writing before the survey opens: system, encryption and web, application, logging

privacy and security requirements worked through in the written compliance package

resident surveys delivered for the County of Minburn in 2026

trackers, advertising pixels or external scripts on the survey page

The problem

The survey is the easy part. The questions afterward are not.

Survey tools are good at collecting answers. What they do not do is take responsibility for the four things a municipality is actually on the hook for.

You do not control where the data lives

A hosted survey stores resident responses on that company's servers, under that company's terms, frequently outside Canada. If the vendor changes its policy, is acquired, or has a breach, the municipality may learn of it only when the vendor chooses to tell it, and still owns the consequences.

Nobody has checked, and nobody wrote it down

“It's a reputable company” is not an assessment. If a councillor, an auditor or a resident asks what security review was performed before residents were invited to submit personal information, there needs to be a document. Usually there is not one.

Privacy obligations are assumed, not met

Alberta's Protection of Privacy Act expects a notice that tells residents the purpose, the legal authority and who can answer their questions, along with reasonable security, limits on use, and a way to ask for a correction. A default survey template usually lacks these unless someone adds them. The obligations still apply.

The analysis lands on someone's desk

The export is the beginning of the work, not the end. Several hundred open-text comments have to be read, grouped and written up. In a lean administration that job gets absorbed by whoever has the least ability to say no, usually months later.

Security

The server is audited before it is ever pointed at residents.

Before a municipal survey opens, the environment it runs on is reviewed against a written checklist across four layers. Every finding is recorded, the fixes in our control are applied, and anything left outstanding is named and assigned, so the municipality has a document, not an assurance.

What gets assessed

System posture: who can get in at all

Firewall rules, how administrators sign in, what software is running that does not need to be, whether security updates install themselves, and whether repeated failed logins get blocked automatically.

Encryption and web layer: what happens in transit

Whether outdated encryption is still accepted, whether the certificate renews itself before it expires, whether the browser is told to refuse injected content, and whether the server answers to anything other than the municipality's own web address.

Application layer: where the answers are written

Where responses are stored, which accounts can read them, whether they can be requested directly through a browser, whether leftover backup files are sitting in a public folder, and how administrator credentials are held.

Logging and monitoring: what you can prove afterward

Whether access and errors are logged, how long those logs are kept, and whether unusual activity produces a signal rather than silence.

How it launches

Password logins switched off. Administrators sign in with a cryptographic key instead.
Direct root sign-in disabled. Administrators use named accounts.
Full browser security header set, including a content policy that helps block injected scripts.
Raw address access blocked. The server answers on the municipality's web address only.
Automatic lockout on repeated failed sign-in attempts.
Response file sealed from the public web; a direct request for it is refused.
Credential store placed out of reach of any browser path.
Unused software shut down and removed from the attack surface.
Certificate auto-renewal in place, so the padlock does not lapse part-way through a survey.

Privacy

Alberta's privacy law, worked through one requirement at a time.

Collecting personal information from Alberta residents carries specific duties under the Protection of Privacy Act (POPA). We work through each of them before the survey is built, add the safeguards we consider good practice, and hand the municipality a written compliance package covering all ten items below.

Requirement	What it means in practice	What we build
Notice and acknowledgement	Residents must be told the purpose of the collection, the legal authority for it, and who can answer their questions.POPA s. 5(2)	A plain-language notice above the submit button, with a tick-box acknowledgement. If it is not ticked, the survey does not send.
Stated purpose	Information may be used only for the purpose it was collected for, or a use consistent with that purpose.POPA s. 12	One purpose, written into the notice. No secondary use, no sharing, no repurposing later.
Data minimisation	Collect only what the program needs, and use only what is necessary.POPA ss. 4 and 12(4)	Every field has to justify itself at design time, and sensitive questions carry a “prefer not to say” option.
Safeguards	Reasonable security arrangements against unauthorized access, use, disclosure or destruction.POPA s. 10(1)	The security assessment and hardening pass described above, documented in writing.
Retention	A defined retention period. If responses are used to make a decision about a person, they must be kept for at least one year.POPA s. 6	A defined retention period, disclosed to the resident before they answer.
Access controls	Only authorized municipal staff should be able to read responses.Good practice, part of safeguards	A password-protected staff portal; the response file is unreadable from the public web.
Contact for questions	The notice must give contact information for someone who can answer residents' questions about the collection.POPA s. 5(2)	A real Privacy Officer, named in the notice with a working contact link.
Access and correction	Residents can request their information under the Access to Information Act and ask for a correction under POPA.ATIA; POPA s. 7	A named contact on the survey, and the internal process for answering agreed with you before it opens.
Data residency	POPA has no data-residency rule, but where the information physically lives still matters to residents and Council.Good practice	Canadian infrastructure. No third-party analytics, advertising pixels or external scripts.
Breach readiness	If a breach creates a real risk of significant harm, the municipality must notify affected individuals, the Commissioner and the Minister without unreasonable delay.POPA s. 10(2)	Flagged in writing as a municipal responsibility, with what it has to cover set out, never left silently unowned.

Outside Alberta, the review is adapted to the province's own privacy law.

A written retention policy and a breach-notification procedure are administrative documents, not software. No vendor can adopt them on your behalf. We tell you so in writing and set out what each has to cover, because the failure we see most often is not a municipality deciding to skip them. It is a municipality never being told it needed them.

Case study

County of Minburn No. 27: two resident surveys in one year.

A rural Alberta county needed to hear from residents twice: once on community policing priorities, and once on the County's 2026–2030 Strategic Plan. Both ran on the County's own web address. The hosting was assessed and privacy-reviewed in writing before the first survey opened, and the same hardened configuration carried the second.

The County of Minburn 2026-2030 Strategic Planning Survey as delivered, showing the County's own branding, a progress bar, and a question matrix with sample answers filled in.

The Strategic Planning Residents Survey as delivered · sample answers filled in

Three pages from the County of Minburn What We Heard report, blurred so that no result figures are legible.

Pages from the What We Heard report · blurred; results are the County's to publish

What was delivered

The Community Policing Priorities Survey: resident input on RCMP service and local policing priorities.
The Strategic Planning Residents Survey: a 27-question public survey shaping the County's 2026–2030 Strategic Plan.
A written security assessment across all four layers, including the items that were not ready, completed before the first survey accepted a response.
A consent gate and a named Privacy Officer: a plain-language notice above the submit button that blocked submission until accepted, disclosing purpose, anonymity, retention and secure destruction.
A staff administration portal with a live response count, individual submissions and a one-click spreadsheet export.
A What We Heard report for the strategic planning survey: an executive summary, a stated methodology and ten result sections, with a companion verbatim appendix of the open responses.

The full County of Minburn engagement

Working together

What you get, and what it costs you in staff time.

Deliverables

The survey instrument: questions drafted with your staff, approved by you.
Hosting on your own subdomain, on Canadian infrastructure.
A staff administration portal: live response count, individual submissions, one-click export.
A data dictionary so the export and the report agree.
The full response export, yours to keep.
Thematic analysis of the open-text comments, read and grouped rather than keyword-counted.
A What We Heard report and a verbatim appendix of the open responses.
A written security and privacy assessment in plain language.

What we need from you

One scoping conversation: what you need to know, and who the answers are for.
A review pass on the draft questions, and Council's sign-off.
One DNS record added by whoever manages your domain.
A named Privacy Officer, usually someone you already have.
Promotion through your existing channels.

What you do not need

An IT department, or a procurement process for a software licence.
Anyone on staff to learn a new platform.
Someone to spend evenings coding open-text comments.
To renew anything after the consultation closes.

How an engagement runs

From a blank page to a document Council can act on.

Scope

One meeting to agree what the municipality needs to know and who the answers are for.

Draft

Questions written and revised with staff, then taken to Council for sign-off. We handle the wording.

Build and assess

The survey is built, the hosting is security-assessed and hardened, the privacy requirements are worked through, and the whole thing is tested. You approve the live link before residents see it.

Collect

You promote it through your existing channels. We monitor it for the whole collection window, and you can see the response count whenever you like.

Report

Closed questions tabulated, open-text comments read and grouped into themes, and the result delivered to Council as a written report with a verbatim appendix.

Questions we get

Resident surveys, answered.

Who builds resident surveys for Canadian municipalities?

Spencer Morley Consulting builds public resident surveys for municipalities across Canada. The survey is purpose-built rather than rented from a survey platform: it runs on the municipality's own web address, on Canadian infrastructure, and the engagement includes the security assessment, the privacy review, the analysis and the written report. Outside Alberta, the privacy review follows the province's own legislation.

Where is resident survey data stored, and does it stay in Canada?

Responses are stored on Canadian infrastructure and stay in Canada. The survey page carries no third-party analytics, advertising pixels or external scripts, so nothing about a resident's visit is reported to a third party.

Does a municipal resident survey need a privacy notice under Alberta's privacy law?

Yes. When a municipality collects personal information from residents, Alberta's Protection of Privacy Act requires it to tell them the purpose, the legal authority for the collection, and who can answer their questions (s. 5(2)). The Act also requires reasonable security and limits how the information can be used. A default survey template usually lacks this unless someone adds it. We work through the requirements before the survey is built.

What is a What We Heard report?

A What We Heard report is the written record of a public consultation, prepared for Council and for the public. It states the methodology, tabulates the closed questions, groups the open-text comments into themes, and carries a verbatim appendix of the open responses so residents can see their input was not filtered out.

Do we need an IT department to run a resident survey on our own domain?

No. Whoever manages the municipality's domain adds one DNS record, which is the same kind of change made for any new subdomain. Everything after that is handled by Spencer Morley Consulting, and there is no software licence to procure and nothing to renew after the consultation closes.

Who owns the survey responses at the end?

The municipality does. The full response export is provided as a plain spreadsheet with a data dictionary so the coded values stay readable, alongside the analysis, the What We Heard report, the verbatim appendix and the written security and privacy assessment.

Next step

Worth a 20-minute call?

No pitch deck. We will walk through what you are trying to find out, whether a survey is even the right instrument for it, and what it would take to run one properly before your next planning cycle.

Or email [email protected] directly. We reply within one business day.