Permit data is operational data. Planning departments generate it constantly: every application, every review, every approval, every inspection leaves a record. That data is also, in many cases, personal information. Applicant names, property addresses tied to individuals, contact details, inspection notes referencing specific people’s projects. British Columbia’s Freedom of Information and Protection of Privacy Act (FIPPA) governs how this information is collected, stored, used, and disclosed.
For planning departments adopting analytics tools, FIPPA is not a background concern. It shapes which data can flow into an analytics platform, where that data can be stored, who can access it, and what the municipality must be able to demonstrate in an audit. Understanding these requirements before selecting a tool is far easier than discovering compliance gaps after.
What FIPPA actually covers
FIPPA applies to public bodies in BC, which includes municipalities, regional districts, school boards, and other public sector entities. It governs personal information: information about an identifiable individual. In permit records, personal information appears in several places.
Applicant names and contact details are the most obvious. A permit application includes the applicant’s legal name, often their mailing address, phone number, and email. These are personal information under FIPPA.
Property owner information may also appear. In some permit types, particularly residential permits, the property owner and applicant may be the same person, making property address a personal information data point.
Contractor and professional information can include individual names and license numbers for sole proprietors and unincorporated trades, which may also constitute personal information.
Inspection notes sometimes reference individuals directly: “Spoke with the owner about the deck framing.” If that note identifies a person by name or in combination with their address, it becomes personal information.
Not all permit data is personal information. Permit type, project value, geographic coordinates (without linking to an identified individual), approval dates, and permit status are typically not personal information on their own. But the combination of fields matters. An analytics platform ingesting permit data needs to handle the personal fields appropriately even if the analytics themselves operate on aggregate or anonymized dimensions.
The data residency requirement
One of FIPPA’s most practically significant requirements for BC municipalities is data residency. Section 30.1 of FIPPA requires that personal information in the custody or control of a public body must be stored and accessed only in Canada, unless the individual consents or disclosure is required by law.
This provision was strengthened specifically in response to concerns about US cloud hosting and the USA PATRIOT Act. The intent is to ensure that personal information held by BC public bodies cannot be accessed or compelled by foreign governments without Canadian legal process.
For permit analytics, this means: if the analytics platform sends permit data to servers outside Canada, including US-based cloud infrastructure, the municipality may be in violation of FIPPA. This is not a theoretical risk. The Office of the Information and Privacy Commissioner for BC has investigated and reported on data residency violations, and procurement officers increasingly ask vendors for written confirmation of Canadian data residency.
Practically, this means evaluating where an analytics vendor’s servers are located, whether data in transit passes through foreign servers (even temporarily), what third-party services the vendor uses and where those are hosted, and whether the vendor can provide documentation of Canadian residency that would satisfy an audit.
What personal information needs to be handled carefully in analytics
Even with Canadian data residency satisfied, the use of personal information in analytics must align with FIPPA’s purpose limitation principle. Personal information should only be used for the purpose it was collected, or for a directly related purpose.
Permit data is collected to process permit applications. Using it in aggregate to understand processing times, application volume trends, permit type distribution, and contractor compliance history is a directly related purpose: it supports the administration of the permit system. This use is generally defensible under FIPPA.
Using permit data to build profiles of individual applicants unrelated to permit administration, sharing identified data with third parties, or using applicant contact information for purposes not related to their permit are more problematic uses that require stronger legal justification.
For most analytics use cases in planning departments, the relevant distinction is between aggregate analytics (safe: processing time trends, volume by type, stage duration averages) and identified records (requires care: individual applicant history, contractor-specific records). A well-designed analytics setup keeps the aggregate layer as the primary interface and treats identified record access as a secondary function with appropriate access controls.
What a compliant analytics setup looks like
A FIPPA-compliant permit analytics environment for a BC planning department has several characteristics.
Data stays in Canada. All storage and processing happens on Canadian infrastructure. The vendor can provide written confirmation and, ideally, their Privacy Impact Assessment documentation.
Access is role-based and logged. Who can see permit analytics, and at what level of detail, is governed by role. A director seeing aggregate processing time trends does not need access to individual applicant records. Access to identified data is logged so the municipality can produce an audit trail if required.
Personal information is minimized in the analytics layer. The analytics platform operates primarily on anonymized or aggregate data. Individual permit records are accessible for administrative purposes, but the dashboards and reports that planners use day-to-day show aggregated metrics rather than individual applicant information.
The vendor has a Privacy Impact Assessment. Any technology system that handles personal information held by a BC public body should have a Privacy Impact Assessment (PIA) completed or in progress. The PIA documents what personal information is collected, how it is used, and what safeguards are in place. Planning departments should ask vendors for their PIA before procurement.
Data sharing is governed. If permit data flows to third-party services, including mapping tools, reporting platforms, or email systems, the municipality needs to understand what data is shared and whether those third parties are subject to equivalent FIPPA-compliant data handling obligations.
FIPPA in the context of Housing Accelerator Fund reporting
Municipal permit analytics often intersects with federal reporting obligations, including Housing Accelerator Fund compliance. HAF reporting to CMHC involves sharing aggregated permit data: unit counts, processing time improvements, housing type breakdowns.
The key distinction from a FIPPA perspective is that HAF reporting should use aggregate, anonymized data, not identified permit records. Sharing anonymized statistics (units permitted by type, median processing time by quarter) with CMHC is different from sharing individual applicant records. The former is standard compliance reporting; the latter would require legal authority under FIPPA.
A good analytics platform makes this distinction easy to maintain by supporting export of anonymized aggregate views specifically designed for compliance reporting, rather than raw data exports that include personal information by default.
What to look for in procurement
When a BC planning department evaluates permit analytics tools, FIPPA compliance is a procurement requirement, not an optional feature. Questions to ask vendors:
Where are the servers? Which cloud provider and region? Is all data processing, including backups and logs, in Canada?
Does the platform have a Privacy Impact Assessment, or can the vendor support the municipality in completing one?
How is access controlled? Can roles be configured to limit identified record access to authorized staff?
What data does the platform share with third-party services, and where are those services hosted?
Can the vendor provide a data processing agreement that confirms their obligations under FIPPA and Canadian privacy law?
Answers to these questions should be documented before any contract is signed. The documentation is also useful if your municipality’s IT security team or privacy officer reviews the deployment.
For more on how permit analytics supports municipal reporting, see our posts on Housing Accelerator Fund reporting requirements and permit approval-speed benchmarking across BC municipalities. You can also find permit analytics information in our foundational post on municipal permit analytics in Canada.
Steller is built for BC planning departments: Canadian data residency, FIPPA-aligned data handling, and permit analytics that stay in your jurisdiction. Talk to procurement.