GraphWarden and PIPEDA: how the proxy supports your compliance obligations

PIPEDA imposes on Canadian private-sector organizations ten Fair Information Principles covering the collection, use, and disclosure of personal information in the course of commercial activities. GraphWarden helps meet several of these principles by centralizing access control to Microsoft Graph, minimizing the data returned, and producing a verifiable audit log. This document maps each of the ten principles to GraphWarden's capabilities, with explicit limits.

Who this document is for

- An organization subject to PIPEDA (federal private sector, or operating outside Alberta, British Columbia, and Quebec) - A personal information protection policy in place - Access to the GraphWarden admin application and to your Azure Key Vault - Intended readers: privacy officer, CISO, legal and compliance team

PIPEDA context

PIPEDA — the Personal Information Protection and Electronic Documents Act — was enacted by the Parliament of Canada in 2000 and governs how private-sector organizations handle personal information during commercial activities. It rests on ten Fair Information Principles drawn from the Canadian Standards Association's Model Code for the Protection of Personal Information, incorporated as Schedule 1 of the Act. The Office of the Privacy Commissioner of Canada (OPC) oversees enforcement, receives complaints, and publishes guidance.

An interprovincial framework applies: PIPEDA does not cover Quebec (Loi 25), Alberta (PIPA), or British Columbia (PIPA BC), which have enacted laws deemed substantially similar. Bill C-27 proposes a modernization of PIPEDA (Consumer Privacy Protection Act and Personal Information and Data Protection Tribunal); the obligations described here reflect the current regime independently of the ongoing legislative evolution.

PIPEDA mapping to GraphWarden capabilities

PIPEDA principle	GraphWarden capability	Status	Technical proof
Principle 1 — Accountability	Dedicated app identities per integrated system	Aligned	Every Graph-integrated application has its own GraphWarden app identity with a versioned YAML ruleset, making responsibilities traceable.
Principle 2 — Identifying Purposes	YAML rulesets documenting permitted endpoints	Aligned	Each app identity's ruleset explicitly documents the Graph endpoints and authorized fields, serving as a purpose-identification artifact.
Principle 3 — Consent	Not covered by GraphWarden	Not in scope	Obtaining consent from data subjects is an application-level concern, not a proxy concern.
Principle 4 — Limiting Collection	Response Filter transforms	Aligned	Configure a Response Filter to restrict the Graph fields returned to those strictly necessary, enforcing data minimization at the source.
Principle 5 — Limiting Use, Disclosure, and Retention	Endpoint blocking via ruleset	Aligned	Block at the ruleset level any Graph endpoint that exceeds the identified purposes.
Principle 6 — Accuracy	Not directly covered	Not in scope	Accuracy of personal information is an application and internal-process responsibility.
Principle 7 — Safeguards	Graph credentials held in your Azure Key Vault (zero-knowledge architecture)	Aligned	GraphWarden holds only a get permission on your Key Vault secrets; Graph credentials never transit through GraphWarden in clear form.
Principle 8 — Openness	Rulesets publishable internally	Supported	The YAML ruleset is a human-readable artifact usable in your internal openness policy.
Principle 9 — Individual Access	Not covered by GraphWarden	Not in scope	Handling access requests (PIPEDA Schedule 1, 4.9) is an application-level responsibility.
Principle 10 — Challenging Compliance	Audit log as technical evidence	Supported	The HMAC-authenticated audit log to your SIEM produces verifiable access evidence useful during an investigation by the OPC.

Concrete scenario

A Canadian insurer operates in 9 provinces (excluding Quebec) and integrates a SaaS human-resources system with Microsoft 365. Without GraphWarden, the SaaS vendor holds the Graph credentials and can query all tenant users. With GraphWarden, the SaaS app identity has a ruleset that limits access to members of the HR-Active group and to the displayName, mail, and jobTitle fields. During an OPC investigation (Principle 10), the insurer produces the YAML ruleset and the audit log as technical evidence of the access controls in place during the relevant window.

Hosting and data residency

Hosted tier: the proxy runtime is in Azure Canada Central; the control plane runs in Canada East (OVHCloud). On-premise tier (Windows Service or Docker): the proxy runs entirely in your infrastructure — no Graph data leaves your environment. Canada-based hosting keeps your data under Canadian jurisdiction, consistent with the PIPEDA operating perimeter. Graph secrets (client secrets, certificates) never leave your Azure Key Vault: GraphWarden holds only their SHA-256 fingerprint to authenticate calls from your applications.

Limits

GraphWarden helps meet several PIPEDA principles but does not cover the entire regime. The following items remain your responsibility.

GraphWarden does NOT cover consent (Principle 3) — that belongs to your application and business processes.
GraphWarden does NOT cover accuracy of personal information (Principle 6).
GraphWarden does NOT cover individual access to personal information by data subjects (Principle 9, PIPEDA Schedule 1, 4.9).
GraphWarden does NOT identify legitimate purposes on your behalf (Principle 2) — the proxy enforces your decision, it does not make it.
GraphWarden does NOT notify data subjects in case of a privacy breach — that process remains your responsibility.
GraphWarden does NOT replace your designated privacy officer (Principle 1).

Prepare your compliance brief with an AI assistant

Prepare a PIPEDA compliance brief

Prepare a PIPEDA compliance brief for my organization using GraphWarden with Microsoft 365.

I need to deliver to my committee:
1. For each of the 10 PIPEDA principles, what GraphWarden helps meet
2. For each principle, what remains under my responsibility
3. The technical artifacts I can extract (rulesets, audit logs)

Reference documentation: https://graphwarden.com/llms.txt

Ask me:
- My province of operation (PIPEDA does not apply in Quebec / Alberta / British Columbia)
- How many Graph-integrated applications I have
- Whether I already have a personal information protection policy

Reference: llms.txt

Troubleshooting

My organization operates in Quebec — does PIPEDA apply? No, Loi 25 applies; see /en/compliance/loi-25.
The OPC asks me for a 12-month access log. See the /audit endpoint in Agent API and configure a periodic export to your archive.
How do I demonstrate that my ruleset meets Principle 4 (limiting collection)? Export the ruleset YAML and attach it as an appendix to the compliance brief.
I am receiving data I did not request. Review the Response Filter in the ruleset; see Rulesets and Rules.
How do I isolate calls from a compromised application? Filter the audit log by app identity and by the incident window; see App Identities.

Resources

For deployment, see On-Premise Windows Installation.
For app identities, see App Identities.
For the proxy trust model, see Trust Model.
Data Processing Agreement (DPA) template — coming in Phase 5b .

Next steps

For a demo tailored to your PIPEDA deployment, contact the GraphWarden team. Review the use cases to see how other Canadian private-sector organizations have documented their Fair Information Principles via rulesets. Bring to the session: your province of operation, your list of Graph-integrated applications, and the desired audit retention tier (90 days, 1 year, or 7 years).

Last reviewed: April 19, 2026