Privacy Impact Assessments for Cloud and AI Projects in BC: What Your Privacy Officer Needs From IT
A privacy impact assessment for a BC cloud or AI project needs answers, not diagrams. The questions a FIPPA or PIPA PIA asks and the Azure evidence IT brings.
Techrupt Team7 min read

A privacy impact assessment (PIA) for an Azure, Microsoft 365 or AI project asks IT for six things: what personal information the system holds and whose it is, where it is stored and processed, who can reach it (including Microsoft), how long it is kept, what security protects it, and what any AI component does with it. The privacy officer writes the assessment. IT’s job is to answer those questions in plain language and back each answer with evidence from the tenant.
PIAs stall when IT sends an architecture diagram and a link to Microsoft’s trust documentation, and the privacy office sends back questions the diagram does not answer. Below are those questions in the order a BC PIA asks them, and the evidence to export for each.
This article describes our consulting approach. It is not legal advice. Confirm your obligations with your privacy officer or legal counsel.
When a PIA is required in BC
Public bodies under FIPPA. Section 69 of the Freedom of Information and Protection of Privacy Act requires the head of every ministry (subsection 5) and every other public body (subsection 5.3) to conduct a PIA in accordance with the minister’s directions (FIPPA Part 6, BC Laws). The Act defines a PIA as an assessment of whether a system, project, program or activity meets the privacy requirements in Part 3, so a new Azure workload or Copilot rollout qualifies. The province publishes separate directions for ministries and other public bodies.
The supplementary assessment for storage outside Canada. Since the 2021 amendments, a public body may disclose personal information outside Canada only in accordance with the regulations (section 33.1). The Personal Information Disclosure for Storage Outside of Canada Regulation, B.C. Reg. 294/2021, requires the head of a public body to assess every program, project or system in which sensitive personal information is disclosed to be stored outside Canada, and to do it inside the section 69 PIA (BC Laws). We covered the background in Canadian data residency on Azure under FIPPA and PIPA.
Private organizations under PIPA. BC’s Personal Information Protection Act has no statutory PIA requirement. The Commissioner’s office says so directly in its private-sector guidance, and still calls PIAs a best practice that demonstrates due diligence, to be completed whenever an initiative is new or substantively changed (OIPC BC, PIAs for the private sector). A private organization serving a public body will usually be asked for PIA inputs by that client anyway.
What the privacy officer needs from IT
What personal information, and whose
Start with an inventory, not a diagram. For each data store, list the categories of personal information, whose it is (staff, clients, the public) and where it comes from. Flag anything sensitive, because sensitive personal information stored outside Canada triggers the supplementary assessment for public bodies.
Free text is the item IT most often forgets: case notes, Teams channels and AI chat logs collect personal information nobody planned for.
Where it is stored and where it is processed
A PIA needs two answers here: where data sits at rest, and where it is processed in use. For AI services they can differ.
For Azure, name the region of every resource and show the Allowed locations policy that keeps them there. For Microsoft 365, the data location card in the admin center shows the current and committed geography for Exchange, SharePoint, OneDrive, Teams and Microsoft 365 Copilot (Microsoft Learn). Then list what sits outside those controls: Microsoft Entra ID, edge caching services, geo-replicated databases, and every AI deployment. If anything sensitive leaves Canada, the public body’s supplementary assessment applies.
Who can access it, including the vendor
For your own staff, export role assignments, SharePoint site permissions and group memberships, and show how access is reviewed. For Microsoft staff, point to Customer Lockbox. With it on, Microsoft engineers need your approval before accessing customer content in Microsoft 365 and in supported Azure services, including Storage, Azure SQL and Azure OpenAI (Customer Lockbox for Microsoft Azure). The Azure version needs a Developer support plan or higher; the Microsoft 365 version comes with E5-level licences.
For Copilot projects this matters most, because Copilot surfaces whatever users can already open. That is why cleaning up SharePoint oversharing before Copilot belongs in the PIA’s risk mitigation section.
How long it is kept and how it is deleted
Both Acts set a floor: if personal information is used to make a decision that directly affects someone, it must be kept at least one year after that use (FIPPA section 31, PIPA section 35). PIPA also requires disposal once the purpose and any legal or business need have ended.
List every place the data persists (primary store, backups, logs, replicas, AI conversation history) with its configured retention and how deletion works. Log Analytics tables default to 30 or 90 days of analytics retention and can be kept for up to 12 years (Microsoft Learn). Microsoft 365 Copilot prompts and responses are governed by Microsoft Purview retention policies using the Microsoft Copilot experiences location (Microsoft Learn).
What security arrangements protect it
FIPPA section 30 and PIPA section 34 both require “reasonable security arrangements” against risks such as unauthorized access, collection, use, disclosure or disposal. The PIA needs the controls that apply to this data, not your whole security architecture: encryption and who holds the keys, network exposure, MFA and Conditional Access, logging, and who reviews alerts. Diagnostic settings pointing at a monitored workspace are better evidence than a statement that logging is on.
What the AI component does with the data
AI projects add questions a standard PIA template does not ask:
- Are prompts and responses stored? Stateless inference does not store them in the model. Features such as the Responses API, Assistants threads, stored completions and uploaded files do store data, at rest in the Foundry resource’s geography, and you can delete it (Microsoft Learn, data privacy for Foundry models).
- Where is inference processed? Standard and Regional Provisioned deployments process prompts within the resource’s Azure geography. Data Zone deployments process within a Microsoft-defined zone, currently the US, EU or Asia Pacific, and none of them is Canada. Global deployments may process in any region where the model runs (deployment types). New models usually arrive as Global first, and regional versions have no guaranteed date.
- Is the data used for training? For models sold by Azure in Microsoft Foundry, including Azure OpenAI, Microsoft states that prompts, completions and training data are not used to train foundation models without your permission and are not available to OpenAI.
- Can a human at Microsoft see it? By default, content flagged by abuse monitoring can be stored and, where automated review is not enough, reviewed by authorized Microsoft employees. Customers who meet Limited Access criteria can apply for modified abuse monitoring, which removes that storage and human review (abuse monitoring). If you were approved, the resource shows a ContentLogging capability set to false.
- For Microsoft 365 Copilot, prompts and responses are stored at rest under Microsoft 365’s data residency commitments, but Microsoft says customers outside the EU may have queries processed in the US, EU or other regions (Microsoft Learn). That is a processing flow the PIA should name. Microsoft plans in-country processing of Copilot interactions for Canada in 2027; until it arrives, name the flow.
Agents act on data as well as read it. Our agentic AI readiness checklist covers the identity and oversight questions to add.
PIA questions and the evidence IT can produce
We give project teams this table at the start of a PIA. Each row is an artifact to export, not describe.
| PIA question | Evidence from Azure or Microsoft 365 | Where to get it |
|---|---|---|
| Where is the data stored? | Allowed locations assignment and compliance state | Azure Policy, at management group scope |
| Where is Microsoft 365 data stored? | Current and committed geography per service | Microsoft 365 admin center, Settings, Org settings, Organization profile, Data location |
| Where is AI inference processed? | List of model deployments with SKU name (Standard, DataZoneStandard, GlobalStandard) | Foundry portal or az cognitiveservices account deployment list |
| Is Global processing blocked? | Custom policy denying deployment SKUs | Azure Policy, from the deployment types documentation |
| Who has access? | Role assignments, group memberships, site permissions | Azure RBAC, Microsoft Entra ID, SharePoint admin center |
| Is access reviewed? | Completed access review history | Microsoft Entra ID Governance access reviews (P2 or Governance licence) |
| Can Microsoft staff access it? | Customer Lockbox enabled, request history | Azure portal Customer Lockbox, Microsoft 365 admin center |
| How long is it kept? | Retention settings per store, table and policy | Log Analytics table settings, backup policies, Purview retention policies |
| Is sensitive data identified? | Sensitivity labels and classification results | Microsoft Purview |
| Is activity logged? | Diagnostic settings and destination workspace | Azure Monitor diagnostic settings |
| Is human review by Microsoft off? | ContentLogging set to false on the resource | Resource JSON view or az cognitiveservices account show |
| Does anything leave Canada? | Data flow table naming non-regional services | Architecture review against the checklist below |
For the residency rows, our free Canadian Data Residency Checklist has the full set of checks and a template for documenting exceptions in a PIA.
Where to start
Do the inventory and the data flow table before the first PIA meeting. When answers arrive with evidence attached, the PIA moves in working sessions instead of rounds of questions. What we see most often is not a missing control. It is a control nobody can prove is on, such as a Global AI deployment under a Canadian resource or a Lockbox setting nobody checked.
Techrupt prepares this evidence for BC public bodies and private organizations as part of our Azure consulting in Vancouver. If you have a PIA waiting on IT, book a consultation and we will work through the table with your team.



